Running linux with kernel 2.6.3* (2.6.32-rc6, for example) on a couple of i386 boxes and an amd64 box, I cannot format floppies or do any low level operations like dd direct to /dev/fd0. I can read and write to floppies already containing file systems. This is on debian testing, although I doubt if that is relevant. I can format floppies under a 2.4.* kernel on an old i386 running an ancient redhat release. I have found no similar reports of such problems, but perhaps not many people still use floppies. fdformat (I realize that is not part of fdutils), gfloppy (ditto) and superformat all fail. (Once gfloppy seemed to have succeeded, but I was not able to replicate that success.) CRC errors are logged to /var/log/messages. More details including strace on superformat are here:- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434 Can anyone help or suggest how to investigate further? Can people here format floppies under 2.6.3* kernels? Thanks in advance for any help, ael
ael wrote:
Running linux with kernel 2.6.3* (2.6.32-rc6, for example) on a couple of i386 boxes and an amd64 box, I cannot format floppies or do any low level operations like dd direct to /dev/fd0.
I just checked with kernel 2.6.32-rc6, and both superformat and fdformat still work. The resulting floppy can then be read and written to using dd.
I can read and write to floppies already containing file systems.
Formatting a floppy has nothing to do with putting a filesystem there.
This is on debian testing, although I doubt if that is relevant.
I tested on kubuntu 9.04 . However, as the kernel is the same, this would point to the problem being elsewhere than the kernel. I tried both with fdutils 5.5-20060227-3 (the default supplied in kubuntu 9.04) and with my newest (20081027). Both work. Could it be that testing supplied a bad /etc/driveprm file (or /usr/local/etc/driveprm)? Try removing it (in which case superformat will try to find out its contents dynamically)
I can format floppies under a 2.4.* kernel on an old i386 running an ancient redhat release.
I have found no similar reports of such problems, but perhaps not many people still use floppies.
You may have a point there :-) Even myself I am rarely using them (mostly only for investigating bug reports, such as this one)
fdformat (I realize that is not part of fdutils), gfloppy (ditto) and superformat all fail. (Once gfloppy seemed to have succeeded, but I was not able to replicate that success.) CRC errors are logged to /var/log/messages.
More details including strace on superformat are here:- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434
Can anyone help or suggest how to investigate further?
I would suspect a hardware problem. Could you try it (with same kernel and fdutils) on a different physical computer? Use different floppy disks (they do become bad with time...) Also, maybe using a more stable version of debian might help? (just in case some component which is neither the kernel nor fdutils interferes with it)
Can people here format floppies under 2.6.3* kernels?
Yes, just tried it here.
Thanks in advance for any help,
ael
Regards, Alain
Alain Knaff wrote:
I would suspect a hardware problem. Could you try it (with same kernel and fdutils) on a different physical computer? Use different floppy disks (they do become bad with time...)
For the list - Alain and I are talking on the debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434 - I get the same problems on 3 different debian testing machines. Media problems have been eliminated, I believe. Likewise floppy drives.
Also, maybe using a more stable version of debian might help? (just in case some component which is neither the kernel nor fdutils interferes with it)
It used to work under testing, but it was a long time ago since I last formatted a floppy on these machines. It works on an old redhat system here, on Gentoo (member of local LUG), and now Alain has success on ubuntu. ael
On 12/03/2009 12:08 PM, A.E.Lawrence wrote:
Alain Knaff wrote:
I would suspect a hardware problem. Could you try it (with same kernel and fdutils) on a different physical computer? Use different floppy disks (they do become bad with time...)
For the list - Alain and I are talking on the debian bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434 - I get the same problems on 3 different debian testing machines. Media problems have been eliminated, I believe. Likewise floppy drives.
Also, maybe using a more stable version of debian might help? (just in case some component which is neither the kernel nor fdutils interferes with it)
It used to work under testing, but it was a long time ago since I last formatted a floppy on these machines. It works on an old redhat system here, on Gentoo (member of local LUG), and now Alain has success on ubuntu.
ael
I just reported a similar problem to LKML and sent a copy of it to you Alain just yesterday. Here it the text of the report. LKML Quote: I have many boxes. They all do the same thing. Running different versions of SuSE, 10.3-11.2. Any kernel at or above 2.6.28 fails to fdformat a floppy. These same machines, using the same floppies and drives, running kernels older than 2.6.28 work just fine. I googled and found other such reports but no solution. I know better than to just assume it's a kernel bug but it sure looks like it could be so I'm inquiring about it here. # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048 dmesg from 2.6.32: Dec 10 14:24:21 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 10 14:24:21 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 10 14:24:23 harley kernel: end_request: I/O error, dev fd0, sector 72 Dec 10 14:24:23 harley kernel: Buffer I/O error on device fd0, logical block 9 Dec 10 14:24:26 harley kernel: end_request: I/O error, dev fd0, sector 117 Dec 10 14:24:26 harley kernel: Buffer I/O error on device fd0, logical block 14 Dec 10 14:24:28 harley kernel: end_request: I/O error, dev fd0, sector 127 Dec 10 14:24:28 harley kernel: Buffer I/O error on device fd0, logical block 15 Dec 10 14:24:30 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 10 14:24:30 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 10 14:24:32 harley kernel: end_request: I/O error, dev fd0, sector 144 Dec 10 14:24:32 harley kernel: Buffer I/O error on device fd0, logical block 18 Dec 10 14:24:34 harley kernel: end_request: I/O error, dev fd0, sector 189 Dec 10 14:24:34 harley kernel: Buffer I/O error on device fd0, logical block 23 Dec 10 14:24:36 harley kernel: end_request: I/O error, dev fd0, sector 216 Dec 10 14:24:36 harley kernel: Buffer I/O error on device fd0, logical block 27 Dec 10 14:24:39 harley kernel: end_request: I/O error, dev fd0, sector 261 Dec 10 14:24:39 harley kernel: Buffer I/O error on device fd0, logical block 32 Dec 10 14:24:41 harley kernel: end_request: I/O error, dev fd0, sector 288 Dec 10 14:24:41 harley kernel: Buffer I/O error on device fd0, logical block 36 Dec 10 14:24:43 harley kernel: end_request: I/O error, dev fd0, sector 333 Dec 10 14:24:43 harley kernel: Buffer I/O error on device fd0, logical block 41 Dec 10 14:24:45 harley kernel: end_request: I/O error, dev fd0, sector 360 Dec 10 14:24:45 harley kernel: Buffer I/O error on device fd0, logical block 45 # rpm -qf /usr/sbin/fdformat util-linux-2.16-4.5.1.i586 Again, on this very machine, running 2.6.27.41 all is fine.... End LMKL Quote: Like I said, I have at least 6 machines that exhibit this anomaly. I'm convinced its a kernel bug. All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT. I really need this resolved as we do use floppies and will continue to for some time. Thanks Mark
On 12/11/2009 03:31 PM, Mark Hounschell wrote:
Like I said, I have at least 6 machines that exhibit this anomaly. I'm convinced its a kernel bug. All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
I really need this resolved as we do use floppies and will continue to for some time.
Oh yea, anything I can to do help get to the bottom of it, I will. Mark
Mark Hounschell wrote:
On 12/03/2009 12:08 PM, A.E.Lawrence wrote:
here, on Gentoo (member of local LUG), and now Alain has success on ubuntu.
But the above tests on Gentoo and Ubuntu were on later kernels...
Like I said, I have at least 6 machines that exhibit this anomaly. I'm convinced its a kernel bug. All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
Maybe the later kernels are implicated in some way, but it isn't anything straightforward, I think. ael
Mark Hounschell wrote: [...]
All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
2.6.28 was when support for sector "bases" other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the "stretch" parameter. Could it be that on some distributions, "something" is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base). Could you try to: fdformat /dev/fd0u1440 in case you don't have /dev/fd0u1440, you can create it using the following command line: mknod /dev/fd0u1440 b 2 28 then do a getfdprm -o /dev/fd0u1440 (or getfdprm /dev/fd0) You should get: 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c The fifth byte (0 here) is the stretch byte. If it contains anything other than 0, this might explain it. Another test would be to perform: fdrawcmd readid 0 repeat=18 on the drive. This gets 18 sector headers, normally you should see all numbers from 1 to 18 as the sector id (byte: 5), but not necessarily in that order. If you see a different range (for instance, from 3 to 20), this might be the explanation. Also, could you try superformat instead of fdformat: superformat /dev/fd0 1440/1440 Regards, Alain
On 12/13/2009 01:45 PM, Alain Knaff wrote:
Mark Hounschell wrote: [...]
All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
2.6.28 was when support for sector "bases" other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the "stretch" parameter.
Could it be that on some distributions, "something" is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base).
Could you try to:
fdformat /dev/fd0u1440
in case you don't have /dev/fd0u1440, you can create it using the following command line:
mknod /dev/fd0u1440 b 2 28
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048
then do a getfdprm -o /dev/fd0u1440 (or getfdprm /dev/fd0)
You should get:
2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
The fifth byte (0 here) is the stretch byte. If it contains anything other than 0, this might explain it.
# getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
Another test would be to perform:
fdrawcmd readid 0 repeat=18
on the drive. This gets 18 sector headers, normally you should see all numbers from 1 to 18 as the sector id (byte: 5), but not necessarily in that order. If you see a different range (for instance, from 3 to 20), this might be the explanation.
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: a 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 9 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: a 4: 0 5: a 6: 2 no disk change
Also, could you try superformat instead of fdformat:
superformat /dev/fd0 1440/1440
# superformat /dev/fd0 hd sect=18 Measuring drive 0's raw capacity In order to avoid this time consuming measurement in the future, add the following line to /etc/driveprm: drive0: deviation=-1040 CAUTION: The line is drive and controller specific, so it should be removed before installing a new drive 0 or floppy controller. Verifying cylinder 79, head 1 mformat -s18 -t80 -h2 -S2 -M512 a: Regards Mark
Mark Hounschell wrote:
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: a 4: 0 5: b 6: 2 no disk change
To save others the bother of checking, the "5:" byte runs through 1 to 18 inclusive with no duplicates. $ show -noshow | > awk '$1 == "5:" {print strtonum("0x" $2)}' | > sort -n | > diff <(seq 1 18) - $ Cheers, Ralph.
On 14/12/09 10:51, Ralph Corderoy wrote:
Mark Hounschell wrote:
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: a 4: 0 5: b 6: 2 no disk change
To save others the bother of checking, the "5:" byte runs through 1 to 18 inclusive with no duplicates.
$ show -noshow | > awk '$1 == "5:" {print strtonum("0x" $2)}' | > sort -n | > diff <(seq 1 18) - $
Cheers,
Ralph.
Checking it was still useful however, because sector one had a bad track (9, instead of a like all the others). That could probably be the reason... now we must only find out _why_ this happens. It would also be useful to find out whether this is the case on all tracks, and if it is always sector 0 that is mis-located. Mark: the 2.6.28 kernel, is it a kernel directly downloaded from ftp.kernel.org, or a kernel supplied by your distribution? Sometimes distros do introduce weird local patches... Regards, Alain
On 12/14/2009 05:04 AM, Alain Knaff wrote:
On 14/12/09 10:51, Ralph Corderoy wrote:
Mark Hounschell wrote:
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: a 4: 0 5: b 6: 2 no disk change
To save others the bother of checking, the "5:" byte runs through 1 to 18 inclusive with no duplicates.
$ show -noshow | > awk '$1 == "5:" {print strtonum("0x" $2)}' | > sort -n | > diff <(seq 1 18) - $
Cheers,
Ralph.
Checking it was still useful however, because sector one had a bad track (9, instead of a like all the others). That could probably be the reason... now we must only find out _why_ this happens.
It would also be useful to find out whether this is the case on all tracks, and if it is always sector 0 that is mis-located.
Mark: the 2.6.28 kernel, is it a kernel directly downloaded from ftp.kernel.org, or a kernel supplied by your distribution? Sometimes distros do introduce weird local patches...
The above was actually on a vanilla 2.6.32 kernel. Would you like me to do the same on a vanilla 2.6.28 kernel? Mark
Alain Knaff wrote:
On 14/12/09 11:18, Mark Hounschell wrote:
The above was actually on a vanilla 2.6.32 kernel. Would you like me to do the same on a vanilla 2.6.28 kernel?
Yes please
2.6.28 vanilla: # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048 fdrawcmd readid 0 repeat=18 raw cmd: Input/output error ???? I retried the format and readid multiple times with the same result. Just for the sake of it I also did it on the same machine running 2.6.27.41 vanilla. 2.6.27.41 vanilla: # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done # getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 4f 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: a 6: 2 no disk change Mark
Mark Hounschell wrote:
Alain Knaff wrote:
On 14/12/09 11:18, Mark Hounschell wrote:
The above was actually on a vanilla 2.6.32 kernel. Would you like me to do the same on a vanilla 2.6.28 kernel? Yes please
2.6.28 vanilla:
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048
fdrawcmd readid 0 repeat=18 raw cmd: Input/output error
????
I retried the format and readid multiple times with the same result.
Just for the sake of it I also did it on the same machine running 2.6.27.41 vanilla.
2.6.27.41 vanilla:
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
# getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 4f 4: 0 5: b 6: 2 no disk change [...]
This sector header sequence looks normal... but if I understand correctly this was done after reformatting the disk on a "working" kernel (i.e. 2.6.27.41) It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28) So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd . Thanks, Alain
Alain Knaff wrote:
It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28)
So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd .
OK, fdformat using 2.6.28 (verify failed as usual). Here is the readid from 2.6.27.41. Looks ok to me. # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 0 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: b 6: 2 no disk change Mark
Mark Hounschell wrote:
Alain Knaff wrote:
It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28)
So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd .
OK, fdformat using 2.6.28 (verify failed as usual). Here is the readid from 2.6.27.41. Looks ok to me.
Indeed, this looks ok. All sector ids present, and no odd track number. Could you check some of the other tracks (use fdrawcmd seek 0 x to seek to track x) Can you read from that disk on 2.6.28 using dd? Regards, Alain
Alain Knaff wrote:
Mark Hounschell wrote:
Alain Knaff wrote:
It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28)
So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd .
Just to say that I can't easily get back to 2.6.27.* under debian testing: too much has changed. So I can't check to see if I see the same sort of results as Mark here. I could maybe try on my very old 2.4.* redhat box (not sure if it has fdrawcmd) if it would be useful to have more data points or confirmation. But that would have to be tomorrow now. ael
On 12/14/2009 04:03 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Alain Knaff wrote:
It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28)
So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd .
OK, fdformat using 2.6.28 (verify failed as usual). Here is the readid from 2.6.27.41. Looks ok to me.
Indeed, this looks ok. All sector ids present, and no odd track number.
Could you check some of the other tracks (use fdrawcmd seek 0 x to seek to track x)
Can you read from that disk on 2.6.28 using dd?
It would appear not: # dd if=/dev/fd0 of=/dev/null bs=512 dd: reading `/dev/fd0': Input/output error 40+0 records in 40+0 records out 20480 bytes (20 kB) copied, 14.9865 s, 1.4 kB/s dmesg shows Dec 14 16:11:09 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 14 16:11:09 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 14 16:11:11 harley kernel: end_request: I/O error, dev fd0, sector 72 Dec 14 16:11:11 harley kernel: Buffer I/O error on device fd0, logical block 9 Dec 14 16:11:14 harley kernel: end_request: I/O error, dev fd0, sector 117 Dec 14 16:11:14 harley kernel: Buffer I/O error on device fd0, logical block 14 Dec 14 16:11:16 harley kernel: end_request: I/O error, dev fd0, sector 144 Dec 14 16:11:16 harley kernel: Buffer I/O error on device fd0, logical block 18 Dec 14 16:11:18 harley kernel: end_request: I/O error, dev fd0, sector 189 Dec 14 16:11:18 harley kernel: Buffer I/O error on device fd0, logical block 23 Dec 14 16:11:20 harley kernel: end_request: I/O error, dev fd0, sector 216 Dec 14 16:11:20 harley kernel: Buffer I/O error on device fd0, logical block 27 Dec 14 16:11:22 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 14 16:11:22 harley kernel: Buffer I/O error on device fd0, logical block But I then tried the dd on 2.6.27.41 with the same disk and it did the same thing as above. I then reformatted it on 2.6.27.41 and the dd went well on both 2.6.27.41 and 2.6.28 ??? # dd if=/dev/fd0 of=/dev/null bs=512 2880+0 records in 2880+0 records out 1474560 bytes (1.5 MB) copied, 40.3691 s, 36.5 kB/s Why does byte 3 of "fdrawcmd readid 0 repeat=18" always show 4f with a disk formatted on 2.6.27.41 and something else on 2.6.28+ ??? Mark
Mark Hounschell wrote:
On 12/14/2009 04:03 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Alain Knaff wrote:
It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28)
So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd .
OK, fdformat using 2.6.28 (verify failed as usual). Here is the readid from 2.6.27.41. Looks ok to me. Indeed, this looks ok. All sector ids present, and no odd track number.
ok, so that was track 0...
Could you check some of the other tracks (use fdrawcmd seek 0 x to seek to track x)
it would really be helpful to see more tracks (not necessarily all 80 of them, but number 1 would definitely be helpful, see below)
Can you read from that disk on 2.6.28 using dd?
It would appear not:
# dd if=/dev/fd0 of=/dev/null bs=512 dd: reading `/dev/fd0': Input/output error 40+0 records in 40+0 records out 20480 bytes (20 kB) copied, 14.9865 s, 1.4 kB/s
dmesg shows
Dec 14 16:11:09 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 14 16:11:09 harley kernel: Buffer I/O error on device fd0, logical block 5
ok, so you apparently have an error on track 1. Could you please have a look at the headers on track 1? Other errors are on 72 (track 2), 117 (track 3), 144 (track 4), ... It's interesting also that this is always sector 1 or 10 (0xa) of the track... [...]
But I then tried the dd on 2.6.27.41 with the same disk and it did the same thing as above.
I then reformatted it on 2.6.27.41 and the dd went well on both 2.6.27.41 and 2.6.28 ???
# dd if=/dev/fd0 of=/dev/null bs=512 2880+0 records in 2880+0 records out 1474560 bytes (1.5 MB) copied, 40.3691 s, 36.5 kB/s
Why does byte 3 of "fdrawcmd readid 0 repeat=18" always show 4f with a disk formatted on 2.6.27.41 and something else on 2.6.28+ ???
Always? I don't believe that the track id is _always_ 0x4f on 2.6.27.41 . Else the disk would not be readable.
Mark
Alain
On 12/14/2009 05:23 PM, Alain Knaff wrote:
Mark Hounschell wrote:
On 12/14/2009 04:03 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Alain Knaff wrote:
It would be more interesting to perform this on a disk formatted on a "broken" kernel (2.6.28)
So you boot into 2.6.28, format the disk, then reboot into 2.6.27.41, and run the fdrawcmd .
OK, fdformat using 2.6.28 (verify failed as usual). Here is the readid from 2.6.27.41. Looks ok to me. Indeed, this looks ok. All sector ids present, and no odd track number.
ok, so that was track 0...
Could you check some of the other tracks (use fdrawcmd seek 0 x to seek to track x)
it would really be helpful to see more tracks (not necessarily all 80 of them, but number 1 would definitely be helpful, see below)
With the 2.6.28 fdformatted disk, on either 2.6.27.41 or 2.6.28, the fdrawcmd seek 0 1: # fdrawcmd seek 0 1 raw cmd: Input/output error And it seems no matter where I Seek to it does the same? So how can I show you those other tracks? Mark
On 15/12/09 10:40, Mark Hounschell wrote:
With the 2.6.28 fdformatted disk, on either 2.6.27.41 or 2.6.28, the fdrawcmd seek 0 1:
# fdrawcmd seek 0 1 raw cmd: Input/output error
And it seems no matter where I Seek to it does the same? So how can I show you those other tracks?
Mark
And what happens if you do a fdrawcmd recalibrate 0 first? Regards, Alain
On 15/12/09 10:56, Mark Hounschell wrote:
On 12/15/2009 04:47 AM, Alain Knaff wrote:
And what happens if you do a fdrawcmd recalibrate 0 first?
Regards,
Alain
# fdrawcmd seek 0 1 raw cmd: Input/output error
# fdrawcmd recalibrate 0 raw cmd: Input/output error
# fdrawcmd seek 0 1 raw cmd: Input/output error
Mark
Try floppycontrol --resetnow 0 If that doesn't help, rmmod the floppy driver, and insmod it again. And also, do any of these commands generate any kernel output (do check with dmesg) Regards, Alain
On 12/15/2009 05:16 AM, Alain Knaff wrote:
On 15/12/09 10:56, Mark Hounschell wrote:
On 12/15/2009 04:47 AM, Alain Knaff wrote:
And what happens if you do a fdrawcmd recalibrate 0 first?
Regards,
Alain
# fdrawcmd seek 0 1 raw cmd: Input/output error
# fdrawcmd recalibrate 0 raw cmd: Input/output error
# fdrawcmd seek 0 1 raw cmd: Input/output error
Mark
Try floppycontrol --resetnow 0
If that doesn't help, rmmod the floppy driver, and insmod it again.
And also, do any of these commands generate any kernel output (do check with dmesg)
Regards,
Alain
Ok that helped, but this looks OK to me: # floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd seek 0 1 0: 20 1: 1 no disk change # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change What other tracks would you like to see? BTW my floppy driver is not a module. It is built in. Mark
On 15/12/09 11:29, Mark Hounschell wrote: [...]
Ok that helped, but this looks OK to me:
# floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change
# fdrawcmd seek 0 1 0: 20 1: 1 no disk change
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change [...] 0: 0 1: 0 2: 0 3: 0 ^^^^^
Not really so ok, this should be 1, not 0
4: 0 5: a 6: 2 no disk change
So I think now we know what happens: for some reason, fdformat uses a wrong track number for one sector in the format (which is sometimes 1, sometimes 10) Now, we must only find out why... and why it only happens on some distributions.
What other tracks would you like to see? BTW my floppy driver is not a module. It is built in. Mark
Could you try setting it up as a module? This will be helpful in the next couple of days, in case we have to try out patches. Could you also send me your kernel .config file, just in case... Another thing worth try would be to check whether more recent kernels (such as 2.6.31 or 2.6.32) work better. I've got some report of a 2.6.31-rc5 failing, but it's not sure this is the exact same problem... Regards, Alain
On 12/15/2009 05:39 AM, Alain Knaff wrote:
0: 0 1: 0 2: 0 3: 0 ^^^^^
Not really so ok, this should be 1, not 0
4: 0 5: a 6: 2 no disk change
Oh yea, I missed that.
So I think now we know what happens: for some reason, fdformat uses a wrong track number for one sector in the format (which is sometimes 1, sometimes 10)
Now, we must only find out why... and why it only happens on some distributions.
What other tracks would you like to see? BTW my floppy driver is not a module. It is built in. Mark
Could you try setting it up as a module? This will be helpful in the next couple of days, in case we have to try out patches.
Could you also send me your kernel .config file, just in case...
Yes, first thing when I get into work this morning, I'll do both.
Another thing worth try would be to check whether more recent kernels (such as 2.6.31 or 2.6.32) work better. I've got some report of a 2.6.31-rc5 failing, but it's not sure this is the exact same problem...
Now that I see what we are looking at, I'll check it on 2.6.32 also after getting into work. Mark
Alain Knaff wrote:
Not really so ok, this should be 1, not 0
4: 0 5: a 6: 2 no disk change
So I think now we know what happens: for some reason, fdformat uses a wrong track number for one sector in the format (which is sometimes 1, sometimes 10)
Now, we must only find out why... and why it only happens on some distributions.
What other tracks would you like to see? BTW my floppy driver is not a module. It is built in. Mark
Could you try setting it up as a module? This will be helpful in the next couple of days, in case we have to try out patches.
Ok, my 2.6.27.41, 2.6.28, and 2.6.32 floppy drivers are now modules.
Could you also send me your kernel .config file, just in case...
Attached is the one I'm using for 2.6.28
Another thing worth try would be to check whether more recent kernels (such as 2.6.31 or 2.6.32) work better. I've got some report of a 2.6.31-rc5 failing, but it's not sure this is the exact same problem...
The same thing is seen using 2.6.32 # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Problem reading cylinder 1, expected 18432, read 2048 # floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd seek 0 1 0: 20 1: 1 no disk change harley:/home/markh/work # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 <----- 4: 0 5: a 6: 2 no disk change Mark # # Automatically generated make config: don't edit # Linux kernel version: 2.6.28 # Tue Dec 15 06:11:03 2009 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set # CONFIG_CGROUP_NS is not set # CONFIG_CGROUP_FREEZER is not set # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_GROUP_SCHED is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_PROC_PID_CPUSET=y CONFIG_RELAY=y CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y # CONFIG_MARKERS is not set CONFIG_OPROFILE=m # CONFIG_OPROFILE_IBS is not set CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_GENERIC_DMA_COHERENT=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y CONFIG_LBD=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_LSF=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_BLK_DEV_INTEGRITY is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # CONFIG_CLASSIC_RCU is not set # CONFIG_FREEZER is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_VSMP is not set # CONFIG_X86_RDC321X is not set CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_PARAVIRT_GUEST is not set # CONFIG_MEMTEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set CONFIG_MK8=y # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_GENERIC=y CONFIG_X86_CPU=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_X86_DEBUGCTLMSR=y CONFIG_CPU_SUP_INTEL=y CONFIG_CPU_SUP_CYRIX_32=y CONFIG_CPU_SUP_AMD=y CONFIG_CPU_SUP_CENTAUR_32=y CONFIG_CPU_SUP_TRANSMETA_32=y CONFIG_CPU_SUP_UMC_32=y # CONFIG_X86_DS is not set CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_DMI=y # CONFIG_IOMMU_HELPER is not set CONFIG_NR_CPUS=32 # CONFIG_SCHED_SMT is not set # CONFIG_SCHED_MC is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_RCU=y # CONFIG_RCU_TRACE is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=m CONFIG_MICROCODE_INTEL=y # CONFIG_MICROCODE_AMD is not set CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y # CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set # CONFIG_PHYS_ADDR_T_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y CONFIG_UNEVICTABLE_LRU=y CONFIG_HIGHPTE=y # CONFIG_X86_CHECK_BIOS_CORRUPTION is not set CONFIG_X86_RESERVE_LOW_64K=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_MTRR_SANITIZER is not set CONFIG_X86_PAT=y # CONFIG_EFI is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set # CONFIG_HZ_300 is not set CONFIG_HZ_1000=y CONFIG_HZ=1000 CONFIG_SCHED_HRTICK=y CONFIG_KEXEC=y CONFIG_CRASH_DUMP=y CONFIG_PHYSICAL_START=0x100000 CONFIG_RELOCATABLE=y CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y # CONFIG_COMPAT_VDSO is not set # CONFIG_CMDLINE_BOOL is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management and ACPI options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SUSPEND is not set # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set # CONFIG_ACPI_BUTTON is not set # CONFIG_ACPI_VIDEO is not set # CONFIG_ACPI_FAN is not set CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_HOTPLUG_CPU=y CONFIG_ACPI_THERMAL=m CONFIG_ACPI_WMI=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_CUSTOM_DSDT_FILE="" # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=2001 # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_CONTAINER=m # CONFIG_ACPI_SBS is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set # CONFIG_PCI_GOOLPC is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y CONFIG_PCIEPORTBUS=y CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_PCIEAER=y # CONFIG_PCIEASPM is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y CONFIG_ISA=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_SCx200=m CONFIG_SCx200HR_TIMER=m # CONFIG_OLPC is not set CONFIG_K8_NB=y CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m CONFIG_PCMCIA_LOAD_CIS=y CONFIG_PCMCIA_IOCTL=y CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m CONFIG_I82365=m CONFIG_TCIC=m CONFIG_PCMCIA_PROBE=y CONFIG_PCCARD_NONSTATIC=m CONFIG_HOTPLUG_PCI=m CONFIG_HOTPLUG_PCI_FAKE=m CONFIG_HOTPLUG_PCI_COMPAQ=m CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y CONFIG_HOTPLUG_PCI_IBM=m CONFIG_HOTPLUG_PCI_ACPI=m CONFIG_HOTPLUG_PCI_ACPI_IBM=m CONFIG_HOTPLUG_PCI_CPCI=y CONFIG_HOTPLUG_PCI_CPCI_ZT5550=m CONFIG_HOTPLUG_PCI_CPCI_GENERIC=m CONFIG_HOTPLUG_PCI_SHPC=m # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set CONFIG_HAVE_AOUT=y CONFIG_BINFMT_AOUT=m CONFIG_BINFMT_MISC=m CONFIG_HAVE_ATOMIC_IOMAP=y CONFIG_NET=y # # Networking options # CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=m # CONFIG_XFRM_SUB_POLICY is not set CONFIG_XFRM_MIGRATE=y # CONFIG_XFRM_STATISTICS is not set CONFIG_XFRM_IPCOMP=m CONFIG_NET_KEY=m CONFIG_NET_KEY_MIGRATE=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y # CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y CONFIG_INET_AH=m CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m CONFIG_INET_XFRM_MODE_BEET=m CONFIG_INET_LRO=m CONFIG_INET_DIAG=m CONFIG_INET_TCP_DIAG=m CONFIG_TCP_CONG_ADVANCED=y CONFIG_TCP_CONG_BIC=m CONFIG_TCP_CONG_CUBIC=m CONFIG_TCP_CONG_WESTWOOD=m CONFIG_TCP_CONG_HTCP=m CONFIG_TCP_CONG_HSTCP=m CONFIG_TCP_CONG_HYBLA=m CONFIG_TCP_CONG_VEGAS=m CONFIG_TCP_CONG_SCALABLE=m CONFIG_TCP_CONG_LP=m CONFIG_TCP_CONG_VENO=m CONFIG_TCP_CONG_YEAH=m CONFIG_TCP_CONG_ILLINOIS=m # CONFIG_DEFAULT_BIC is not set # CONFIG_DEFAULT_CUBIC is not set # CONFIG_DEFAULT_HTCP is not set # CONFIG_DEFAULT_VEGAS is not set # CONFIG_DEFAULT_WESTWOOD is not set CONFIG_DEFAULT_RENO=y CONFIG_DEFAULT_TCP_CONG="reno" # CONFIG_TCP_MD5SIG is not set CONFIG_IPV6=m CONFIG_IPV6_PRIVACY=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y # CONFIG_IPV6_OPTIMISTIC_DAD is not set CONFIG_INET6_AH=m CONFIG_INET6_ESP=m CONFIG_INET6_IPCOMP=m CONFIG_IPV6_MIP6=m CONFIG_INET6_XFRM_TUNNEL=m CONFIG_INET6_TUNNEL=m CONFIG_INET6_XFRM_MODE_TRANSPORT=m CONFIG_INET6_XFRM_MODE_TUNNEL=m CONFIG_INET6_XFRM_MODE_BEET=m CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=m CONFIG_IPV6_SIT=m CONFIG_IPV6_NDISC_NODETYPE=y CONFIG_IPV6_TUNNEL=m CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y # CONFIG_IPV6_MROUTE is not set # CONFIG_NETLABEL is not set CONFIG_NETWORK_SECMARK=y CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y CONFIG_BRIDGE_NETFILTER=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_SECMARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_DCCP=m CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_SCTP=m # CONFIG_NF_CT_PROTO_UDPLITE is not set CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SANE=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m # CONFIG_NETFILTER_TPROXY is not set CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m # CONFIG_NETFILTER_XT_TARGET_TRACE is not set CONFIG_NETFILTER_XT_TARGET_SECMARK=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m # CONFIG_NETFILTER_XT_MATCH_CONNLIMIT is not set CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m # CONFIG_NETFILTER_XT_MATCH_RECENT is not set CONFIG_NETFILTER_XT_MATCH_SCTP=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m # CONFIG_NETFILTER_XT_MATCH_TIME is not set # CONFIG_NETFILTER_XT_MATCH_U32 is not set CONFIG_IP_VS=m # CONFIG_IP_VS_IPV6 is not set # CONFIG_IP_VS_DEBUG is not set CONFIG_IP_VS_TAB_BITS=12 # # IPVS transport protocol load balancing support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y # # IPVS scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m CONFIG_IP_VS_NQ=m # # IPVS application helper # CONFIG_IP_VS_FTP=m # # IP: Netfilter Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set CONFIG_IP_NF_QUEUE=m CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_DCCP=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_SCTP=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_CLUSTERIP=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m # CONFIG_IP_NF_SECURITY is not set CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # IPv6: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV6=m CONFIG_IP6_NF_QUEUE=m CONFIG_IP6_NF_IPTABLES=m CONFIG_IP6_NF_MATCH_AH=m CONFIG_IP6_NF_MATCH_EUI64=m CONFIG_IP6_NF_MATCH_FRAG=m CONFIG_IP6_NF_MATCH_OPTS=m CONFIG_IP6_NF_MATCH_HL=m CONFIG_IP6_NF_MATCH_IPV6HEADER=m CONFIG_IP6_NF_MATCH_MH=m CONFIG_IP6_NF_MATCH_RT=m CONFIG_IP6_NF_TARGET_LOG=m CONFIG_IP6_NF_FILTER=m CONFIG_IP6_NF_TARGET_REJECT=m CONFIG_IP6_NF_MANGLE=m CONFIG_IP6_NF_TARGET_HL=m CONFIG_IP6_NF_RAW=m # CONFIG_IP6_NF_SECURITY is not set # # DECnet: Netfilter Configuration # CONFIG_DECNET_NF_GRABULATOR=m CONFIG_BRIDGE_NF_EBTABLES=m CONFIG_BRIDGE_EBT_BROUTE=m CONFIG_BRIDGE_EBT_T_FILTER=m CONFIG_BRIDGE_EBT_T_NAT=m CONFIG_BRIDGE_EBT_802_3=m CONFIG_BRIDGE_EBT_AMONG=m CONFIG_BRIDGE_EBT_ARP=m CONFIG_BRIDGE_EBT_IP=m # CONFIG_BRIDGE_EBT_IP6 is not set CONFIG_BRIDGE_EBT_LIMIT=m CONFIG_BRIDGE_EBT_MARK=m CONFIG_BRIDGE_EBT_PKTTYPE=m CONFIG_BRIDGE_EBT_STP=m CONFIG_BRIDGE_EBT_VLAN=m CONFIG_BRIDGE_EBT_ARPREPLY=m CONFIG_BRIDGE_EBT_DNAT=m CONFIG_BRIDGE_EBT_MARK_T=m CONFIG_BRIDGE_EBT_REDIRECT=m CONFIG_BRIDGE_EBT_SNAT=m CONFIG_BRIDGE_EBT_LOG=m CONFIG_BRIDGE_EBT_ULOG=m CONFIG_BRIDGE_EBT_NFLOG=m CONFIG_IP_DCCP=m CONFIG_INET_DCCP_DIAG=m CONFIG_IP_DCCP_ACKVEC=y # # DCCP CCIDs Configuration (EXPERIMENTAL) # CONFIG_IP_DCCP_CCID2=m # CONFIG_IP_DCCP_CCID2_DEBUG is not set CONFIG_IP_DCCP_CCID3=m # CONFIG_IP_DCCP_CCID3_DEBUG is not set CONFIG_IP_DCCP_CCID3_RTO=100 CONFIG_IP_DCCP_TFRC_LIB=m CONFIG_IP_SCTP=m # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set # CONFIG_SCTP_HMAC_SHA1 is not set CONFIG_SCTP_HMAC_MD5=y # CONFIG_TIPC is not set CONFIG_ATM=m CONFIG_ATM_CLIP=m CONFIG_ATM_CLIP_NO_ICMP=y CONFIG_ATM_LANE=m CONFIG_ATM_MPOA=m CONFIG_ATM_BR2684=m # CONFIG_ATM_BR2684_IPFILTER is not set CONFIG_STP=m CONFIG_BRIDGE=m # CONFIG_NET_DSA is not set CONFIG_VLAN_8021Q=m # CONFIG_VLAN_8021Q_GVRP is not set CONFIG_DECNET=m CONFIG_DECNET_ROUTER=y CONFIG_LLC=y CONFIG_LLC2=m CONFIG_IPX=m # CONFIG_IPX_INTERN is not set CONFIG_ATALK=m CONFIG_DEV_APPLETALK=m CONFIG_LTPC=m CONFIG_COPS=m CONFIG_COPS_DAYNA=y CONFIG_COPS_TANGENT=y CONFIG_IPDDP=m CONFIG_IPDDP_ENCAP=y CONFIG_IPDDP_DECAP=y CONFIG_X25=m CONFIG_LAPB=m CONFIG_ECONET=m # CONFIG_ECONET_AUNUDP is not set # CONFIG_ECONET_NATIVE is not set CONFIG_WAN_ROUTER=m CONFIG_NET_SCHED=y # # Queueing/Scheduling # CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_ATM=m CONFIG_NET_SCH_PRIO=m # CONFIG_NET_SCH_MULTIQ is not set CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_FLOW=m # CONFIG_NET_EMATCH is not set CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m # CONFIG_NET_ACT_NAT is not set CONFIG_NET_ACT_PEDIT=m CONFIG_NET_ACT_SIMP=m # CONFIG_NET_ACT_SKBEDIT is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_SCH_FIFO=y # # Network testing # CONFIG_NET_PKTGEN=m CONFIG_NET_TCPPROBE=m CONFIG_HAMRADIO=y # # Packet Radio protocols # CONFIG_AX25=m CONFIG_AX25_DAMA_SLAVE=y CONFIG_NETROM=m CONFIG_ROSE=m # # AX.25 network device drivers # CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_SCC=m CONFIG_SCC_DELAY=y CONFIG_SCC_TRXECHO=y CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_BAYCOM_EPP=m CONFIG_YAM=m CONFIG_CAN=m CONFIG_CAN_RAW=m CONFIG_CAN_BCM=m # # CAN Device Drivers # CONFIG_CAN_VCAN=m # CONFIG_CAN_DEBUG_DEVICES is not set CONFIG_IRDA=m # # IrDA protocols # CONFIG_IRLAN=m CONFIG_IRNET=m CONFIG_IRCOMM=m CONFIG_IRDA_ULTRA=y # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y # CONFIG_IRDA_FAST_RR is not set # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=m # # Dongle support # CONFIG_DONGLE=y CONFIG_ESI_DONGLE=m CONFIG_ACTISYS_DONGLE=m CONFIG_TEKRAM_DONGLE=m CONFIG_TOIM3232_DONGLE=m CONFIG_LITELINK_DONGLE=m CONFIG_MA600_DONGLE=m CONFIG_GIRBIL_DONGLE=m CONFIG_MCP2120_DONGLE=m CONFIG_OLD_BELKIN_DONGLE=m CONFIG_ACT200L_DONGLE=m CONFIG_KINGSUN_DONGLE=m # CONFIG_KSDAZZLE_DONGLE is not set # CONFIG_KS959_DONGLE is not set # # FIR device drivers # CONFIG_USB_IRDA=m CONFIG_SIGMATEL_FIR=m CONFIG_NSC_FIR=m CONFIG_WINBOND_FIR=m CONFIG_TOSHIBA_FIR=m CONFIG_SMC_IRCC_FIR=m CONFIG_ALI_FIR=m CONFIG_VLSI_FIR=m CONFIG_VIA_FIR=m CONFIG_MCS_FIR=m CONFIG_BT=m CONFIG_BT_L2CAP=m CONFIG_BT_SCO=m CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y CONFIG_BT_BNEP=m CONFIG_BT_BNEP_MC_FILTER=y CONFIG_BT_BNEP_PROTO_FILTER=y CONFIG_BT_HIDP=m # # Bluetooth device drivers # CONFIG_BT_HCIUSB=m CONFIG_BT_HCIUSB_SCO=y # CONFIG_BT_HCIBTUSB is not set # CONFIG_BT_HCIBTSDIO is not set CONFIG_BT_HCIUART=m CONFIG_BT_HCIUART_H4=y CONFIG_BT_HCIUART_BCSP=y # CONFIG_BT_HCIUART_LL is not set CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIDTL1=m CONFIG_BT_HCIBT3C=m CONFIG_BT_HCIBLUECARD=m CONFIG_BT_HCIBTUART=m CONFIG_BT_HCIVHCI=m CONFIG_AF_RXRPC=m # CONFIG_AF_RXRPC_DEBUG is not set CONFIG_RXKAD=m # CONFIG_PHONET is not set CONFIG_FIB_RULES=y CONFIG_WIRELESS=y CONFIG_CFG80211=m CONFIG_NL80211=y CONFIG_WIRELESS_OLD_REGULATORY=y CONFIG_WIRELESS_EXT=y CONFIG_WIRELESS_EXT_SYSFS=y CONFIG_MAC80211=m # # Rate control algorithm selection # CONFIG_MAC80211_RC_PID=y # CONFIG_MAC80211_RC_MINSTREL is not set CONFIG_MAC80211_RC_DEFAULT_PID=y # CONFIG_MAC80211_RC_DEFAULT_MINSTREL is not set CONFIG_MAC80211_RC_DEFAULT="pid" # CONFIG_MAC80211_MESH is not set CONFIG_MAC80211_LEDS=y CONFIG_MAC80211_DEBUGFS=y # CONFIG_MAC80211_DEBUG_MENU is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m CONFIG_RFKILL_LEDS=y # CONFIG_NET_9P is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" # CONFIG_STANDALONE is not set CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y CONFIG_MTD=m # CONFIG_MTD_DEBUG is not set CONFIG_MTD_CONCAT=m CONFIG_MTD_PARTITIONS=y CONFIG_MTD_REDBOOT_PARTS=m CONFIG_MTD_REDBOOT_DIRECTORY_BLOCK=-1 # CONFIG_MTD_REDBOOT_PARTS_UNALLOCATED is not set # CONFIG_MTD_REDBOOT_PARTS_READONLY is not set CONFIG_MTD_AR7_PARTS=m # # User Modules And Translation Layers # CONFIG_MTD_CHAR=m CONFIG_HAVE_MTD_OTP=y CONFIG_MTD_BLKDEVS=m CONFIG_MTD_BLOCK=m # CONFIG_MTD_BLOCK_RO is not set # CONFIG_FTL is not set # CONFIG_NFTL is not set # CONFIG_INFTL is not set CONFIG_RFD_FTL=m # CONFIG_SSFDC is not set # CONFIG_MTD_OOPS is not set # # RAM/ROM/Flash chip drivers # CONFIG_MTD_CFI=m CONFIG_MTD_JEDECPROBE=m CONFIG_MTD_GEN_PROBE=m CONFIG_MTD_CFI_ADV_OPTIONS=y CONFIG_MTD_CFI_NOSWAP=y # CONFIG_MTD_CFI_BE_BYTE_SWAP is not set # CONFIG_MTD_CFI_LE_BYTE_SWAP is not set # CONFIG_MTD_CFI_GEOMETRY is not set CONFIG_MTD_MAP_BANK_WIDTH_1=y CONFIG_MTD_MAP_BANK_WIDTH_2=y CONFIG_MTD_MAP_BANK_WIDTH_4=y # CONFIG_MTD_MAP_BANK_WIDTH_8 is not set # CONFIG_MTD_MAP_BANK_WIDTH_16 is not set # CONFIG_MTD_MAP_BANK_WIDTH_32 is not set CONFIG_MTD_CFI_I1=y CONFIG_MTD_CFI_I2=y # CONFIG_MTD_CFI_I4 is not set # CONFIG_MTD_CFI_I8 is not set # CONFIG_MTD_OTP is not set CONFIG_MTD_CFI_INTELEXT=m CONFIG_MTD_CFI_AMDSTD=m CONFIG_MTD_CFI_STAA=m CONFIG_MTD_CFI_UTIL=m # CONFIG_MTD_RAM is not set # CONFIG_MTD_ROM is not set CONFIG_MTD_ABSENT=m # # Mapping drivers for chip access # CONFIG_MTD_COMPLEX_MAPPINGS=y CONFIG_MTD_PHYSMAP=m CONFIG_MTD_PHYSMAP_START=0x8000000 CONFIG_MTD_PHYSMAP_LEN=0x4000000 CONFIG_MTD_PHYSMAP_BANKWIDTH=2 CONFIG_MTD_SC520CDP=m CONFIG_MTD_NETSC520=m CONFIG_MTD_TS5500=m CONFIG_MTD_SBC_GXX=m CONFIG_MTD_SCx200_DOCFLASH=m CONFIG_MTD_AMD76XROM=m CONFIG_MTD_ICHXROM=m CONFIG_MTD_ESB2ROM=m CONFIG_MTD_CK804XROM=m CONFIG_MTD_SCB2_FLASH=m CONFIG_MTD_NETtel=m CONFIG_MTD_DILNETPC=m CONFIG_MTD_DILNETPC_BOOTSIZE=0x80000 CONFIG_MTD_L440GX=m CONFIG_MTD_PCI=m # CONFIG_MTD_INTEL_VR_NOR is not set # CONFIG_MTD_PLATRAM is not set # # Self-contained MTD device drivers # CONFIG_MTD_PMC551=m CONFIG_MTD_PMC551_BUGFIX=y # CONFIG_MTD_PMC551_DEBUG is not set # CONFIG_MTD_DATAFLASH is not set # CONFIG_MTD_M25P80 is not set CONFIG_MTD_SLRAM=m CONFIG_MTD_PHRAM=m CONFIG_MTD_MTDRAM=m CONFIG_MTDRAM_TOTAL_SIZE=4096 CONFIG_MTDRAM_ERASE_SIZE=128 CONFIG_MTD_BLOCK2MTD=m # # Disk-On-Chip Device Drivers # CONFIG_MTD_DOC2000=m CONFIG_MTD_DOC2001=m CONFIG_MTD_DOC2001PLUS=m CONFIG_MTD_DOCPROBE=m CONFIG_MTD_DOCECC=m CONFIG_MTD_DOCPROBE_ADVANCED=y CONFIG_MTD_DOCPROBE_ADDRESS=0x0000 CONFIG_MTD_DOCPROBE_HIGH=y CONFIG_MTD_DOCPROBE_55AA=y CONFIG_MTD_NAND=m # CONFIG_MTD_NAND_VERIFY_WRITE is not set CONFIG_MTD_NAND_ECC_SMC=y # CONFIG_MTD_NAND_MUSEUM_IDS is not set CONFIG_MTD_NAND_IDS=m CONFIG_MTD_NAND_DISKONCHIP=m # CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADVANCED is not set CONFIG_MTD_NAND_DISKONCHIP_PROBE_ADDRESS=0 CONFIG_MTD_NAND_DISKONCHIP_BBTWRITE=y CONFIG_MTD_NAND_CAFE=m CONFIG_MTD_NAND_CS553X=m CONFIG_MTD_NAND_NANDSIM=m CONFIG_MTD_NAND_PLATFORM=m # CONFIG_MTD_ALAUDA is not set CONFIG_MTD_ONENAND=m # CONFIG_MTD_ONENAND_VERIFY_WRITE is not set CONFIG_MTD_ONENAND_OTP=y # CONFIG_MTD_ONENAND_2X_PROGRAM is not set # CONFIG_MTD_ONENAND_SIM is not set # # UBI - Unsorted block images # CONFIG_MTD_UBI=m CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_RESERVE=1 # CONFIG_MTD_UBI_GLUEBI is not set # # UBI debugging options # # CONFIG_MTD_UBI_DEBUG is not set CONFIG_PARPORT=m CONFIG_PARPORT_PC=m CONFIG_PARPORT_SERIAL=m CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y CONFIG_PARPORT_PC_PCMCIA=m # CONFIG_PARPORT_GSC is not set CONFIG_PARPORT_AX88796=m CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y CONFIG_PNP_DEBUG_MESSAGES=y # # Protocols # CONFIG_ISAPNP=y CONFIG_PNPBIOS=y CONFIG_PNPBIOS_PROC_FS=y CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=m CONFIG_BLK_DEV_XD=m CONFIG_PARIDE=m # # Parallel IDE high-level drivers # CONFIG_PARIDE_PD=m CONFIG_PARIDE_PCD=m CONFIG_PARIDE_PF=m CONFIG_PARIDE_PT=m CONFIG_PARIDE_PG=m # # Parallel IDE protocol modules # CONFIG_PARIDE_ATEN=m CONFIG_PARIDE_BPCK=m CONFIG_PARIDE_BPCK6=m CONFIG_PARIDE_COMM=m CONFIG_PARIDE_DSTR=m CONFIG_PARIDE_FIT2=m CONFIG_PARIDE_FIT3=m CONFIG_PARIDE_EPAT=m CONFIG_PARIDE_EPATC8=y CONFIG_PARIDE_EPIA=m CONFIG_PARIDE_FRIQ=m CONFIG_PARIDE_FRPW=m CONFIG_PARIDE_KBIC=m CONFIG_PARIDE_KTTI=m CONFIG_PARIDE_ON20=m CONFIG_PARIDE_ON26=m CONFIG_BLK_CPQ_DA=m CONFIG_BLK_CPQ_CISS_DA=m CONFIG_CISS_SCSI_TAPE=y CONFIG_BLK_DEV_DAC960=m CONFIG_BLK_DEV_UMEM=m # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=64000 # CONFIG_BLK_DEV_XIP is not set CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_CDROM_PKTCDVD_WCACHE=y CONFIG_ATA_OVER_ETH=m # CONFIG_BLK_DEV_HD is not set CONFIG_MISC_DEVICES=y CONFIG_IBM_ASM=m CONFIG_PHANTOM=m CONFIG_EEPROM_93CX6=m # CONFIG_SGI_IOC4 is not set CONFIG_TIFM_CORE=m CONFIG_TIFM_7XX1=m CONFIG_ACER_WMI=m CONFIG_ASUS_LAPTOP=m CONFIG_FUJITSU_LAPTOP=m # CONFIG_FUJITSU_LAPTOP_DEBUG is not set CONFIG_TC1100_WMI=m # CONFIG_HP_WMI is not set # CONFIG_ICS932S401 is not set CONFIG_MSI_LAPTOP=m # CONFIG_PANASONIC_LAPTOP is not set # CONFIG_COMPAL_LAPTOP is not set CONFIG_SONY_LAPTOP=m CONFIG_SONYPI_COMPAT=y CONFIG_THINKPAD_ACPI=m # CONFIG_THINKPAD_ACPI_DEBUG is not set CONFIG_THINKPAD_ACPI_BAY=y CONFIG_THINKPAD_ACPI_VIDEO=y CONFIG_THINKPAD_ACPI_HOTKEY_POLL=y # CONFIG_INTEL_MENLOW is not set CONFIG_EEEPC_LAPTOP=m CONFIG_ENCLOSURE_SERVICES=m # CONFIG_HP_ILO is not set # CONFIG_C2PORT is not set CONFIG_HAVE_IDE=y CONFIG_IDE=m # # Please see Documentation/ide/ide.txt for help/info on IDE drives # CONFIG_IDE_TIMINGS=y CONFIG_IDE_ATAPI=y # CONFIG_BLK_DEV_IDE_SATA is not set CONFIG_IDE_GD=m CONFIG_IDE_GD_ATA=y # CONFIG_IDE_GD_ATAPI is not set CONFIG_BLK_DEV_IDECS=m CONFIG_BLK_DEV_DELKIN=m CONFIG_BLK_DEV_IDECD=m CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y CONFIG_BLK_DEV_IDETAPE=m CONFIG_BLK_DEV_IDESCSI=m CONFIG_BLK_DEV_IDEACPI=y # CONFIG_IDE_TASK_IOCTL is not set CONFIG_IDE_PROC_FS=y # # IDE chipset support/bugfixes # CONFIG_IDE_GENERIC=m # CONFIG_BLK_DEV_PLATFORM is not set CONFIG_BLK_DEV_CMD640=m CONFIG_BLK_DEV_CMD640_ENHANCED=y CONFIG_BLK_DEV_IDEPNP=m CONFIG_BLK_DEV_IDEDMA_SFF=y # # PCI IDE chipsets support # CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_OFFBOARD=y CONFIG_BLK_DEV_GENERIC=m CONFIG_BLK_DEV_OPTI621=m CONFIG_BLK_DEV_RZ1000=m CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_BLK_DEV_AEC62XX=m CONFIG_BLK_DEV_ALI15X3=m CONFIG_BLK_DEV_AMD74XX=m CONFIG_BLK_DEV_ATIIXP=m CONFIG_BLK_DEV_CMD64X=m CONFIG_BLK_DEV_TRIFLEX=m CONFIG_BLK_DEV_CS5520=m CONFIG_BLK_DEV_CS5530=m CONFIG_BLK_DEV_CS5535=m CONFIG_BLK_DEV_HPT366=m CONFIG_BLK_DEV_JMICRON=m CONFIG_BLK_DEV_SC1200=m CONFIG_BLK_DEV_PIIX=m CONFIG_BLK_DEV_IT8213=m CONFIG_BLK_DEV_IT821X=m CONFIG_BLK_DEV_NS87415=m CONFIG_BLK_DEV_PDC202XX_OLD=m CONFIG_BLK_DEV_PDC202XX_NEW=m CONFIG_BLK_DEV_SVWKS=m CONFIG_BLK_DEV_SIIMAGE=m CONFIG_BLK_DEV_SIS5513=m CONFIG_BLK_DEV_SLC90E66=m CONFIG_BLK_DEV_TRM290=m CONFIG_BLK_DEV_VIA82CXXX=m # CONFIG_BLK_DEV_TC86C001 is not set # # Other IDE chipsets support # # # Note: most of these also require special kernel boot parameters # CONFIG_BLK_DEV_4DRIVES=m CONFIG_BLK_DEV_ALI14XX=m CONFIG_BLK_DEV_DTC2278=m CONFIG_BLK_DEV_HT6560B=m CONFIG_BLK_DEV_QD65XX=m CONFIG_BLK_DEV_UMC8672=m CONFIG_BLK_DEV_IDEDMA=y # # SCSI device support # CONFIG_RAID_ATTRS=m CONFIG_SCSI=m CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=m CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=m CONFIG_CHR_DEV_ST=m CONFIG_CHR_DEV_OSST=m CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set CONFIG_CHR_DEV_SG=m CONFIG_CHR_DEV_SCH=m CONFIG_SCSI_ENCLOSURE=m # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # CONFIG_SCSI_MULTI_LUN=y CONFIG_SCSI_CONSTANTS=y CONFIG_SCSI_LOGGING=y # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=m CONFIG_SCSI_FC_ATTRS=m # CONFIG_SCSI_FC_TGT_ATTRS is not set CONFIG_SCSI_ISCSI_ATTRS=m CONFIG_SCSI_SAS_ATTRS=m CONFIG_SCSI_SAS_LIBSAS=m # CONFIG_SCSI_SAS_ATA is not set CONFIG_SCSI_SAS_HOST_SMP=y CONFIG_SCSI_SAS_LIBSAS_DEBUG=y CONFIG_SCSI_SRP_ATTRS=m # CONFIG_SCSI_SRP_TGT_ATTRS is not set CONFIG_SCSI_LOWLEVEL=y CONFIG_ISCSI_TCP=m CONFIG_BLK_DEV_3W_XXXX_RAID=m CONFIG_SCSI_3W_9XXX=m CONFIG_SCSI_7000FASST=m CONFIG_SCSI_ACARD=m CONFIG_SCSI_AHA152X=m CONFIG_SCSI_AHA1542=m CONFIG_SCSI_AACRAID=m CONFIG_SCSI_AIC7XXX=m CONFIG_AIC7XXX_CMDS_PER_DEVICE=32 CONFIG_AIC7XXX_RESET_DELAY_MS=5000 # CONFIG_AIC7XXX_DEBUG_ENABLE is not set CONFIG_AIC7XXX_DEBUG_MASK=0 CONFIG_AIC7XXX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC7XXX_OLD=m CONFIG_SCSI_AIC79XX=m CONFIG_AIC79XX_CMDS_PER_DEVICE=32 CONFIG_AIC79XX_RESET_DELAY_MS=15000 # CONFIG_AIC79XX_DEBUG_ENABLE is not set CONFIG_AIC79XX_DEBUG_MASK=0 CONFIG_AIC79XX_REG_PRETTY_PRINT=y CONFIG_SCSI_AIC94XX=m CONFIG_AIC94XX_DEBUG=y CONFIG_SCSI_DPT_I2O=m CONFIG_SCSI_ADVANSYS=m CONFIG_SCSI_IN2000=m CONFIG_SCSI_ARCMSR=m # CONFIG_SCSI_ARCMSR_AER is not set CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=m CONFIG_MEGARAID_MAILBOX=m CONFIG_MEGARAID_LEGACY=m CONFIG_MEGARAID_SAS=m CONFIG_SCSI_HPTIOP=m CONFIG_SCSI_BUSLOGIC=m # CONFIG_SCSI_FLASHPOINT is not set CONFIG_SCSI_DMX3191D=m CONFIG_SCSI_DTC3280=m CONFIG_SCSI_EATA=m CONFIG_SCSI_EATA_TAGGED_QUEUE=y CONFIG_SCSI_EATA_LINKED_COMMANDS=y CONFIG_SCSI_EATA_MAX_TAGS=16 CONFIG_SCSI_FUTURE_DOMAIN=m CONFIG_SCSI_GDTH=m CONFIG_SCSI_GENERIC_NCR5380=m CONFIG_SCSI_GENERIC_NCR5380_MMIO=m CONFIG_SCSI_GENERIC_NCR53C400=y CONFIG_SCSI_IPS=m CONFIG_SCSI_INITIO=m CONFIG_SCSI_INIA100=m CONFIG_SCSI_PPA=m CONFIG_SCSI_IMM=m # CONFIG_SCSI_IZIP_EPP16 is not set # CONFIG_SCSI_IZIP_SLOW_CTR is not set # CONFIG_SCSI_MVSAS is not set CONFIG_SCSI_NCR53C406A=m CONFIG_SCSI_STEX=m CONFIG_SCSI_SYM53C8XX_2=m CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=1 CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=16 CONFIG_SCSI_SYM53C8XX_MAX_TAGS=64 CONFIG_SCSI_SYM53C8XX_MMIO=y CONFIG_SCSI_IPR=m CONFIG_SCSI_IPR_TRACE=y CONFIG_SCSI_IPR_DUMP=y CONFIG_SCSI_PAS16=m CONFIG_SCSI_QLOGIC_FAS=m CONFIG_SCSI_QLOGIC_1280=m CONFIG_SCSI_QLA_FC=m CONFIG_SCSI_QLA_ISCSI=m CONFIG_SCSI_LPFC=m CONFIG_SCSI_SYM53C416=m CONFIG_SCSI_DC395x=m CONFIG_SCSI_DC390T=m CONFIG_SCSI_T128=m CONFIG_SCSI_U14_34F=m CONFIG_SCSI_U14_34F_TAGGED_QUEUE=y CONFIG_SCSI_U14_34F_LINKED_COMMANDS=y CONFIG_SCSI_U14_34F_MAX_TAGS=8 CONFIG_SCSI_ULTRASTOR=m CONFIG_SCSI_NSP32=m CONFIG_SCSI_DEBUG=m CONFIG_SCSI_SRP=m # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set # CONFIG_SCSI_DH is not set CONFIG_ATA=m # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_PMP=y CONFIG_SATA_AHCI=m CONFIG_SATA_SIL24=m CONFIG_ATA_SFF=y CONFIG_SATA_SVW=m CONFIG_ATA_PIIX=m CONFIG_SATA_MV=m CONFIG_SATA_NV=m CONFIG_PDC_ADMA=m CONFIG_SATA_QSTOR=m CONFIG_SATA_PROMISE=m CONFIG_SATA_SX4=m CONFIG_SATA_SIL=m CONFIG_SATA_SIS=m CONFIG_SATA_ULI=m CONFIG_SATA_VIA=m CONFIG_SATA_VITESSE=m CONFIG_SATA_INIC162X=m CONFIG_PATA_ACPI=m CONFIG_PATA_ALI=m CONFIG_PATA_AMD=m CONFIG_PATA_ARTOP=m CONFIG_PATA_ATIIXP=m CONFIG_PATA_CMD640_PCI=m CONFIG_PATA_CMD64X=m CONFIG_PATA_CS5520=m CONFIG_PATA_CS5530=m CONFIG_PATA_CS5535=m CONFIG_PATA_CS5536=m CONFIG_PATA_CYPRESS=m CONFIG_PATA_EFAR=m CONFIG_ATA_GENERIC=m CONFIG_PATA_HPT366=m CONFIG_PATA_HPT37X=m CONFIG_PATA_HPT3X2N=m CONFIG_PATA_HPT3X3=m # CONFIG_PATA_HPT3X3_DMA is not set CONFIG_PATA_ISAPNP=m CONFIG_PATA_IT821X=m CONFIG_PATA_IT8213=m CONFIG_PATA_JMICRON=m CONFIG_PATA_LEGACY=m CONFIG_PATA_TRIFLEX=m CONFIG_PATA_MARVELL=m CONFIG_PATA_MPIIX=m CONFIG_PATA_OLDPIIX=m CONFIG_PATA_NETCELL=m # CONFIG_PATA_NINJA32 is not set CONFIG_PATA_NS87410=m CONFIG_PATA_NS87415=m CONFIG_PATA_OPTI=m CONFIG_PATA_OPTIDMA=m CONFIG_PATA_PCMCIA=m CONFIG_PATA_PDC_OLD=m CONFIG_PATA_QDI=m CONFIG_PATA_RADISYS=m CONFIG_PATA_RZ1000=m CONFIG_PATA_SC1200=m CONFIG_PATA_SERVERWORKS=m CONFIG_PATA_PDC2027X=m CONFIG_PATA_SIL680=m CONFIG_PATA_SIS=m CONFIG_PATA_VIA=m CONFIG_PATA_WINBOND=m CONFIG_PATA_WINBOND_VLB=m # CONFIG_PATA_SCH is not set CONFIG_MD=y CONFIG_BLK_DEV_MD=y CONFIG_MD_AUTODETECT=y CONFIG_MD_LINEAR=m CONFIG_MD_RAID0=m CONFIG_MD_RAID1=m CONFIG_MD_RAID10=m CONFIG_MD_RAID456=m CONFIG_MD_RAID5_RESHAPE=y CONFIG_MD_MULTIPATH=m CONFIG_MD_FAULTY=m CONFIG_BLK_DEV_DM=m # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=m CONFIG_DM_SNAPSHOT=m CONFIG_DM_MIRROR=m CONFIG_DM_ZERO=m CONFIG_DM_MULTIPATH=m CONFIG_DM_DELAY=m # CONFIG_DM_UEVENT is not set CONFIG_FUSION=y CONFIG_FUSION_SPI=m CONFIG_FUSION_FC=m CONFIG_FUSION_SAS=m CONFIG_FUSION_MAX_SGE=128 CONFIG_FUSION_CTL=m CONFIG_FUSION_LAN=m # CONFIG_FUSION_LOGGING is not set # # IEEE 1394 (FireWire) support # # # Enable only one of the two stacks, unless you know what you are doing # # CONFIG_FIREWIRE is not set CONFIG_IEEE1394=m CONFIG_IEEE1394_OHCI1394=m CONFIG_IEEE1394_PCILYNX=m CONFIG_IEEE1394_SBP2=m # CONFIG_IEEE1394_SBP2_PHYS_DMA is not set CONFIG_IEEE1394_ETH1394_ROM_ENTRY=y CONFIG_IEEE1394_ETH1394=m CONFIG_IEEE1394_RAWIO=m CONFIG_IEEE1394_VIDEO1394=m CONFIG_IEEE1394_DV1394=m # CONFIG_IEEE1394_VERBOSEDEBUG is not set CONFIG_I2O=m CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y CONFIG_I2O_EXT_ADAPTEC=y CONFIG_I2O_CONFIG=m CONFIG_I2O_CONFIG_OLD_IOCTL=y CONFIG_I2O_BUS=m CONFIG_I2O_BLOCK=m CONFIG_I2O_SCSI=m CONFIG_I2O_PROC=m # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y CONFIG_IFB=m CONFIG_DUMMY=m CONFIG_BONDING=m # CONFIG_MACVLAN is not set CONFIG_EQUALIZER=m CONFIG_TUN=m # CONFIG_VETH is not set CONFIG_NET_SB1000=m CONFIG_ARCNET=m CONFIG_ARCNET_1201=m CONFIG_ARCNET_1051=m CONFIG_ARCNET_RAW=m CONFIG_ARCNET_CAP=m CONFIG_ARCNET_COM90xx=m CONFIG_ARCNET_COM90xxIO=m CONFIG_ARCNET_RIM_I=m # CONFIG_ARCNET_COM20020 is not set CONFIG_PHYLIB=m # # MII PHY device drivers # CONFIG_MARVELL_PHY=m CONFIG_DAVICOM_PHY=m CONFIG_QSEMI_PHY=m CONFIG_LXT_PHY=m CONFIG_CICADA_PHY=m CONFIG_VITESSE_PHY=m CONFIG_SMSC_PHY=m CONFIG_BROADCOM_PHY=m # CONFIG_ICPLUS_PHY is not set # CONFIG_REALTEK_PHY is not set # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_MII=m CONFIG_HAPPYMEAL=m CONFIG_SUNGEM=m CONFIG_CASSINI=m CONFIG_NET_VENDOR_3COM=y CONFIG_EL1=m CONFIG_EL2=m CONFIG_ELPLUS=m CONFIG_EL16=m CONFIG_EL3=m CONFIG_3C515=m CONFIG_VORTEX=m CONFIG_TYPHOON=m CONFIG_LANCE=m CONFIG_NET_VENDOR_SMC=y CONFIG_WD80x3=m CONFIG_ULTRA=m CONFIG_SMC9194=m # CONFIG_ENC28J60 is not set CONFIG_NET_VENDOR_RACAL=y CONFIG_NI52=m CONFIG_NI65=m CONFIG_NET_TULIP=y CONFIG_DE2104X=m CONFIG_TULIP=m # CONFIG_TULIP_MWI is not set # CONFIG_TULIP_MMIO is not set CONFIG_TULIP_NAPI=y CONFIG_TULIP_NAPI_HW_MITIGATION=y CONFIG_DE4X5=m CONFIG_WINBOND_840=m CONFIG_DM9102=m CONFIG_ULI526X=m CONFIG_PCMCIA_XIRCOM=m CONFIG_AT1700=m CONFIG_DEPCA=m CONFIG_HP100=m CONFIG_NET_ISA=y CONFIG_E2100=m CONFIG_EWRK3=m CONFIG_EEXPRESS=m CONFIG_EEXPRESS_PRO=m CONFIG_HPLAN_PLUS=m CONFIG_HPLAN=m CONFIG_LP486E=m CONFIG_ETH16I=m CONFIG_NE2000=m CONFIG_ZNET=m CONFIG_SEEQ8005=m # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set # CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set # CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set # CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set CONFIG_NET_PCI=y CONFIG_PCNET32=m CONFIG_AMD8111_ETH=m CONFIG_ADAPTEC_STARFIRE=m CONFIG_AC3200=m CONFIG_APRICOT=m CONFIG_B44=m CONFIG_B44_PCI_AUTOSELECT=y CONFIG_B44_PCICORE_AUTOSELECT=y CONFIG_B44_PCI=y CONFIG_FORCEDETH=m CONFIG_FORCEDETH_NAPI=y CONFIG_CS89x0=m CONFIG_EEPRO100=m CONFIG_E100=m CONFIG_FEALNX=m CONFIG_NATSEMI=m CONFIG_NE2K_PCI=m CONFIG_8139CP=m CONFIG_8139TOO=m # CONFIG_8139TOO_PIO is not set # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y # CONFIG_8139_OLD_RX_RESET is not set # CONFIG_R6040 is not set CONFIG_SIS900=m CONFIG_EPIC100=m CONFIG_SUNDANCE=m # CONFIG_SUNDANCE_MMIO is not set CONFIG_TLAN=m CONFIG_VIA_RHINE=m # CONFIG_VIA_RHINE_MMIO is not set CONFIG_SC92031=m CONFIG_NET_POCKET=y CONFIG_ATP=m CONFIG_DE600=m CONFIG_DE620=m # CONFIG_ATL2 is not set CONFIG_NETDEV_1000=y CONFIG_ACENIC=m # CONFIG_ACENIC_OMIT_TIGON_I is not set CONFIG_DL2K=m CONFIG_E1000=m CONFIG_E1000E=m CONFIG_IP1000=m CONFIG_IGB=m # CONFIG_IGB_LRO is not set CONFIG_NS83820=m CONFIG_HAMACHI=m CONFIG_YELLOWFIN=m CONFIG_R8169=m CONFIG_R8169_VLAN=y CONFIG_SIS190=m CONFIG_SKGE=m # CONFIG_SKGE_DEBUG is not set CONFIG_SKY2=m # CONFIG_SKY2_DEBUG is not set CONFIG_VIA_VELOCITY=m CONFIG_TIGON3=m CONFIG_BNX2=m CONFIG_QLA3XXX=m CONFIG_ATL1=m # CONFIG_ATL1E is not set # CONFIG_JME is not set CONFIG_NETDEV_10000=y CONFIG_CHELSIO_T1=m CONFIG_CHELSIO_T1_1G=y CONFIG_CHELSIO_T3=m # CONFIG_ENIC is not set CONFIG_IXGBE=m CONFIG_IXGB=m CONFIG_S2IO=m CONFIG_MYRI10GE=m CONFIG_NETXEN_NIC=m CONFIG_NIU=m # CONFIG_MLX4_EN is not set CONFIG_MLX4_CORE=m CONFIG_MLX4_DEBUG=y CONFIG_TEHUTI=m CONFIG_BNX2X=m # CONFIG_QLGE is not set CONFIG_SFC=m CONFIG_TR=y CONFIG_IBMTR=m CONFIG_IBMOL=m CONFIG_IBMLS=m CONFIG_3C359=m CONFIG_TMS380TR=m CONFIG_TMSPCI=m CONFIG_SKISA=m CONFIG_PROTEON=m CONFIG_ABYSS=m CONFIG_SMCTR=m # # Wireless LAN # CONFIG_WLAN_PRE80211=y CONFIG_STRIP=m # CONFIG_ARLAN is not set CONFIG_WAVELAN=m CONFIG_PCMCIA_WAVELAN=m CONFIG_PCMCIA_NETWAVE=m CONFIG_WLAN_80211=y CONFIG_PCMCIA_RAYCS=m CONFIG_IPW2100=m CONFIG_IPW2100_MONITOR=y # CONFIG_IPW2100_DEBUG is not set CONFIG_IPW2200=m CONFIG_IPW2200_MONITOR=y CONFIG_IPW2200_RADIOTAP=y CONFIG_IPW2200_PROMISCUOUS=y CONFIG_IPW2200_QOS=y # CONFIG_IPW2200_DEBUG is not set CONFIG_LIBERTAS=m CONFIG_LIBERTAS_USB=m CONFIG_LIBERTAS_CS=m CONFIG_LIBERTAS_SDIO=m # CONFIG_LIBERTAS_DEBUG is not set # CONFIG_LIBERTAS_THINFIRM is not set CONFIG_AIRO=m CONFIG_HERMES=m CONFIG_PLX_HERMES=m CONFIG_TMD_HERMES=m CONFIG_NORTEL_HERMES=m CONFIG_PCI_HERMES=m CONFIG_PCMCIA_HERMES=m CONFIG_PCMCIA_SPECTRUM=m CONFIG_ATMEL=m CONFIG_PCI_ATMEL=m CONFIG_PCMCIA_ATMEL=m CONFIG_AIRO_CS=m CONFIG_PCMCIA_WL3501=m CONFIG_PRISM54=m CONFIG_USB_ZD1201=m CONFIG_USB_NET_RNDIS_WLAN=m CONFIG_RTL8180=m CONFIG_RTL8187=m CONFIG_ADM8211=m # CONFIG_MAC80211_HWSIM is not set CONFIG_P54_COMMON=m CONFIG_P54_USB=m CONFIG_P54_PCI=m CONFIG_ATH5K=m # CONFIG_ATH5K_DEBUG is not set # CONFIG_ATH9K is not set CONFIG_IWLWIFI=m CONFIG_IWLCORE=m # CONFIG_IWLWIFI_LEDS is not set # CONFIG_IWLWIFI_RFKILL is not set # CONFIG_IWLWIFI_DEBUG is not set # CONFIG_IWLAGN is not set CONFIG_IWL3945=m # CONFIG_IWL3945_RFKILL is not set # CONFIG_IWL3945_SPECTRUM_MEASUREMENT is not set # CONFIG_IWL3945_LEDS is not set # CONFIG_IWL3945_DEBUG is not set CONFIG_HOSTAP=m CONFIG_HOSTAP_FIRMWARE=y CONFIG_HOSTAP_FIRMWARE_NVRAM=y CONFIG_HOSTAP_PLX=m CONFIG_HOSTAP_PCI=m CONFIG_HOSTAP_CS=m CONFIG_B43=m CONFIG_B43_PCI_AUTOSELECT=y CONFIG_B43_PCICORE_AUTOSELECT=y # CONFIG_B43_PCMCIA is not set CONFIG_B43_LEDS=y CONFIG_B43_RFKILL=y # CONFIG_B43_DEBUG is not set CONFIG_B43LEGACY=m CONFIG_B43LEGACY_PCI_AUTOSELECT=y CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y CONFIG_B43LEGACY_LEDS=y CONFIG_B43LEGACY_RFKILL=y CONFIG_B43LEGACY_DEBUG=y CONFIG_B43LEGACY_DMA=y CONFIG_B43LEGACY_PIO=y CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y # CONFIG_B43LEGACY_DMA_MODE is not set # CONFIG_B43LEGACY_PIO_MODE is not set CONFIG_ZD1211RW=m # CONFIG_ZD1211RW_DEBUG is not set CONFIG_RT2X00=m # CONFIG_RT2400PCI is not set # CONFIG_RT2500PCI is not set # CONFIG_RT61PCI is not set # CONFIG_RT2500USB is not set # CONFIG_RT73USB is not set # # USB Network Adapters # CONFIG_USB_CATC=m CONFIG_USB_KAWETH=m CONFIG_USB_PEGASUS=m CONFIG_USB_RTL8150=m CONFIG_USB_USBNET=m CONFIG_USB_NET_AX8817X=m CONFIG_USB_NET_CDCETHER=m CONFIG_USB_NET_DM9601=m # CONFIG_USB_NET_SMSC95XX is not set CONFIG_USB_NET_GL620A=m CONFIG_USB_NET_NET1080=m CONFIG_USB_NET_PLUSB=m CONFIG_USB_NET_MCS7830=m CONFIG_USB_NET_RNDIS_HOST=m CONFIG_USB_NET_CDC_SUBSET=m CONFIG_USB_ALI_M5632=y CONFIG_USB_AN2720=y CONFIG_USB_BELKIN=y CONFIG_USB_ARMLINUX=y CONFIG_USB_EPSON2888=y CONFIG_USB_KC2190=y CONFIG_USB_NET_ZAURUS=m # CONFIG_USB_HSO is not set CONFIG_NET_PCMCIA=y CONFIG_PCMCIA_3C589=m CONFIG_PCMCIA_3C574=m CONFIG_PCMCIA_FMVJ18X=m CONFIG_PCMCIA_PCNET=m CONFIG_PCMCIA_NMCLAN=m CONFIG_PCMCIA_SMC91C92=m CONFIG_PCMCIA_XIRC2PS=m CONFIG_PCMCIA_AXNET=m CONFIG_PCMCIA_IBMTR=m CONFIG_WAN=y CONFIG_HOSTESS_SV11=m # CONFIG_COSA is not set CONFIG_LANMEDIA=m CONFIG_SEALEVEL_4021=m CONFIG_HDLC=m CONFIG_HDLC_RAW=m CONFIG_HDLC_RAW_ETH=m CONFIG_HDLC_CISCO=m CONFIG_HDLC_FR=m CONFIG_HDLC_PPP=m CONFIG_HDLC_X25=m CONFIG_PCI200SYN=m CONFIG_WANXL=m CONFIG_PC300TOO=m CONFIG_N2=m CONFIG_C101=m CONFIG_FARSYNC=m # CONFIG_DSCC4 is not set CONFIG_DLCI=m CONFIG_DLCI_MAX=8 CONFIG_SDLA=m # CONFIG_WAN_ROUTER_DRIVERS is not set CONFIG_LAPBETHER=m CONFIG_X25_ASY=m # CONFIG_SBNI is not set CONFIG_ATM_DRIVERS=y CONFIG_ATM_DUMMY=m CONFIG_ATM_TCP=m CONFIG_ATM_LANAI=m CONFIG_ATM_ENI=m # CONFIG_ATM_ENI_DEBUG is not set # CONFIG_ATM_ENI_TUNE_BURST is not set CONFIG_ATM_FIRESTREAM=m CONFIG_ATM_ZATM=m # CONFIG_ATM_ZATM_DEBUG is not set CONFIG_ATM_NICSTAR=m CONFIG_ATM_NICSTAR_USE_SUNI=y CONFIG_ATM_NICSTAR_USE_IDT77105=y CONFIG_ATM_IDT77252=m # CONFIG_ATM_IDT77252_DEBUG is not set CONFIG_ATM_IDT77252_RCV_ALL=y CONFIG_ATM_IDT77252_USE_SUNI=y CONFIG_ATM_AMBASSADOR=m # CONFIG_ATM_AMBASSADOR_DEBUG is not set CONFIG_ATM_HORIZON=m # CONFIG_ATM_HORIZON_DEBUG is not set CONFIG_ATM_IA=m # CONFIG_ATM_IA_DEBUG is not set CONFIG_ATM_FORE200E=m CONFIG_ATM_FORE200E_USE_TASKLET=y CONFIG_ATM_FORE200E_TX_RETRY=16 CONFIG_ATM_FORE200E_DEBUG=0 CONFIG_ATM_HE=m CONFIG_ATM_HE_USE_SUNI=y CONFIG_FDDI=y # CONFIG_DEFXX is not set CONFIG_SKFP=m CONFIG_HIPPI=y CONFIG_ROADRUNNER=m CONFIG_ROADRUNNER_LARGE_RINGS=y CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_MULTILINK=y CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_PPP_MPPE=m CONFIG_PPPOE=m CONFIG_PPPOATM=m # CONFIG_PPPOL2TP is not set CONFIG_SLIP=m CONFIG_SLIP_COMPRESSED=y CONFIG_SLHC=m CONFIG_SLIP_SMART=y CONFIG_SLIP_MODE_SLIP6=y CONFIG_NET_FC=y CONFIG_NETCONSOLE=m # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y CONFIG_NETPOLL_TRAP=y CONFIG_NET_POLL_CONTROLLER=y # CONFIG_ISDN is not set CONFIG_PHONE=m CONFIG_PHONE_IXJ=m CONFIG_PHONE_IXJ_PCMCIA=m # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=m CONFIG_INPUT_POLLDEV=m # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 CONFIG_INPUT_JOYDEV=m CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y CONFIG_KEYBOARD_SUNKBD=m # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_XTKBD=m CONFIG_KEYBOARD_NEWTON=m # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=y CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_ELANTECH is not set # CONFIG_MOUSE_PS2_TOUCHKIT is not set CONFIG_MOUSE_SERIAL=m CONFIG_MOUSE_APPLETOUCH=m # CONFIG_MOUSE_BCM5974 is not set CONFIG_MOUSE_INPORT=m CONFIG_MOUSE_ATIXL=y CONFIG_MOUSE_LOGIBM=m CONFIG_MOUSE_PC110PAD=m # CONFIG_MOUSE_VSXXXAA is not set CONFIG_INPUT_JOYSTICK=y CONFIG_JOYSTICK_ANALOG=m CONFIG_JOYSTICK_A3D=m CONFIG_JOYSTICK_ADI=m CONFIG_JOYSTICK_COBRA=m CONFIG_JOYSTICK_GF2K=m CONFIG_JOYSTICK_GRIP=m CONFIG_JOYSTICK_GRIP_MP=m CONFIG_JOYSTICK_GUILLEMOT=m CONFIG_JOYSTICK_INTERACT=m CONFIG_JOYSTICK_SIDEWINDER=m CONFIG_JOYSTICK_TMDC=m CONFIG_JOYSTICK_IFORCE=m CONFIG_JOYSTICK_IFORCE_USB=y CONFIG_JOYSTICK_IFORCE_232=y CONFIG_JOYSTICK_WARRIOR=m CONFIG_JOYSTICK_MAGELLAN=m CONFIG_JOYSTICK_SPACEORB=m CONFIG_JOYSTICK_SPACEBALL=m CONFIG_JOYSTICK_STINGER=m CONFIG_JOYSTICK_TWIDJOY=m CONFIG_JOYSTICK_ZHENHUA=m CONFIG_JOYSTICK_DB9=m CONFIG_JOYSTICK_GAMECON=m CONFIG_JOYSTICK_TURBOGRAFX=m CONFIG_JOYSTICK_JOYDUMP=m CONFIG_JOYSTICK_XPAD=m # CONFIG_JOYSTICK_XPAD_FF is not set # CONFIG_JOYSTICK_XPAD_LEDS is not set CONFIG_INPUT_TABLET=y CONFIG_TABLET_USB_ACECAD=m CONFIG_TABLET_USB_AIPTEK=m CONFIG_TABLET_USB_GTCO=m CONFIG_TABLET_USB_KBTAB=m CONFIG_TABLET_USB_WACOM=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=m # CONFIG_TOUCHSCREEN_FUJITSU is not set CONFIG_TOUCHSCREEN_GUNZE=m CONFIG_TOUCHSCREEN_ELO=m CONFIG_TOUCHSCREEN_MTOUCH=m # CONFIG_TOUCHSCREEN_INEXIO is not set CONFIG_TOUCHSCREEN_MK712=m # CONFIG_TOUCHSCREEN_HTCPEN is not set CONFIG_TOUCHSCREEN_PENMOUNT=m CONFIG_TOUCHSCREEN_TOUCHRIGHT=m CONFIG_TOUCHSCREEN_TOUCHWIN=m CONFIG_TOUCHSCREEN_WM97XX=m # CONFIG_TOUCHSCREEN_WM9705 is not set # CONFIG_TOUCHSCREEN_WM9712 is not set # CONFIG_TOUCHSCREEN_WM9713 is not set CONFIG_TOUCHSCREEN_USB_COMPOSITE=m CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y # CONFIG_TOUCHSCREEN_TOUCHIT213 is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=y CONFIG_INPUT_APANEL=m CONFIG_INPUT_WISTRON_BTNS=m CONFIG_INPUT_ATLAS_BTNS=m CONFIG_INPUT_ATI_REMOTE=m CONFIG_INPUT_ATI_REMOTE2=m CONFIG_INPUT_KEYSPAN_REMOTE=m CONFIG_INPUT_POWERMATE=m CONFIG_INPUT_YEALINK=m # CONFIG_INPUT_CM109 is not set CONFIG_INPUT_UINPUT=m # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=m CONFIG_SERIO_CT82C710=m CONFIG_SERIO_PARKBD=m CONFIG_SERIO_PCIPS2=m CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=m CONFIG_GAMEPORT=m CONFIG_GAMEPORT_NS558=m CONFIG_GAMEPORT_L4=m CONFIG_GAMEPORT_EMU10K1=m CONFIG_GAMEPORT_FM801=m # # Character devices # CONFIG_VT=y CONFIG_CONSOLE_TRANSLATIONS=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y CONFIG_DEVKMEM=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_COMPUTONE=m CONFIG_ROCKETPORT=m CONFIG_CYCLADES=m CONFIG_CYZ_INTR=y CONFIG_DIGIEPCA=m CONFIG_ESPSERIAL=m CONFIG_MOXA_INTELLIO=m CONFIG_MOXA_SMARTIO=m CONFIG_ISI=m CONFIG_SYNCLINK=m CONFIG_SYNCLINKMP=m CONFIG_SYNCLINK_GT=m CONFIG_N_HDLC=m CONFIG_RISCOM8=m CONFIG_SPECIALIX=m # CONFIG_SX is not set # CONFIG_RIO is not set CONFIG_STALDRV=y # CONFIG_STALLION is not set # CONFIG_ISTALLION is not set CONFIG_NOZOMI=m # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_CS=m CONFIG_SERIAL_8250_NR_UARTS=8 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_FOURPORT=m CONFIG_SERIAL_8250_ACCENT=m CONFIG_SERIAL_8250_BOCA=m CONFIG_SERIAL_8250_EXAR_ST16C554=m CONFIG_SERIAL_8250_HUB6=m CONFIG_SERIAL_8250_SHARE_IRQ=y # CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_SERIAL_JSM=m CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=64 CONFIG_PRINTER=m # CONFIG_LP_CONSOLE is not set CONFIG_PPDEV=m CONFIG_IPMI_HANDLER=m CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_PANIC_STRING=y CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_SI=m CONFIG_IPMI_WATCHDOG=m CONFIG_IPMI_POWEROFF=m CONFIG_HW_RANDOM=y CONFIG_HW_RANDOM_INTEL=m CONFIG_HW_RANDOM_AMD=m CONFIG_HW_RANDOM_GEODE=m CONFIG_HW_RANDOM_VIA=m CONFIG_NVRAM=m CONFIG_DTLK=m CONFIG_R3964=m CONFIG_APPLICOM=m CONFIG_SONYPI=m # # PCMCIA character devices # CONFIG_SYNCLINK_CS=m CONFIG_CARDMAN_4000=m CONFIG_CARDMAN_4040=m CONFIG_IPWIRELESS=m CONFIG_MWAVE=m CONFIG_SCx200_GPIO=m CONFIG_PC8736x_GPIO=m CONFIG_NSC_GPIO=m CONFIG_CS5535_GPIO=m CONFIG_RAW_DRIVER=m CONFIG_MAX_RAW_DEVS=4096 CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_HANGCHECK_TIMER=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m CONFIG_TCG_ATMEL=m CONFIG_TCG_INFINEON=m CONFIG_TELCLOCK=m CONFIG_DEVPORT=y CONFIG_I2C=m CONFIG_I2C_BOARDINFO=y CONFIG_I2C_CHARDEV=m CONFIG_I2C_HELPER_AUTO=y CONFIG_I2C_ALGOBIT=m CONFIG_I2C_ALGOPCA=m # # I2C Hardware Bus support # # # PC SMBus host controller drivers # CONFIG_I2C_ALI1535=m CONFIG_I2C_ALI1563=m CONFIG_I2C_ALI15X3=m CONFIG_I2C_AMD756=m CONFIG_I2C_AMD756_S4882=m CONFIG_I2C_AMD8111=m CONFIG_I2C_I801=m # CONFIG_I2C_ISCH is not set CONFIG_I2C_PIIX4=m CONFIG_I2C_NFORCE2=m # CONFIG_I2C_NFORCE2_S4985 is not set CONFIG_I2C_SIS5595=m CONFIG_I2C_SIS630=m CONFIG_I2C_SIS96X=m CONFIG_I2C_VIA=m CONFIG_I2C_VIAPRO=m # # I2C system bus drivers (mostly embedded / system-on-chip) # CONFIG_I2C_OCORES=m CONFIG_I2C_SIMTEC=m # # External I2C/SMBus adapter drivers # CONFIG_I2C_PARPORT=m CONFIG_I2C_PARPORT_LIGHT=m # CONFIG_I2C_TAOS_EVM is not set CONFIG_I2C_TINY_USB=m # # Graphics adapter I2C/DDC channel drivers # CONFIG_I2C_VOODOO3=m # # Other I2C/SMBus bus drivers # CONFIG_I2C_PCA_ISA=m CONFIG_I2C_PCA_PLATFORM=m CONFIG_I2C_STUB=m CONFIG_SCx200_I2C=m CONFIG_SCx200_I2C_SCL=12 CONFIG_SCx200_I2C_SDA=13 CONFIG_SCx200_ACB=m # # Miscellaneous I2C Chip support # # CONFIG_DS1682 is not set # CONFIG_AT24 is not set CONFIG_SENSORS_EEPROM=m CONFIG_SENSORS_PCF8574=m CONFIG_PCF8575=m # CONFIG_SENSORS_PCA9539 is not set CONFIG_SENSORS_PCF8591=m CONFIG_SENSORS_MAX6875=m # CONFIG_SENSORS_TSL2550 is not set # CONFIG_I2C_DEBUG_CORE is not set # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set # CONFIG_I2C_DEBUG_CHIP is not set CONFIG_SPI=y CONFIG_SPI_MASTER=y # # SPI Master Controller Drivers # CONFIG_SPI_BITBANG=m CONFIG_SPI_BUTTERFLY=m CONFIG_SPI_LM70_LLP=m # # SPI Protocol Masters # CONFIG_SPI_AT25=m CONFIG_SPI_SPIDEV=m # CONFIG_SPI_TLE62X0 is not set CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y # CONFIG_GPIOLIB is not set CONFIG_W1=m CONFIG_W1_CON=y # # 1-wire Bus Masters # CONFIG_W1_MASTER_MATROX=m CONFIG_W1_MASTER_DS2490=m CONFIG_W1_MASTER_DS2482=m # # 1-wire Slaves # CONFIG_W1_SLAVE_THERM=m CONFIG_W1_SLAVE_SMEM=m CONFIG_W1_SLAVE_DS2433=m CONFIG_W1_SLAVE_DS2433_CRC=y # CONFIG_W1_SLAVE_DS2760 is not set # CONFIG_W1_SLAVE_BQ27000 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_BATTERY_BQ27x00 is not set CONFIG_HWMON=m CONFIG_HWMON_VID=m CONFIG_SENSORS_ABITUGURU=m # CONFIG_SENSORS_ABITUGURU3 is not set # CONFIG_SENSORS_AD7414 is not set CONFIG_SENSORS_AD7418=m # CONFIG_SENSORS_ADCXX is not set CONFIG_SENSORS_ADM1021=m CONFIG_SENSORS_ADM1025=m CONFIG_SENSORS_ADM1026=m CONFIG_SENSORS_ADM1029=m CONFIG_SENSORS_ADM1031=m CONFIG_SENSORS_ADM9240=m # CONFIG_SENSORS_ADT7462 is not set # CONFIG_SENSORS_ADT7470 is not set CONFIG_SENSORS_ADT7473=m CONFIG_SENSORS_K8TEMP=m CONFIG_SENSORS_ASB100=m CONFIG_SENSORS_ATXP1=m CONFIG_SENSORS_DS1621=m # CONFIG_SENSORS_I5K_AMB is not set CONFIG_SENSORS_F71805F=m # CONFIG_SENSORS_F71882FG is not set # CONFIG_SENSORS_F75375S is not set CONFIG_SENSORS_FSCHER=m CONFIG_SENSORS_FSCPOS=m # CONFIG_SENSORS_FSCHMD is not set CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m CONFIG_SENSORS_CORETEMP=m CONFIG_SENSORS_IBMAEM=m # CONFIG_SENSORS_IBMPEX is not set CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM70=m CONFIG_SENSORS_LM75=m CONFIG_SENSORS_LM77=m CONFIG_SENSORS_LM78=m CONFIG_SENSORS_LM80=m CONFIG_SENSORS_LM83=m CONFIG_SENSORS_LM85=m CONFIG_SENSORS_LM87=m CONFIG_SENSORS_LM90=m CONFIG_SENSORS_LM92=m # CONFIG_SENSORS_LM93 is not set # CONFIG_SENSORS_MAX1111 is not set CONFIG_SENSORS_MAX1619=m CONFIG_SENSORS_MAX6650=m CONFIG_SENSORS_PC87360=m CONFIG_SENSORS_PC87427=m CONFIG_SENSORS_SIS5595=m # CONFIG_SENSORS_DME1737 is not set CONFIG_SENSORS_SMSC47M1=m CONFIG_SENSORS_SMSC47M192=m CONFIG_SENSORS_SMSC47B397=m CONFIG_SENSORS_ADS7828=m # CONFIG_SENSORS_THMC50 is not set CONFIG_SENSORS_VIA686A=m CONFIG_SENSORS_VT1211=m CONFIG_SENSORS_VT8231=m CONFIG_SENSORS_W83781D=m CONFIG_SENSORS_W83791D=m CONFIG_SENSORS_W83792D=m CONFIG_SENSORS_W83793=m CONFIG_SENSORS_W83L785TS=m CONFIG_SENSORS_W83L786NG=m CONFIG_SENSORS_W83627HF=m CONFIG_SENSORS_W83627EHF=m CONFIG_SENSORS_HDAPS=m # CONFIG_SENSORS_LIS3LV02D is not set CONFIG_SENSORS_APPLESMC=m # CONFIG_HWMON_DEBUG_CHIP is not set CONFIG_THERMAL=m # CONFIG_THERMAL_HWMON is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # CONFIG_SOFT_WATCHDOG=m CONFIG_ACQUIRE_WDT=m CONFIG_ADVANTECH_WDT=m CONFIG_ALIM1535_WDT=m CONFIG_ALIM7101_WDT=m CONFIG_SC520_WDT=m CONFIG_EUROTECH_WDT=m CONFIG_IB700_WDT=m CONFIG_IBMASR=m CONFIG_WAFER_WDT=m CONFIG_I6300ESB_WDT=m CONFIG_ITCO_WDT=m CONFIG_ITCO_VENDOR_SUPPORT=y # CONFIG_IT8712F_WDT is not set # CONFIG_IT87_WDT is not set CONFIG_HP_WATCHDOG=m CONFIG_SC1200_WDT=m CONFIG_SCx200_WDT=m CONFIG_PC87413_WDT=m CONFIG_60XX_WDT=m CONFIG_SBC8360_WDT=m # CONFIG_SBC7240_WDT is not set CONFIG_CPU5_WDT=m CONFIG_SMSC37B787_WDT=m CONFIG_W83627HF_WDT=m CONFIG_W83697HF_WDT=m # CONFIG_W83697UG_WDT is not set CONFIG_W83877F_WDT=m CONFIG_W83977F_WDT=m CONFIG_MACHZ_WDT=m CONFIG_SBC_EPX_C3_WATCHDOG=m # # ISA-based Watchdog Cards # CONFIG_PCWATCHDOG=m CONFIG_MIXCOMWD=m CONFIG_WDT=m CONFIG_WDT_501=y # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=m CONFIG_WDTPCI=m CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # CONFIG_USBPCWATCHDOG=m CONFIG_SSB_POSSIBLE=y # # Sonics Silicon Backplane # CONFIG_SSB=m CONFIG_SSB_SPROM=y CONFIG_SSB_PCIHOST_POSSIBLE=y CONFIG_SSB_PCIHOST=y CONFIG_SSB_B43_PCI_BRIDGE=y CONFIG_SSB_PCMCIAHOST_POSSIBLE=y # CONFIG_SSB_PCMCIAHOST is not set # CONFIG_SSB_DEBUG is not set CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y CONFIG_SSB_DRIVER_PCICORE=y # # Multifunction device drivers # # CONFIG_MFD_CORE is not set CONFIG_MFD_SM501=m CONFIG_HTC_PASIC3=m # CONFIG_MFD_TMIO is not set # CONFIG_MFD_WM8400 is not set # CONFIG_MFD_WM8350_I2C is not set # CONFIG_REGULATOR is not set # # Multimedia devices # # # Multimedia core support # CONFIG_VIDEO_DEV=m CONFIG_VIDEO_V4L2_COMMON=m CONFIG_VIDEO_ALLOW_V4L1=y CONFIG_VIDEO_V4L1_COMPAT=y CONFIG_DVB_CORE=m CONFIG_VIDEO_MEDIA=m # # Multimedia drivers # CONFIG_VIDEO_SAA7146=m CONFIG_VIDEO_SAA7146_VV=m CONFIG_MEDIA_ATTACH=y CONFIG_MEDIA_TUNER=m # CONFIG_MEDIA_TUNER_CUSTOMIZE is not set CONFIG_MEDIA_TUNER_SIMPLE=m CONFIG_MEDIA_TUNER_TDA8290=m CONFIG_MEDIA_TUNER_TDA827X=m CONFIG_MEDIA_TUNER_TDA18271=m CONFIG_MEDIA_TUNER_TDA9887=m CONFIG_MEDIA_TUNER_TEA5761=m CONFIG_MEDIA_TUNER_TEA5767=m CONFIG_MEDIA_TUNER_MT20XX=m CONFIG_MEDIA_TUNER_MT2060=m CONFIG_MEDIA_TUNER_MT2266=m CONFIG_MEDIA_TUNER_MT2131=m CONFIG_MEDIA_TUNER_QT1010=m CONFIG_MEDIA_TUNER_XC2028=m CONFIG_MEDIA_TUNER_XC5000=m CONFIG_MEDIA_TUNER_MXL5005S=m CONFIG_MEDIA_TUNER_MXL5007T=m CONFIG_VIDEO_V4L2=m CONFIG_VIDEO_V4L1=m CONFIG_VIDEOBUF_GEN=m CONFIG_VIDEOBUF_DMA_SG=m CONFIG_VIDEOBUF_VMALLOC=m CONFIG_VIDEOBUF_DVB=m CONFIG_VIDEO_BTCX=m CONFIG_VIDEO_IR=m CONFIG_VIDEO_TVEEPROM=m CONFIG_VIDEO_TUNER=m CONFIG_VIDEO_CAPTURE_DRIVERS=y # CONFIG_VIDEO_ADV_DEBUG is not set # CONFIG_VIDEO_FIXED_MINOR_RANGES is not set CONFIG_VIDEO_HELPER_CHIPS_AUTO=y CONFIG_VIDEO_IR_I2C=m CONFIG_VIDEO_TVAUDIO=m CONFIG_VIDEO_TDA7432=m CONFIG_VIDEO_TDA9840=m CONFIG_VIDEO_TDA9875=m CONFIG_VIDEO_TEA6415C=m CONFIG_VIDEO_TEA6420=m CONFIG_VIDEO_MSP3400=m CONFIG_VIDEO_CS5345=m CONFIG_VIDEO_CS53L32A=m CONFIG_VIDEO_M52790=m CONFIG_VIDEO_WM8775=m CONFIG_VIDEO_WM8739=m CONFIG_VIDEO_VP27SMPX=m CONFIG_VIDEO_BT819=m CONFIG_VIDEO_BT856=m CONFIG_VIDEO_KS0127=m CONFIG_VIDEO_OV7670=m CONFIG_VIDEO_SAA7110=m CONFIG_VIDEO_SAA7111=m CONFIG_VIDEO_SAA7114=m CONFIG_VIDEO_SAA711X=m CONFIG_VIDEO_SAA717X=m CONFIG_VIDEO_TVP5150=m CONFIG_VIDEO_VPX3220=m CONFIG_VIDEO_CX25840=m CONFIG_VIDEO_CX2341X=m CONFIG_VIDEO_SAA7127=m CONFIG_VIDEO_SAA7185=m CONFIG_VIDEO_ADV7170=m CONFIG_VIDEO_ADV7175=m CONFIG_VIDEO_UPD64031A=m CONFIG_VIDEO_UPD64083=m CONFIG_VIDEO_VIVI=m CONFIG_VIDEO_BT848=m CONFIG_VIDEO_BT848_DVB=y CONFIG_VIDEO_SAA6588=m CONFIG_VIDEO_PMS=m CONFIG_VIDEO_BWQCAM=m CONFIG_VIDEO_CQCAM=m CONFIG_VIDEO_W9966=m CONFIG_VIDEO_CPIA=m CONFIG_VIDEO_CPIA_PP=m CONFIG_VIDEO_CPIA_USB=m CONFIG_VIDEO_CPIA2=m CONFIG_VIDEO_SAA5246A=m CONFIG_VIDEO_SAA5249=m CONFIG_VIDEO_STRADIS=m CONFIG_VIDEO_ZORAN=m CONFIG_VIDEO_ZORAN_DC30=m CONFIG_VIDEO_ZORAN_ZR36060=m CONFIG_VIDEO_ZORAN_BUZ=m CONFIG_VIDEO_ZORAN_DC10=m CONFIG_VIDEO_ZORAN_LML33=m CONFIG_VIDEO_ZORAN_LML33R10=m CONFIG_VIDEO_ZORAN_AVS6EYES=m CONFIG_VIDEO_MEYE=m CONFIG_VIDEO_SAA7134=m CONFIG_VIDEO_SAA7134_ALSA=m CONFIG_VIDEO_SAA7134_DVB=m CONFIG_VIDEO_MXB=m CONFIG_VIDEO_HEXIUM_ORION=m CONFIG_VIDEO_HEXIUM_GEMINI=m CONFIG_VIDEO_CX88=m CONFIG_VIDEO_CX88_ALSA=m CONFIG_VIDEO_CX88_BLACKBIRD=m CONFIG_VIDEO_CX88_DVB=m CONFIG_VIDEO_CX88_VP3054=m CONFIG_VIDEO_CX23885=m CONFIG_VIDEO_AU0828=m CONFIG_VIDEO_IVTV=m CONFIG_VIDEO_FB_IVTV=m CONFIG_VIDEO_CX18=m CONFIG_VIDEO_CAFE_CCIC=m CONFIG_SOC_CAMERA=m CONFIG_SOC_CAMERA_MT9M001=m # CONFIG_SOC_CAMERA_MT9M111 is not set CONFIG_SOC_CAMERA_MT9V022=m # CONFIG_SOC_CAMERA_PLATFORM is not set # CONFIG_VIDEO_SH_MOBILE_CEU is not set CONFIG_V4L_USB_DRIVERS=y CONFIG_USB_VIDEO_CLASS=m CONFIG_USB_VIDEO_CLASS_INPUT_EVDEV=y # CONFIG_USB_GSPCA is not set CONFIG_VIDEO_PVRUSB2=m CONFIG_VIDEO_PVRUSB2_SYSFS=y CONFIG_VIDEO_PVRUSB2_DVB=y # CONFIG_VIDEO_PVRUSB2_DEBUGIFC is not set CONFIG_VIDEO_EM28XX=m CONFIG_VIDEO_EM28XX_ALSA=m CONFIG_VIDEO_EM28XX_DVB=m CONFIG_VIDEO_USBVISION=m CONFIG_VIDEO_USBVIDEO=m CONFIG_USB_VICAM=m CONFIG_USB_IBMCAM=m CONFIG_USB_KONICAWC=m CONFIG_USB_QUICKCAM_MESSENGER=m CONFIG_USB_ET61X251=m CONFIG_VIDEO_OVCAMCHIP=m CONFIG_USB_W9968CF=m CONFIG_USB_OV511=m CONFIG_USB_SE401=m CONFIG_USB_SN9C102=m CONFIG_USB_STV680=m CONFIG_USB_ZC0301=m CONFIG_USB_PWC=m # CONFIG_USB_PWC_DEBUG is not set CONFIG_USB_ZR364XX=m CONFIG_USB_STKWEBCAM=m # CONFIG_USB_S2255 is not set CONFIG_RADIO_ADAPTERS=y CONFIG_RADIO_CADET=m CONFIG_RADIO_RTRACK=m CONFIG_RADIO_RTRACK2=m CONFIG_RADIO_AZTECH=m CONFIG_RADIO_GEMTEK=m CONFIG_RADIO_GEMTEK_PCI=m CONFIG_RADIO_MAXIRADIO=m CONFIG_RADIO_MAESTRO=m CONFIG_RADIO_SF16FMI=m CONFIG_RADIO_SF16FMR2=m CONFIG_RADIO_TERRATEC=m CONFIG_RADIO_TRUST=m CONFIG_RADIO_TYPHOON=m CONFIG_RADIO_TYPHOON_PROC_FS=y CONFIG_RADIO_ZOLTRIX=m CONFIG_USB_DSBR=m CONFIG_USB_SI470X=m # CONFIG_USB_MR800 is not set CONFIG_DVB_CAPTURE_DRIVERS=y # # Supported SAA7146 based PCI Adapters # CONFIG_TTPCI_EEPROM=m CONFIG_DVB_AV7110=m # CONFIG_DVB_AV7110_FIRMWARE is not set CONFIG_DVB_AV7110_OSD=y CONFIG_DVB_BUDGET_CORE=m CONFIG_DVB_BUDGET=m CONFIG_DVB_BUDGET_CI=m CONFIG_DVB_BUDGET_AV=m CONFIG_DVB_BUDGET_PATCH=m # # Supported USB Adapters # CONFIG_DVB_USB=m # CONFIG_DVB_USB_DEBUG is not set CONFIG_DVB_USB_A800=m CONFIG_DVB_USB_DIBUSB_MB=m # CONFIG_DVB_USB_DIBUSB_MB_FAULTY is not set CONFIG_DVB_USB_DIBUSB_MC=m CONFIG_DVB_USB_DIB0700=m CONFIG_DVB_USB_UMT_010=m # CONFIG_DVB_USB_CXUSB is not set CONFIG_DVB_USB_M920X=m CONFIG_DVB_USB_GL861=m CONFIG_DVB_USB_AU6610=m CONFIG_DVB_USB_DIGITV=m CONFIG_DVB_USB_VP7045=m CONFIG_DVB_USB_VP702X=m CONFIG_DVB_USB_GP8PSK=m CONFIG_DVB_USB_NOVA_T_USB2=m CONFIG_DVB_USB_TTUSB2=m CONFIG_DVB_USB_DTT200U=m CONFIG_DVB_USB_OPERA1=m CONFIG_DVB_USB_AF9005=m CONFIG_DVB_USB_AF9005_REMOTE=m # CONFIG_DVB_USB_DW2102 is not set # CONFIG_DVB_USB_CINERGY_T2 is not set # CONFIG_DVB_USB_ANYSEE is not set # CONFIG_DVB_USB_DTV5100 is not set # CONFIG_DVB_USB_AF9015 is not set CONFIG_DVB_TTUSB_BUDGET=m CONFIG_DVB_TTUSB_DEC=m # CONFIG_DVB_SIANO_SMS1XXX is not set # # Supported FlexCopII (B2C2) Adapters # CONFIG_DVB_B2C2_FLEXCOP=m CONFIG_DVB_B2C2_FLEXCOP_PCI=m CONFIG_DVB_B2C2_FLEXCOP_USB=m # CONFIG_DVB_B2C2_FLEXCOP_DEBUG is not set # # Supported BT878 Adapters # CONFIG_DVB_BT8XX=m # # Supported Pluto2 Adapters # # CONFIG_DVB_PLUTO2 is not set # # Supported SDMC DM1105 Adapters # # CONFIG_DVB_DM1105 is not set # # Supported DVB Frontends # # # Customise DVB Frontends # # CONFIG_DVB_FE_CUSTOMISE is not set # # DVB-S (satellite) frontends # CONFIG_DVB_CX24110=m CONFIG_DVB_CX24123=m CONFIG_DVB_MT312=m CONFIG_DVB_S5H1420=m CONFIG_DVB_STV0288=m CONFIG_DVB_STB6000=m CONFIG_DVB_STV0299=m CONFIG_DVB_TDA8083=m CONFIG_DVB_TDA10086=m CONFIG_DVB_VES1X93=m CONFIG_DVB_TUNER_ITD1000=m CONFIG_DVB_TDA826X=m CONFIG_DVB_TUA6100=m CONFIG_DVB_CX24116=m # CONFIG_DVB_SI21XX is not set # # DVB-T (terrestrial) frontends # CONFIG_DVB_SP8870=m CONFIG_DVB_SP887X=m CONFIG_DVB_CX22700=m CONFIG_DVB_CX22702=m # CONFIG_DVB_DRX397XD is not set CONFIG_DVB_L64781=m CONFIG_DVB_TDA1004X=m CONFIG_DVB_NXT6000=m CONFIG_DVB_MT352=m CONFIG_DVB_ZL10353=m CONFIG_DVB_DIB3000MB=m CONFIG_DVB_DIB3000MC=m CONFIG_DVB_DIB7000M=m CONFIG_DVB_DIB7000P=m CONFIG_DVB_TDA10048=m # # DVB-C (cable) frontends # CONFIG_DVB_VES1820=m CONFIG_DVB_TDA10021=m CONFIG_DVB_TDA10023=m CONFIG_DVB_STV0297=m # # ATSC (North American/Korean Terrestrial/Cable DTV) frontends # CONFIG_DVB_NXT200X=m CONFIG_DVB_OR51211=m CONFIG_DVB_OR51132=m CONFIG_DVB_BCM3510=m CONFIG_DVB_LGDT330X=m CONFIG_DVB_S5H1409=m CONFIG_DVB_AU8522=m CONFIG_DVB_S5H1411=m # # Digital terrestrial only tuners/PLL # CONFIG_DVB_PLL=m CONFIG_DVB_TUNER_DIB0070=m # # SEC control devices for DVB-S # CONFIG_DVB_LNBP21=m CONFIG_DVB_ISL6405=m CONFIG_DVB_ISL6421=m # CONFIG_DVB_LGS8GL5 is not set # # Tools to develop new frontends # # CONFIG_DVB_DUMMY_FE is not set # CONFIG_DVB_AF9013 is not set CONFIG_DAB=y CONFIG_USB_DABUSB=m # # Graphics support # CONFIG_AGP=m CONFIG_AGP_ALI=m CONFIG_AGP_ATI=m CONFIG_AGP_AMD=m CONFIG_AGP_AMD64=m CONFIG_AGP_INTEL=m CONFIG_AGP_NVIDIA=m CONFIG_AGP_SIS=m CONFIG_AGP_SWORKS=m CONFIG_AGP_VIA=m CONFIG_AGP_EFFICEON=m CONFIG_DRM=m CONFIG_DRM_TDFX=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m CONFIG_DRM_VIA=m CONFIG_DRM_SAVAGE=m CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=m CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set CONFIG_FB_SYS_FILLRECT=m CONFIG_FB_SYS_COPYAREA=m CONFIG_FB_SYS_IMAGEBLIT=m # CONFIG_FB_FOREIGN_ENDIAN is not set CONFIG_FB_SYS_FOPS=m CONFIG_FB_DEFERRED_IO=y CONFIG_FB_HECUBA=m CONFIG_FB_SVGALIB=m # CONFIG_FB_MACMODES is not set CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_CIRRUS=m CONFIG_FB_PM2=m CONFIG_FB_PM2_FIFO_DISCONNECT=y CONFIG_FB_CYBER2000=m CONFIG_FB_ARC=m # CONFIG_FB_ASILIANT is not set CONFIG_FB_IMSTT=y CONFIG_FB_VGA16=m CONFIG_FB_UVESA=m CONFIG_FB_VESA=y CONFIG_FB_N411=m CONFIG_FB_HGA=m CONFIG_FB_HGA_ACCEL=y CONFIG_FB_S1D13XXX=m CONFIG_FB_NVIDIA=m CONFIG_FB_NVIDIA_I2C=y # CONFIG_FB_NVIDIA_DEBUG is not set CONFIG_FB_NVIDIA_BACKLIGHT=y CONFIG_FB_RIVA=m CONFIG_FB_RIVA_I2C=y # CONFIG_FB_RIVA_DEBUG is not set CONFIG_FB_RIVA_BACKLIGHT=y CONFIG_FB_I810=m CONFIG_FB_I810_GTF=y CONFIG_FB_I810_I2C=y CONFIG_FB_LE80578=m CONFIG_FB_CARILLO_RANCH=m CONFIG_FB_INTEL=m # CONFIG_FB_INTEL_DEBUG is not set CONFIG_FB_INTEL_I2C=y CONFIG_FB_MATROX=m CONFIG_FB_MATROX_MILLENIUM=y CONFIG_FB_MATROX_MYSTIQUE=y CONFIG_FB_MATROX_G=y # CONFIG_FB_MATROX_I2C is not set CONFIG_FB_MATROX_MULTIHEAD=y CONFIG_FB_RADEON=m CONFIG_FB_RADEON_I2C=y CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set CONFIG_FB_ATY=m CONFIG_FB_ATY_CT=y CONFIG_FB_ATY_GENERIC_LCD=y CONFIG_FB_ATY_GX=y CONFIG_FB_ATY_BACKLIGHT=y CONFIG_FB_S3=m CONFIG_FB_SAVAGE=m CONFIG_FB_SAVAGE_I2C=y CONFIG_FB_SAVAGE_ACCEL=y CONFIG_FB_SIS=m CONFIG_FB_SIS_300=y CONFIG_FB_SIS_315=y # CONFIG_FB_VIA is not set CONFIG_FB_NEOMAGIC=m CONFIG_FB_KYRO=m CONFIG_FB_3DFX=m CONFIG_FB_3DFX_ACCEL=y CONFIG_FB_VOODOO1=m CONFIG_FB_VT8623=m CONFIG_FB_CYBLA=m CONFIG_FB_TRIDENT=m CONFIG_FB_TRIDENT_ACCEL=y CONFIG_FB_ARK=m CONFIG_FB_PM3=m # CONFIG_FB_CARMINE is not set CONFIG_FB_GEODE=y CONFIG_FB_GEODE_LX=m CONFIG_FB_GEODE_GX=m CONFIG_FB_GEODE_GX1=m CONFIG_FB_SM501=m # CONFIG_FB_VIRTUAL is not set # CONFIG_FB_METRONOME is not set # CONFIG_FB_MB862XX is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m # CONFIG_LCD_LTV350QV is not set # CONFIG_LCD_ILI9320 is not set # CONFIG_LCD_TDO24M is not set # CONFIG_LCD_VGG2432A4 is not set # CONFIG_LCD_PLATFORM is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_CORGI is not set CONFIG_BACKLIGHT_PROGEAR=m CONFIG_BACKLIGHT_CARILLO_RANCH=m # CONFIG_BACKLIGHT_MBP_NVIDIA is not set # CONFIG_BACKLIGHT_SAHARA is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=m # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_MDA_CONSOLE=m CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y # CONFIG_FONTS is not set CONFIG_FONT_8x8=y CONFIG_FONT_8x16=y # CONFIG_LOGO is not set CONFIG_SOUND=m CONFIG_SOUND_OSS_CORE=y CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_HWDEP=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y CONFIG_SND_DYNAMIC_MINORS=y CONFIG_SND_SUPPORT_OLD_API=y CONFIG_SND_VERBOSE_PROCFS=y CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y # CONFIG_SND_DEBUG_VERBOSE is not set # CONFIG_SND_PCM_XRUN_DEBUG is not set CONFIG_SND_VMASTER=y CONFIG_SND_MPU401_UART=m CONFIG_SND_OPL3_LIB=m CONFIG_SND_OPL4_LIB=m CONFIG_SND_VX_LIB=m CONFIG_SND_AC97_CODEC=m CONFIG_SND_DRIVERS=y CONFIG_SND_PCSP=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_MTS64=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m CONFIG_SND_PORTMAN2X4=m CONFIG_SND_AC97_POWER_SAVE=y CONFIG_SND_AC97_POWER_SAVE_DEFAULT=0 CONFIG_SND_WSS_LIB=m CONFIG_SND_SB_COMMON=m CONFIG_SND_SB8_DSP=m CONFIG_SND_SB16_DSP=m CONFIG_SND_ISA=y CONFIG_SND_ADLIB=m CONFIG_SND_AD1816A=m CONFIG_SND_AD1848=m CONFIG_SND_ALS100=m CONFIG_SND_AZT2320=m CONFIG_SND_CMI8330=m CONFIG_SND_CS4231=m CONFIG_SND_CS4232=m CONFIG_SND_CS4236=m CONFIG_SND_DT019X=m CONFIG_SND_ES968=m CONFIG_SND_ES1688=m CONFIG_SND_ES18XX=m # CONFIG_SND_SC6000 is not set CONFIG_SND_GUSCLASSIC=m CONFIG_SND_GUSEXTREME=m CONFIG_SND_GUSMAX=m CONFIG_SND_INTERWAVE=m CONFIG_SND_INTERWAVE_STB=m CONFIG_SND_OPL3SA2=m CONFIG_SND_OPTI92X_AD1848=m CONFIG_SND_OPTI92X_CS4231=m CONFIG_SND_OPTI93X=m CONFIG_SND_MIRO=m CONFIG_SND_SB8=m CONFIG_SND_SB16=m CONFIG_SND_SBAWE=m CONFIG_SND_SB16_CSP=y CONFIG_SND_SGALAXY=m CONFIG_SND_SSCAPE=m CONFIG_SND_WAVEFRONT=m # CONFIG_SND_WAVEFRONT_FIRMWARE_IN_KERNEL is not set CONFIG_SND_PCI=y CONFIG_SND_AD1889=m CONFIG_SND_ALS300=m CONFIG_SND_ALS4000=m CONFIG_SND_ALI5451=m CONFIG_SND_ATIIXP=m CONFIG_SND_ATIIXP_MODEM=m CONFIG_SND_AU8810=m CONFIG_SND_AU8820=m CONFIG_SND_AU8830=m CONFIG_SND_AW2=m CONFIG_SND_AZT3328=m CONFIG_SND_BT87X=m # CONFIG_SND_BT87X_OVERCLOCK is not set CONFIG_SND_CA0106=m CONFIG_SND_CMIPCI=m CONFIG_SND_OXYGEN_LIB=m CONFIG_SND_OXYGEN=m CONFIG_SND_CS4281=m CONFIG_SND_CS46XX=m CONFIG_SND_CS46XX_NEW_DSP=y # CONFIG_SND_CS5530 is not set CONFIG_SND_CS5535AUDIO=m CONFIG_SND_DARLA20=m CONFIG_SND_GINA20=m CONFIG_SND_LAYLA20=m CONFIG_SND_DARLA24=m CONFIG_SND_GINA24=m CONFIG_SND_LAYLA24=m CONFIG_SND_MONA=m CONFIG_SND_MIA=m CONFIG_SND_ECHO3G=m CONFIG_SND_INDIGO=m CONFIG_SND_INDIGOIO=m CONFIG_SND_INDIGODJ=m CONFIG_SND_EMU10K1=m CONFIG_SND_EMU10K1X=m CONFIG_SND_ENS1370=m CONFIG_SND_ENS1371=m CONFIG_SND_ES1938=m CONFIG_SND_ES1968=m CONFIG_SND_FM801=m CONFIG_SND_FM801_TEA575X_BOOL=y CONFIG_SND_FM801_TEA575X=m CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set # CONFIG_SND_HDA_INPUT_BEEP is not set CONFIG_SND_HDA_CODEC_REALTEK=y CONFIG_SND_HDA_CODEC_ANALOG=y CONFIG_SND_HDA_CODEC_SIGMATEL=y CONFIG_SND_HDA_CODEC_VIA=y CONFIG_SND_HDA_CODEC_ATIHDMI=y CONFIG_SND_HDA_CODEC_NVHDMI=y CONFIG_SND_HDA_CODEC_CONEXANT=y CONFIG_SND_HDA_CODEC_CMEDIA=y CONFIG_SND_HDA_CODEC_SI3054=y CONFIG_SND_HDA_GENERIC=y # CONFIG_SND_HDA_POWER_SAVE is not set CONFIG_SND_HDSP=m CONFIG_SND_HDSPM=m CONFIG_SND_HIFIER=m CONFIG_SND_ICE1712=m CONFIG_SND_ICE1724=m CONFIG_SND_INTEL8X0=m CONFIG_SND_INTEL8X0M=m CONFIG_SND_KORG1212=m CONFIG_SND_MAESTRO3=m CONFIG_SND_MIXART=m CONFIG_SND_NM256=m CONFIG_SND_PCXHR=m CONFIG_SND_RIPTIDE=m CONFIG_SND_RME32=m CONFIG_SND_RME96=m CONFIG_SND_RME9652=m CONFIG_SND_SIS7019=m CONFIG_SND_SONICVIBES=m CONFIG_SND_TRIDENT=m CONFIG_SND_VIA82XX=m CONFIG_SND_VIA82XX_MODEM=m CONFIG_SND_VIRTUOSO=m CONFIG_SND_VX222=m CONFIG_SND_YMFPCI=m CONFIG_SND_SPI=y CONFIG_SND_USB=y CONFIG_SND_USB_AUDIO=m CONFIG_SND_USB_USX2Y=m CONFIG_SND_USB_CAIAQ=m CONFIG_SND_USB_CAIAQ_INPUT=y # CONFIG_SND_USB_US122L is not set CONFIG_SND_PCMCIA=y CONFIG_SND_VXPOCKET=m CONFIG_SND_PDAUDIOCF=m # CONFIG_SND_SOC is not set CONFIG_SOUND_PRIME=m # CONFIG_SOUND_MSNDCLAS is not set # CONFIG_SOUND_MSNDPIN is not set CONFIG_SOUND_OSS=m CONFIG_SOUND_TRACEINIT=y CONFIG_SOUND_DMAP=y CONFIG_SOUND_SSCAPE=m CONFIG_SOUND_VMIDI=m CONFIG_SOUND_TRIX=m CONFIG_SOUND_MSS=m CONFIG_SOUND_MPU401=m CONFIG_SOUND_PAS=m CONFIG_SOUND_PSS=m CONFIG_PSS_MIXER=y # CONFIG_PSS_HAVE_BOOT is not set CONFIG_SOUND_SB=m CONFIG_SOUND_YM3812=m CONFIG_SOUND_UART6850=m CONFIG_SOUND_AEDSP16=m CONFIG_SC6600=y CONFIG_SC6600_JOY=y CONFIG_SC6600_CDROM=4 CONFIG_SC6600_CDROMBASE=0x0 CONFIG_SOUND_KAHLUA=m CONFIG_AC97_BUS=m CONFIG_HID_SUPPORT=y CONFIG_HID=y # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_HID_PID is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set # # Special HID drivers # CONFIG_HID_COMPAT=y CONFIG_HID_A4TECH=m CONFIG_HID_APPLE=m CONFIG_HID_BELKIN=m CONFIG_HID_BRIGHT=m CONFIG_HID_CHERRY=m CONFIG_HID_CHICONY=m CONFIG_HID_CYPRESS=m CONFIG_HID_DELL=m CONFIG_HID_EZKEY=m CONFIG_HID_GYRATION=m CONFIG_HID_LOGITECH=m # CONFIG_LOGITECH_FF is not set # CONFIG_LOGIRUMBLEPAD2_FF is not set CONFIG_HID_MICROSOFT=m CONFIG_HID_MONTEREY=m CONFIG_HID_PANTHERLORD=m # CONFIG_PANTHERLORD_FF is not set CONFIG_HID_PETALYNX=m CONFIG_HID_SAMSUNG=m CONFIG_HID_SONY=m CONFIG_HID_SUNPLUS=m # CONFIG_THRUSTMASTER_FF is not set # CONFIG_ZEROPLUS_FF is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set CONFIG_USB_ANNOUNCE_NEW_DEVICES=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # CONFIG_USB_OTG is not set CONFIG_USB_MON=y # CONFIG_USB_WUSB is not set # CONFIG_USB_WUSB_CBAF is not set # # USB Host Controller Drivers # CONFIG_USB_C67X00_HCD=m CONFIG_USB_EHCI_HCD=m CONFIG_USB_EHCI_ROOT_HUB_TT=y CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_ISP116X_HCD=m CONFIG_USB_ISP1760_HCD=m CONFIG_USB_OHCI_HCD=m CONFIG_USB_OHCI_HCD_SSB=y # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_U132_HCD is not set CONFIG_USB_SL811_HCD=m CONFIG_USB_SL811_CS=m CONFIG_USB_R8A66597_HCD=m # CONFIG_USB_WHCI_HCD is not set # CONFIG_USB_HWA_HCD is not set # # Enable Host or Gadget support to see Inventra options # # # USB Device Class drivers # CONFIG_USB_ACM=m CONFIG_USB_PRINTER=m CONFIG_USB_WDM=m # CONFIG_USB_TMC is not set # # NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may also be needed; # # # see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_ONETOUCH=y CONFIG_USB_STORAGE_KARMA=y # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # CONFIG_USB_MDC800=m CONFIG_USB_MICROTEK=m # # USB port drivers # CONFIG_USB_USS720=m CONFIG_USB_SERIAL=m CONFIG_USB_EZUSB=y CONFIG_USB_SERIAL_GENERIC=y CONFIG_USB_SERIAL_AIRCABLE=m CONFIG_USB_SERIAL_ARK3116=m CONFIG_USB_SERIAL_BELKIN=m CONFIG_USB_SERIAL_CH341=m CONFIG_USB_SERIAL_WHITEHEAT=m CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m CONFIG_USB_SERIAL_CP2101=m CONFIG_USB_SERIAL_CYPRESS_M8=m CONFIG_USB_SERIAL_EMPEG=m CONFIG_USB_SERIAL_FTDI_SIO=m CONFIG_USB_SERIAL_FUNSOFT=m CONFIG_USB_SERIAL_VISOR=m CONFIG_USB_SERIAL_IPAQ=m CONFIG_USB_SERIAL_IR=m CONFIG_USB_SERIAL_EDGEPORT=m CONFIG_USB_SERIAL_EDGEPORT_TI=m CONFIG_USB_SERIAL_GARMIN=m CONFIG_USB_SERIAL_IPW=m CONFIG_USB_SERIAL_IUU=m CONFIG_USB_SERIAL_KEYSPAN_PDA=m CONFIG_USB_SERIAL_KEYSPAN=m CONFIG_USB_SERIAL_KEYSPAN_MPR=y CONFIG_USB_SERIAL_KEYSPAN_USA28=y CONFIG_USB_SERIAL_KEYSPAN_USA28X=y CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y CONFIG_USB_SERIAL_KEYSPAN_USA18X=y CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y CONFIG_USB_SERIAL_KLSI=m CONFIG_USB_SERIAL_KOBIL_SCT=m CONFIG_USB_SERIAL_MCT_U232=m CONFIG_USB_SERIAL_MOS7720=m CONFIG_USB_SERIAL_MOS7840=m CONFIG_USB_SERIAL_MOTOROLA=m CONFIG_USB_SERIAL_NAVMAN=m CONFIG_USB_SERIAL_PL2303=m CONFIG_USB_SERIAL_OTI6858=m CONFIG_USB_SERIAL_SPCP8X5=m CONFIG_USB_SERIAL_HP4X=m CONFIG_USB_SERIAL_SAFE=m CONFIG_USB_SERIAL_SAFE_PADDED=y CONFIG_USB_SERIAL_SIERRAWIRELESS=m CONFIG_USB_SERIAL_TI=m CONFIG_USB_SERIAL_CYBERJACK=m CONFIG_USB_SERIAL_XIRCOM=m CONFIG_USB_SERIAL_OPTION=m CONFIG_USB_SERIAL_OMNINET=m CONFIG_USB_SERIAL_DEBUG=m # # USB Miscellaneous drivers # CONFIG_USB_EMI62=m CONFIG_USB_EMI26=m CONFIG_USB_ADUTUX=m # CONFIG_USB_SEVSEG is not set CONFIG_USB_RIO500=m CONFIG_USB_LEGOTOWER=m CONFIG_USB_LCD=m CONFIG_USB_BERRY_CHARGE=m CONFIG_USB_LED=m CONFIG_USB_CYPRESS_CY7C63=m CONFIG_USB_CYTHERM=m CONFIG_USB_PHIDGET=m CONFIG_USB_PHIDGETKIT=m CONFIG_USB_PHIDGETMOTORCONTROL=m CONFIG_USB_PHIDGETSERVO=m CONFIG_USB_IDMOUSE=m CONFIG_USB_FTDI_ELAN=m CONFIG_USB_APPLEDISPLAY=m CONFIG_USB_SISUSBVGA=m CONFIG_USB_SISUSBVGA_CON=y CONFIG_USB_LD=m CONFIG_USB_TRANCEVIBRATOR=m CONFIG_USB_IOWARRIOR=m # CONFIG_USB_TEST is not set CONFIG_USB_ISIGHTFW=m # CONFIG_USB_VST is not set CONFIG_USB_ATM=m CONFIG_USB_SPEEDTOUCH=m CONFIG_USB_CXACRU=m CONFIG_USB_UEAGLEATM=m CONFIG_USB_XUSBATM=m # CONFIG_USB_GADGET is not set # CONFIG_UWB is not set CONFIG_MMC=m # CONFIG_MMC_DEBUG is not set # CONFIG_MMC_UNSAFE_RESUME is not set # # MMC/SD/SDIO Card Drivers # CONFIG_MMC_BLOCK=m CONFIG_MMC_BLOCK_BOUNCE=y CONFIG_SDIO_UART=m CONFIG_MMC_TEST=m # # MMC/SD/SDIO Host Controller Drivers # CONFIG_MMC_SDHCI=m # CONFIG_MMC_SDHCI_PCI is not set CONFIG_MMC_WBSD=m CONFIG_MMC_TIFM_SD=m # CONFIG_MMC_SDRICOH_CS is not set CONFIG_MEMSTICK=m # CONFIG_MEMSTICK_DEBUG is not set # # MemoryStick drivers # # CONFIG_MEMSTICK_UNSAFE_RESUME is not set CONFIG_MSPRO_BLOCK=m # # MemoryStick Host Controller Drivers # CONFIG_MEMSTICK_TIFM_MS=m CONFIG_MEMSTICK_JMICRON_38X=m CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=m # # LED drivers # CONFIG_LEDS_NET48XX=m CONFIG_LEDS_WRAP=m # CONFIG_LEDS_PCA9532 is not set # CONFIG_LEDS_HP_DISK is not set CONFIG_LEDS_CLEVO_MAIL=m # CONFIG_LEDS_PCA955X is not set # # LED Triggers # CONFIG_LEDS_TRIGGERS=y CONFIG_LEDS_TRIGGER_TIMER=m CONFIG_LEDS_TRIGGER_IDE_DISK=y CONFIG_LEDS_TRIGGER_HEARTBEAT=m # CONFIG_LEDS_TRIGGER_BACKLIGHT is not set CONFIG_LEDS_TRIGGER_DEFAULT_ON=m # CONFIG_ACCESSIBILITY is not set CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_USER_MEM=y CONFIG_INFINIBAND_ADDR_TRANS=y CONFIG_INFINIBAND_MTHCA=m CONFIG_INFINIBAND_MTHCA_DEBUG=y CONFIG_INFINIBAND_AMSO1100=m # CONFIG_INFINIBAND_AMSO1100_DEBUG is not set CONFIG_INFINIBAND_CXGB3=m # CONFIG_INFINIBAND_CXGB3_DEBUG is not set CONFIG_MLX4_INFINIBAND=m CONFIG_INFINIBAND_NES=m # CONFIG_INFINIBAND_NES_DEBUG is not set CONFIG_INFINIBAND_IPOIB=m CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_IPOIB_DEBUG=y # CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set CONFIG_INFINIBAND_SRP=m CONFIG_INFINIBAND_ISER=m # CONFIG_EDAC is not set CONFIG_RTC_LIB=m CONFIG_RTC_CLASS=m # # RTC interfaces # CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=m # # I2C RTC drivers # CONFIG_RTC_DRV_DS1307=m CONFIG_RTC_DRV_DS1374=m CONFIG_RTC_DRV_DS1672=m CONFIG_RTC_DRV_MAX6900=m CONFIG_RTC_DRV_RS5C372=m CONFIG_RTC_DRV_ISL1208=m CONFIG_RTC_DRV_X1205=m CONFIG_RTC_DRV_PCF8563=m CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_M41T80=m # CONFIG_RTC_DRV_M41T80_WDT is not set CONFIG_RTC_DRV_S35390A=m CONFIG_RTC_DRV_FM3130=m # CONFIG_RTC_DRV_RX8581 is not set # # SPI RTC drivers # # CONFIG_RTC_DRV_M41T94 is not set # CONFIG_RTC_DRV_DS1305 is not set # CONFIG_RTC_DRV_DS1390 is not set CONFIG_RTC_DRV_MAX6902=m CONFIG_RTC_DRV_R9701=m CONFIG_RTC_DRV_RS5C348=m # CONFIG_RTC_DRV_DS3234 is not set # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=m # CONFIG_RTC_DRV_DS1286 is not set CONFIG_RTC_DRV_DS1511=m CONFIG_RTC_DRV_DS1553=m CONFIG_RTC_DRV_DS1742=m CONFIG_RTC_DRV_STK17TA8=m CONFIG_RTC_DRV_M48T86=m # CONFIG_RTC_DRV_M48T35 is not set CONFIG_RTC_DRV_M48T59=m # CONFIG_RTC_DRV_BQ4802 is not set CONFIG_RTC_DRV_V3020=m # # on-CPU RTC drivers # # CONFIG_DMADEVICES is not set # CONFIG_AUXDISPLAY is not set CONFIG_UIO=m CONFIG_UIO_CIF=m # CONFIG_UIO_PDRV is not set # CONFIG_UIO_PDRV_GENIRQ is not set CONFIG_UIO_SMX=m # CONFIG_UIO_SERCOS3 is not set # CONFIG_STAGING is not set # # Firmware Drivers # CONFIG_EDD=m # CONFIG_EDD_OFF is not set CONFIG_FIRMWARE_MEMMAP=y CONFIG_DELL_RBU=m CONFIG_DCDBAS=m CONFIG_DMIID=y # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=m CONFIG_EXT2_FS_XATTR=y CONFIG_EXT2_FS_POSIX_ACL=y CONFIG_EXT2_FS_SECURITY=y # CONFIG_EXT2_FS_XIP is not set CONFIG_EXT3_FS=m CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4_FS is not set CONFIG_JBD=m CONFIG_JBD_DEBUG=y CONFIG_JBD2=m CONFIG_JBD2_DEBUG=y CONFIG_FS_MBCACHE=m CONFIG_REISERFS_FS=m # CONFIG_REISERFS_CHECK is not set # CONFIG_REISERFS_PROC_INFO is not set CONFIG_REISERFS_FS_XATTR=y CONFIG_REISERFS_FS_POSIX_ACL=y CONFIG_REISERFS_FS_SECURITY=y CONFIG_JFS_FS=m CONFIG_JFS_POSIX_ACL=y CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set CONFIG_JFS_STATISTICS=y CONFIG_FS_POSIX_ACL=y CONFIG_FILE_LOCKING=y CONFIG_XFS_FS=m CONFIG_XFS_QUOTA=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y # CONFIG_XFS_DEBUG is not set CONFIG_GFS2_FS=m CONFIG_GFS2_FS_LOCKING_DLM=m CONFIG_OCFS2_FS=m CONFIG_OCFS2_FS_O2CB=m CONFIG_OCFS2_FS_USERSPACE_CLUSTER=m CONFIG_OCFS2_FS_STATS=y # CONFIG_OCFS2_DEBUG_MASKLOG is not set # CONFIG_OCFS2_DEBUG_FS is not set # CONFIG_OCFS2_COMPAT_JBD is not set CONFIG_DNOTIFY=y CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_QUOTA=y # CONFIG_QUOTA_NETLINK_INTERFACE is not set CONFIG_PRINT_QUOTA_WARNING=y CONFIG_QFMT_V1=m CONFIG_QFMT_V2=m CONFIG_QUOTACTL=y CONFIG_AUTOFS_FS=m CONFIG_AUTOFS4_FS=m CONFIG_FUSE_FS=m CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=y CONFIG_JOLIET=y CONFIG_ZISOFS=y CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m CONFIG_MSDOS_FS=m CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_VMCORE=y CONFIG_PROC_SYSCTL=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_HUGETLB_PAGE=y CONFIG_CONFIGFS_FS=m # # Miscellaneous filesystems # CONFIG_ADFS_FS=m # CONFIG_ADFS_FS_RW is not set CONFIG_AFFS_FS=m CONFIG_ECRYPT_FS=m CONFIG_HFS_FS=m CONFIG_HFSPLUS_FS=m CONFIG_BEFS_FS=m # CONFIG_BEFS_DEBUG is not set CONFIG_BFS_FS=m CONFIG_EFS_FS=m CONFIG_JFFS2_FS=m CONFIG_JFFS2_FS_DEBUG=0 CONFIG_JFFS2_FS_WRITEBUFFER=y # CONFIG_JFFS2_FS_WBUF_VERIFY is not set CONFIG_JFFS2_SUMMARY=y CONFIG_JFFS2_FS_XATTR=y CONFIG_JFFS2_FS_POSIX_ACL=y CONFIG_JFFS2_FS_SECURITY=y CONFIG_JFFS2_COMPRESSION_OPTIONS=y CONFIG_JFFS2_ZLIB=y CONFIG_JFFS2_LZO=y CONFIG_JFFS2_RTIME=y # CONFIG_JFFS2_RUBIN is not set # CONFIG_JFFS2_CMODE_NONE is not set CONFIG_JFFS2_CMODE_PRIORITY=y # CONFIG_JFFS2_CMODE_SIZE is not set # CONFIG_JFFS2_CMODE_FAVOURLZO is not set # CONFIG_UBIFS_FS is not set CONFIG_CRAMFS=m CONFIG_VXFS_FS=m CONFIG_MINIX_FS=y # CONFIG_OMFS_FS is not set CONFIG_HPFS_FS=m CONFIG_QNX4FS_FS=m CONFIG_ROMFS_FS=m CONFIG_SYSV_FS=m CONFIG_UFS_FS=m CONFIG_UFS_FS_WRITE=y # CONFIG_UFS_DEBUG is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m CONFIG_SUNRPC_GSS=m CONFIG_SUNRPC_XPRT_RDMA=m # CONFIG_SUNRPC_REGISTER_V4 is not set CONFIG_RPCSEC_GSS_KRB5=m CONFIG_RPCSEC_GSS_SPKM3=m # CONFIG_SMB_FS is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_STATS2=y CONFIG_CIFS_WEAK_PW_HASH=y # CONFIG_CIFS_UPCALL is not set CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set CONFIG_NCP_FS=m CONFIG_NCPFS_PACKET_SIGNING=y CONFIG_NCPFS_IOCTL_LOCKING=y CONFIG_NCPFS_STRONG=y CONFIG_NCPFS_NFS_NS=y CONFIG_NCPFS_OS2_NS=y CONFIG_NCPFS_SMALLDOS=y CONFIG_NCPFS_NLS=y CONFIG_NCPFS_EXTRAS=y CONFIG_CODA_FS=m CONFIG_AFS_FS=m # CONFIG_AFS_DEBUG is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y # CONFIG_ACORN_PARTITION is not set CONFIG_OSF_PARTITION=y # CONFIG_AMIGA_PARTITION is not set CONFIG_ATARI_PARTITION=y CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y # CONFIG_MINIX_SUBPARTITION is not set CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y # CONFIG_LDM_DEBUG is not set CONFIG_SGI_PARTITION=y CONFIG_ULTRIX_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y CONFIG_SYSV68_PARTITION=y CONFIG_NLS=y CONFIG_NLS_DEFAULT="utf8" CONFIG_NLS_CODEPAGE_437=m CONFIG_NLS_CODEPAGE_737=m CONFIG_NLS_CODEPAGE_775=m CONFIG_NLS_CODEPAGE_850=m CONFIG_NLS_CODEPAGE_852=m CONFIG_NLS_CODEPAGE_855=m CONFIG_NLS_CODEPAGE_857=m CONFIG_NLS_CODEPAGE_860=m CONFIG_NLS_CODEPAGE_861=m CONFIG_NLS_CODEPAGE_862=m CONFIG_NLS_CODEPAGE_863=m CONFIG_NLS_CODEPAGE_864=m CONFIG_NLS_CODEPAGE_865=m CONFIG_NLS_CODEPAGE_866=m CONFIG_NLS_CODEPAGE_869=m CONFIG_NLS_CODEPAGE_936=m CONFIG_NLS_CODEPAGE_950=m CONFIG_NLS_CODEPAGE_932=m CONFIG_NLS_CODEPAGE_949=m CONFIG_NLS_CODEPAGE_874=m CONFIG_NLS_ISO8859_8=m CONFIG_NLS_CODEPAGE_1250=m CONFIG_NLS_CODEPAGE_1251=m CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m CONFIG_NLS_ISO8859_2=m CONFIG_NLS_ISO8859_3=m CONFIG_NLS_ISO8859_4=m CONFIG_NLS_ISO8859_5=m CONFIG_NLS_ISO8859_6=m CONFIG_NLS_ISO8859_7=m CONFIG_NLS_ISO8859_9=m CONFIG_NLS_ISO8859_13=m CONFIG_NLS_ISO8859_14=m CONFIG_NLS_ISO8859_15=m CONFIG_NLS_KOI8_R=m CONFIG_NLS_KOI8_U=m CONFIG_NLS_UTF8=m CONFIG_DLM=m # CONFIG_DLM_DEBUG is not set # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=1024 CONFIG_MAGIC_SYSRQ=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_KERNEL is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_MEMORY_INIT=y # CONFIG_LATENCYTOP is not set CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_HAVE_FUNCTION_TRACER=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y # # Tracers # # CONFIG_SYSPROF_TRACER is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_DYNAMIC_PRINTK_DEBUG is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_STRICT_DEVMEM is not set CONFIG_X86_VERBOSE_BOOTUP=y CONFIG_EARLY_PRINTK=y # CONFIG_EARLY_PRINTK_DBGP is not set # CONFIG_4KSTACKS is not set CONFIG_DOUBLEFAULT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_OPTIMIZE_INLINING is not set # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_SECURITY=y CONFIG_SECURITYFS=y CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_FILE_CAPABILITIES is not set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 # CONFIG_SECURITY_SELINUX is not set CONFIG_XOR_BLOCKS=m CONFIG_ASYNC_CORE=m CONFIG_ASYNC_MEMCPY=m CONFIG_ASYNC_XOR=m CONFIG_CRYPTO=y # # Crypto core or helper # # CONFIG_CRYPTO_FIPS is not set CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=m CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_GF128MUL=m CONFIG_CRYPTO_NULL=m CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m CONFIG_CRYPTO_TEST=m # # Authenticated Encryption with Associated Data # CONFIG_CRYPTO_CCM=m CONFIG_CRYPTO_GCM=m CONFIG_CRYPTO_SEQIV=m # # Block modes # CONFIG_CRYPTO_CBC=m CONFIG_CRYPTO_CTR=m # CONFIG_CRYPTO_CTS is not set CONFIG_CRYPTO_ECB=m CONFIG_CRYPTO_LRW=m CONFIG_CRYPTO_PCBC=m CONFIG_CRYPTO_XTS=m # # Hash modes # CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=m # # Digest # CONFIG_CRYPTO_CRC32C=m # CONFIG_CRYPTO_CRC32C_INTEL is not set CONFIG_CRYPTO_MD4=m CONFIG_CRYPTO_MD5=m CONFIG_CRYPTO_MICHAEL_MIC=m # CONFIG_CRYPTO_RMD128 is not set # CONFIG_CRYPTO_RMD160 is not set # CONFIG_CRYPTO_RMD256 is not set # CONFIG_CRYPTO_RMD320 is not set CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m CONFIG_CRYPTO_TGR192=m CONFIG_CRYPTO_WP512=m # # Ciphers # CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m CONFIG_CRYPTO_ANUBIS=m CONFIG_CRYPTO_ARC4=m CONFIG_CRYPTO_BLOWFISH=m CONFIG_CRYPTO_CAMELLIA=m CONFIG_CRYPTO_CAST5=m CONFIG_CRYPTO_CAST6=m CONFIG_CRYPTO_DES=m CONFIG_CRYPTO_FCRYPT=m CONFIG_CRYPTO_KHAZAD=m CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_586=m CONFIG_CRYPTO_SEED=m CONFIG_CRYPTO_SERPENT=m CONFIG_CRYPTO_TEA=m # CONFIG_CRYPTO_TWOFISH is not set CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_LZO=m # # Random Number Generation # # CONFIG_CRYPTO_ANSI_CPRNG is not set CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=m CONFIG_CRYPTO_DEV_PADLOCK_AES=m CONFIG_CRYPTO_DEV_PADLOCK_SHA=m CONFIG_CRYPTO_DEV_GEODE=m CONFIG_CRYPTO_DEV_HIFN_795X=m # CONFIG_CRYPTO_DEV_HIFN_795X_RNG is not set CONFIG_HAVE_KVM=y # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_CRC_CCITT=m CONFIG_CRC16=m # CONFIG_CRC_T10DIF is not set CONFIG_CRC_ITU_T=m CONFIG_CRC32=y CONFIG_CRC7=m CONFIG_LIBCRC32C=m CONFIG_AUDIT_GENERIC=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=m CONFIG_LZO_COMPRESS=m CONFIG_LZO_DECOMPRESS=m CONFIG_GENERIC_ALLOCATOR=y CONFIG_REED_SOLOMON=m CONFIG_REED_SOLOMON_DEC16=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y
For what it is worth, here are the results from my debian testing box under 2.6.32_exact-55846-gf405425 $ lsmod |grep floppy floppy 45327 0 # setfdprm /dev/fd0 HD # fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1 # floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd seek 0 1 0: 20 1: 1 no disk change # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change ael
ael wrote:
For what it is worth, here are the results from my debian testing box under 2.6.32_exact-55846-gf405425
$ lsmod |grep floppy floppy 45327 0
# setfdprm /dev/fd0 HD # fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1
# floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change
# fdrawcmd seek 0 1 0: 20 1: 1 no disk change
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change
ael
Wow, why are the sectors not shown in order and why do you seem to have 2 sector 10s. I'm just figuring out what I'm looking at but this looks really strange to me as opposed to what I've been seeing. Mark
On 15/12/09 15:59, ael wrote:
For what it is worth, here are the results from my debian testing box under 2.6.32_exact-55846-gf405425
$ lsmod |grep floppy floppy 45327 0
# setfdprm /dev/fd0 HD # fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1
# floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change
# fdrawcmd seek 0 1 0: 20 1: 1 no disk change
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change
0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change
ael
This does indeed look like a different problem to me... No sector with a "bad" track id, but lots of sectors "skipped". But these skips look more like they are happening during read (rather than being really missed), as on the second pass, they are present. Could you try the same with a "higher" repetition count: fdrawcmd readid 0 repeat=40 Just to make sure that eventually all sectors show up Also, on your case, the actual read error seems to be on track 0. Could you give me also the headers of track 0? Thanks, Alain
Alain Knaff wrote:
Could you try the same with a "higher" repetition count:
fdrawcmd readid 0 repeat=40
Just to make sure that eventually all sectors show up
Also, on your case, the actual read error seems to be on track 0. Could you give me also the headers of track 0?
Have to go out for an hour or more, so can't report immediately. ael
On 12/15/2009 10:08 AM, Alain Knaff wrote:
This does indeed look like a different problem to me... No sector with a "bad" track id, but lots of sectors "skipped". But these skips look more like they are happening during read (rather than being really missed), as on the second pass, they are present.
Could you try the same with a "higher" repetition count:
fdrawcmd readid 0 repeat=40
Just to make sure that eventually all sectors show up
Also, on your case, the actual read error seems to be on track 0. Could you give me also the headers of track 0?
Just to further complicate things, or maybe not... I mentioned I had multiple machines with this problem. Some running different versions of SuSE. Mainly 11.0, which is where all the info I've provided came from thus far. This machine also has a SuSE-11.2 disk on it. When I do all this using SuSE-11.2 my results look more like ael's. So I think when the cause is found, it will be a single cause. Regards Mark
Mark Hounschell wrote:
On 12/15/2009 10:08 AM, Alain Knaff wrote:
I mentioned I had multiple machines with this problem. Some running different versions of SuSE. Mainly 11.0, which is where all the info I've provided came from thus far. This machine also has a SuSE-11.2 disk on it. When I do all this using SuSE-11.2 my results look more like ael's.
So I think when the cause is found, it will be a single cause.
Uninitialised variable? gcc version bugs? I know that doesn't really help in tracking things down... :-( About to run with repeat=40. I have only just downloaded the data sheet and have only skimmed small portions, so I have some catching up to do... ael
ael wrote:
Mark Hounschell wrote:
On 12/15/2009 10:08 AM, Alain Knaff wrote:
I mentioned I had multiple machines with this problem. Some running different versions of SuSE. Mainly 11.0, which is where all the info I've provided came from thus far. This machine also has a SuSE-11.2 disk on it. When I do all this using SuSE-11.2 my results look more like ael's.
So I think when the cause is found, it will be a single cause.
Uninitialised variable? gcc version bugs?
In any case, something very veird must be going on. Thhis is the loop that initializes the track headers, everything except for the sector numbers: for (count = 0; count < F_SECT_PER_TRACK; ++count) { here[count].track = format_req.track; here[count].head = format_req.head; here[count].sect = 0; here[count].size = F_SIZECODE; } The unitialized sector is always the first one of the track (not necessarily the lowest numbered, because of skew...). Other fields (most notably head) are initialized correctly, and only track seems to have the value from the previous call. Weird. If you suspect a compiler bug, it might be interesting to compile a kernel on one box, but run it on the other, just to see whether anything interesting happens...
I know that doesn't really help in tracking things down... :-(
About to run with repeat=40. I have only just downloaded the data sheet and have only skimmed small portions, so I have some catching up to do...
ael
Alain
Alain Knaff wrote:
ael wrote:
Mark Hounschell wrote:
On 12/15/2009 10:08 AM, Alain Knaff wrote: I mentioned I had multiple machines with this problem. Some running different versions of SuSE. Mainly 11.0, which is where all the info I've provided came from thus far. This machine also has a SuSE-11.2 disk on it. When I do all this using SuSE-11.2 my results look more like ael's.
So I think when the cause is found, it will be a single cause. Uninitialised variable? gcc version bugs?
[..snip..]
Weird.
If you suspect a compiler bug,
No, not really. I was just grasping at straws trying to think what could vary among distributions if they are all using the same source code. I guess almost anything non-deterministic *might* show in different distributions. On the other hand, one of my machines seems to have "mended" itself - at least it worked on a single test 2 days ago - so that might fit again with some non determinism around timing. Anyhow, I wasting time because this sort of speculation isn't likely to help find the bug.... ael
Alain Knaff wrote:
Could you try the same with a "higher" repetition count:
On same floppy (medium) as before: # fdrawcmd readid 0 repeat=40 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change # fdrawcmd readid 0 repeat=40 2>&1 |grep "^5:" 5: 9 5: a 5: b 5: e 5: f 5: 10 5: 12 5: 1 5: 4 5: 5 5: 6 5: 7 5: 8 5: 9 5: a 5: c 5: e 5: f 5: 10 5: 11 5: 12 5: 1 5: 4 5: 5 5: 6 5: 7 5: 9 5: c 5: d 5: e 5: 10 5: 11 5: 12 5: 1 5: 2 5: 3 5: 6 5: 7 5: 9 5: a ??? ael
ael wrote:
Alain Knaff wrote:
Could you try the same with a "higher" repetition count:
On same floppy (medium) as before: [...]
All sector ids seem to be present (although occasionally they are skipped during read...), and track is correct everywhere... but if I remember correctly, you got the error on track 0. So it might be interesting to the headers of track 0 rather than 1. Regards, Alain
Alain Knaff wrote:
Also, on your case, the actual read error seems to be on track 0. Could you give me also the headers of track 0?
# fdrawcmd seek 0 0 0: 20 1: 0 no disk change # fdrawcmd readid 0 repeat=40 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: e 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 11 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 4 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 5 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 6 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 7 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 8 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: b 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: c 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: d 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: f 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 10 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 3 6: 2 no disk change # fdrawcmd readid 0 repeat=40 2>&1 |grep "^5:" 5: 8 5: 9 5: a 5: b 5: c 5: d 5: e 5: f 5: 10 5: 11 5: 12 5: 1 5: 2 5: 3 5: 5 5: 6 5: 7 5: 8 5: 9 5: a 5: b 5: d 5: e 5: f 5: 10 5: 11 5: 12 5: 1 5: 2 5: 3 5: 4 5: 8 5: 9 5: a 5: b 5: c 5: d 5: e 5: f 5: 10 Is that what you wanted? ael
Alain Knaff wrote:
ael wrote:
Is that what you wanted?
ael
Yes. All sectors are there, ... so I wonder why you are getting errors.
So, next round of tests: trying to read these sectors:
fdrawcmd recalibrate 0 fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 >/dev/null
# fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 >/dev/null remaining= 17920 0: 40 1: 20 2: 20 3: 0 4: 0 5: 1 6: 2 no disk change
A.E.Lawrence wrote:
Alain Knaff wrote:
ael wrote:
Is that what you wanted?
ael Yes. All sectors are there, ... so I wonder why you are getting errors.
So, next round of tests: trying to read these sectors:
fdrawcmd recalibrate 0 fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 >/dev/null
# fdrawcmd recalibrate 0 0: 20 1: 0 no disk change
# fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 >/dev/null remaining= 17920 0: 40 1: 20 2: 20 3: 0 4: 0 5: 1 6: 2 no disk change
A CRC error both in the header (1: 20) and in the data of the sector (2: 20) It begins to look more and more like a hardware problem, at least in your case... Now it might be interesting to check it for all sectors separately. fdrawcmd read 0 0 0 1 2 18 1 1 length=512 >/dev/null fdrawcmd read 0 0 0 2 2 18 1 1 length=512 >/dev/null fdrawcmd read 0 0 0 3 2 18 1 1 length=512 >/dev/null ... fdrawcmd read 0 0 0 18 2 18 1 1 length=512 >/dev/null fdrawcmd read 4 0 1 1 2 18 1 1 length=512 >/dev/null fdrawcmd read 4 0 1 2 2 18 1 1 length=512 >/dev/null ... fdrawcmd read 4 0 1 18 2 18 1 1 length=512 >/dev/null Which ones succeed, which ones fail... Alain
Alain Knaff wrote:
A.E.Lawrence wrote:
Alain Knaff wrote:
ael wrote:
Is that what you wanted?
ael Yes. All sectors are there, ... so I wonder why you are getting errors.
So, next round of tests: trying to read these sectors:
fdrawcmd recalibrate 0 fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 >/dev/null
# fdrawcmd recalibrate 0 0: 20 1: 0 no disk change
# fdrawcmd read 0 0 0 1 2 18 1 1 length=18432 >/dev/null remaining= 17920 0: 40 1: 20 2: 20 3: 0 4: 0 5: 1 6: 2 no disk change
A CRC error both in the header (1: 20) and in the data of the sector (2: 20)
It begins to look more and more like a hardware problem, at least in your case...
I am pretty confident that I had ruled out hardware. I haven't tried the formatting floppies in my amd64 debian testing box for a while, but that was showing exactly the same problem. Maybe if I can test that again tomorrow if necessary. But the Mark said he was seeing something very similar: we can't both have the same hardware problems on multiple machines? ael
ael wrote:
I am pretty confident that I had ruled out hardware. I haven't tried the formatting floppies in my amd64 debian testing box for a while, but that was showing exactly the same problem. Maybe if I can test that again tomorrow if necessary. But the Mark said he was seeing something very similar: we can't both have the same hardware problems on multiple machines?
ael, are you sure you can't try a vanilla 2.6.27.41 kernel? That kernel should run on any current dist. You only have to get it up far enough to format a floppy. Even single user mode would probably work? Mark
Mark Hounschell wrote:
ael wrote:
I am pretty confident that I had ruled out hardware. I haven't tried the formatting floppies in my amd64 debian testing box for a while, but that was showing exactly the same problem. Maybe if I can test that again tomorrow if necessary. But the Mark said he was seeing something very similar: we can't both have the same hardware problems on multiple machines?
Also, just because I think I am seeing (on SuSE-11.2) what you are seeing doesn't make it so. I'm not the expert here so Alain could be right. One thing I know for sure, if it doesn't work on 2.6.27.41 or older kernel, you have a hardware problem. regards Mark
Mark Hounschell wrote:
Mark Hounschell wrote:
ael wrote:
I am pretty confident that I had ruled out hardware. I haven't tried the
I am embarrassed to say that I *do* now suspect the floppy drive on the i386 box that I have been using for the majority of my testing. Mark prompted me to find that I had a 2.6.26-1-686 Debian kernel that I could boot. fdformat failed on that. I even resorted to trying another very old op system on this same box and tried to format with that. That appeared to succeed but only after grinding away at the floppy drive for maybe 10 minutes :-) Rebooting into sanity, attempts to read the floppy still gave CRC errors. I then took the same floppy (medium) and tried it on another debian testing i386, and it succeeded. And I could dd to the floppy and also dd from the same floppy back on the box with the current failures. Now I was absolutely convinced that I had eliminated media problems: that stands up. I was also sure that I had eliminated hardware problems, but now that is in question. It is too late to do more tonight, but I will test around all 3 debian testing boxes again tomorrow and report. But for now, I think you should regard my results as possibly hardware related after. I do apologise for wasting so much time and effort... ael
It seems to me that a compiler problem is not at all out of the question. Probably the version of the compiler that compiled the kernel. +-----------------------------------------------------------+ | David C Niemi (Reston, VA, USA) niemi at tuxers dot net | +-----------------------------------------------------------+
On 15/12/09 23:54, ael wrote:
I am embarrassed to say that I *do* now suspect the floppy drive on the i386 box that I have been using for the majority of my testing.
Mark prompted me to find that I had a 2.6.26-1-686 Debian kernel that I could boot. fdformat failed on that. I even resorted to trying another very old op system on this same box and tried to format with that. That appeared to succeed but only after grinding away at the floppy drive for maybe 10 minutes :-) Rebooting into sanity, attempts to read the floppy still gave CRC errors. I then took the same floppy (medium) and tried it on another debian testing i386, and it succeeded. And I could dd to the floppy and also dd from the same floppy back on the box with the current failures.
Now I was absolutely convinced that I had eliminated media problems: that stands up. I was also sure that I had eliminated hardware problems, but now that is in question.
It is too late to do more tonight, but I will test around all 3 debian testing boxes again tomorrow and report.
But for now, I think you should regard my results as possibly hardware related after.
I do apologise for wasting so much time and effort...
ael
Apologies accepted. In any case, your symptoms looked different from Mark's (CRC error, rather than sector with wrong cylinder label), so I already figured that the cause must have been different. Regards, Alain
Alain Knaff wrote:
On 15/12/09 23:54, ael wrote:
I am embarrassed to say that I *do* now suspect the floppy drive on the
Sorry for the delay: I have ordered a couple of replacement drives and that always takes longer than it should. Yes, it seems it was a faulty drive. I have confirmed everything is now working on an amd64 debian testing box. I really did see problems there as well: I now wonder whether I really understood how to use get/setfdprm properly back then. I often find that I need to use setfdprm a few times before getfdprm sees the result. Sometimes I have to explicitly "modprobe floppy" before that works. Anyway, further apologies for not checking the drives more thoroughly before posting bugs... Congratulations on tracking Mark's problem at least as far as dma. ael
ael wrote:
Yes, it seems it was a faulty drive.
Faulty - but maybe just needing the heads cleaning with a bit of isopropanol. PC's are horrible for killing drives because they push air out of the machine via the back, and have a habit of sucking it in through the front via the floppy drive door. The less the drive's used, the worse it gets... cheers Jules
Jules Richardson wrote:
ael wrote:
Yes, it seems it was a faulty drive.
Faulty - but maybe just needing the heads cleaning with a bit of isopropanol.
Yes, I know. But as replacement drives are so cheap (if you go to the right place) and also rather rare these days, I want some backups anyway. It is such a pain dismantling a machine to get to the drive, I don't want to do it twice if cleaning doesn't fix the problem. Of course, a nightmare would be if it is the controller: that would be a motherboard replacement ... ael
For the record, after replacing drives *and* cables, the problem persists. I can only assume that it is the controller after all :-( I think I will live without a floppy on that particular box. ael
Mark Hounschell wrote:
ael wrote:
I am pretty confident that I had ruled out hardware. I haven't tried the formatting floppies in my amd64 debian testing box for a while, but that was showing exactly the same problem. Maybe if I can test that again tomorrow if necessary. But the Mark said he was seeing something very similar: we can't both have the same hardware problems on multiple machines?
ael, are you sure you can't try a vanilla 2.6.27.41 kernel? That kernel should run on any current dist. You only have to get it up far enough to format a floppy. Even single user mode would probably work?
Not easily. I am not sure just what I would need to do: a fair bit of work on a .config, I suspect. I have just noticed that I have a 2.6.26 kernel compiled on this machine, and with a matching initrd, so it might just run with that. I will give it a whirl. ael
Alain Knaff wrote:
fdrawcmd read 0 0 0 1 2 18 1 1 length=512 >/dev/null fdrawcmd read 0 0 0 2 2 18 1 1 length=512 >/dev/null fdrawcmd read 0 0 0 3 2 18 1 1 length=512 >/dev/null ... fdrawcmd read 0 0 0 18 2 18 1 1 length=512 >/dev/null fdrawcmd read 4 0 1 1 2 18 1 1 length=512 >/dev/null fdrawcmd read 4 0 1 2 2 18 1 1 length=512 >/dev/null ... fdrawcmd read 4 0 1 18 2 18 1 1 length=512 >/dev/null
# for s in {1..18} ; do echo sector= $s; fdrawcmd read 0 0 0 $s 2 18 1 1 length=512 >>/dev/null ; done sector= 1 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 1 6: 2 no disk change sector= 2 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 2 6: 2 no disk change sector= 3 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 3 6: 2 no disk change sector= 4 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 4 6: 2 no disk change sector= 5 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 5 6: 2 no disk change sector= 6 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 6 6: 2 no disk change sector= 7 remaining= 0 0: 0 1: 0 2: 0 3: 0 4: 0 5: 8 6: 2 no disk change sector= 8 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 8 6: 2 no disk change sector= 9 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 9 6: 2 no disk change sector= 10 remaining= 0 0: 0 1: 0 2: 0 3: 0 4: 0 5: b 6: 2 no disk change sector= 11 remaining= 0 0: 0 1: 0 2: 0 3: 0 4: 0 5: c 6: 2 no disk change sector= 12 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: c 6: 2 no disk change sector= 13 remaining= 512 0: 40 1: 4 2: 0 3: 0 4: 0 5: d 6: 2 no disk change sector= 14 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: e 6: 2 no disk change sector= 15 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: f 6: 2 no disk change sector= 16 remaining= 0 0: 40 1: 20 2: 20 3: 0 4: 0 5: 10 6: 2 no disk change sector= 17 remaining= 0 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change sector= 18 remaining= 512 0: 40 1: 4 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change ----------------------------------------------- # for s in {1..18} ; do echo sector= $s; fdrawcmd read 4 0 1 $s 2 18 1 1 length=512 >>/dev/null ; done sector= 1 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 1 6: 2 no disk change sector= 2 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 2 6: 2 no disk change sector= 3 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 3 6: 2 no disk change sector= 4 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 4 6: 2 no disk change sector= 5 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 5 6: 2 no disk change sector= 6 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 6 6: 2 no disk change sector= 7 remaining= 512 0: 44 1: 4 2: 0 3: 0 4: 1 5: 7 6: 2 no disk change sector= 8 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 8 6: 2 no disk change sector= 9 remaining= 0 0: 4 1: 0 2: 0 3: 0 4: 1 5: a 6: 2 no disk change sector= 10 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: a 6: 2 no disk change sector= 11 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: b 6: 2 no disk change sector= 12 remaining= 0 0: 4 1: 0 2: 0 3: 0 4: 1 5: d 6: 2 no disk change sector= 13 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: d 6: 2 no disk change sector= 14 remaining= 0 0: 4 1: 0 2: 0 3: 0 4: 1 5: f 6: 2 no disk change sector= 15 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: f 6: 2 no disk change sector= 16 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 10 6: 2 no disk change sector= 17 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 11 6: 2 no disk change sector= 18 remaining= 0 0: 44 1: 20 2: 20 3: 0 4: 1 5: 12 6: 2 no disk change ael
On 12/15/2009 03:18 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Attached is the one I'm using for 2.6.28
I just compiled a kernel with it here, and everything works fine on my test machine...
Weird
Alain
Alain, where exactly does the driver send the track label buffer to the drive for the FDFMTTRK ioctl? I can see (via printks) that the setup_format_params routine is NOT doing anything wrong so something between there and when it actually gets sent to the drive must be happening to the track number in that buffer for these sector 0xa's. Maybe I can capture and see that data right before it is sent to the drive? # fdrawcmd seek 0 1 0: 20 1: 1 no disk change # fdrawcmd readid 0 repeat=18 . . 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 <-- 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change . . # fdrawcmd seek 0 5 0: 20 1: 5 no disk change # fdrawcmd readid 0 repeat=18 . . 0: 0 1: 0 2: 0 3: 5 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4 <--- 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 5 4: 0 5: b 6: 2 no disk change . . # fdrawcmd seek 0 9 0: 20 1: 9 no disk change #fdrawcmd readid 0 repeat=18 . . 0: 0 1: 0 2: 0 3: 9 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 8 <-- 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 9 4: 0 5: b 6: 2 no disk change . . Mark
On 16/12/09 16:34, Mark Hounschell wrote:
On 12/15/2009 03:18 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Attached is the one I'm using for 2.6.28
I just compiled a kernel with it here, and everything works fine on my test machine...
Weird
Alain
Alain, where exactly does the driver send the track label buffer to the drive for the FDFMTTRK ioctl? I can see (via printks) that the setup_format_params routine is NOT doing anything wrong so something between there and when it actually gets sent to the drive must be happening to the track number in that buffer for these sector 0xa's. Maybe I can capture and see that data right before it is sent to the drive?
Data is sent via DMA, so there is no specific place in the code where it is sent (basically, the FDC grabs it itself). However, the floppy command is sent in function setup_rw_floppy: for (i = 0; i < raw_cmd->cmd_count; i++) r |= output_byte(raw_cmd->cmd[i]); Only after the FD_FORMAT command has been received entirely by the FDC will it start fetching the track label buffer via DMA. It could be that for some reason the DMA transfer itself is buggy... in that case, it might be useful to test without dma. You can do this by supplying the floppy=nodma flag to modprobe when inserting the module: modprobe floppy floppy=nodma Regards, Alain
On 12/16/2009 10:43 AM, Alain Knaff wrote:
On 16/12/09 16:34, Mark Hounschell wrote:
On 12/15/2009 03:18 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Attached is the one I'm using for 2.6.28
I just compiled a kernel with it here, and everything works fine on my test machine...
Weird
Alain
Alain, where exactly does the driver send the track label buffer to the drive for the FDFMTTRK ioctl? I can see (via printks) that the setup_format_params routine is NOT doing anything wrong so something between there and when it actually gets sent to the drive must be happening to the track number in that buffer for these sector 0xa's. Maybe I can capture and see that data right before it is sent to the drive?
Data is sent via DMA, so there is no specific place in the code where it is sent (basically, the FDC grabs it itself). However, the floppy command is sent in function setup_rw_floppy:
for (i = 0; i < raw_cmd->cmd_count; i++) r |= output_byte(raw_cmd->cmd[i]);
Only after the FD_FORMAT command has been received entirely by the FDC will it start fetching the track label buffer via DMA.
It could be that for some reason the DMA transfer itself is buggy... in that case, it might be useful to test without dma. You can do this by supplying the floppy=nodma flag to modprobe when inserting the module:
modprobe floppy floppy=nodma
Regards,
Alain
Yep, it works with nodma??? 0: 0 1: 0 2: 0 3: 1 4: 0 5: a 6: 2 no disk change dd also then works Mark
On 16/12/09 16:50, Mark Hounschell wrote:
On 12/16/2009 10:43 AM, Alain Knaff wrote:
On 16/12/09 16:34, Mark Hounschell wrote:
On 12/15/2009 03:18 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Attached is the one I'm using for 2.6.28
I just compiled a kernel with it here, and everything works fine on my test machine...
Weird
Alain
Alain, where exactly does the driver send the track label buffer to the drive for the FDFMTTRK ioctl? I can see (via printks) that the setup_format_params routine is NOT doing anything wrong so something between there and when it actually gets sent to the drive must be happening to the track number in that buffer for these sector 0xa's. Maybe I can capture and see that data right before it is sent to the drive?
Data is sent via DMA, so there is no specific place in the code where it is sent (basically, the FDC grabs it itself). However, the floppy command is sent in function setup_rw_floppy:
for (i = 0; i < raw_cmd->cmd_count; i++) r |= output_byte(raw_cmd->cmd[i]);
Only after the FD_FORMAT command has been received entirely by the FDC will it start fetching the track label buffer via DMA.
It could be that for some reason the DMA transfer itself is buggy... in that case, it might be useful to test without dma. You can do this by supplying the floppy=nodma flag to modprobe when inserting the module:
modprobe floppy floppy=nodma
Regards,
Alain
Yep, it works with nodma???
This is great news! So now we know it's somehow DMA related. There are still 2 possible theories: 1. data is being corrupted in memory before being transferred. 2. data is being corrupted during DMA (while still being left all right in memory) To check this, it still might be interesting to check the buffer, as you intended earlier, both just before the command is sent in setup_rw_floppy, and also after command complete. A good place for the "after" check is in do_format, after the following statement: IWAIT(redo_format); If it shows the correct data, we probably have 2 (corruption in transit), otherwise 1 (corruption in memory, maybe due to a stray pointer...). Regards, Alain
On 12/16/2009 11:04 AM, Alain Knaff wrote:
On 16/12/09 16:50, Mark Hounschell wrote:
On 12/16/2009 10:43 AM, Alain Knaff wrote:
On 16/12/09 16:34, Mark Hounschell wrote:
On 12/15/2009 03:18 PM, Alain Knaff wrote:
Mark Hounschell wrote:
Attached is the one I'm using for 2.6.28
I just compiled a kernel with it here, and everything works fine on my test machine...
Weird
Alain
Alain, where exactly does the driver send the track label buffer to the drive for the FDFMTTRK ioctl? I can see (via printks) that the setup_format_params routine is NOT doing anything wrong so something between there and when it actually gets sent to the drive must be happening to the track number in that buffer for these sector 0xa's. Maybe I can capture and see that data right before it is sent to the drive?
Data is sent via DMA, so there is no specific place in the code where it is sent (basically, the FDC grabs it itself). However, the floppy command is sent in function setup_rw_floppy:
for (i = 0; i < raw_cmd->cmd_count; i++) r |= output_byte(raw_cmd->cmd[i]);
Only after the FD_FORMAT command has been received entirely by the FDC will it start fetching the track label buffer via DMA.
It could be that for some reason the DMA transfer itself is buggy... in that case, it might be useful to test without dma. You can do this by supplying the floppy=nodma flag to modprobe when inserting the module:
modprobe floppy floppy=nodma
Regards,
Alain
Yep, it works with nodma???
This is great news! So now we know it's somehow DMA related.
There are still 2 possible theories: 1. data is being corrupted in memory before being transferred. 2. data is being corrupted during DMA (while still being left all right in memory)
To check this, it still might be interesting to check the buffer, as you intended earlier, both just before the command is sent in setup_rw_floppy, and also after command complete. A good place for the "after" check is in do_format, after the following statement:
IWAIT(redo_format);
If it shows the correct data, we probably have 2 (corruption in transit), otherwise 1 (corruption in memory, maybe due to a stray pointer...).
Ok, I assume that the dma buffer is the actual floppy_track_buffer. To be sure, I corrupted it before the DMA in such a way I could see the corruption doing the readid. If that is in fact the case, there is no corruption of the floppy_track_buffer taking place. Dec 16 13:43:05 harley kernel: Dec 16 13:43:05 harley kernel: setup_rw_floppy: Track Label Buffer Before Dec 16 13:43:05 harley kernel: Logical Sector 0: track = 1 head 0 sect = 10 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 1: track = 1 head 0 sect = 11 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 2: track = 1 head 0 sect = 12 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 3: track = 1 head 0 sect = 13 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 4: track = 1 head 0 sect = 14 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 5: track = 1 head 0 sect = 15 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 6: track = 1 head 0 sect = 16 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 7: track = 1 head 0 sect = 17 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 8: track = 1 head 0 sect = 18 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 9: track = 1 head 0 sect = 1 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 10: track = 1 head 0 sect = 2 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 11: track = 1 head 0 sect = 3 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 12: track = 1 head 0 sect = 4 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 13: track = 1 head 0 sect = 5 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 14: track = 1 head 0 sect = 6 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 15: track = 1 head 0 sect = 7 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 16: track = 1 head 0 sect = 8 size = 2 Dec 16 13:43:05 harley kernel: Logical Sector 17: track = 1 head 0 sect = 9 size = 2 Dec 16 13:43:06 harley kernel: do_format: Track Label Buffer after Dec 16 13:43:06 harley kernel: Logical Sector 0: track = 1 head 0 sect = 10 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 1: track = 1 head 0 sect = 11 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 2: track = 1 head 0 sect = 12 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 3: track = 1 head 0 sect = 13 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 4: track = 1 head 0 sect = 14 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 5: track = 1 head 0 sect = 15 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 6: track = 1 head 0 sect = 16 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 7: track = 1 head 0 sect = 17 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 8: track = 1 head 0 sect = 18 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 9: track = 1 head 0 sect = 1 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 10: track = 1 head 0 sect = 2 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 11: track = 1 head 0 sect = 3 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 12: track = 1 head 0 sect = 4 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 13: track = 1 head 0 sect = 5 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 14: track = 1 head 0 sect = 6 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 15: track = 1 head 0 sect = 7 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 16: track = 1 head 0 sect = 8 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 17: track = 1 head 0 sect = 9 size = 2 Dec 16 13:43:06 harley kernel: Dec 16 13:43:06 harley kernel: setup_rw_floppy: Track Label Buffer Before Dec 16 13:43:06 harley kernel: Logical Sector 0: track = 1 head 1 sect = 7 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 1: track = 1 head 1 sect = 8 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 2: track = 1 head 1 sect = 9 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 3: track = 1 head 1 sect = 10 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 4: track = 1 head 1 sect = 11 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 5: track = 1 head 1 sect = 12 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 6: track = 1 head 1 sect = 13 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 7: track = 1 head 1 sect = 14 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 8: track = 1 head 1 sect = 15 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 9: track = 1 head 1 sect = 16 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 10: track = 1 head 1 sect = 17 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 11: track = 1 head 1 sect = 18 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 12: track = 1 head 1 sect = 1 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 13: track = 1 head 1 sect = 2 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 14: track = 1 head 1 sect = 3 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 15: track = 1 head 1 sect = 4 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 16: track = 1 head 1 sect = 5 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 17: track = 1 head 1 sect = 6 size = 2 Dec 16 13:43:06 harley kernel: do_format: Track Label Buffer after Dec 16 13:43:06 harley kernel: Logical Sector 0: track = 1 head 1 sect = 7 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 1: track = 1 head 1 sect = 8 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 2: track = 1 head 1 sect = 9 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 3: track = 1 head 1 sect = 10 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 4: track = 1 head 1 sect = 11 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 5: track = 1 head 1 sect = 12 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 6: track = 1 head 1 sect = 13 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 7: track = 1 head 1 sect = 14 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 8: track = 1 head 1 sect = 15 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 9: track = 1 head 1 sect = 16 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 10: track = 1 head 1 sect = 17 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 11: track = 1 head 1 sect = 18 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 12: track = 1 head 1 sect = 1 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 13: track = 1 head 1 sect = 2 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 14: track = 1 head 1 sect = 3 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 15: track = 1 head 1 sect = 4 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 16: track = 1 head 1 sect = 5 size = 2 Dec 16 13:43:06 harley kernel: Logical Sector 17: track = 1 head 1 sect = 6 size = 2 So, to me, if my assumptions above are correct, it looks like we have corruption in transit?? Mark
Mark Hounschell wrote:
So, to me, if my assumptions above are correct, it looks like we have corruption in transit??
Indeed, it looks as if. Now, we must only understand why this happens, and why it only happens in "recent" kernels. My theory is that it may be due to a bug in cache consistency: when the DMA controller starts out sending data to the FDC, it has first to make sure that the data it sees is the most up to date. If it has a cache, this must be refreshed from memory. If there is a bug in this process (for example, first byte already sent, before it is updated to most recent value), we will see the behavior observed. In order to confirm or invalidate this hypothesis, it might be interesting to format the tracks "out of order", for instance, first track 23, than track 18. If this hypothesis is correct, then the first sector of track 18 should have track id 23 (rather than 18 or 17). If this is confirmed, we have to wonder why it only happens with certain kernels. My theory is that it might have something to do with the exact alignment of the floppy track buffer. Some kernels might allocate DMA buffers on any page boundaries (4096 bytes), whereas others might enforce larger alignments (for instance 64 K). The bug might only happen for the larger alignment. In order to test this out, you could: 1. printk the address of the floppy_track buffer both on a "good" kernel (2.6.27.41) and on a "bad" one (2.6.28), and compare alignment (roughly, with how many zeroes the address ends...) 2. Deliberately misalign the floppy track buffer. In setup_format_params, replace the following: struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)floppy_track_buffer; with struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+4); and (a couple of lines later): raw_cmd->kernel_data = floppy_track_buffer; with raw_cmd->kernel_data = (char *) here; If this "fixes" the issue, then we know that it is related to alignment. However, this is only a diagnostic tool, rather than a proper fix, because: 1. Very probably, the same issue would occur for *any* legacy DMA transfer. I.e. when writing a sector using dd to the floppy, the first byte written will probably be whatever happened to be at that position in the DMA buffer before (would only apply to first sector of track, because only that one is stored at beginning of DMA buffer). 2. It might also affect other drivers which use legacy DMA Regards, Alain
On 12/16/2009 05:42 PM, Alain Knaff wrote:
Mark Hounschell wrote:
So, to me, if my assumptions above are correct, it looks like we have corruption in transit??
Indeed, it looks as if.
Now, we must only understand why this happens, and why it only happens in "recent" kernels.
My theory is that it may be due to a bug in cache consistency: when the DMA controller starts out sending data to the FDC, it has first to make sure that the data it sees is the most up to date. If it has a cache, this must be refreshed from memory. If there is a bug in this process (for example, first byte already sent, before it is updated to most recent value), we will see the behavior observed.
In order to confirm or invalidate this hypothesis, it might be interesting to format the tracks "out of order", for instance, first track 23, than track 18. If this hypothesis is correct, then the first sector of track 18 should have track id 23 (rather than 18 or 17).
If this is confirmed, we have to wonder why it only happens with certain kernels.
I haven't done this as I'm not sure how to proceed with it.
My theory is that it might have something to do with the exact alignment of the floppy track buffer. Some kernels might allocate DMA buffers on any page boundaries (4096 bytes), whereas others might enforce larger alignments (for instance 64 K). The bug might only happen for the larger alignment.
In order to test this out, you could: 1. printk the address of the floppy_track buffer both on a "good" kernel (2.6.27.41) and on a "bad" one (2.6.28), and compare alignment (roughly, with how many zeroes the address ends...)
Good = 0xc0c08000 Bad = 0xc0a88000
2. Deliberately misalign the floppy track buffer. In setup_format_params, replace the following:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)floppy_track_buffer;
with
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+4);
and (a couple of lines later):
raw_cmd->kernel_data = floppy_track_buffer;
with
raw_cmd->kernel_data = (char *) here;
If this "fixes" the issue, then we know that it is related to alignment.
This causes the following. # fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... ioctl(FDFMTTRK): Input/output error and dmesg: Dec 17 08:50:04 harley kernel: non aligned address: c0c10004
On 17/12/09 14:54, Mark Hounschell wrote: [...]
In order to confirm or invalidate this hypothesis, it might be interesting to format the tracks "out of order", for instance, first track 23, than track 18. If this hypothesis is correct, then the first sector of track 18 should have track id 23 (rather than 18 or 17).
If this is confirmed, we have to wonder why it only happens with certain kernels.
I haven't done this as I'm not sure how to proceed with it.
Sorry, from your earlier mention of the FDFMTTRK I optimistically assumed that you had already written a small test program to issue this call "manually" for each track... But, now that I think of it, actually no such thing is needed to perform this test: just fdformat the disk twice in a row, the first time without verification: fdformat -n /dev/fd0u1440 fdformat /dev/fd0u1440 If my theory is correct, the disk should have track id 79 (0x4f) in sector 1 of track 0 (0x4f being left over by the _previous_ format)
My theory is that it might have something to do with the exact alignment of the floppy track buffer. Some kernels might allocate DMA buffers on any page boundaries (4096 bytes), whereas others might enforce larger alignments (for instance 64 K). The bug might only happen for the larger alignment.
In order to test this out, you could: 1. printk the address of the floppy_track buffer both on a "good" kernel (2.6.27.41) and on a "bad" one (2.6.28), and compare alignment (roughly, with how many zeroes the address ends...)
Good = 0xc0c08000 Bad = 0xc0a88000
yeah, same alignment for both (no pun intended :-) )
2. Deliberately misalign the floppy track buffer. In setup_format_params, replace the following:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)floppy_track_buffer;
with
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+4);
and (a couple of lines later):
raw_cmd->kernel_data = floppy_track_buffer;
with
raw_cmd->kernel_data = (char *) here;
If this "fixes" the issue, then we know that it is related to alignment.
This causes the following.
# fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... ioctl(FDFMTTRK): Input/output error
and dmesg:
Dec 17 08:50:04 harley kernel: non aligned address: c0c10004
Oops, yeah, forgot about this: elsewhere the code enforces an alignment of at least 512. So you can do: 1. Use the following instead: struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+512); or 2. Do you 4, but remove the alignment check in setup_DMA Regards, Alain
On 12/17/2009 09:20 AM, Alain Knaff wrote:
On 17/12/09 14:54, Mark Hounschell wrote: [...]
In order to confirm or invalidate this hypothesis, it might be interesting to format the tracks "out of order", for instance, first track 23, than track 18. If this hypothesis is correct, then the first sector of track 18 should have track id 23 (rather than 18 or 17).
If this is confirmed, we have to wonder why it only happens with certain kernels.
I haven't done this as I'm not sure how to proceed with it.
Sorry, from your earlier mention of the FDFMTTRK I optimistically assumed that you had already written a small test program to issue this call "manually" for each track...
I new fdformat was using it. And I do have an emulator that uses it but thats another story.
But, now that I think of it, actually no such thing is needed to perform this test:
just fdformat the disk twice in a row, the first time without verification:
fdformat -n /dev/fd0u1440 fdformat /dev/fd0u1440
If my theory is correct, the disk should have track id 79 (0x4f) in sector 1 of track 0 (0x4f being left over by the _previous_ format)
Yep, looks like your suspicion is right. 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change
My theory is that it might have something to do with the exact alignment of the floppy track buffer. Some kernels might allocate DMA buffers on any page boundaries (4096 bytes), whereas others might enforce larger alignments (for instance 64 K). The bug might only happen for the larger alignment.
In order to test this out, you could: 1. printk the address of the floppy_track buffer both on a "good" kernel (2.6.27.41) and on a "bad" one (2.6.28), and compare alignment (roughly, with how many zeroes the address ends...)
Good = 0xc0c08000 Bad = 0xc0a88000
yeah, same alignment for both (no pun intended :-) )
2. Deliberately misalign the floppy track buffer. In setup_format_params, replace the following:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)floppy_track_buffer;
with
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+4);
and (a couple of lines later):
raw_cmd->kernel_data = floppy_track_buffer;
with
raw_cmd->kernel_data = (char *) here;
If this "fixes" the issue, then we know that it is related to alignment.
This causes the following.
# fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... ioctl(FDFMTTRK): Input/output error
and dmesg:
Dec 17 08:50:04 harley kernel: non aligned address: c0c10004
Oops, yeah, forgot about this: elsewhere the code enforces an alignment of at least 512.
So you can do:
1. Use the following instead:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+512);
or
2. Do you 4, but remove the alignment check in setup_DMA
I did option 1 and things got worse. Every track looks like this. # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: f6 4: f6 5: f6 6: f6 no disk change 0: 0 1: 0 2: 0 3: f6 4: f6 5: f6 6: f6 no disk change . . . Mark
On 17/12/09 15:48, Mark Hounschell wrote:
If my theory is correct, the disk should have track id 79 (0x4f) in sector 1 of track 0 (0x4f being left over by the _previous_ format)
Yep, looks like your suspicion is right.
0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change
0: 0 1: 0 2: 0 3: 4f 4: 0 5: 1 6: 2 no disk change
0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change
Good, so now we know for sure that it is indeed the _previous_ value which is getting transmitted. [...]
2. Deliberately misalign the floppy track buffer. In setup_format_params, replace the following:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)floppy_track_buffer;
with
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+4);
and (a couple of lines later):
raw_cmd->kernel_data = floppy_track_buffer;
with
raw_cmd->kernel_data = (char *) here; [...] I did option 1 and things got worse. Every track looks like this.
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: f6 4: f6 5: f6 6: f6 no disk change
This is weird. It looks as if it was reading the track data from some different place than the one which has been initialized. Are you sure you still have the "raw_cmd->kernel_data = (char *) here;" line in place? I'll check this evening what happens on my test machine when I do this. Or you could try with floppy=nodma . Regards, Alain
On 12/17/2009 09:54 AM, Alain Knaff wrote:
This is weird. It looks as if it was reading the track data from some different place than the one which has been initialized.
Are you sure you still have the "raw_cmd->kernel_data = (char *) here;" line in place?
Oops, your right again. I backed it out for option 1. I'll try it again now. Mark
On 12/17/2009 09:20 AM, Alain Knaff wrote:
On 17/12/09 14:54, Mark Hounschell wrote: [...]
In order to confirm or invalidate this hypothesis, it might be interesting to format the tracks "out of order", for instance, first track 23, than track 18. If this hypothesis is correct, then the first sector of track 18 should have track id 23 (rather than 18 or 17).
If this is confirmed, we have to wonder why it only happens with certain kernels.
I haven't done this as I'm not sure how to proceed with it.
Sorry, from your earlier mention of the FDFMTTRK I optimistically assumed that you had already written a small test program to issue this call "manually" for each track...
But, now that I think of it, actually no such thing is needed to perform this test:
just fdformat the disk twice in a row, the first time without verification:
fdformat -n /dev/fd0u1440 fdformat /dev/fd0u1440
If my theory is correct, the disk should have track id 79 (0x4f) in sector 1 of track 0 (0x4f being left over by the _previous_ format)
My theory is that it might have something to do with the exact alignment of the floppy track buffer. Some kernels might allocate DMA buffers on any page boundaries (4096 bytes), whereas others might enforce larger alignments (for instance 64 K). The bug might only happen for the larger alignment.
In order to test this out, you could: 1. printk the address of the floppy_track buffer both on a "good" kernel (2.6.27.41) and on a "bad" one (2.6.28), and compare alignment (roughly, with how many zeroes the address ends...)
Good = 0xc0c08000 Bad = 0xc0a88000
yeah, same alignment for both (no pun intended :-) )
2. Deliberately misalign the floppy track buffer. In setup_format_params, replace the following:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)floppy_track_buffer;
with
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+4);
and (a couple of lines later):
raw_cmd->kernel_data = floppy_track_buffer;
with
raw_cmd->kernel_data = (char *) here;
If this "fixes" the issue, then we know that it is related to alignment.
This causes the following.
# fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... ioctl(FDFMTTRK): Input/output error
and dmesg:
Dec 17 08:50:04 harley kernel: non aligned address: c0c10004
Oops, yeah, forgot about this: elsewhere the code enforces an alignment of at least 512.
So you can do:
1. Use the following instead:
struct fparm { unsigned char track, head, sect, size; } *here = (struct fparm *)(floppy_track_buffer+512);
or
2. Do you 4, but remove the alignment check in setup_DMA
Regards,
Alain
Ok, I used "+512" and I see the same (original) thing on track 1 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change Mark
On 12/17/2009 10:10 AM, Alain Knaff wrote:
On 17/12/09 16:08, Mark Hounschell wrote:
Ok, I used "+512" and I see the same (original) thing on track 1
ok, good, so it might be interesting to test option 2 then (+4, and yanking the alignment test...)
Alain
OK # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change and dmesg: Dec 17 10:15:06 harley kernel: end_request: I/O error, dev fd0, sector 19 Dec 17 10:15:06 harley kernel: Buffer I/O error on device fd0, logical block 2 Dec 17 10:15:08 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 17 10:15:08 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 17 10:15:10 harley kernel: end_request: I/O error, dev fd0, sector 72 Dec 17 10:15:10 harley kernel: Buffer I/O error on device fd0, logical block 9 Dec 17 10:15:12 harley kernel: end_request: I/O error, dev fd0, sector 117 Dec 17 10:15:12 harley kernel: Buffer I/O error on device fd0, logical block 14 Dec 17 10:15:15 harley kernel: end_request: I/O error, dev fd0, sector 19 Dec 17 10:15:15 harley kernel: Buffer I/O error on device fd0, logical block 2 Mark
On 17/12/09 16:18, Mark Hounschell wrote:
On 12/17/2009 10:10 AM, Alain Knaff wrote:
On 17/12/09 16:08, Mark Hounschell wrote:
Ok, I used "+512" and I see the same (original) thing on track 1
ok, good, so it might be interesting to test option 2 then (+4, and yanking the alignment test...)
Alain
OK [...] 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change
Ok, problem still there, so I think we can rule out any influence of alignment. So the cause must be changed cache coherency settings elsewhere in the kernel... Alain
On 12/17/2009 10:08 AM, Mark Hounschell wrote: Also track 0 got messed up. 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: f6 4: 0 5: 1 6: 2 no disk change Mark
Mark
_______________________________________________ Fdutils mailing list Fdutils@fdutils.linux.lu https://fdutils.linux.lu/cgi-bin/mailman/listinfo/fdutils
On 17/12/09 16:10, Mark Hounschell wrote:
0: 0 1: 0 2: 0 3: f6 4: 0 5: 1 6: 2 no disk change
hehe, probably a left-over of the previous "failed" test were the "raw_cmd->kernel_data = (char *) here;" line was missing. ... proving once again that the DMA controller sends whatever byte was at that location _previously_... Another thing to do now would be to repeat the "fdformat twice" test, but this time do lots of memory-intensive, but not floppy-related things between the to fdformats... fdformat -n /dev/fd0u1440 *do lots of stuff* fdformat /dev/fd0u1440 The reason for this is, AFAIK, DMA controller do _not_ have caches... So the only inconsistency that may occur is an inconsistency between the _processor's_ cache, and the main memory (where the DMA controller gets its data from). Doing lots of memory-intensive stuff would have the effect of making sure the processor's cache is appropriately written out to memory (but without affecting any hypothetical cache of the DMA controller), and might make the problem go away. Here is a small program that I sometimes use to use up lots of memory: #include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <string.h> void main(int argc, char **argv) { unsigned int max,min; int n; char *a; unsigned int i; int ctr; char maxs[40],mins[40]; if ( argc < 3 ) { printf("Trying to find maximum allocatable memory size\n"); min = 0; max = -1; } else { min=strtoul(argv[1],0,0); max=strtoul(argv[2],0,0); } n = (max >> 1) + (min >> 1) + (((min&1)+(max&1)) >> 1); printf("%08x < %08x < %08x\r",min,n,max); fflush(stdout); a=malloc(n); if (max - min >= 4 || a == 0){ if (a != 0){ sprintf(mins,"%d",n); sprintf(maxs,"%d",max); } else{ sprintf(mins,"%d",min); sprintf(maxs,"%d",n); } execlp(argv[0],argv[0],mins,maxs,0); } printf("\nok\nDirtying pages\n"); for(ctr = 0; ctr < n / 2049; ctr++) { i=random() % n; a[i]=1; if (!(ctr % 16)) { printf("%08x\r",ctr); fflush(stdout); } } printf("\n"); exit(0); } Alain
On 12/17/2009 10:17 AM, Alain Knaff wrote:
On 17/12/09 16:10, Mark Hounschell wrote:
0: 0 1: 0 2: 0 3: f6 4: 0 5: 1 6: 2 no disk change
hehe, probably a left-over of the previous "failed" test were the "raw_cmd->kernel_data = (char *) here;" line was missing.
... proving once again that the DMA controller sends whatever byte was at that location _previously_...
Another thing to do now would be to repeat the "fdformat twice" test, but this time do lots of memory-intensive, but not floppy-related things between the to fdformats...
fdformat -n /dev/fd0u1440 *do lots of stuff* fdformat /dev/fd0u1440
The reason for this is, AFAIK, DMA controller do _not_ have caches... So the only inconsistency that may occur is an inconsistency between the _processor's_ cache, and the main memory (where the DMA controller gets its data from). Doing lots of memory-intensive stuff would have the effect of making sure the processor's cache is appropriately written out to memory (but without affecting any hypothetical cache of the DMA controller), and might make the problem go away.
Here is a small program that I sometimes use to use up lots of memory:
#include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> #include <string.h>
void main(int argc, char **argv) { unsigned int max,min; int n; char *a; unsigned int i; int ctr; char maxs[40],mins[40];
if ( argc < 3 ) { printf("Trying to find maximum allocatable memory size\n"); min = 0; max = -1; } else { min=strtoul(argv[1],0,0); max=strtoul(argv[2],0,0); } n = (max >> 1) + (min >> 1) + (((min&1)+(max&1)) >> 1); printf("%08x < %08x < %08x\r",min,n,max); fflush(stdout); a=malloc(n); if (max - min >= 4 || a == 0){ if (a != 0){ sprintf(mins,"%d",n); sprintf(maxs,"%d",max); } else{ sprintf(mins,"%d",min); sprintf(maxs,"%d",n); } execlp(argv[0],argv[0],mins,maxs,0); } printf("\nok\nDirtying pages\n"); for(ctr = 0; ctr < n / 2049; ctr++) { i=random() % n; a[i]=1; if (!(ctr % 16)) { printf("%08x\r",ctr); fflush(stdout); } } printf("\n"); exit(0); }
Alain
Do you want me to do this with an unmodified floppy.c? Mark
On 12/17/2009 10:23 AM, Alain Knaff wrote:
On 17/12/09 16:21, Mark Hounschell wrote:
Do you want me to do this with an unmodified floppy.c?
Doesn't matter, as the modification to floppy.c didn't change the behavior anyways...
# fdformat -n /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done # /home/markh/a.out Trying to find maximum allocatable memory size af5ae37d < af5ae37e < af5ae37f ok Dirtying pages # fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1 # floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change # fdrawcmd seek 0 1 0: 20 1: 1 no disk change # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 1 4: 0 5: 9 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: a 6: 2 no disk change 0: 0 1: 0 2: 0 3: 1 4: 0 5: b 6: 2 no disk change dmesg for the verify: Dec 17 10:26:59 harley kernel: end_request: I/O error, dev fd0, sector 72 Dec 17 10:26:59 harley kernel: Buffer I/O error on device fd0, logical block 9 Dec 17 10:27:01 harley kernel: end_request: I/O error, dev fd0, sector 97 Dec 17 10:27:01 harley kernel: Buffer I/O error on device fd0, logical block 12 Dec 17 10:27:03 harley kernel: end_request: I/O error, dev fd0, sector 0 Dec 17 10:27:03 harley kernel: Buffer I/O error on device fd0, logical block 0 Dec 17 10:27:05 harley kernel: end_request: I/O error, dev fd0, sector 45 Dec 17 10:27:05 harley kernel: Buffer I/O error on device fd0, logical block 5 Dec 17 10:27:07 harley kernel: end_request: I/O error, dev fd0, sector 0 Dec 17 10:27:07 harley kernel: Buffer I/O error on device fd0, logical block 0 Should I do more work in between? Mark
On 17/12/09 16:31, Mark Hounschell wrote:
On 12/17/2009 10:23 AM, Alain Knaff wrote:
On 17/12/09 16:21, Mark Hounschell wrote:
Do you want me to do this with an unmodified floppy.c?
Doesn't matter, as the modification to floppy.c didn't change the behavior anyways...
# fdformat -n /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done # /home/markh/a.out Trying to find maximum allocatable memory size af5ae37d < af5ae37e < af5ae37f ok Dirtying pages
# fdformat /dev/fd0 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1
# floppycontrol --resetnow 0 # fdrawcmd recalibrate 0 0: 20 1: 0 no disk change
# fdrawcmd seek 0 1 ^ Actually, tracks start being numbered at zero....
Just recalibrate is enough. [...]
Should I do more work in between?
No, but make sure to look at track 0... Other tracks will still have the error, as there was nothing forcing a memory flush between track 0 and 1... Alain
On 12/17/2009 10:35 AM, Alain Knaff wrote:
Should I do more work in between?
No, but make sure to look at track 0... Other tracks will still have the error, as there was nothing forcing a memory flush between track 0 and 1...
Ok track 0 # fdrawcmd seek 0 0 0: 20 1: 0 no disk change # fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f <-- 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change
On 17/12/09 16:43, Mark Hounschell wrote:
On 12/17/2009 10:35 AM, Alain Knaff wrote:
Should I do more work in between?
No, but make sure to look at track 0... Other tracks will still have the error, as there was nothing forcing a memory flush between track 0 and 1...
Ok track 0 [...] 0: 0 1: 0 2: 0 3: 4f <-- 4: 0 5: 1 6: 2 no disk change
Yeah, that's what I meant... So the memory flusher program didn't manage to clear up the inconsistency... So either my theory is wrong, or the memory flusher program was not efficient enough.... hmmm, maybe doing some surfing in between the formats, or doing another kernel compilation might be a better test. Alain
On 12/17/2009 10:49 AM, Alain Knaff wrote:
So either my theory is wrong, or the memory flusher program was not efficient enough.... hmmm, maybe doing some surfing in between the formats, or doing another kernel compilation might be a better test.
Ok, I did a "make clean ; make -j 4" in a kernel source tree and did some web surfing at the same time in between formats. There is 4GB in this box? 0: 0 1: 0 2: 0 3: 0 4: 0 5: 12 6: 2 no disk change 0: 0 1: 0 2: 0 3: 4f 4: 0 5: 1 6: 2 no disk change 0: 0 1: 0 2: 0 3: 0 4: 0 5: 2 6: 2 no disk change I still think you theory is right though?? Mark
On 17/12/09 16:49, Alain Knaff wrote:
On 17/12/09 16:43, Mark Hounschell wrote:
On 12/17/2009 10:35 AM, Alain Knaff wrote:
Should I do more work in between?
No, but make sure to look at track 0... Other tracks will still have the error, as there was nothing forcing a memory flush between track 0 and 1...
Ok track 0 [...] 0: 0 1: 0 2: 0 3: 4f <-- 4: 0 5: 1 6: 2 no disk change
Yeah, that's what I meant... So the memory flusher program didn't manage to clear up the inconsistency...
So either my theory is wrong, or the memory flusher program was not efficient enough.... hmmm, maybe doing some surfing in between the formats, or doing another kernel compilation might be a better test.
Alain
Ok, so I had a look at the differences between 2.6.27.41 and 2.6.28, and there have indeed been changes to the iommu and DMA handling code. So I suspect that the problem may be lying here Cc'ed Linus and kernel list on this. For Linux and the list, here's the summary of what we are observing: - A DMA transfer of a memory block transfers the wrong value for the first byte of the block. All other bytes of the block are transferred correctly. The value of the first byte turns out to be the value that this byte held during the *previous* transfer. Just as if there was some kind of cache, and the transfer started before that cache was refreshed with the new values from main memory. Example: 1. initial contents: 33 44 55 66 2. one DMA transfer is performed 3. program changes buffer to: 77 88 99 aa 4. new DMA transfer is performed => instead it transmits 33 88 99 aa (i.e. first byte is from previous contents) This used to work in 2.6.27.41, but broke in 2.6.28 . It doesn't happen on all hardware though. It does indeed seem to be related to a DMA-side cache (rather than the processor's cache not being flushed to main memory), as doing lots of memory intensive work (kernel compilation) between 2 and 3 doesn't fix the problem. In the diff between 2.6.27.41 and 2.6.28, I noticed a lot of changes in arch/x86/kernel/amd_iommu.c and related files, could any of these have triggered this behavior? Any ideas, anybody? Alain
On Thu, 17 Dec 2009, Alain Knaff wrote:
1. initial contents: 33 44 55 66 2. one DMA transfer is performed 3. program changes buffer to: 77 88 99 aa 4. new DMA transfer is performed => instead it transmits 33 88 99 aa (i.e. first byte is from previous contents)
This used to work in 2.6.27.41, but broke in 2.6.28 . It doesn't happen on all hardware though.
Do you have a list of hardware it works on? Especially chipsets. On x86, where all caches are supposed to be totally coherent (except for I$ under very special circumstances), the above should never be able to happen. At least not unless there is really buggy hardware involved.
It does indeed seem to be related to a DMA-side cache (rather than the processor's cache not being flushed to main memory), as doing lots of memory intensive work (kernel compilation) between 2 and 3 doesn't fix the problem.
I'm not entirely surprised. Actual CPU bugs are pretty rare in the x86 world. But chipset bugs? Another thing entirely. There are buffers and caches there, and those are sometimes software-visible. The most obvious case of that is just the IOMMU's themselves, but from your description I don't think you actually change the DMA _mappings_ do you? Just the actual buffer (that was then mapped earlier)? So I don't think it's the IOMMU code itself necessarily, although an IOMMU may well be involved (eg I could easily see a few cachelines worth of actual DMA data caching going on in the whole IOMMU too) And to some degree the floppy driver might be _more_ likely to see some kinds of bugs, because it uses that crazy legacy DMA engine. So it's not going to go through the regular PCI DMA hardware paths, it's going to go through its own special paths that nobody else uses any more (and thus has probably not had as much testing).
In the diff between 2.6.27.41 and 2.6.28, I noticed a lot of changes in arch/x86/kernel/amd_iommu.c and related files, could any of these have triggered this behavior?
Could it have triggered? Sure. Chipset caches are often flushed by certain trivial operations (often the caches are small, and operations like "any PIO access" will make sure they are flushed). Different IOMMU flush patterns could easily account for it. But I think we'd like to see a list of hardware where this can be triggered, and quite frankly, a 'git bisect' would be absolutely wonderful especially if the list of hardware is not showing any really obvious patterns (and I assume they aren't all _that_ obvious, or you'd have mentioned them). Linus
Linus Torvalds <torvalds@linux-foundation.org> writes:
On x86, where all caches are supposed to be totally coherent (except for I$ under very special circumstances),
BTW SWIOTLB is a non-coherent "cache" in some sense, though I'd be surprised if it's related. Anyway mentioning $CPU and $RAM at the very least would be a good idea in such cases. -- Krzysztof Halasa
Linus Torvalds wrote:
On Thu, 17 Dec 2009, Alain Knaff wrote:
1. initial contents: 33 44 55 66 2. one DMA transfer is performed 3. program changes buffer to: 77 88 99 aa 4. new DMA transfer is performed => instead it transmits 33 88 99 aa (i.e. first byte is from previous contents)
This used to work in 2.6.27.41, but broke in 2.6.28 . It doesn't happen on all hardware though.
Do you have a list of hardware it works on? Especially chipsets.
For the moment, I have a very small sample of hardware: 1. One machine which works (my own): Athlon XP 1800+ processor 2. One which doesn't work (Mark's) I might get access to a wider sample of boxen in a week or so, in order to do some stats. What's the easiest way to find out the chipset? Here's already the output of lspci from my machine (works): 00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80) 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50) 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) [...]
I'm not entirely surprised. Actual CPU bugs are pretty rare in the x86 world. But chipset bugs? Another thing entirely. There are buffers and caches there, and those are sometimes software-visible. The most obvious case of that is just the IOMMU's themselves, but from your description I don't think you actually change the DMA _mappings_ do you? Just the actual buffer (that was then mapped earlier)?
No, I don't change any DMA mappings. And the buffer is still the same physical buffer, at the same physical address. (It happens during formatting the floppy drive: here the first byte happens to be the trackid of the first physical sector of the track, and it always ends up being the track of the *previously* formatted track).
So I don't think it's the IOMMU code itself necessarily, although an IOMMU may well be involved (eg I could easily see a few cachelines worth of actual DMA data caching going on in the whole IOMMU too)
And to some degree the floppy driver might be _more_ likely to see some kinds of bugs, because it uses that crazy legacy DMA engine. So it's not
Indeed, most other drivers use "bus master" DMA, that doesn't use the legacy DMA controller at all, but use DMA controllers hosted on the device itself...
going to go through the regular PCI DMA hardware paths, it's going to go through its own special paths that nobody else uses any more (and thus has probably not had as much testing).
In the diff between 2.6.27.41 and 2.6.28, I noticed a lot of changes in arch/x86/kernel/amd_iommu.c and related files, could any of these have triggered this behavior?
Could it have triggered? Sure. Chipset caches are often flushed by certain trivial operations (often the caches are small, and operations like "any PIO access" will make sure they are flushed). Different IOMMU flush patterns could easily account for it.
But I think we'd like to see a list of hardware where this can be triggered,
We'll get a list of 2 machines relatively quickly (unless other people would like to chime in: the test is easy, just fdformat a floppy disk), and more in a week or so.
and quite frankly, a 'git bisect' would be absolutely wonderful
How exactly would I use this (command line sample)?
especially if the list of hardware is not showing any really obvious patterns (and I assume they aren't all _that_ obvious, or you'd have mentioned them).
Linus
Thanks, Alain
On Thu, 17 Dec 2009, Alain Knaff wrote:
For the moment, I have a very small sample of hardware: 1. One machine which works (my own): Athlon XP 1800+ processor 2. One which doesn't work (Mark's)
Ok. I don't think I even have any machines with floppy drives any more (one external USB drive somewhere gathering dust just in case I ever encounter a floppy again).
I might get access to a wider sample of boxen in a week or so, in order to do some stats.
Ok, I was more thinking "we have a bugzilla with ten different people reporting this". If it's just a single machine, that's not going to be relevant.
What's the easiest way to find out the chipset?
Here's already the output of lspci from my machine (works):
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
Yeah, lspci (and generally only the northbridge and southbridge matters, the "ISA bridge" might technically be relevant, but since it's universally on the same die as the southbridge, I left it in there just for kicks).
(It happens during formatting the floppy drive: here the first byte happens to be the trackid of the first physical sector of the track, and it always ends up being the track of the *previously* formatted track).
I guess it could simply be a floppy controller bug too, triggered by some random timing difference or innocuous-looking change.
But I think we'd like to see a list of hardware where this can be triggered,
We'll get a list of 2 machines relatively quickly (unless other people would like to chime in: the test is easy, just fdformat a floppy disk), and more in a week or so.
Only the "it doesn't work on xyz" is likely interesting. The machines it works on are probably uninteresting statistically.
and quite frankly, a 'git bisect' would be absolutely wonderful
How exactly would I use this (command line sample)?
You'd need a git tree that contains both the working and non-working versions, and then literally just do git bisect start git bisect good <known good version number here> git bisect bad <known bad version here> and it will give you a commit to try. Compile, test, see if it's good or bad, and do git bisect [good|bad] depending on the result. Rinse and repeat (depending on how tight the initial good/bad commits were, it will need 10-15 kernel tests). So in this case, since apparently 2.6.27.41 is good, and 2.6.28 is not, it would be something like this: # clone hpa's tree that has all the stable releases in one place git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git cd linux-2.6-allstable git bisect start git bisect bad v2.6.28 git bisect good v2.6.27.41 and off you go. NOTE! Bisection depends very much on the bug being 100% reproducible. If you ever mark a good kernel bad (because you messed up) or a bad kernel good (because the bug wasn't 100% reproducible, so you _thought_ it was good even though the bug was present and just happened to hide), the end result of the bisect will be totally unreliable and seriously screwed up. So after a successful bisect, it is usually a good idea to try to go back to the original known-bad kernel, and then revert the commit that was indicated as the bad one (assuming the revert works - it could be that the bad one ends up being fundamental to other commits after it), and test that yes, that really fixes the bug. It gets more complicated if the bisect hits kernels that you can't test because they have _unrelated_ issues on that machine (compile failures or just other bugs that hide the actual floppy behavior), but generally bisection is pretty simple. "man git-bisect" does have some extra pointers. So git bisect may be somewhat time-consuming and mindless, but for reliably triggering bugs where nobody really knows what caused the bug it is a _really_ convenient thing to do. The only thing you need is a reliably triggering test-case, and some time. Linus
Linus Torvalds wrote:
On Thu, 17 Dec 2009, Alain Knaff wrote:
For the moment, I have a very small sample of hardware: 1. One machine which works (my own): Athlon XP 1800+ processor 2. One which doesn't work (Mark's)
Ok. I don't think I even have any machines with floppy drives any more (one external USB drive somewhere gathering dust just in case I ever encounter a floppy again).
Well, on my new box, I have no floppy drive either. The one I mentioned is an old machine that I kept around just in case I needed to debug floppy-related problems.
I might get access to a wider sample of boxen in a week or so, in order to do some stats.
Ok, I was more thinking "we have a bugzilla with ten different people reporting this". If it's just a single machine, that's not going to be relevant.
We do have a bugzilla http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548434 , but unfortunately it has only 2 people so far having seen the bug, one of which (ael) turned out to be a false alert (dusty drive).
What's the easiest way to find out the chipset?
Here's already the output of lspci from my machine (works):
00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 AGP] Host Bridge 00:01.0 PCI bridge: VIA Technologies, Inc. VT8235 PCI Bridge 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
Yeah, lspci (and generally only the northbridge and southbridge matters, the "ISA bridge" might technically be relevant, but since it's universally on the same die as the southbridge, I left it in there just for kicks).
Good. Here's some info about some machines of Mark which do have the problem (there's more than one, fortunately): 1st one showing the problem (claimed to be AMD 790x chipset): 00:00.0 Host bridge: ATI Technologies Inc RD790 Northbridge only dual slot PCI-e_GFX and HT3 K8 part 00:02.0 PCI bridge: ATI Technologies Inc RD790 PCI to PCI bridge (external gfx0 port A) 00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller 2nd one showing the problem (also claimed to be AMD 790x chipset): 00:00.0 Host bridge: Advanced Micro Devices [AMD] RS780 Host Bridge 00:01.0 PCI bridge: Advanced Micro Devices [AMD] RS780 PCI to PCI bridge (int gfx) 00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller He also has several machines that do work: 1st one that does work: 00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) ... and a couple more where he didn't get around to test. [...]
Only the "it doesn't work on xyz" is likely interesting. The machines it works on are probably uninteresting statistically.
I understand... (working machine above just mentioned for completeness' sake). [...]
You'd need a git tree that contains both the working and non-working versions, and then literally just do
git bisect start git bisect good <known good version number here> git bisect bad <known bad version here>
and it will give you a commit to try. Compile, test, see if it's good or bad, and do
git bisect [good|bad]
depending on the result. Rinse and repeat (depending on how tight the initial good/bad commits were, it will need 10-15 kernel tests).
... and how do I check out the most recent good / oldest bad kernel for compilation?
So in this case, since apparently 2.6.27.41 is good, and 2.6.28 is not, it would be something like this:
# clone hpa's tree that has all the stable releases in one place git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
cd linux-2.6-allstable git bisect start git bisect bad v2.6.28 git bisect good v2.6.27.41
and off you go.
ok...
NOTE! Bisection depends very much on the bug being 100% reproducible. If you ever mark a good kernel bad (because you messed up) or a bad kernel good (because the bug wasn't 100% reproducible, so you _thought_ it was good even though the bug was present and just happened to hide), the end result of the bisect will be totally unreliable and seriously screwed up.
So after a successful bisect, it is usually a good idea to try to go back to the original known-bad kernel, and then revert the commit that was indicated as the bad one (assuming the revert works - it could be that the bad one ends up being fundamental to other commits after it), and test that yes, that really fixes the bug.
What command lines would I use for that revert?
It gets more complicated if the bisect hits kernels that you can't test because they have _unrelated_ issues on that machine (compile failures or just other bugs that hide the actual floppy behavior), but generally bisection is pretty simple. "man git-bisect" does have some extra pointers.
So git bisect may be somewhat time-consuming and mindless, but for reliably triggering bugs where nobody really knows what caused the bug it is a _really_ convenient thing to do. The only thing you need is a reliably triggering test-case, and some time.
Linus
Alain
On Thu, 17 Dec 2009, Alain Knaff wrote:
[...]
You'd need a git tree that contains both the working and non-working versions, and then literally just do
git bisect start git bisect good <known good version number here> git bisect bad <known bad version here>
and it will give you a commit to try. Compile, test, see if it's good or bad, and do
git bisect [good|bad]
depending on the result. Rinse and repeat (depending on how tight the initial good/bad commits were, it will need 10-15 kernel tests).
... and how do I check out the most recent good / oldest bad kernel for compilation?
'git bisect' does all that for you. You don't need to check out the kernels you mark good or bad - git will just calculate the commit graphs, and pick a commit that is in the "middle" between them, and check out that commit.
So after a successful bisect, it is usually a good idea to try to go back to the original known-bad kernel, and then revert the commit that was indicated as the bad one (assuming the revert works - it could be that the bad one ends up being fundamental to other commits after it), and test that yes, that really fixes the bug.
What command lines would I use for that revert?
git revert <sha1-that-git-bisect-reported> but even if that revert isn't successful, just the bisection result will be very interesting (assuming it all looks sane, of course - as mentioned, sometimes bisect results get screwed up because the bug isn't entirely reproducible due to timing etc). Linus
Linus Torvalds wrote:
On Thu, 17 Dec 2009, Alain Knaff wrote:
[...]
You'd need a git tree that contains both the working and non-working versions, and then literally just do
git bisect start git bisect good <known good version number here> git bisect bad <known bad version here>
and it will give you a commit to try. Compile, test, see if it's good or bad, and do
git bisect [good|bad]
depending on the result. Rinse and repeat (depending on how tight the initial good/bad commits were, it will need 10-15 kernel tests). ... and how do I check out the most recent good / oldest bad kernel for compilation?
'git bisect' does all that for you. You don't need to check out the kernels you mark good or bad - git will just calculate the commit graphs, and pick a commit that is in the "middle" between them, and check out that commit.
So after a successful bisect, it is usually a good idea to try to go back to the original known-bad kernel, and then revert the commit that was indicated as the bad one (assuming the revert works - it could be that the bad one ends up being fundamental to other commits after it), and test that yes, that really fixes the bug. What command lines would I use for that revert?
git revert <sha1-that-git-bisect-reported>
but even if that revert isn't successful, just the bisection result will be very interesting (assuming it all looks sane, of course - as mentioned, sometimes bisect results get screwed up because the bug isn't entirely reproducible due to timing etc).
Linus
thanks for these explanations, that makes it clearer indeed. Now, I only need to find a machine locally to test this on. Or Mark: are you confident in doing this yourself? Thanks, Alain
On 12/17/2009 06:24 PM, Alain Knaff wrote:
Now, I only need to find a machine locally to test this on. Or Mark: are you confident in doing this yourself?
I'll give it a shot. Sounds easy enough. If I have problems, I'll yell. Mark
On 12/18/2009 03:59 AM, Mark Hounschell wrote:
On 12/17/2009 06:24 PM, Alain Knaff wrote:
Now, I only need to find a machine locally to test this on. Or Mark: are you confident in doing this yourself?
I'll give it a shot. Sounds easy enough. If I have problems, I'll yell.
Ok, I ran into a build issue on the third on. #harley:/usr/src # git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git Initialized empty Git repository in /usr/src/linux-2.6-allstable/.git/ remote: Counting objects: 1486248, done. remote: Compressing objects: 100% (248092/248092), done. Receiving objects: 100% (1486248/1486248), 323.35 MiB | 6753 KiB/s, done. remote: Total 1486248 (delta 1236282), reused 1476516 (delta 1227133) Resolving deltas: 100% (1236282/1236282), done. Checking out files: 100% (31502/31502), done. harley:/usr/src # cd linux-2.6-allstable harley:/usr/src/linux-2.6-allstable # git bisect start harley:/usr/src/linux-2.6-allstable # git bisect bad v2.6.28 harley:/usr/src/linux-2.6-allstable # git bisect good v2.6.27.41 Bisecting: a merge base must be tested [3fa8749e584b55f1180411ab1b51117190bac1e5] Linux 2.6.27 Build and test kernel: This one worked so: harley:/usr/src/linux-2.6-allstable # git bisect good Bisecting: 4879 revisions left to test after this (roughly 12 steps) [c813b4e16ead3c3df98ac84419d4df2adf33fe01] Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6 Build and test kernel: This one worked so: harley:/usr/src/linux-2.6-allstable # git bisect good Bisecting: 2443 revisions left to test after this (roughly 11 steps) [db563fc2e80534f98c7f9121a6f7dfe41f177a79] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6 This one doesn't build: CC [M] fs/ext3/super.o fs/ext3/super.c: In function ‘ext3_quota_on’: fs/ext3/super.c:2839: error: ‘nd’ undeclared (first use in this function) fs/ext3/super.c:2839: error: (Each undeclared identifier is reported only once fs/ext3/super.c:2839: error: for each function it appears in.) make[2]: *** [fs/ext3/super.o] Error 1 make[1]: *** [fs/ext3] Error 2 make: *** [fs] Error 2 I haven't yet determined that I can but, if I were to make a modification to the tree now to fix this would that screw up the bisect process? Regards Mark
Mark Hounschell <dmarkh@cfl.rr.com> writes:
harley:/usr/src/linux-2.6-allstable # git bisect good Bisecting: 2443 revisions left to test after this (roughly 11 steps) [db563fc2e80534f98c7f9121a6f7dfe41f177a79] Merge git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6
This one doesn't build:
CC [M] fs/ext3/super.o fs/ext3/super.c: In function ‘ext3_quota_on’: fs/ext3/super.c:2839: error: ‘nd’ undeclared (first use in this function) fs/ext3/super.c:2839: error: (Each undeclared identifier is reported only once fs/ext3/super.c:2839: error: for each function it appears in.) make[2]: *** [fs/ext3/super.o] Error 1 make[1]: *** [fs/ext3] Error 2 make: *** [fs] Error 2
I haven't yet determined that I can but, if I were to make a modification to the tree now to fix this would that screw up the bisect process?
It won't, in such cases. But you can also git reset --hard another_commit_id (while doing git bisect) if it fixes this problem (e.g. some next commit). And you can skip uninteresting parts of the tree when starting git bisect (though if the cause is in skipped parts, the results will be meaningless). -- Krzysztof Halasa
On Fri, 18 Dec 2009, Mark Hounschell wrote:
This one doesn't build:
CC [M] fs/ext3/super.o fs/ext3/super.c: In function ‘ext3_quota_on’: fs/ext3/super.c:2839: error: ‘nd’ undeclared (first use in this function) fs/ext3/super.c:2839: error: (Each undeclared identifier is reported only once fs/ext3/super.c:2839: error: for each function it appears in.) make[2]: *** [fs/ext3/super.o] Error 1 make[1]: *** [fs/ext3] Error 2 make: *** [fs] Error 2
I haven't yet determined that I can but, if I were to make a modification to the tree now to fix this would that screw up the bisect process?
You can safely fix unrelated problems without screwing up the bisection. And in this case you can be pretty sure that this is unrelated, so it's all ok. The fix for that silly problem is - path_put(&nd.path); + path_put(&path); (it's due to a silent merge failure - it merged cleanly, but semantics had changed in a branch and impacted code that was newly introduced in another branch). Linus
On 12/18/2009 10:22 AM, Linus Torvalds wrote:
On Fri, 18 Dec 2009, Mark Hounschell wrote:
This one doesn't build:
CC [M] fs/ext3/super.o fs/ext3/super.c: In function ‘ext3_quota_on’: fs/ext3/super.c:2839: error: ‘nd’ undeclared (first use in this function) fs/ext3/super.c:2839: error: (Each undeclared identifier is reported only once fs/ext3/super.c:2839: error: for each function it appears in.) make[2]: *** [fs/ext3/super.o] Error 1 make[1]: *** [fs/ext3] Error 2 make: *** [fs] Error 2
I haven't yet determined that I can but, if I were to make a modification to the tree now to fix this would that screw up the bisect process?
You can safely fix unrelated problems without screwing up the bisection. And in this case you can be pretty sure that this is unrelated, so it's all ok.
The fix for that silly problem is
- path_put(&nd.path); + path_put(&path);
(it's due to a silent merge failure - it merged cleanly, but semantics had changed in a branch and impacted code that was newly introduced in another branch).
Yep, thanks. I'm past that now. But haven't done a bisect [good|bad] on the results of that one yet. Did you see Alain's email response to my bisect progress report to him? I'm still at a loss as to how to proceed? Mark
On Fri, 18 Dec 2009, Mark Hounschell wrote:
Yep, thanks. I'm past that now. But haven't done a bisect [good|bad] on the results of that one yet. Did you see Alain's email response to my bisect progress report to him?
I'm still at a loss as to how to proceed?
Ahh, the HPET issue. That one is actually very interesting information, because we've had problems with HPET before. But what I would suggest is to try to continue to bisect with HPET enabled (to see the problem), and the commit that you couldn't even boot with HPET enabled you should not count as good or bad because you just don't know. You can do "git bisect skip" to make git know that some particular commit is not a commit you can test, and you can also move away from a whole problematic region to another area by doing git bisect visualize to bring up a graphical gitk view of what all you have left to bisect, pick a good point (still _reasonably_ close to the middle) there, and do git reset --hard <the-point-you-want-to-test> and try that kernel instead of the one git bisect suggested. But this floppy DMA inconsistency being somehow HPET-related is interestign in itself. One thing that HPET does si to obviously change how we read the time - and what that can cause (totally indirectly) is that now we don't touch the southbridge with IO accesses nearly as much, because instead of going to the old 8253 PIT will touch the same legacy chip support that implements the floppy controller itself. So it's entirely possible that the reason a non-HPET setup doesn't show this is that the accesses to the i8253 PIT part will "synchronize" the old floppy controller too, and hide some issue. But still, I assume you had HPET enabled in 2.6.27, so it would be interesting to see exactly when the problem starts. Linus
On 12/18/2009 10:45 AM, Linus Torvalds wrote:
On Fri, 18 Dec 2009, Mark Hounschell wrote:
Yep, thanks. I'm past that now. But haven't done a bisect [good|bad] on the results of that one yet. Did you see Alain's email response to my bisect progress report to him?
I'm still at a loss as to how to proceed?
Ahh, the HPET issue.
That one is actually very interesting information, because we've had problems with HPET before. But what I would suggest is to try to continue to bisect with HPET enabled (to see the problem), and the commit that you couldn't even boot with HPET enabled you should not count as good or bad because you just don't know.
You can do "git bisect skip" to make git know that some particular commit is not a commit you can test, and you can also move away from a whole problematic region to another area by doing
git bisect visualize
to bring up a graphical gitk view of what all you have left to bisect, pick a good point (still _reasonably_ close to the middle) there, and do
git reset --hard <the-point-you-want-to-test>
and try that kernel instead of the one git bisect suggested.
But this floppy DMA inconsistency being somehow HPET-related is interestign in itself. One thing that HPET does si to obviously change how we read the time - and what that can cause (totally indirectly) is that now we don't touch the southbridge with IO accesses nearly as much, because instead of going to the old 8253 PIT will touch the same legacy chip support that implements the floppy controller itself.
So it's entirely possible that the reason a non-HPET setup doesn't show this is that the accesses to the i8253 PIT part will "synchronize" the old floppy controller too, and hide some issue.
But still, I assume you had HPET enabled in 2.6.27, so it would be interesting to see exactly when the problem starts.
Linus
It looks like I may have to back up and first find the points that, let me, and stop me, booting with the HPET enabled. Before I change direction, can the git-bisect start sequence use the SHA1 id for the starting 'goods' and 'bads'? I don't see reference to that in the doc. Thanks Mark
On Fri, 18 Dec 2009, Mark Hounschell wrote:
It looks like I may have to back up and first find the points that, let me, and stop me, booting with the HPET enabled. Before I change direction, can the git-bisect start sequence use the SHA1 id for the starting 'goods' and 'bads'? I don't see reference to that in the doc.
You can always use a SHA1 id instead of a tag. So when you did git bisect good v2.6.17.4 you could always have replaced that "v2.6.17.4" with the SHA1 of the commit. In git, the SHA1 ID's are the "real" names - the tags and branch names are purely for human-readable decoration. Git always turns them into SHA1 id's internally. Linus
On 12/18/2009 03:15 PM, Linus Torvalds wrote:
On Fri, 18 Dec 2009, Mark Hounschell wrote:
It looks like I may have to back up and first find the points that, let me, and stop me, booting with the HPET enabled. Before I change direction, can the git-bisect start sequence use the SHA1 id for the starting 'goods' and 'bads'? I don't see reference to that in the doc.
You can always use a SHA1 id instead of a tag. So when you did
git bisect good v2.6.17.4
you could always have replaced that "v2.6.17.4" with the SHA1 of the commit.
In git, the SHA1 ID's are the "real" names - the tags and branch names are purely for human-readable decoration. Git always turns them into SHA1 id's internally.
Linus
Ok, I may have something that might help. # git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> Date: Fri Sep 5 18:02:18 2008 -0700 x86: HPET_MSI Initialise per-cpu HPET timers Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states. If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast. Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> :040000 040000 b0a11fa0abdc591427e78236a1f25f26b824140e f2e9b13cf9e2eb7e0fc101660b1e1d499033d78f M arch And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a @ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) { if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1; disable_irq(dev->irq); AND add the quiet cmdline option. Also, of all the machines it does work on with hpets enabled, I don't see the HPET2 in /proc/interupts as below. cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 3 0 IO-APIC-edge timer 1: 0 0 1712 6 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 60 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 37798 179 IO-APIC-edge i8042 14: 0 0 16462 71 IO-APIC-edge pata_atiixp 15: 0 0 5713 17 IO-APIC-edge pata_atiixp 16: 0 0 904 2 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel, ni-pci-gpib 17: 0 0 2 0 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 49940 90 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia 19: 0 0 703 2 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 1303 15 IO-APIC-fasteoi ahci 24: 261763 0 0 0 HPET_MSI-edge hpet2 29: 0 0 220 5 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 138 271356 264446 261050 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 4511 9275 8470 8086 Rescheduling interrupts CAL: 3624 8666 523 4543 Function call interrupts TLB: 981 1111 1065 1058 TLB shootdowns ERR: 0 MIS: 0 Regards Mark
[ Ingo, Venki and Shaohua added to cc: see the whole thread on lkml for details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block. Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed. What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET. So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ] On Tue, 22 Dec 2009, Mark Hounschell wrote:
Ok, I may have something that might help.
# git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> Date: Fri Sep 5 18:02:18 2008 -0700
x86: HPET_MSI Initialise per-cpu HPET timers
Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states.
If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c
commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
@ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) {
if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1;
disable_irq(dev->irq);
AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving? IOW, _if_ you boot with that fix from commit 5ceb1a04 (and the quiet option - I wonder what that is about: do you have any ideas?), is the per-CPU HPET timer commit also the commit that causes floppy problems, or is this purely a "bisect when HPET became a boot-up problem"? Linus ---
Also, of all the machines it does work on with hpets enabled, I don't see the HPET2 in /proc/interupts as below.
cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 3 0 IO-APIC-edge timer 1: 0 0 1712 6 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 60 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 37798 179 IO-APIC-edge i8042 14: 0 0 16462 71 IO-APIC-edge pata_atiixp 15: 0 0 5713 17 IO-APIC-edge pata_atiixp 16: 0 0 904 2 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel, ni-pci-gpib 17: 0 0 2 0 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 49940 90 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia 19: 0 0 703 2 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 1303 15 IO-APIC-fasteoi ahci
24: 261763 0 0 0 HPET_MSI-edge hpet2
29: 0 0 220 5 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 138 271356 264446 261050 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 4511 9275 8470 8086 Rescheduling interrupts CAL: 3624 8666 523 4543 Function call interrupts TLB: 981 1111 1065 1058 TLB shootdowns ERR: 0 MIS: 0
On 12/22/2009 12:38 PM, Linus Torvalds wrote:
[ Ingo, Venki and Shaohua added to cc: see the whole thread on lkml for details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block.
Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed.
What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET.
So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ]
On Tue, 22 Dec 2009, Mark Hounschell wrote:
Ok, I may have something that might help.
# git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> Date: Fri Sep 5 18:02:18 2008 -0700
x86: HPET_MSI Initialise per-cpu HPET timers
Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states.
If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c
commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
@ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) {
if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1;
disable_irq(dev->irq);
AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving?
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled. Commit 5ceb1a04 is where I found I could boot again with the hpet enabled. It was a simple patch so backed it into where I was in order to be able to boot with hpet on. I did 2 different bisects. First to find out when I could boot again with hpet on, then the next to find which caused the floppy problem. Using the patch from the first bisect (5ceb1a04) while doing the second bisect.
IOW, _if_ you boot with that fix from commit 5ceb1a04 (and the quiet option - I wonder what that is about: do you have any ideas?), is the per-CPU HPET timer commit also the commit that causes floppy problems, or is this purely a "bisect when HPET became a boot-up problem"?
The quiet option was only needed because with that 5ceb1a04 commit applied to the kernels I was interested in, kernel messages of some kind went on for hours and I could not get a login prompt. They went by so fast and I didn't have a serial console available to see them. They must not have too important or critical because the machine acted as normal as any machine in single user mode. But once I got to a single user login prompt it was for sure the same floppy problem.
---
Also, of all the machines it does work on with hpets enabled, I don't see the HPET2 in /proc/interupts as below.
cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 3 0 IO-APIC-edge timer 1: 0 0 1712 6 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 60 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 37798 179 IO-APIC-edge i8042 14: 0 0 16462 71 IO-APIC-edge pata_atiixp 15: 0 0 5713 17 IO-APIC-edge pata_atiixp 16: 0 0 904 2 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel, ni-pci-gpib 17: 0 0 2 0 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 49940 90 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia 19: 0 0 703 2 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 1303 15 IO-APIC-fasteoi ahci
24: 261763 0 0 0 HPET_MSI-edge hpet2
29: 0 0 220 5 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 138 271356 264446 261050 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 4511 9275 8470 8086 Rescheduling interrupts CAL: 3624 8666 523 4543 Function call interrupts TLB: 981 1111 1065 1058 TLB shootdowns ERR: 0 MIS: 0
Regards Mark
On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
On 12/22/2009 12:38 PM, Linus Torvalds wrote:
[ Ingo, Venki and Shaohua added to cc: see the whole thread on lkml for details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block.
Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed.
What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET.
So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ]
On Tue, 22 Dec 2009, Mark Hounschell wrote:
Ok, I may have something that might help.
# git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> Date: Fri Sep 5 18:02:18 2008 -0700
x86: HPET_MSI Initialise per-cpu HPET timers
Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states.
If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c
commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
@ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) {
if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1;
disable_irq(dev->irq);
AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving?
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled.
I am missing something here. Commit 26afe5f2 is where system does not boot with HPET or is it where the floppy stops working when you boot with HPET enabled. Can you try "idle=halt" with both .27 and .28 with /proc/interrupts output in each case. With that option, we should be using local APIC timer and PIT, HPET or HPET with MSI should not really matter. Does it still fail with .28 with that option? Thanks, Venki
On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
On 12/22/2009 12:38 PM, Linus Torvalds wrote:
[ Ingo, Venki and Shaohua added to cc: see the whole thread on lkml for details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block.
Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed.
What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET.
So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ]
On Tue, 22 Dec 2009, Mark Hounschell wrote:
Ok, I may have something that might help.
# git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> Date: Fri Sep 5 18:02:18 2008 -0700
x86: HPET_MSI Initialise per-cpu HPET timers
Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states.
If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c
commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
@ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) {
if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1;
disable_irq(dev->irq);
AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving?
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled.
I am missing something here. Commit 26afe5f2 is where system does not boot with HPET or is it where the floppy stops working when you boot with HPET enabled.
As it happens, both happen there. Commit 5ceb1a04 is where it starts booting _again_ with hpet enabled. So I took that patch (5ceb1a04) and applied it to (26afe5f2f) to be able to boot with hpet enabled. I had to use the quiet option to get to a login prompt, but there is where the floppy format first fails, just as it does in 2.6.28 and up.
Can you try "idle=halt" with both .27 and .28 with /proc/interrupts output in each case. With that option, we should be using local APIC timer and PIT, HPET or HPET with MSI should not really matter. Does it still fail with .28 with that option?
Yes, I will try that for you but will have to wait until the morning. Sorry. Regards Mark
On 12/22/2009 07:22 PM, Mark Hounschell wrote:
On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
On 12/22/2009 12:38 PM, Linus Torvalds wrote:
[ Ingo, Venki and Shaohua added to cc: see the whole thread on lkml for details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block.
Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed.
What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET.
So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ]
On Tue, 22 Dec 2009, Mark Hounschell wrote:
Ok, I may have something that might help.
# git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> Date: Fri Sep 5 18:02:18 2008 -0700
x86: HPET_MSI Initialise per-cpu HPET timers
Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states.
If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c
commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
@ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) {
if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1;
disable_irq(dev->irq);
AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving?
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled.
I am missing something here. Commit 26afe5f2 is where system does not boot with HPET or is it where the floppy stops working when you boot with HPET enabled.
As it happens, both happen there. Commit 5ceb1a04 is where it starts booting _again_ with hpet enabled. So I took that patch (5ceb1a04) and applied it to (26afe5f2f) to be able to boot with hpet enabled. I had to use the quiet option to get to a login prompt, but there is where the floppy format first fails, just as it does in 2.6.28 and up.
Can you try "idle=halt" with both .27 and .28 with /proc/interrupts output in each case. With that option, we should be using local APIC timer and PIT, HPET or HPET with MSI should not really matter. Does it still fail with .28 with that option?
2.6.28 still fails with that option. 2.6.27.41 /proc/interrupts with idle=halt CPU0 CPU1 CPU2 CPU3 0: 126 0 0 1 IO-APIC-edge timer 1: 0 0 1 157 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 6 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 1 128 IO-APIC-edge i8042 14: 0 0 34 4457 IO-APIC-edge pata_atiixp 15: 0 0 4 480 IO-APIC-edge pata_atiixp 16: 0 0 0 397 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel 17: 0 0 0 2 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 0 142 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 4 1154 IO-APIC-fasteoi ahci 219: 0 0 3 63 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 91539 91964 92525 91181 Local timer interrupts RES: 2888 3873 2434 2721 Rescheduling interrupts CAL: 240 245 247 84 function call interrupts TLB: 768 628 526 512 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0 2.6.28 /proc/interrupts with idle=halt CPU0 CPU1 CPU2 CPU3 0: 126 0 2 0 IO-APIC-edge timer 1: 0 0 192 0 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 1 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 128 1 IO-APIC-edge i8042 14: 0 1 147114 396 IO-APIC-edge pata_atiixp 15: 0 0 646 2 IO-APIC-edge pata_atiixp 16: 0 0 396 0 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel 17: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 362 1 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 874 1 IO-APIC-fasteoi ahci 1274: 0 0 193 4 PCI-MSI-edge eth0 1279: 513207 0 0 0 HPET_MSI-edge hpet2 NMI: 0 0 0 0 Non-maskable interrupts LOC: 268 513395 513138 522088 Local timer interrupts RES: 3262 3679 2573 3746 Rescheduling interrupts CAL: 131 166 57 147 Function call interrupts TLB: 680 438 450 639 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0 Mark
-----Original Message----- From: Mark Hounschell [mailto:markh@compro.net] Sent: Wednesday, December 23, 2009 5:03 AM To: Pallipadi, Venkatesh Cc: dmarkh@cfl.rr.com; Linus Torvalds; Alain Knaff; Linux Kernel Mailing List; fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar Subject: Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?)
On 12/22/2009 07:22 PM, Mark Hounschell wrote:
On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
On 12/22/2009 12:38 PM, Linus Torvalds wrote:
[ Ingo, Venki and Shaohua added to cc: see the whole
thread on lkml for
details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block.
Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed.
What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET.
So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ]
On Tue, 22 Dec 2009, Mark Hounschell wrote:
Ok, I may have something that might help.
# git bisect bad 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 Author: venkatesh.pallipadi@intel.com
<venkatesh.pallipadi@intel.com>
Date: Fri Sep 5 18:02:18 2008 -0700
x86: HPET_MSI Initialise per-cpu HPET timers
Initialize a per CPU HPET MSI timer when possible. We retain the HPET timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We setup the remaining HPET timers as per CPU MSI based timers. This per CPU timer will eliminate the need for timer broadcasting with IRQ 0 when there is non-functional LAPIC timer across CPU deep C-states.
If there are more CPUs than number of available timers, CPUs that do not find any timer to use will continue using LAPIC and IRQ 0 broadcast.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Shaohua Li <shaohua.li@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
And of coarse this was the first commit that I could not boot if I had hpet enabled. To get this one to boot (single user mode only) I had to add the the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c
commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a
@ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) {
if (request_irq(dev->irq, hpet_interrupt_handler, - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) return -1;
disable_irq(dev->irq);
AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving?
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled.
I am missing something here. Commit 26afe5f2 is where system does not boot with HPET or is it where the floppy stops working when you boot with HPET enabled.
As it happens, both happen there. Commit 5ceb1a04 is where it starts booting _again_ with hpet enabled. So I took that patch (5ceb1a04) and applied it to (26afe5f2f) to be able to boot with hpet enabled. I had to use the quiet option to get to a login prompt, but there is where the floppy format first fails, just as it does in 2.6.28 and up.
Can you try "idle=halt" with both .27 and .28 with /proc/interrupts output in each case. With that option, we should be using local APIC timer and PIT, HPET or HPET with MSI should not really matter. Does it still fail with .28 with that option?
2.6.28 still fails with that option.
2.6.27.41 /proc/interrupts with idle=halt
CPU0 CPU1 CPU2 CPU3 0: 126 0 0 1 IO-APIC-edge timer 1: 0 0 1 157 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 6 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 1 128 IO-APIC-edge i8042 14: 0 0 34 4457 IO-APIC-edge pata_atiixp 15: 0 0 4 480 IO-APIC-edge pata_atiixp 16: 0 0 0 397 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel 17: 0 0 0 2 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 0 142 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 4 1154 IO-APIC-fasteoi ahci 219: 0 0 3 63 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 91539 91964 92525 91181 Local timer interrupts RES: 2888 3873 2434 2721 Rescheduling interrupts CAL: 240 245 247 84 function call interrupts TLB: 768 628 526 512 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0
2.6.28 /proc/interrupts with idle=halt
CPU0 CPU1 CPU2 CPU3 0: 126 0 2 0 IO-APIC-edge timer 1: 0 0 192 0 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 1 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 128 1 IO-APIC-edge i8042 14: 0 1 147114 396 IO-APIC-edge pata_atiixp 15: 0 0 646 2 IO-APIC-edge pata_atiixp 16: 0 0 396 0 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel 17: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 362 1 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 874 1 IO-APIC-fasteoi ahci 1274: 0 0 193 4 PCI-MSI-edge eth0 1279: 513207 0 0 0 HPET_MSI-edge hpet2 NMI: 0 0 0 0 Non-maskable interrupts LOC: 268 513395 513138 522088 Local timer interrupts RES: 3262 3679 2573 3746 Rescheduling interrupts CAL: 131 166 57 147 Function call interrupts TLB: 680 438 450 639 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0
Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case. I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28 /proc/timer_list grep . /sys/devices/system/cpu/cpu0/cpuidle/*/* Thanks, Venki
On 12/23/2009 10:10 AM, Pallipadi, Venkatesh wrote:
-----Original Message----- From: Mark Hounschell [mailto:markh@compro.net] Sent: Wednesday, December 23, 2009 5:03 AM To: Pallipadi, Venkatesh Cc: dmarkh@cfl.rr.com; Linus Torvalds; Alain Knaff; Linux Kernel Mailing List; fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar Subject: Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?)
On 12/22/2009 07:22 PM, Mark Hounschell wrote:
On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
On 12/22/2009 12:38 PM, Linus Torvalds wrote:
[ Ingo, Venki and Shaohua added to cc: see the whole
thread on lkml for
details, but Mark is basically chasing down a situation where the floppy driver seems to have trouble formatting floppies, and it happened between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a memory block transfers the wrong value for the first byte of the block.
Which should be impossible, but whatever. Some part of the system has a cached buffer that isn't flushed.
What gets _you_ guys involved is that Mark cannot reproduce the bug if HPET is disabled in the BIOS or by using 'nohpet'. He found that out by pure luck while bisecting, because some time during his bisect, his machine wouldn't even boot with HPET.
So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But 2.6.28 (and current -git) does not. Any ideas? ]
On Tue, 22 Dec 2009, Mark Hounschell wrote: > > Ok, I may have something that might help. > > # git bisect bad > 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit > commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 > Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> > Date: Fri Sep 5 18:02:18 2008 -0700 > > x86: HPET_MSI Initialise per-cpu HPET timers > > Initialize a per CPU HPET MSI timer when possible. We retain the HPET > timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We > setup the remaining HPET timers as per CPU MSI based timers. This per CPU > timer will eliminate the need for timer broadcasting with IRQ 0 when there > is non-functional LAPIC timer across CPU deep C-states. > > If there are more CPUs than number of available timers, CPUs that do not > find any timer to use will continue using LAPIC and IRQ 0 broadcast. > > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> > Signed-off-by: Shaohua Li <shaohua.li@intel.com> > Signed-off-by: Ingo Molnar <mingo@elte.hu> > > And of coarse this was the first commit that I could not boot if I had hpet > enabled. To get this one to boot (single user mode only) I had to add the > the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c > > commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a > > @ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) > { > > if (request_irq(dev->irq, hpet_interrupt_handler, > - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) > + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) > return -1; > > disable_irq(dev->irq); > > AND add the quiet cmdline option.
Ok, so we know why HPET didn't boot for you, and that was fixed later (by that 5ceb1a04). But is this also when the floppy started mis-behaving?
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled.
I am missing something here. Commit 26afe5f2 is where system does not boot with HPET or is it where the floppy stops working when you boot with HPET enabled.
As it happens, both happen there. Commit 5ceb1a04 is where it starts booting _again_ with hpet enabled. So I took that patch (5ceb1a04) and applied it to (26afe5f2f) to be able to boot with hpet enabled. I had to use the quiet option to get to a login prompt, but there is where the floppy format first fails, just as it does in 2.6.28 and up.
Can you try "idle=halt" with both .27 and .28 with /proc/interrupts output in each case. With that option, we should be using local APIC timer and PIT, HPET or HPET with MSI should not really matter. Does it still fail with .28 with that option?
2.6.28 still fails with that option.
2.6.27.41 /proc/interrupts with idle=halt
CPU0 CPU1 CPU2 CPU3 0: 126 0 0 1 IO-APIC-edge timer 1: 0 0 1 157 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 6 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 1 128 IO-APIC-edge i8042 14: 0 0 34 4457 IO-APIC-edge pata_atiixp 15: 0 0 4 480 IO-APIC-edge pata_atiixp 16: 0 0 0 397 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel 17: 0 0 0 2 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 0 142 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 4 1154 IO-APIC-fasteoi ahci 219: 0 0 3 63 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 91539 91964 92525 91181 Local timer interrupts RES: 2888 3873 2434 2721 Rescheduling interrupts CAL: 240 245 247 84 function call interrupts TLB: 768 628 526 512 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0
2.6.28 /proc/interrupts with idle=halt
CPU0 CPU1 CPU2 CPU3 0: 126 0 2 0 IO-APIC-edge timer 1: 0 0 192 0 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 1 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 128 1 IO-APIC-edge i8042 14: 0 1 147114 396 IO-APIC-edge pata_atiixp 15: 0 0 646 2 IO-APIC-edge pata_atiixp 16: 0 0 396 0 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel 17: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 362 1 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 874 1 IO-APIC-fasteoi ahci 1274: 0 0 193 4 PCI-MSI-edge eth0 1279: 513207 0 0 0 HPET_MSI-edge hpet2 NMI: 0 0 0 0 Non-maskable interrupts LOC: 268 513395 513138 522088 Local timer interrupts RES: 3262 3679 2573 3746 Rescheduling interrupts CAL: 131 166 57 147 Function call interrupts TLB: 680 438 450 639 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0
Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case.
I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28 /proc/timer_list
Attached.
grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
I have no /sys/devices/system/cpu/cpu0/cpuidle on this machine. Maybe because of # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set Would it be OK if when you ask for 2.6.28 info, I use a 2.6.32.2 kernel? That kernel also fails fdformat with hpet enabled on these machines. Thanks Mark
On 12/23/2009 10:34 AM, Mark Hounschell wrote:
On 12/23/2009 10:10 AM, Pallipadi, Venkatesh wrote:
-----Original Message----- From: Mark Hounschell [mailto:markh@compro.net] Sent: Wednesday, December 23, 2009 5:03 AM To: Pallipadi, Venkatesh Cc: dmarkh@cfl.rr.com; Linus Torvalds; Alain Knaff; Linux Kernel Mailing List; fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar Subject: Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28 (Was: Re: Cannot format floppies under kernel 2.6.*?)
On 12/22/2009 07:22 PM, Mark Hounschell wrote:
On 12/22/2009 06:37 PM, Pallipadi, Venkatesh wrote:
On Tue, 2009-12-22 at 09:57 -0800, Mark Hounschell wrote:
On 12/22/2009 12:38 PM, Linus Torvalds wrote: > > [ Ingo, Venki and Shaohua added to cc: see the whole thread on lkml for > details, but Mark is basically chasing down a situation where the floppy > driver seems to have trouble formatting floppies, and it happened > between 2.6.27 and .28. The trouble seems to be that a DMA transfer of a > memory block transfers the wrong value for the first byte of the block. > > Which should be impossible, but whatever. Some part of the system has a > cached buffer that isn't flushed. > > What gets _you_ guys involved is that Mark cannot reproduce the bug if > HPET is disabled in the BIOS or by using 'nohpet'. He found that out by > pure luck while bisecting, because some time during his bisect, his > machine wouldn't even boot with HPET. > > So the problem is: with HPET enabled, 2.6.27.4 _used_ to work. But > 2.6.28 (and current -git) does not. Any ideas? ] > > On Tue, 22 Dec 2009, Mark Hounschell wrote: >> >> Ok, I may have something that might help. >> >> # git bisect bad >> 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is the first bad commit >> commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 >> Author: venkatesh.pallipadi@intel.com <venkatesh.pallipadi@intel.com> >> Date: Fri Sep 5 18:02:18 2008 -0700 >> >> x86: HPET_MSI Initialise per-cpu HPET timers >> >> Initialize a per CPU HPET MSI timer when possible. We retain the HPET >> timer 0 (IRQ 0) and timer 1 (IRQ 8) as is when legacy mode is being used. We >> setup the remaining HPET timers as per CPU MSI based timers. This per CPU >> timer will eliminate the need for timer broadcasting with IRQ 0 when there >> is non-functional LAPIC timer across CPU deep C-states. >> >> If there are more CPUs than number of available timers, CPUs that do not >> find any timer to use will continue using LAPIC and IRQ 0 broadcast. >> >> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> >> Signed-off-by: Shaohua Li <shaohua.li@intel.com> >> Signed-off-by: Ingo Molnar <mingo@elte.hu> >> >> And of coarse this was the first commit that I could not boot if I had hpet >> enabled. To get this one to boot (single user mode only) I had to add the >> the quiet cmdline option and following patch from to arch/x86/kernel/hpet.c >> >> commit 5ceb1a04187553e08c6ab60d30cee7c454ee139a >> >> @ -445,7 +445,7 @@ static int hpet_setup_irq(struct hpet_dev *dev) >> { >> >> if (request_irq(dev->irq, hpet_interrupt_handler, >> - IRQF_SHARED|IRQF_NOBALANCING, dev->name, dev)) >> + IRQF_DISABLED|IRQF_NOBALANCING, dev->name, dev)) >> return -1; >> >> disable_irq(dev->irq); >> >> AND add the quiet cmdline option. > > Ok, so we know why HPET didn't boot for you, and that was fixed later (by > that 5ceb1a04). But is this also when the floppy started mis-behaving? >
Commit 26afe5f2fbf06ea0765aaa316640c4dd472310c0 is when the floppy stops working and also when I could no longer boot with hpet enabled.
I am missing something here. Commit 26afe5f2 is where system does not boot with HPET or is it where the floppy stops working when you boot with HPET enabled.
As it happens, both happen there. Commit 5ceb1a04 is where it starts booting _again_ with hpet enabled. So I took that patch (5ceb1a04) and applied it to (26afe5f2f) to be able to boot with hpet enabled. I had to use the quiet option to get to a login prompt, but there is where the floppy format first fails, just as it does in 2.6.28 and up.
Can you try "idle=halt" with both .27 and .28 with /proc/interrupts output in each case. With that option, we should be using local APIC timer and PIT, HPET or HPET with MSI should not really matter. Does it still fail with .28 with that option?
2.6.28 still fails with that option.
2.6.27.41 /proc/interrupts with idle=halt
CPU0 CPU1 CPU2 CPU3 0: 126 0 0 1 IO-APIC-edge timer 1: 0 0 1 157 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 6 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 1 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 1 128 IO-APIC-edge i8042 14: 0 0 34 4457 IO-APIC-edge pata_atiixp 15: 0 0 4 480 IO-APIC-edge pata_atiixp 16: 0 0 0 397 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel 17: 0 0 0 2 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 0 142 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 4 1154 IO-APIC-fasteoi ahci 219: 0 0 3 63 PCI-MSI-edge eth0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 91539 91964 92525 91181 Local timer interrupts RES: 2888 3873 2434 2721 Rescheduling interrupts CAL: 240 245 247 84 function call interrupts TLB: 768 628 526 512 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0
2.6.28 /proc/interrupts with idle=halt
CPU0 CPU1 CPU2 CPU3 0: 126 0 2 0 IO-APIC-edge timer 1: 0 0 192 0 IO-APIC-edge i8042 3: 0 0 6 0 IO-APIC-edge 4: 0 0 6 0 IO-APIC-edge 6: 0 0 4 0 IO-APIC-edge floppy 8: 0 0 1 0 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 128 1 IO-APIC-edge i8042 14: 0 1 147114 396 IO-APIC-edge pata_atiixp 15: 0 0 646 2 IO-APIC-edge pata_atiixp 16: 0 0 396 0 IO-APIC-fasteoi aic79xx, ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel 17: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 18: 0 0 0 0 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 0 0 362 1 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb3, ttySLG0, eth1 22: 0 0 874 1 IO-APIC-fasteoi ahci 1274: 0 0 193 4 PCI-MSI-edge eth0 1279: 513207 0 0 0 HPET_MSI-edge hpet2 NMI: 0 0 0 0 Non-maskable interrupts LOC: 268 513395 513138 522088 Local timer interrupts RES: 3262 3679 2573 3746 Rescheduling interrupts CAL: 131 166 57 147 Function call interrupts TLB: 680 438 450 639 TLB shootdowns SPU: 0 0 0 0 Spurious interrupts ERR: 0 MIS: 0
Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case.
I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28 /proc/timer_list
Attached.
grep . /sys/devices/system/cpu/cpu0/cpuidle/*/*
I have no /sys/devices/system/cpu/cpu0/cpuidle on this machine. Maybe because of
# # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set
Would it be OK if when you ask for 2.6.28 info, I use a 2.6.32.2 kernel? That kernel also fails fdformat with hpet enabled on these machines.
I do have this on 2.6.32.2 though. # grep . /sys/devices/system/cpu/cpuidle/current_* /sys/devices/system/cpu/cpuidle/current_driver:acpi_idle /sys/devices/system/cpu/cpuidle/current_governor_ro:ladder Want me to go back to 2.6.28 and show this? Mark
On Wed, 23 Dec 2009, Mark Hounschell wrote:
Hmm. Looks like hpet2 is still getting used instead of local APIC timer in .28 case.
I was expecting some low number in hpet2 and local timer on all CPU to be around the same value. Above shows CPU 0 is depending on hpet2 for some reason even with idle=halt. Can you send the output of below two in case of .28 /proc/timer_list
Attached.
Oh wow. That's crazy: Tick Device: mode: 1 Per CPU device: 0 Clock Event Device: hpet2 max_delta_ns: 2147483647 min_delta_ns: 5000 mult: 61510047 shift: 32 mode: 3 next_event: 123991000000 nsecs set_next_event: hpet_msi_next_event set_mode: hpet_msi_set_mode event_handler: hrtimer_interrupt Tick Device: mode: 1 Per CPU device: 1 Clock Event Device: lapic max_delta_ns: 670831998 min_delta_ns: 1199 mult: 53707624 shift: 32 mode: 3 next_event: 123991125000 nsecs set_next_event: lapic_next_event set_mode: lapic_timer_setup event_handler: hrtimer_interrupt ... It's not using the lapic for CPU0. Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd. The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;) That said, none of this seems to explain why DMA/fdformat doesn't work. Linus
Linus Torvalds <torvalds@linux-foundation.org> writes:
It's not using the lapic for CPU0.
Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd.
The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;)
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer. This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled? -Andi -- ak@linux.intel.com -- Speaking for myself only.
On Wed, 23 Dec 2009, Andi Kleen wrote:
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
Ahh, ok, that makes sense. I was assuming the broadcast timer would act in that capacity, but..
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
We have indeed had historical issues with floppy and sleep states before. I do note another issue, though - the floppy driver itself seems totally broken when it comes to using interleaved sectors. Alain, that "place logical sectors" code is simply _broken_ - the "while" kicks in only if the first sector we test is busy _and_ we were at the last sector so that we increment past F_SECT_PER_TRACK. So shouldn't that sector layout be something like the appended? Linus --- drivers/block/floppy.c | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 3266b4f..9c9148c 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -2237,13 +2237,10 @@ static void setup_format_params(int track) for (count = 1; count <= F_SECT_PER_TRACK; ++count) { here[n].sect = count; n = (n + il) % F_SECT_PER_TRACK; - if (here[n].sect) { /* sector busy, find next free sector */ + while (here[n].sect) { /* sector busy, find next free sector */ ++n; - if (n >= F_SECT_PER_TRACK) { + if (n >= F_SECT_PER_TRACK) n -= F_SECT_PER_TRACK; - while (here[n].sect) - ++n; - } } } if (_floppy->stretch & FD_SECTBASEMASK) {
On Wed, Dec 23, 2009 at 08:49:38AM -0800, Linus Torvalds wrote:
On Wed, 23 Dec 2009, Andi Kleen wrote:
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
Ahh, ok, that makes sense. I was assuming the broadcast timer would act in that capacity, but..
The "broadcasts" are done using IPIs from cpu #08 and only when that target CPU is deep idle. That's more efficient than letting the hardware always broadcast.
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
We have indeed had historical issues with floppy and sleep states before.
I removed that code when moving to 64bit (floppy driver disabling C1), but perhaps we need some variant of it again (but it's the first such report in many years). Although it would be sad to have it again on all systems. -Andi
On Wed, 23 Dec 2009 18:08:32 +0100 Andi Kleen <andi@firstfloor.org> wrote:
I removed that code when moving to 64bit (floppy driver disabling C1), but perhaps we need some variant of it again (but it's the first such report in many years). Although it would be sad to have it again on all systems.
at least now we have the pmqos infrastructure, driver just needs to ask for 0 latency ;) -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
On Fri, Dec 25, 2009 at 01:21:16PM +0100, Arjan van de Ven wrote:
On Wed, 23 Dec 2009 18:08:32 +0100 Andi Kleen <andi@firstfloor.org> wrote:
I removed that code when moving to 64bit (floppy driver disabling C1), but perhaps we need some variant of it again (but it's the first such report in many years). Although it would be sad to have it again on all systems.
at least now we have the pmqos infrastructure, driver just needs to ask for 0 latency ;)
Does pmqos work with apci=off etc.? I didn't think it shut down the classic "HLT" idle, does it? The old i386 systems needed that apparently, they long pre date any deeper idle states. Anyways the code is still there for 32bit. -Andi -- ak@linux.intel.com -- Speaking for myself only.
On Fri, 25 Dec 2009 21:33:04 +0100 Andi Kleen <andi@firstfloor.org> wrote:
On Fri, Dec 25, 2009 at 01:21:16PM +0100, Arjan van de Ven wrote:
On Wed, 23 Dec 2009 18:08:32 +0100 Andi Kleen <andi@firstfloor.org> wrote:
I removed that code when moving to 64bit (floppy driver disabling C1), but perhaps we need some variant of it again (but it's the first such report in many years). Although it would be sad to have it again on all systems.
at least now we have the pmqos infrastructure, driver just needs to ask for 0 latency ;)
Does pmqos work with apci=off etc.?
yes
I didn't think it shut down the classic "HLT" idle, does it?
it does if you specify a latency of 0; it will then go into the spin-only state until you give up your latency requirement -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Does pmqos work with apci=off etc.?
yes
I didn't think it shut down the classic "HLT" idle, does it?
it does if you specify a latency of 0; it will then go into the spin-only state until you give up your latency requirement
I looked at it this evening, but it seems like pm_qos is not interrupt safe (e.g. calls blocking notifiers) and floppy currently does enable/disable_hlt from interrupts and bottom halves. Would need some more infrastructure work or restructuring of the floppy driver. -Andi -- ak@linux.intel.com -- Speaking for myself only.
Andi Kleen wrote:
Does pmqos work with apci=off etc.? yes
I didn't think it shut down the classic "HLT" idle, does it? it does if you specify a latency of 0; it will then go into the spin-only state until you give up your latency requirement
I looked at it this evening, but it seems like pm_qos is not interrupt safe (e.g. calls blocking notifiers) and floppy currently does enable/disable_hlt from interrupts and bottom halves.
Would need some more infrastructure work or restructuring of the floppy driver.
-Andi
disable_hlt/enable_hlt was only needed to work around a bug on TM4000 (Texas Instrument) Laptops which were popular around 1994 / 1995. Basically, as soon as the CPU went into hlt() state, so did the DMA controller, either causing a really slow transfer, or (worse) a buffer over/underrun which failed the operation. On hardware unaffected by this particular bug (which would be most hardware around now, 14 years after the fact...), these calls can safely be removed. Regards, Alain
disable_hlt/enable_hlt was only needed to work around a bug on TM4000 (Texas Instrument) Laptops which were popular around 1994 / 1995.
I don't think we can fully drop support for these systems. Did they have an unique PCI ID or something else that could be tested for? Perhaps it could be just a white list like dmi_year > 1995 to disable. Depending on how often floppies are still used this might save non trivial amounts of power on newer systems :) Anyways it would be probably good to convert this to the new infrastructure, and remove the old hooks, but the interrupt-context issue would need to be fixed first. -Andi -- ak@linux.intel.com -- Speaking for myself only.
Andi Kleen wrote:
disable_hlt/enable_hlt was only needed to work around a bug on TM4000 (Texas Instrument) Laptops which were popular around 1994 / 1995.
I don't think we can fully drop support for these systems.
Did they have an unique PCI ID or something else that could be tested for?
Floppy controllers are not PCI devices and thus have no PCI id unfortunately... :-(
Perhaps it could be just a white list like dmi_year > 1995 to disable.
Depending on how often floppies are still used this might save non trivial amounts of power on newer systems :)
Removing these calls will indeed save a *tiny* amount of power by allowing the CPU to go into halt during DMA transfer. But the main argument should be simplification.
Anyways it would be probably good to convert this to the new infrastructure, and remove the old hooks, but the interrupt-context issue would need to be fixed first.
-Andi
Well, at least for testing whether it fixes the new problem (DMA cache issue), it's useful to know that these calls can be safely removed on almost all of today's machines. That way, we will know whether this refactoring will be worth the effort. Regards, Alain
On Mon, Dec 28, 2009 at 11:27:56AM +0100, Alain Knaff wrote:
Andi Kleen wrote:
disable_hlt/enable_hlt was only needed to work around a bug on TM4000 (Texas Instrument) Laptops which were popular around 1994 / 1995.
I don't think we can fully drop support for these systems.
Did they have an unique PCI ID or something else that could be tested for?
Floppy controllers are not PCI devices and thus have no PCI id unfortunately... :-(
Yes, but it's enough to identify any component in the system. -Andi -- ak@linux.intel.com -- Speaking for myself only.
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
We have indeed had historical issues with floppy and sleep states before.
I removed that code when moving to 64bit (floppy driver disabling C1), but perhaps we need some variant of it again (but it's the first such report in many years). Although it would be sad to have it again on all systems.
C1 is hlt. Are you sure? I could see how C3 could cause problems (DMA latency), but... Can mark simply try with idle=poll? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 12/27/2009 06:09 AM, Pavel Machek wrote:
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
We have indeed had historical issues with floppy and sleep states before.
I removed that code when moving to 64bit (floppy driver disabling C1), but perhaps we need some variant of it again (but it's the first such report in many years). Although it would be sad to have it again on all systems.
C1 is hlt. Are you sure? I could see how C3 could cause problems (DMA latency), but...
Can mark simply try with idle=poll?
Pavel
The floppy still fails with idle=poll Mark
-----Original Message----- From: Linus Torvalds [mailto:torvalds@linux-foundation.org] Sent: Wednesday, December 23, 2009 8:50 AM To: Andi Kleen Cc: Mark Hounschell; Pallipadi, Venkatesh; dmarkh@cfl.rr.com; Alain Knaff; Linux Kernel Mailing List; fdutils@fdutils.linux.lu; Li, Shaohua; Ingo Molnar Subject: Re: [Fdutils] DMA cache consistency bug introduced in 2.6.28
On Wed, 23 Dec 2009, Andi Kleen wrote:
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer
broadcasts
when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
Ahh, ok, that makes sense. I was assuming the broadcast timer would act in that capacity, but..
This is what I was thining yday and asked Mark to try idle=halt. This /proc/interrupts is with idle=halt when there should not be any C-states and broadcasts involved.
HPET_MSI-edge hpet2 NMI: 0 0 0 0 Non-maskable interrupts LOC: 268 513395 513138 522088 Local timer interrupts
Not sure how this is related to floppy problem. But, we surely have something wrong with percpu HPET usage here. Thanks, Venki
This is what I was thining yday and asked Mark to try idle=halt. This /proc/interrupts is with idle=halt when there should not be any C-states and broadcasts involved.
Ah ok, missed that sorry. Actually I'm glad that the floppy-idle hack is not needed again. -Andi -- ak@linux.intel.com -- Speaking for myself only.
Linus Torvalds wrote:
diff --git a/drivers/block/floppy.c b/drivers/block/floppy.c index 3266b4f..9c9148c 100644 --- a/drivers/block/floppy.c +++ b/drivers/block/floppy.c @@ -2237,13 +2237,10 @@ static void setup_format_params(int track) for (count = 1; count <= F_SECT_PER_TRACK; ++count) { here[n].sect = count; n = (n + il) % F_SECT_PER_TRACK; - if (here[n].sect) { /* sector busy, find next free sector */ + while (here[n].sect) { /* sector busy, find next free sector */ ++n; - if (n >= F_SECT_PER_TRACK) { + if (n >= F_SECT_PER_TRACK) n -= F_SECT_PER_TRACK; - while (here[n].sect) - ++n; - } } } if (_floppy->stretch & FD_SECTBASEMASK) {
The original code does indeed look a little bit strange... and might break if there is a long run of "busy" sectors near the end of the physical track. Or maybe there is a mathematical reason why this situation cannot occur. I'll have to think about it a little bit more to come up with a test case that will break either the new or old code. But in any case, if a bug would occur due to this code, it would only depend on the format's parameters, and not on the hardwarde. Regards, Alain
On 12/23/2009 11:38 AM, Andi Kleen wrote:
Linus Torvalds <torvalds@linux-foundation.org> writes:
It's not using the lapic for CPU0.
Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd.
The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;)
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
I just did and /proc/interrupts looks the same and the floppy still does not format. I'll try the patch Linus provided now. Mark
On Wed, 23 Dec 2009, Mark Hounschell wrote:
I'll try the patch Linus provided now.
I doubt it matters - because if it did, it would matter for everybody, and the HPET thing shouldn't make any difference at all. [ Or rather, it should matter for everybody trying to format a specific format (without interleave it won't matter, and not all formats have any interleave - I think it was mainly used on 5.25" floppies and special formats). ] Besides, maybe I was just mis-reading the code. But getting some testing for the patch certainly won't hurt, so I'm not going to argue against it any more ;) Linus
On 12/23/2009 01:01 PM, Linus Torvalds wrote:
On Wed, 23 Dec 2009, Mark Hounschell wrote:
I'll try the patch Linus provided now.
I doubt it matters - because if it did, it would matter for everybody, and the HPET thing shouldn't make any difference at all.
[ Or rather, it should matter for everybody trying to format a specific format (without interleave it won't matter, and not all formats have any interleave - I think it was mainly used on 5.25" floppies and special formats). ]
Besides, maybe I was just mis-reading the code.
But getting some testing for the patch certainly won't hurt, so I'm not going to argue against it any more ;)
Yea, that hosed it up pretty good. The very first track label sent out caused some sort of timeout. Dec 23 13:10:02 harley kernel: Dec 23 13:10:02 harley kernel: floppy driver state Dec 23 13:10:02 harley kernel: ------------------- Dec 23 13:10:02 harley kernel: now=9017 last interrupt=8117 diff=900 last called handler=f73ce27d Dec 23 13:10:02 harley kernel: timeout_message=lock fdc Dec 23 13:10:02 harley kernel: last output bytes: Dec 23 13:10:02 harley kernel: 0 90 4294899106 Dec 23 13:10:02 harley kernel: 1a 90 4294899106 Dec 23 13:10:02 harley kernel: 0 90 4294899106 Dec 23 13:10:02 harley kernel: 3 90 4294899106 Dec 23 13:10:02 harley kernel: c1 90 4294899106 Dec 23 13:10:02 harley kernel: 10 90 4294899106 Dec 23 13:10:02 harley kernel: 7 80 4294899106 Dec 23 13:10:02 harley kernel: 0 90 4294899106 Dec 23 13:10:02 harley kernel: 8 81 4294899106 Dec 23 13:10:02 harley kernel: 4 80 4294899106 Dec 23 13:10:02 harley kernel: 0 90 4294899106 Dec 23 13:10:02 harley kernel: e6 80 8007 Dec 23 13:10:02 harley kernel: 0 90 8007 Dec 23 13:10:02 harley syslog-ng[2651]: last message repeated 2 times Dec 23 13:10:02 harley kernel: 1 90 8007 Dec 23 13:10:02 harley kernel: 2 90 8007 Dec 23 13:10:02 harley kernel: 12 90 8007 Dec 23 13:10:02 harley kernel: 1b 90 8007 Dec 23 13:10:02 harley kernel: ff 90 8007 Dec 23 13:10:02 harley kernel: last result at 8117 Dec 23 13:10:02 harley kernel: last redo_fd_request at 8117 Dec 23 13:10:02 harley kernel: Dec 23 13:10:02 harley kernel: status=80 Dec 23 13:10:02 harley kernel: fdc_busy=1 Dec 23 13:10:02 harley kernel: cont=f73d58e4 Dec 23 13:10:02 harley kernel: current_req=(null) Dec 23 13:10:02 harley kernel: command_status=-1 Dec 23 13:10:02 harley kernel: Dec 23 13:10:02 harley kernel: floppy0: floppy timeout called Dec 23 13:10:22 harley kernel: Dec 23 13:10:22 harley kernel: floppy driver state Dec 23 13:10:22 harley kernel: ------------------- Dec 23 13:10:22 harley kernel: now=15017 last interrupt=8117 diff=6900 last called handler=f73ce27d Dec 23 13:10:22 harley kernel: timeout_message=do wakeup Dec 23 13:10:22 harley kernel: last output bytes: Dec 23 13:10:22 harley kernel: 0 90 4294899106 Dec 23 13:10:22 harley kernel: 1a 90 4294899106 Dec 23 13:10:22 harley kernel: 0 90 4294899106 Dec 23 13:10:22 harley kernel: 3 90 4294899106 Dec 23 13:10:22 harley kernel: c1 90 4294899106 Dec 23 13:10:22 harley kernel: 10 90 4294899106 Dec 23 13:10:22 harley kernel: 7 80 4294899106 Dec 23 13:10:22 harley kernel: 0 90 4294899106 Dec 23 13:10:22 harley kernel: 8 81 4294899106 Dec 23 13:10:22 harley kernel: 4 80 4294899106 Dec 23 13:10:22 harley kernel: 0 90 4294899106 Dec 23 13:10:22 harley kernel: e6 80 8007 Dec 23 13:10:22 harley kernel: 0 90 8007 Dec 23 13:10:22 harley syslog-ng[2651]: last message repeated 2 times Dec 23 13:10:22 harley kernel: 1 90 8007 Dec 23 13:10:22 harley kernel: 2 90 8007 Dec 23 13:10:22 harley kernel: 12 90 8007 Dec 23 13:10:22 harley kernel: 1b 90 8007 Dec 23 13:10:22 harley kernel: ff 90 8007 Dec 23 13:10:22 harley kernel: last result at 8117 Dec 23 13:10:22 harley kernel: last redo_fd_request at 8117 Dec 23 13:10:22 harley kernel: Dec 23 13:10:22 harley kernel: status=80 Dec 23 13:10:22 harley kernel: fdc_busy=1 Dec 23 13:10:22 harley kernel: floppy_work.func=f73d03da Dec 23 13:10:22 harley kernel: cont=f73d5274 Dec 23 13:10:22 harley kernel: current_req=(null) Dec 23 13:10:22 harley kernel: command_status=-1 Dec 23 13:10:22 harley kernel: Dec 23 13:10:22 harley kernel: floppy0: floppy timeout called Dec 23 13:10:22 harley kernel: floppy.c: no request in request_don Have to reboot now... Mark
On Wed, Dec 23, 2009 at 09:41:50AM -0800, Mark Hounschell wrote:
On 12/23/2009 11:38 AM, Andi Kleen wrote:
Linus Torvalds <torvalds@linux-foundation.org> writes:
It's not using the lapic for CPU0.
Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd.
The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;)
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
I just did and /proc/interrupts looks the same and the floppy still does not format.
Can you try this one line patch either on .28 or .32 (with /proc/interrupts output). This disables hpet2 and lapic timer should then be used on CPU 0. If things work with this test patch, we will know that the failure is somehow related to HPET usage in MSI mode. Thanks, Venki Reduce the rating of percpu hpet timer Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cafb1c6..f89d17a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -480,7 +480,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) hpet_setup_irq(hdev); evt->irq = hdev->irq; - evt->rating = 110; + evt->rating = 40; evt->features = CLOCK_EVT_FEAT_ONESHOT; if (hdev->flags & HPET_DEV_PERI_CAP) evt->features |= CLOCK_EVT_FEAT_PERIODIC; -- 1.6.0.6
On 12/23/2009 02:18 PM, Pallipadi, Venkatesh wrote:
On Wed, Dec 23, 2009 at 09:41:50AM -0800, Mark Hounschell wrote:
On 12/23/2009 11:38 AM, Andi Kleen wrote:
Linus Torvalds <torvalds@linux-foundation.org> writes:
It's not using the lapic for CPU0.
Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd.
The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;)
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
I just did and /proc/interrupts looks the same and the floppy still does not format.
Can you try this one line patch either on .28 or .32 (with /proc/interrupts output). This disables hpet2 and lapic timer should then be used on CPU 0. If things work with this test patch, we will know that the failure is somehow related to HPET usage in MSI mode.
Thanks, Venki
Reduce the rating of percpu hpet timer
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cafb1c6..f89d17a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -480,7 +480,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) hpet_setup_irq(hdev); evt->irq = hdev->irq;
- evt->rating = 110; + evt->rating = 40; evt->features = CLOCK_EVT_FEAT_ONESHOT; if (hdev->flags & HPET_DEV_PERI_CAP) evt->features |= CLOCK_EVT_FEAT_PERIODIC;
That made it work. Used 2.6.32.2 cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 0 1 IO-APIC-edge timer 1: 0 0 0 67 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 4 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 8 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 10 1519 IO-APIC-edge i8042 14: 0 0 39 10995 IO-APIC-edge pata_atiixp 15: 0 0 3 391 IO-APIC-edge pata_atiixp 16: 0 0 2 606 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel, Digi DBX2, ni-pci-gpib 17: 0 0 0 3 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 10 2168 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, Digi DBX2, nvidia 19: 0 0 0 130 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 8 1151 IO-APIC-fasteoi ahci 24: 0 0 0 0 HPET_MSI-edge hpet2 29: 0 0 0 48 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 34842 30177 29672 29632 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 17501 20449 16670 11224 Rescheduling interrupts CAL: 10554 2336 1102 1071 Function call interrupts TLB: 364 562 753 468 TLB shootdowns ERR: 0 MIS: 0 # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
On Wed, 2009-12-23 at 11:35 -0800, Mark Hounschell wrote:
On 12/23/2009 02:18 PM, Pallipadi, Venkatesh wrote:
On Wed, Dec 23, 2009 at 09:41:50AM -0800, Mark Hounschell wrote:
On 12/23/2009 11:38 AM, Andi Kleen wrote:
Linus Torvalds <torvalds@linux-foundation.org> writes:
It's not using the lapic for CPU0.
Using the HPET as a per-cpu timer is some crazy sh*t, since it's pretty expensive to reprogram (compared to the local apic). And having different timers for different CPU's is just odd.
The fact that the timer subsystem can do this and it all (mostly) works at all is nice and impressive, but doesn't make it any less crazy ;)
I suspect it's a system where the APIC timer stops in deeper idle states and it supports them. In this case CPU #0 does timer broadcasts when needed to wake the other CPUs up from deep C, but for that it has to run with HPET. At least the other ones can still enjoy the LAPIC timer.
This might suggest that Mark's floppy controller doesn't like deep C? Mark, did you try booting with processor.max_cstate=1 and HPET enabled?
I just did and /proc/interrupts looks the same and the floppy still does not format.
Can you try this one line patch either on .28 or .32 (with /proc/interrupts output). This disables hpet2 and lapic timer should then be used on CPU 0. If things work with this test patch, we will know that the failure is somehow related to HPET usage in MSI mode.
Thanks, Venki
Reduce the rating of percpu hpet timer
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cafb1c6..f89d17a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -480,7 +480,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) hpet_setup_irq(hdev); evt->irq = hdev->irq;
- evt->rating = 110; + evt->rating = 40; evt->features = CLOCK_EVT_FEAT_ONESHOT; if (hdev->flags & HPET_DEV_PERI_CAP) evt->features |= CLOCK_EVT_FEAT_PERIODIC;
That made it work. Used 2.6.32.2
cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 0 1 IO-APIC-edge timer 1: 0 0 0 67 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 4 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 8 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 10 1519 IO-APIC-edge i8042 14: 0 0 39 10995 IO-APIC-edge pata_atiixp 15: 0 0 3 391 IO-APIC-edge pata_atiixp 16: 0 0 2 606 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel, Digi DBX2, ni-pci-gpib 17: 0 0 0 3 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 10 2168 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, Digi DBX2, nvidia 19: 0 0 0 130 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 8 1151 IO-APIC-fasteoi ahci 24: 0 0 0 0 HPET_MSI-edge hpet2 29: 0 0 0 48 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 34842 30177 29672 29632 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 17501 20449 16670 11224 Rescheduling interrupts CAL: 10554 2336 1102 1071 Function call interrupts TLB: 364 562 753 468 TLB shootdowns ERR: 0 MIS: 0
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
Hmmm.. Thats very interesting indeed. That clearly says that HPET MSI interrupts somehow is causing some caching side effect in the chipset that results in this floppy dma failure. Here's is what we have until now. IRQ 0 is based on HPET legacy interrupt and HPET device is also capable of MSI on this platform. So we also have a percpu hpet (hpet2 tied to CPU0). percpu hpet was added to avoid the usage of IRQ0+LAPIC broadcast in cases where LAPIC timer will stop working in deep C-state. As we have only one HPET channel free for percpu HPET, we only have hpet2 tied to CPU 0 and other CPUs still have to go through IRQ0+LAPIC broadcast with deep C-state. One problem here is that percpu hpet should only get used when LAPIC cannot be used (that is when CPU enters deep C-state). Using hpet2 in place of LAPIC timer even when deep C-state is not supported is not right in terms of performance. We need some changes here to fix that [Problem 1]. But, that still does not explain why we are seeing this problem in the first place. I mean, using hpet2 is not optimal, but should not have functionality issues like this. Even fixing [Problem 1] above, we may see this problem on some other platform that supports deep C-state and so has hpet2 enabled for a valid reason. Also, I am not sure whether the problem also happens if legacy HPET interrupts are used during run time in place of LAPIC timer (May be worth to try this with a simple test patch, let me think about it). In this case, legacy HPET interrupt rightly goes quiet after boot, giving priority to LAPIC timer. With hpet MSI interrupts, we do a write followed by read of HPET memmapped register to set a HPET channel timeout + read of global HPET timer. This happens on every timer interrupt on CPU 0. And we also have MSI interrupt being delivered to CPU 0. I cannot think of any reason why this can break dma. We can probably try adding some dummy HPET read after dma write, to see if that flushes things properly. Thanks, Venki
Pallipadi, Venkatesh wrote:
MSI interrupt being delivered to CPU 0. I cannot think of any reason why this can break dma. We can probably try adding some dummy HPET read after dma write, to see if that flushes things properly.
Shouldn't that be "... some dummy HPET read _before_ dma write...". In order to ensure that DMA cache is consistent _before_ dma controller reads it? Regards, Alain
On Wed, 2009-12-23 at 12:34 -0800, alain wrote:
Pallipadi, Venkatesh wrote:
MSI interrupt being delivered to CPU 0. I cannot think of any reason why this can break dma. We can probably try adding some dummy HPET read after dma write, to see if that flushes things properly.
Shouldn't that be "... some dummy HPET read _before_ dma write...". In order to ensure that DMA cache is consistent _before_ dma controller reads it?
Yes. I meant after the contents of the buffer is changed and before the DMA transfer and the controller reading it. Thanks, Venki
On 12/23/2009 03:30 PM, Pallipadi, Venkatesh wrote:
Can you try this one line patch either on .28 or .32 (with /proc/interrupts output). This disables hpet2 and lapic timer should then be used on CPU 0. If things work with this test patch, we will know that the failure is somehow related to HPET usage in MSI mode.
Thanks, Venki
Reduce the rating of percpu hpet timer
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cafb1c6..f89d17a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -480,7 +480,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) hpet_setup_irq(hdev); evt->irq = hdev->irq;
- evt->rating = 110; + evt->rating = 40; evt->features = CLOCK_EVT_FEAT_ONESHOT; if (hdev->flags & HPET_DEV_PERI_CAP) evt->features |= CLOCK_EVT_FEAT_PERIODIC;
That made it work. Used 2.6.32.2
cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 0 1 IO-APIC-edge timer 1: 0 0 0 67 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 4 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 8 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 10 1519 IO-APIC-edge i8042 14: 0 0 39 10995 IO-APIC-edge pata_atiixp 15: 0 0 3 391 IO-APIC-edge pata_atiixp 16: 0 0 2 606 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel, Digi DBX2, ni-pci-gpib 17: 0 0 0 3 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 10 2168 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, Digi DBX2, nvidia 19: 0 0 0 130 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 8 1151 IO-APIC-fasteoi ahci 24: 0 0 0 0 HPET_MSI-edge hpet2 29: 0 0 0 48 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 34842 30177 29672 29632 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 17501 20449 16670 11224 Rescheduling interrupts CAL: 10554 2336 1102 1071 Function call interrupts TLB: 364 562 753 468 TLB shootdowns ERR: 0 MIS: 0
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
Hmmm.. Thats very interesting indeed.
That clearly says that HPET MSI interrupts somehow is causing some caching side effect in the chipset that results in this floppy dma failure.
Here's is what we have until now. IRQ 0 is based on HPET legacy interrupt and HPET device is also capable of MSI on this platform. So we also have a percpu hpet (hpet2 tied to CPU0). percpu hpet was added to avoid the usage of IRQ0+LAPIC broadcast in cases where LAPIC timer will stop working in deep C-state. As we have only one HPET channel free for percpu HPET, we only have hpet2 tied to CPU 0 and other CPUs still have to go through IRQ0+LAPIC broadcast with deep C-state.
One problem here is that percpu hpet should only get used when LAPIC cannot be used (that is when CPU enters deep C-state). Using hpet2 in place of LAPIC timer even when deep C-state is not supported is not right in terms of performance. We need some changes here to fix that [Problem 1].
But, that still does not explain why we are seeing this problem in the first place. I mean, using hpet2 is not optimal, but should not have functionality issues like this. Even fixing [Problem 1] above, we may see this problem on some other platform that supports deep C-state and so has hpet2 enabled for a valid reason.
Also, I am not sure whether the problem also happens if legacy HPET interrupts are used during run time in place of LAPIC timer (May be worth to try this with a simple test patch, let me think about it). In this case, legacy HPET interrupt rightly goes quiet after boot, giving priority to LAPIC timer.
With hpet MSI interrupts, we do a write followed by read of HPET memmapped register to set a HPET channel timeout + read of global HPET timer. This happens on every timer interrupt on CPU 0. And we also have MSI interrupt being delivered to CPU 0. I cannot think of any reason why this can break dma. We can probably try adding some dummy HPET read after dma write, to see if that flushes things properly.
Haven't seen any activity on this thread in a while. Just curious, are we still working this? Is there anything else I can do to help? Thanks Mark
On Fri, 2010-01-08 at 09:42 -0800, Mark Hounschell wrote:
On 12/23/2009 03:30 PM, Pallipadi, Venkatesh wrote:
Can you try this one line patch either on .28 or .32 (with /proc/interrupts output). This disables hpet2 and lapic timer should then be used on CPU 0. If things work with this test patch, we will know that the failure is somehow related to HPET usage in MSI mode.
Thanks, Venki
Reduce the rating of percpu hpet timer
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cafb1c6..f89d17a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -480,7 +480,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) hpet_setup_irq(hdev); evt->irq = hdev->irq;
- evt->rating = 110; + evt->rating = 40; evt->features = CLOCK_EVT_FEAT_ONESHOT; if (hdev->flags & HPET_DEV_PERI_CAP) evt->features |= CLOCK_EVT_FEAT_PERIODIC;
That made it work. Used 2.6.32.2
cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 0 1 IO-APIC-edge timer 1: 0 0 0 67 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 4 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 8 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 10 1519 IO-APIC-edge i8042 14: 0 0 39 10995 IO-APIC-edge pata_atiixp 15: 0 0 3 391 IO-APIC-edge pata_atiixp 16: 0 0 2 606 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel, Digi DBX2, ni-pci-gpib 17: 0 0 0 3 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 10 2168 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, Digi DBX2, nvidia 19: 0 0 0 130 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 8 1151 IO-APIC-fasteoi ahci 24: 0 0 0 0 HPET_MSI-edge hpet2 29: 0 0 0 48 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 34842 30177 29672 29632 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 17501 20449 16670 11224 Rescheduling interrupts CAL: 10554 2336 1102 1071 Function call interrupts TLB: 364 562 753 468 TLB shootdowns ERR: 0 MIS: 0
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
Hmmm.. Thats very interesting indeed.
That clearly says that HPET MSI interrupts somehow is causing some caching side effect in the chipset that results in this floppy dma failure.
Here's is what we have until now. IRQ 0 is based on HPET legacy interrupt and HPET device is also capable of MSI on this platform. So we also have a percpu hpet (hpet2 tied to CPU0). percpu hpet was added to avoid the usage of IRQ0+LAPIC broadcast in cases where LAPIC timer will stop working in deep C-state. As we have only one HPET channel free for percpu HPET, we only have hpet2 tied to CPU 0 and other CPUs still have to go through IRQ0+LAPIC broadcast with deep C-state.
One problem here is that percpu hpet should only get used when LAPIC cannot be used (that is when CPU enters deep C-state). Using hpet2 in place of LAPIC timer even when deep C-state is not supported is not right in terms of performance. We need some changes here to fix that [Problem 1].
But, that still does not explain why we are seeing this problem in the first place. I mean, using hpet2 is not optimal, but should not have functionality issues like this. Even fixing [Problem 1] above, we may see this problem on some other platform that supports deep C-state and so has hpet2 enabled for a valid reason.
Also, I am not sure whether the problem also happens if legacy HPET interrupts are used during run time in place of LAPIC timer (May be worth to try this with a simple test patch, let me think about it). In this case, legacy HPET interrupt rightly goes quiet after boot, giving priority to LAPIC timer.
With hpet MSI interrupts, we do a write followed by read of HPET memmapped register to set a HPET channel timeout + read of global HPET timer. This happens on every timer interrupt on CPU 0. And we also have MSI interrupt being delivered to CPU 0. I cannot think of any reason why this can break dma. We can probably try adding some dummy HPET read after dma write, to see if that flushes things properly.
Haven't seen any activity on this thread in a while. Just curious, are we still working this? Is there anything else I can do to help?
Sorry for not following up on this. We have narrowed this down to HPET MSI and floppy DMA. I still don't know how HPET MSI interrupts are breaking floppy DMA. You are seeing the problem on two different systems. Correct? Do you have any system where this works with HPET MSI enabled? Couple of options on how we can go about this one: 1) Change the HPET-MSI change to not get activated when there are no C-states with LAPIC stoppage involved. This will resolve the problem on the systems you reported as there are no deep C-states. But, I fear that with the actual problem unresolved, we may hit it in future with this or some other platform having same issue with CPUs that support deep C-state. 2) Try this testcase on few other platforms that support HPET-MSI and deep C-states and check how widespread the problem is and then add a whitelist-blacklist for HPET MSI usage. I think, for 2.6.33 option 1 is better. Will work on that and send in patches for you test. Thanks, Venki
On 01/11/2010 07:19 PM, Pallipadi, Venkatesh wrote:
On Fri, 2010-01-08 at 09:42 -0800, Mark Hounschell wrote:
On 12/23/2009 03:30 PM, Pallipadi, Venkatesh wrote:
Can you try this one line patch either on .28 or .32 (with /proc/interrupts output). This disables hpet2 and lapic timer should then be used on CPU 0. If things work with this test patch, we will know that the failure is somehow related to HPET usage in MSI mode.
Thanks, Venki
Reduce the rating of percpu hpet timer
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- arch/x86/kernel/hpet.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index cafb1c6..f89d17a 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -480,7 +480,7 @@ static void init_one_hpet_msi_clockevent(struct hpet_dev *hdev, int cpu) hpet_setup_irq(hdev); evt->irq = hdev->irq;
- evt->rating = 110; + evt->rating = 40; evt->features = CLOCK_EVT_FEAT_ONESHOT; if (hdev->flags & HPET_DEV_PERI_CAP) evt->features |= CLOCK_EVT_FEAT_PERIODIC;
That made it work. Used 2.6.32.2
cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 82 0 0 1 IO-APIC-edge timer 1: 0 0 0 67 IO-APIC-edge i8042 3: 0 0 0 6 IO-APIC-edge 4: 0 0 0 4 IO-APIC-edge 6: 0 0 0 4 IO-APIC-edge floppy 8: 0 0 0 8 IO-APIC-edge rtc0 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 10 1519 IO-APIC-edge i8042 14: 0 0 39 10995 IO-APIC-edge pata_atiixp 15: 0 0 3 391 IO-APIC-edge pata_atiixp 16: 0 0 2 606 IO-APIC-fasteoi aic79xx, ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel, Digi DBX2, ni-pci-gpib 17: 0 0 0 3 IO-APIC-fasteoi ehci_hcd:usb1, parport0, ni-pci-gpib 18: 0 0 10 2168 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, Digi DBX2, nvidia 19: 0 0 0 130 IO-APIC-fasteoi aic7xxx, ehci_hcd:usb2, ttySLG0, eth1 22: 0 0 8 1151 IO-APIC-fasteoi ahci 24: 0 0 0 0 HPET_MSI-edge hpet2 29: 0 0 0 48 PCI-MSI-edge sky2@pci:0000:04:00.0 NMI: 0 0 0 0 Non-maskable interrupts LOC: 34842 30177 29672 29632 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 0 0 0 0 Performance monitoring interrupts PND: 0 0 0 0 Performance pending work RES: 17501 20449 16670 11224 Rescheduling interrupts CAL: 10554 2336 1102 1071 Function call interrupts TLB: 364 562 753 468 TLB shootdowns ERR: 0 MIS: 0
# fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... done
Hmmm.. Thats very interesting indeed.
That clearly says that HPET MSI interrupts somehow is causing some caching side effect in the chipset that results in this floppy dma failure.
Here's is what we have until now. IRQ 0 is based on HPET legacy interrupt and HPET device is also capable of MSI on this platform. So we also have a percpu hpet (hpet2 tied to CPU0). percpu hpet was added to avoid the usage of IRQ0+LAPIC broadcast in cases where LAPIC timer will stop working in deep C-state. As we have only one HPET channel free for percpu HPET, we only have hpet2 tied to CPU 0 and other CPUs still have to go through IRQ0+LAPIC broadcast with deep C-state.
One problem here is that percpu hpet should only get used when LAPIC cannot be used (that is when CPU enters deep C-state). Using hpet2 in place of LAPIC timer even when deep C-state is not supported is not right in terms of performance. We need some changes here to fix that [Problem 1].
But, that still does not explain why we are seeing this problem in the first place. I mean, using hpet2 is not optimal, but should not have functionality issues like this. Even fixing [Problem 1] above, we may see this problem on some other platform that supports deep C-state and so has hpet2 enabled for a valid reason.
Also, I am not sure whether the problem also happens if legacy HPET interrupts are used during run time in place of LAPIC timer (May be worth to try this with a simple test patch, let me think about it). In this case, legacy HPET interrupt rightly goes quiet after boot, giving priority to LAPIC timer.
With hpet MSI interrupts, we do a write followed by read of HPET memmapped register to set a HPET channel timeout + read of global HPET timer. This happens on every timer interrupt on CPU 0. And we also have MSI interrupt being delivered to CPU 0. I cannot think of any reason why this can break dma. We can probably try adding some dummy HPET read after dma write, to see if that flushes things properly.
Haven't seen any activity on this thread in a while. Just curious, are we still working this? Is there anything else I can do to help?
Sorry for not following up on this. We have narrowed this down to HPET MSI and floppy DMA. I still don't know how HPET MSI interrupts are breaking floppy DMA.
You are seeing the problem on two different systems. Correct? Do you have any system where this works with HPET MSI enabled?
I see the problem on every system in which the HPET2 shows up in /proc/interrupts. The machines that work with HPET enabled don't show HPET at all in /proc/interrupts. I have some of each. All the boxes that fail here use the (AMD) 790x series chip sets.
Couple of options on how we can go about this one: 1) Change the HPET-MSI change to not get activated when there are no C-states with LAPIC stoppage involved. This will resolve the problem on the systems you reported as there are no deep C-states. But, I fear that with the actual problem unresolved, we may hit it in future with this or some other platform having same issue with CPUs that support deep C-state. 2) Try this testcase on few other platforms that support HPET-MSI and deep C-states and check how widespread the problem is and then add a whitelist-blacklist for HPET MSI usage.
I think, for 2.6.33 option 1 is better. Will work on that and send in patches for you test.
OK, thanks Mark
On Tue, 2010-01-12 at 01:04 -0800, Mark Hounschell wrote:
On 01/11/2010 07:19 PM, Pallipadi, Venkatesh wrote:
Sorry for not following up on this. We have narrowed this down to HPET MSI and floppy DMA. I still don't know how HPET MSI interrupts are breaking floppy DMA.
You are seeing the problem on two different systems. Correct? Do you have any system where this works with HPET MSI enabled?
I see the problem on every system in which the HPET2 shows up in /proc/interrupts. The machines that work with HPET enabled don't show HPET at all in /proc/interrupts. I have some of each. All the boxes that fail here use the (AMD) 790x series chip sets.
Couple of options on how we can go about this one: 1) Change the HPET-MSI change to not get activated when there are no C-states with LAPIC stoppage involved. This will resolve the problem on the systems you reported as there are no deep C-states. But, I fear that with the actual problem unresolved, we may hit it in future with this or some other platform having same issue with CPUs that support deep C-state. 2) Try this testcase on few other platforms that support HPET-MSI and deep C-states and check how widespread the problem is and then add a whitelist-blacklist for HPET MSI usage.
I think, for 2.6.33 option 1 is better. Will work on that and send in patches for you test.
Mark, I just sent out a patchset that should workaround the problem here. Can you check and let me know whether thats the case. We will still need a simpler/smaller workaround for .33. Will send a patch for that soon. Also, are you testing this with usb floppy controller? I tried to test it on my end, but fdformat doesn't seem to like my usb floppy drive. I tried, 'ufiformat -f 1440 <dev>', with which I am not able to reproduce the failure on any of my boxes. Not sure whether that really means I don't hit this bug or that is going through totally different code path. Thanks, Venki
On 01/14/2010 09:01 PM, Pallipadi, Venkatesh wrote:
On Tue, 2010-01-12 at 01:04 -0800, Mark Hounschell wrote:
On 01/11/2010 07:19 PM, Pallipadi, Venkatesh wrote:
Sorry for not following up on this. We have narrowed this down to HPET MSI and floppy DMA. I still don't know how HPET MSI interrupts are breaking floppy DMA.
You are seeing the problem on two different systems. Correct? Do you have any system where this works with HPET MSI enabled?
I see the problem on every system in which the HPET2 shows up in /proc/interrupts. The machines that work with HPET enabled don't show HPET at all in /proc/interrupts. I have some of each. All the boxes that fail here use the (AMD) 790x series chip sets.
Couple of options on how we can go about this one: 1) Change the HPET-MSI change to not get activated when there are no C-states with LAPIC stoppage involved. This will resolve the problem on the systems you reported as there are no deep C-states. But, I fear that with the actual problem unresolved, we may hit it in future with this or some other platform having same issue with CPUs that support deep C-state. 2) Try this testcase on few other platforms that support HPET-MSI and deep C-states and check how widespread the problem is and then add a whitelist-blacklist for HPET MSI usage.
I think, for 2.6.33 option 1 is better. Will work on that and send in patches for you test.
Mark,
I just sent out a patchset that should workaround the problem here. Can you check and let me know whether thats the case.
Yes, I'll try that today. I assume I'll find them on LMKL.
We will still need a simpler/smaller workaround for .33. Will send a patch for that soon.
Also, are you testing this with usb floppy controller? I tried to test it on my end, but fdformat doesn't seem to like my usb floppy drive. I tried, 'ufiformat -f 1440 <dev>', with which I am not able to reproduce the failure on any of my boxes. Not sure whether that really means I don't hit this bug or that is going through totally different code path.
No, I've never even seen a USB floppy controller. Mark
On 01/14/2010 09:01 PM, Pallipadi, Venkatesh wrote:
On Tue, 2010-01-12 at 01:04 -0800, Mark Hounschell wrote:
On 01/11/2010 07:19 PM, Pallipadi, Venkatesh wrote:
Sorry for not following up on this. We have narrowed this down to HPET MSI and floppy DMA. I still don't know how HPET MSI interrupts are breaking floppy DMA.
You are seeing the problem on two different systems. Correct? Do you have any system where this works with HPET MSI enabled?
I see the problem on every system in which the HPET2 shows up in /proc/interrupts. The machines that work with HPET enabled don't show HPET at all in /proc/interrupts. I have some of each. All the boxes that fail here use the (AMD) 790x series chip sets.
Couple of options on how we can go about this one: 1) Change the HPET-MSI change to not get activated when there are no C-states with LAPIC stoppage involved. This will resolve the problem on the systems you reported as there are no deep C-states. But, I fear that with the actual problem unresolved, we may hit it in future with this or some other platform having same issue with CPUs that support deep C-state. 2) Try this testcase on few other platforms that support HPET-MSI and deep C-states and check how widespread the problem is and then add a whitelist-blacklist for HPET MSI usage.
I think, for 2.6.33 option 1 is better. Will work on that and send in patches for you test.
Mark,
I just sent out a patchset that should workaround the problem here. Can you check and let me know whether thats the case.
Yes, it does seem to fix the issue. The floppy formats and /proc/interrupts look normal with nothing going on with the hpet2 msi. Regards Mark
HPET MSI on platforms with ATI SB700/SB800 as they seem to have some side-effects on floppy DMA. Do not use HPET MSI on such platforms. Original problem report from Mark Hounschell http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01118.html Tested-by: Mark Hounschell <markh@compro.net> Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> --- This patch needs to go to stable as well. But, there are some conflicts that prevents the patch from going as is. I can rebase/resubmit to stable once the patch goes upstream. arch/x86/include/asm/hpet.h | 1 + arch/x86/kernel/hpet.c | 8 ++++++++ arch/x86/kernel/quirks.c | 13 +++++++++++++ 3 files changed, 22 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/hpet.h b/arch/x86/include/asm/hpet.h index 5d89fd2..1d5c08a 100644 --- a/arch/x86/include/asm/hpet.h +++ b/arch/x86/include/asm/hpet.h @@ -67,6 +67,7 @@ extern unsigned long hpet_address; extern unsigned long force_hpet_address; extern u8 hpet_blockid; extern int hpet_force_user; +extern u8 hpet_msi_disable; extern int is_hpet_enabled(void); extern int hpet_enable(void); extern void hpet_disable(void); diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c index ba6e658..ad80a1c 100644 --- a/arch/x86/kernel/hpet.c +++ b/arch/x86/kernel/hpet.c @@ -34,6 +34,8 @@ */ unsigned long hpet_address; u8 hpet_blockid; /* OS timer block num */ +u8 hpet_msi_disable; + #ifdef CONFIG_PCI_MSI static unsigned long hpet_num_timers; #endif @@ -596,6 +598,9 @@ static void hpet_msi_capability_lookup(unsigned int start_timer) unsigned int num_timers_used = 0; int i; + if (hpet_msi_disable) + return; + if (boot_cpu_has(X86_FEATURE_ARAT)) return; id = hpet_readl(HPET_ID); @@ -928,6 +933,9 @@ static __init int hpet_late_init(void) hpet_reserve_platform_timers(hpet_readl(HPET_ID)); hpet_print_config(); + if (hpet_msi_disable) + return 0; + if (boot_cpu_has(X86_FEATURE_ARAT)) return 0; diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c index 18093d7..12e9fea 100644 --- a/arch/x86/kernel/quirks.c +++ b/arch/x86/kernel/quirks.c @@ -491,6 +491,19 @@ void force_hpet_resume(void) break; } } + +/* + * HPET MSI on some boards (ATI SB700/SB800) has side effect on + * floppy DMA. Disable HPET MSI on such platforms. + */ +static void force_disable_hpet_msi(struct pci_dev *unused) +{ + hpet_msi_disable = 1; +} + +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, + force_disable_hpet_msi); + #endif #if defined(CONFIG_PCI) && defined(CONFIG_NUMA) -- 1.6.0.6
Alain Knaff wrote:
On 14/12/09 10:51, Ralph Corderoy wrote:
Mark Hounschell wrote:
# fdrawcmd readid 0 repeat=18 0: 0 1: 0 2: 0 3: a 4: 0 5: b 6: 2 no disk change To save others the bother of checking, the "5:" byte runs through 1 to 18 inclusive with no duplicates.
$ show -noshow | > awk '$1 == "5:" {print strtonum("0x" $2)}' | > sort -n | > diff <(seq 1 18) - $
Cheers,
Ralph.
Checking it was still useful however, because sector one had a bad track (9, instead of a like all the others). That could probably be the reason... now we must only find out _why_ this happens.
It would also be useful to find out whether this is the case on all tracks, and if it is always sector 0 that is mis-located.
Mark: the 2.6.28 kernel, is it a kernel directly downloaded from ftp.kernel.org, or a kernel supplied by your distribution? Sometimes distros do introduce weird local patches...
For the record, I use and compile stock kernels and the problem is present with them all. ael
Alain Knaff wrote:
Mark Hounschell wrote: [...]
All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
2.6.28 was when support for sector "bases" other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the "stretch" parameter.
Could it be that on some distributions, "something" is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base).
Could you try to:
The first thing I have to report is that I started by checking fdformat on /dev/fd0 in the usual way to confirm that the bug was still present. This is on debian testing updated daily so many packages are updated freqently. To my surprise, fdformat worked without problems on one i386 machine, but failed in the usual way on another. My next message will report the results of Alain's test on the failing machine. ael
Alain Knaff wrote:
Mark Hounschell wrote: [...]
All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
2.6.28 was when support for sector "bases" other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the "stretch" parameter.
Could it be that on some distributions, "something" is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base).
Could you try to:
fdformat /dev/fd0u1440
in case you don't have /dev/fd0u1440, you can create it using the following command line:
mknod /dev/fd0u1440 b 2 28
then do a getfdprm -o /dev/fd0u1440 (or getfdprm /dev/fd0)
You should get:
2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
The fifth byte (0 here) is the stretch byte. If it contains anything other than 0, this might explain it.
Another test would be to perform:
fdrawcmd readid 0 repeat=18
Here are my results to complement Mark's. Unfortunately fdrawcmd would not run here, perhaps because I have different a different floppy controller. Or maybe I have a different version and am not giving it the right parameters. # dpkg -s fdutils Package: fdutils Status: install ok installed Priority: optional Section: utils Installed-Size: 924 Maintainer: Anibal Monsalve Salazar <anibal@debian.org> Architecture: i386 Version: 5.5-20060227-3 ------------------------------------------------------------------------ # mknod /dev/fd0u1440 b 2 28 # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1 # getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c # fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18 raw cmd: Invalid argument # fdrawcmd drive=0 rate=0 readid 0 raw cmd: Invalid argument # hexdump /dev/fd0 hexdump: /dev/fd0: Input/output error /sys/devices/platform/floppy.0/block/fd0# ls -l total 0 -r--r--r-- 1 root root 4096 2009-12-14 11:18 alignment_offset lrwxrwxrwx 1 root root 0 2009-12-14 11:18 bdi -> ../../../../virtual/bdi/2:0 -r--r--r-- 1 root root 4096 2009-12-14 11:18 capability -r--r--r-- 1 root root 4096 2009-12-14 10:28 dev lrwxrwxrwx 1 root root 0 2009-12-14 10:28 device -> ../../../floppy.0 -r--r--r-- 1 root root 4096 2009-12-14 11:18 discard_alignment -r--r--r-- 1 root root 4096 2009-12-14 11:18 ext_range drwxr-xr-x 2 root root 0 2009-12-14 10:51 holders -r--r--r-- 1 root root 4096 2009-12-14 11:18 inflight drwxr-xr-x 2 root root 0 2009-12-14 11:18 power drwxr-xr-x 3 root root 0 2009-12-14 10:51 queue -r--r--r-- 1 root root 4096 2009-12-14 10:28 range -r--r--r-- 1 root root 4096 2009-12-14 10:28 removable -r--r--r-- 1 root root 4096 2009-12-14 11:18 ro -r--r--r-- 1 root root 4096 2009-12-14 11:18 size drwxr-xr-x 2 root root 0 2009-12-14 10:51 slaves -r--r--r-- 1 root root 4096 2009-12-14 11:18 stat lrwxrwxrwx 1 root root 0 2009-12-14 10:28 subsystem -> ../../../../../class/block -rw-r--r-- 1 root root 4096 2009-12-14 10:28 uevent
Alain Knaff wrote:
On 14/12/09 12:27, ael wrote:
# getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
# fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18 raw cmd: Invalid argument
... and if you try with /dev/fd0 instead?
Yes. I tried all the obvious things. The man/info page for fdrawcmd wasn't very clear on exactly what was accepted, so I tried several options. All with the same result. And now Mark has just the same under 2.6.28 vanilla. I guess all these are further clues... Any point in running under strace? Or gdb (not sure whether I have a debug version around...)? ael
ael wrote:
Alain Knaff wrote:
On 14/12/09 12:27, ael wrote:
# getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
# fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18 raw cmd: Invalid argument
... and if you try with /dev/fd0 instead?
Yes. I tried all the obvious things. The man/info page for fdrawcmd wasn't very clear on exactly what was accepted, so I tried several options. All with the same result. And now Mark has just the same under 2.6.28 vanilla.
Well, not quite the same. I get an i/o error you get an invalid argument. Mark
Alain Knaff wrote:
On 14/12/09 15:58, ael wrote:
Any point in running under strace?
Yes, this would be useful, especially for analyzing the "Invalid argument" issue.
Ok, Will try and fit it in later today. Meanwhile, what exactly is the command line that should work? The one you suggested didn't match the man page - which is probably incomplete or out of date? ael
Alain Knaff wrote:
On 14/12/09 15:58, ael wrote:
Any point in running under strace?
Yes, this would be useful, especially for analyzing the "Invalid argument" issue.
Looks as if that was something to do with my command line. Below is the strace giving the IO error which probably isn't much help :-) # strace fdrawcmd readid 0 repeat=18 2>&1 |tee fdrawcmd.dump|less --------------fdrawcmd.dump--------------------execve("/usr/bin/fdrawcmd", ["fdrawcmd", "readid", "0", "repeat=18"], [/* 34 vars */]) = 0 brk(0) = 0x804b000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb777d000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=94365, ...}) = 0 mmap2(NULL, 94365, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7765000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260l\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1331684, ...}) = 0 mmap2(NULL, 1337704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb761e000 mmap2(0xb775f000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x141) = 0xb775f000 mmap2(0xb7762000, 10600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7762000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb761d000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb761d6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb775f000, 8192, PROT_READ) = 0 mprotect(0xb779b000, 4096, PROT_READ) = 0 munmap(0xb7765000, 94365) = 0 open("/dev/fd0", O_ACCMODE|O_NONBLOCK) = 3 gettimeofday({1260803901, 152148}, NULL) = 0 ioctl(3, FDRAWCMD, 0xbf8ce620) = -1 EIO (Input/output error) dup(2) = 4 fcntl64(4, F_GETFL) = 0x1 (flags O_WRONLY) close(4) = 0 write(2, "raw cmd: Input/output error\n", 28raw cmd: Input/output error ) = 28 exit_group(1) = ? -------------------------------------------------------------------------- Do I need to give strace some flags? ael
On 14/12/09 16:24, ael wrote:
Alain Knaff wrote:
On 14/12/09 15:58, ael wrote:
Any point in running under strace?
Yes, this would be useful, especially for analyzing the "Invalid argument" issue.
Looks as if that was something to do with my command line. Below is the strace giving the IO error which probably isn't much help :-)
# strace fdrawcmd readid 0 repeat=18 2>&1 |tee fdrawcmd.dump|less
[...]
ioctl(3, FDRAWCMD, 0xbf8ce620) = -1 EIO (Input/output error)
Well, at least we now that it is indeed the rawcmd ioctl that gets the error (rather than some other system call), and this is interesting information. Could you also check whether anything interesting got output by the kernel (dmesg) during the fdrawcmd attempt? Thanks, Alain
Alain Knaff wrote:
On 14/12/09 16:24, ael wrote:
Alain Knaff wrote:
On 14/12/09 15:58, ael wrote:
Any point in running under strace? Yes, this would be useful, especially for analyzing the "Invalid argument" issue. Looks as if that was something to do with my command line. Below is the strace giving the IO error which probably isn't much help :-)
# strace fdrawcmd readid 0 repeat=18 2>&1 |tee fdrawcmd.dump|less [...] ioctl(3, FDRAWCMD, 0xbf8ce620) = -1 EIO (Input/output error)
Well, at least we now that it is indeed the rawcmd ioctl that gets the error (rather than some other system call), and this is interesting information.
Could you also check whether anything interesting got output by the kernel (dmesg) during the fdrawcmd attempt?
No. I checked that. Nothing in any of the logs in /var/log/ ael
ael wrote:
Alain Knaff wrote:
Mark Hounschell wrote: [...]
All kernels below 2.6.28 work on these boxes. All kernels 2.6.28 and higher do NOT.
2.6.28 was when support for sector "bases" other than 0 or 1 were introduced. So, rather than have sectors numbered from 1 to 18, you can now have sectors numbered from 129 to 146 (as is used by some of the more exotic CP/M formats). This info is stored in some previously unused bits of the "stretch" parameter.
Could it be that on some distributions, "something" is setting this to some spurious value (which got ignored before 2.6.28, but from 2.6.28 got misinterpreted as a non-zero sector base).
Could you try to:
fdformat /dev/fd0u1440
in case you don't have /dev/fd0u1440, you can create it using the following command line:
mknod /dev/fd0u1440 b 2 28
then do a getfdprm -o /dev/fd0u1440 (or getfdprm /dev/fd0)
You should get:
2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
The fifth byte (0 here) is the stretch byte. If it contains anything other than 0, this might explain it.
Another test would be to perform:
fdrawcmd readid 0 repeat=18
Here are my results to complement Mark's. Unfortunately fdrawcmd would not run here, perhaps because I have different a different floppy controller. Or maybe I have a different version and am not giving it the right parameters.
# dpkg -s fdutils Package: fdutils Status: install ok installed Priority: optional Section: utils Installed-Size: 924 Maintainer: Anibal Monsalve Salazar <anibal@debian.org> Architecture: i386 Version: 5.5-20060227-3
------------------------------------------------------------------------ # mknod /dev/fd0u1440 b 2 28 # fdformat /dev/fd0u1440 Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB. Formatting ... done Verifying ... Read: : Input/output error Problem reading cylinder 0, expected 18432, read -1
# getfdprm -o /dev/fd0u1440 2880 18 2 80 0 0x1b 0x00 0xcf 0x6c
# fdrawcmd drive=/dev/fd0u1440 readid 0 repeat=18 raw cmd: Invalid argument
# fdrawcmd drive=0 rate=0 readid 0 raw cmd: Invalid argument
Maybe "fdrawcmd readid 0 repeat=18 /dev/fd0" Mark
participants (15)
-
A.E.Lawrence -
ael -
alain -
Alain Knaff
-
Andi Kleen -
Arjan van de Ven -
David C Niemi -
Jules Richardson -
Krzysztof Halasa -
Linus Torvalds -
Mark Hounschell -
Mark Hounschell -
Pallipadi, Venkatesh -
Pavel Machek -
Ralph Corderoy