Re: rc6 keeps hanging and blanking displays - bisection complete
On Mon, Aug 15, 2005 at 03:59:07PM -0700, Linus Torvalds wrote: > > > On Tue, 16 Aug 2005, Helge Hafting wrote: > > > > This was interesting. At first, lots of kernels just kept working, > > I almost suspected I was doing something wrong. Then the second last kernel > > recompiled a lot of DRM stuff - and the crash came back! > > The kernel after that worked again, and so the final message was: > > > > 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit > > Ok, that definitely looks bogus. > > That commit should not matter at _all_, it only changes ppc64 specific > things. > > If the bug is sometimes hard to trigger, maybe one of the "good" kernels > wasn't good after all. That would definitely throw a wrench in the > bisection. > The hang, or at least an X "pause" tends to happen in 5-10 minutes of playing cuyo. (�2D game). I have now had the last good kernel (6ade43fbbcc3c12f0ddba112351d14d6c82ae476) running for almost 24 hours, only interrupted by the brief test of drm-less rc6. Normal use haven't provoked anything. Since DRM sort of works with this kernell, I tried tuxracer on the radeon. (Trouble is always with the radeon, never the mga xserver). I played several games, ok except for the usual lousy 5-9 fps. One time I had a "pause", the 3D-game just froze for about half a minute. The other xserver kept displaying firefox (and updating the page too) but I could not start any processes there. I tried starting an xterm - it did not appear until tuxracer "unfroze" and continued as if nothing happened. Perhaps the frozen process held a lock? Disk io seemed sluggish after that incident, and the load meter in icewm seemed to indicate more waiting than usual. The logs tells me of SCSI aborts and a bus reset. I booted into drm-less rc6 after that. Some interrupts are shared on this machine: $ cat /proc/interrupts CPU0 0: 10113154IO-APIC-edge timer 1:371IO-APIC-edge i8042 2: 0 XT-PIC cascade 4: 5735IO-APIC-edge serial 8: 0IO-APIC-edge rtc 12: 11024IO-APIC-edge i8042 14: 21IO-APIC-edge ide0 16: 803248 IO-APIC-level sym53c8xx, eth0, [EMAIL PROTECTED]::01:00.0 17: 0 IO-APIC-level Trident Audio 19: 755535 IO-APIC-level [EMAIL PROTECTED]::00:08.0 20: 5946 IO-APIC-level libata 21: 9448 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 NMI:234 LOC: 10111810 ERR: 0 MIS: 0 The troublesome radoen has a irq of its own. The scsi controller shares irq with the matrox g550, but that card never seem to cause any trouble, other than saturating the cpu during games. :-) On to look at iomem and that rc6 crash. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
Linus Torvalds wrote: On Tue, 16 Aug 2005, Helge Hafting wrote: This was interesting. At first, lots of kernels just kept working, I almost suspected I was doing something wrong. Then the second last kernel recompiled a lot of DRM stuff - and the crash came back! The kernel after that worked again, and so the final message was: 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit Ok, that definitely looks bogus. That commit should not matter at _all_, it only changes ppc64 specific things. If the bug is sometimes hard to trigger, maybe one of the "good" kernels wasn't good after all. That would definitely throw a wrench in the bisection. The bisection search: a46e812620bd7db457ce002544a1a6572c313d8a good e0b98c79e605f64f263ede53344f283f5e0548be good fd3113e84e188781aa2935fbc4351d64ccdd171b good 2757a71c3122c7653e3dd8077ad6ca71efb1d450 good ba17101b41977f124948e0a7797fdcbb59e19f3e good, this one has got more testing, as my default kernel to boot for the moment. saw lots of drm recompile for the next one: 561fb765b97f287211a2c73a844c5edb12f44f1d bad 6ade43fbbcc3c12f0ddba112351d14d6c82ae476 good I'll test this one more to see if it is a false positive, and I'll also test a known bad kernel without DRM. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Tue, Aug 16, 2005 at 09:24:25AM +1000, Dave Airlie wrote: > > > I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for > > > x86_64? But perhaps they share something? > > > > My guess is that it is maybe the DRM changes that have done it... the > > 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested > > on a number of configurations (none of them by me... I can't test what > > I don't have...) > > > > Actually after looking back 2.6.13-rc4-mm1 which you say works doesn't > contain any of the later 32/64-bit changes.. so maybe you can try just > applying the git-drm.patch from that tree to see if it makes a > difference... > > I'm getting less and less sure this is caused by the drm, (have you > built with DRM disabled completely??) > No, but I can try that after work today. > Do you have any fb support in-kernel (I know you might have answered > this already but I'm getting a bit lost on this thread...) There is no fb support at all. I have the vga console, agp support (which obviously only applies to the agp g550) drm/dri support for g550 and for the pci radeon. Could the new patches possibly have issues with the case where AGP support is compiled into the kernel, but the card is pci so it isn't supposed to _use_ it? Also, the two cards aren't used by the same user, it is two desktops, not one big one. The X freeze comes fast if I play "cuyo", a nice 2D game somewhat similiar to tetris. I don't think it uses DRM, unless x.org 6.8.2 somehow uses it to speed up 2D operations. The bisection search: a46e812620bd7db457ce002544a1a6572c313d8a good e0b98c79e605f64f263ede53344f283f5e0548be good fd3113e84e188781aa2935fbc4351d64ccdd171b good 2757a71c3122c7653e3dd8077ad6ca71efb1d450 good ba17101b41977f124948e0a7797fdcbb59e19f3e good saw lots of drm recompile for the next one: 561fb765b97f287211a2c73a844c5edb12f44f1d bad 6ade43fbbcc3c12f0ddba112351d14d6c82ae476 good And then the final one also seemed good. If the stop condition could be off by one, wonder what the next patch is? Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Tue, Aug 16, 2005 at 09:24:25AM +1000, Dave Airlie wrote: I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for x86_64? But perhaps they share something? My guess is that it is maybe the DRM changes that have done it... the 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested on a number of configurations (none of them by me... I can't test what I don't have...) Actually after looking back 2.6.13-rc4-mm1 which you say works doesn't contain any of the later 32/64-bit changes.. so maybe you can try just applying the git-drm.patch from that tree to see if it makes a difference... I'm getting less and less sure this is caused by the drm, (have you built with DRM disabled completely??) No, but I can try that after work today. Do you have any fb support in-kernel (I know you might have answered this already but I'm getting a bit lost on this thread...) There is no fb support at all. I have the vga console, agp support (which obviously only applies to the agp g550) drm/dri support for g550 and for the pci radeon. Could the new patches possibly have issues with the case where AGP support is compiled into the kernel, but the card is pci so it isn't supposed to _use_ it? Also, the two cards aren't used by the same user, it is two desktops, not one big one. The X freeze comes fast if I play cuyo, a nice 2D game somewhat similiar to tetris. I don't think it uses DRM, unless x.org 6.8.2 somehow uses it to speed up 2D operations. The bisection search: a46e812620bd7db457ce002544a1a6572c313d8a good e0b98c79e605f64f263ede53344f283f5e0548be good fd3113e84e188781aa2935fbc4351d64ccdd171b good 2757a71c3122c7653e3dd8077ad6ca71efb1d450 good ba17101b41977f124948e0a7797fdcbb59e19f3e good saw lots of drm recompile for the next one: 561fb765b97f287211a2c73a844c5edb12f44f1d bad 6ade43fbbcc3c12f0ddba112351d14d6c82ae476 good And then the final one also seemed good. If the stop condition could be off by one, wonder what the next patch is? Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
Linus Torvalds wrote: On Tue, 16 Aug 2005, Helge Hafting wrote: This was interesting. At first, lots of kernels just kept working, I almost suspected I was doing something wrong. Then the second last kernel recompiled a lot of DRM stuff - and the crash came back! The kernel after that worked again, and so the final message was: 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit Ok, that definitely looks bogus. That commit should not matter at _all_, it only changes ppc64 specific things. If the bug is sometimes hard to trigger, maybe one of the good kernels wasn't good after all. That would definitely throw a wrench in the bisection. The bisection search: a46e812620bd7db457ce002544a1a6572c313d8a good e0b98c79e605f64f263ede53344f283f5e0548be good fd3113e84e188781aa2935fbc4351d64ccdd171b good 2757a71c3122c7653e3dd8077ad6ca71efb1d450 good ba17101b41977f124948e0a7797fdcbb59e19f3e good, this one has got more testing, as my default kernel to boot for the moment. saw lots of drm recompile for the next one: 561fb765b97f287211a2c73a844c5edb12f44f1d bad 6ade43fbbcc3c12f0ddba112351d14d6c82ae476 good I'll test this one more to see if it is a false positive, and I'll also test a known bad kernel without DRM. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Mon, Aug 15, 2005 at 03:59:07PM -0700, Linus Torvalds wrote: On Tue, 16 Aug 2005, Helge Hafting wrote: This was interesting. At first, lots of kernels just kept working, I almost suspected I was doing something wrong. Then the second last kernel recompiled a lot of DRM stuff - and the crash came back! The kernel after that worked again, and so the final message was: 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit Ok, that definitely looks bogus. That commit should not matter at _all_, it only changes ppc64 specific things. If the bug is sometimes hard to trigger, maybe one of the good kernels wasn't good after all. That would definitely throw a wrench in the bisection. The hang, or at least an X pause tends to happen in 5-10 minutes of playing cuyo. (�2D game). I have now had the last good kernel (6ade43fbbcc3c12f0ddba112351d14d6c82ae476) running for almost 24 hours, only interrupted by the brief test of drm-less rc6. Normal use haven't provoked anything. Since DRM sort of works with this kernell, I tried tuxracer on the radeon. (Trouble is always with the radeon, never the mga xserver). I played several games, ok except for the usual lousy 5-9 fps. One time I had a pause, the 3D-game just froze for about half a minute. The other xserver kept displaying firefox (and updating the page too) but I could not start any processes there. I tried starting an xterm - it did not appear until tuxracer unfroze and continued as if nothing happened. Perhaps the frozen process held a lock? Disk io seemed sluggish after that incident, and the load meter in icewm seemed to indicate more waiting than usual. The logs tells me of SCSI aborts and a bus reset. I booted into drm-less rc6 after that. Some interrupts are shared on this machine: $ cat /proc/interrupts CPU0 0: 10113154IO-APIC-edge timer 1:371IO-APIC-edge i8042 2: 0 XT-PIC cascade 4: 5735IO-APIC-edge serial 8: 0IO-APIC-edge rtc 12: 11024IO-APIC-edge i8042 14: 21IO-APIC-edge ide0 16: 803248 IO-APIC-level sym53c8xx, eth0, [EMAIL PROTECTED]::01:00.0 17: 0 IO-APIC-level Trident Audio 19: 755535 IO-APIC-level [EMAIL PROTECTED]::00:08.0 20: 5946 IO-APIC-level libata 21: 9448 IO-APIC-level ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4 NMI:234 LOC: 10111810 ERR: 0 MIS: 0 The troublesome radoen has a irq of its own. The scsi controller shares irq with the matrox g550, but that card never seem to cause any trouble, other than saturating the cpu during games. :-) On to look at iomem and that rc6 crash. Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
> > I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for > > x86_64? But perhaps they share something? > > My guess is that it is maybe the DRM changes that have done it... the > 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested > on a number of configurations (none of them by me... I can't test what > I don't have...) > Actually after looking back 2.6.13-rc4-mm1 which you say works doesn't contain any of the later 32/64-bit changes.. so maybe you can try just applying the git-drm.patch from that tree to see if it makes a difference... I'm getting less and less sure this is caused by the drm, (have you built with DRM disabled completely??) Do you have any fb support in-kernel (I know you might have answered this already but I'm getting a bit lost on this thread...) Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
> > I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for > x86_64? But perhaps they share something? My guess is that it is maybe the DRM changes that have done it... the 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested on a number of configurations (none of them by me... I can't test what I don't have...) Can you do me a favour and check 2.6.13-rc6 with the git-drm.patch from -mm? http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/broken-out/git-drm.patch If this is a 32/64-bit issue I think that patch might help, I'm not convinced I can't see how the DRM would ever start blanking the screen, it doesn't have any code in that area at all.. but stranger things have surprised me... Is there any difference in your Xorg.0.log files before/after this... There is also an issue at: http://bugme.osdl.org/show_bug.cgi?id=4965 which was caused by the pci assign resources patch on x86... I'm not sure if this is similiar.. Dave. Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Tue, 16 Aug 2005, Helge Hafting wrote: > > This was interesting. At first, lots of kernels just kept working, > I almost suspected I was doing something wrong. Then the second last kernel > recompiled a lot of DRM stuff - and the crash came back! > The kernel after that worked again, and so the final message was: > > 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit Ok, that definitely looks bogus. That commit should not matter at _all_, it only changes ppc64 specific things. If the bug is sometimes hard to trigger, maybe one of the "good" kernels wasn't good after all. That would definitely throw a wrench in the bisection. Anyway, with something like this, where there may be false positives (false "good" kernels), the only thing you can _really_ trust is a kernel that got marked bad, because that one definitely has the problem. So make sure that you remember all known-bad kernels. Btw, we haven't had a lot of testign of the termination condition for "git bisect", so it's possible it's off by a commit or two. However, the commit you actually ended up on is literally just two commits before 2.6.13-rc5, which makes me suspect that it's not the termination condition, as much as the fact that it really was an earlier kernel that had the problem, but you bisected it as "good" because the problem just didn't trigger quickly enough.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Mon, Aug 15, 2005 at 08:50:12AM -0700, Linus Torvalds wrote: > > > On Mon, 15 Aug 2005, Helge Hafting wrote: > > > > Ok, I have downlaoded git and started the first compile. > > Git will tell when the correct point is found (assuming I > > do the "git bisect bad/good" right), by itself? > > Yes. You should see > > Bisecting: xxx revisions left to test after this > > and the "xxx" should hopefully decrease by half during each round. And t > the end of it, you should get > >is first bad commit > > followed by the actual patch that caused the problem. > This was interesting. At first, lots of kernels just kept working, I almost suspected I was doing something wrong. Then the second last kernel recompiled a lot of DRM stuff - and the crash came back! The kernel after that worked again, and so the final message was: 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit diff-tree 561fb765b97f287211a2c73a844c5edb12f44f1d (from 6ade43fbbcc3c12f0ddba112351d14d6c82ae476) Author: Anton Blanchard <[EMAIL PROTECTED]> Date: Mon Aug 1 21:11:46 2005 -0700 [PATCH] ppc64: topology API fix Dont include asm-generic/topology.h unconditionally, we end up overriding all the ppc64 specific functions when NUMA is on. Signed-off-by: Anton Blanchard <[EMAIL PROTECTED]> Acked-by: Paul Mackerras <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 a760521110f862aecbee74cffa674993b6dca4a3 66b9cb2db119ab029ca7b8f71bd06507fca63921 M include I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for x86_64? But perhaps they share something? I hope this is of help, Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Mon, Aug 15, 2005 at 08:50:12AM -0700, Linus Torvalds wrote: On Mon, 15 Aug 2005, Helge Hafting wrote: Ok, I have downlaoded git and started the first compile. Git will tell when the correct point is found (assuming I do the git bisect bad/good right), by itself? Yes. You should see Bisecting: xxx revisions left to test after this and the xxx should hopefully decrease by half during each round. And t the end of it, you should get sha1 is first bad commit followed by the actual patch that caused the problem. This was interesting. At first, lots of kernels just kept working, I almost suspected I was doing something wrong. Then the second last kernel recompiled a lot of DRM stuff - and the crash came back! The kernel after that worked again, and so the final message was: 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit diff-tree 561fb765b97f287211a2c73a844c5edb12f44f1d (from 6ade43fbbcc3c12f0ddba112351d14d6c82ae476) Author: Anton Blanchard [EMAIL PROTECTED] Date: Mon Aug 1 21:11:46 2005 -0700 [PATCH] ppc64: topology API fix Dont include asm-generic/topology.h unconditionally, we end up overriding all the ppc64 specific functions when NUMA is on. Signed-off-by: Anton Blanchard [EMAIL PROTECTED] Acked-by: Paul Mackerras [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 a760521110f862aecbee74cffa674993b6dca4a3 66b9cb2db119ab029ca7b8f71bd06507fca63921 M include I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for x86_64? But perhaps they share something? I hope this is of help, Helge Hafting - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
On Tue, 16 Aug 2005, Helge Hafting wrote: This was interesting. At first, lots of kernels just kept working, I almost suspected I was doing something wrong. Then the second last kernel recompiled a lot of DRM stuff - and the crash came back! The kernel after that worked again, and so the final message was: 561fb765b97f287211a2c73a844c5edb12f44f1d is first bad commit Ok, that definitely looks bogus. That commit should not matter at _all_, it only changes ppc64 specific things. If the bug is sometimes hard to trigger, maybe one of the good kernels wasn't good after all. That would definitely throw a wrench in the bisection. Anyway, with something like this, where there may be false positives (false good kernels), the only thing you can _really_ trust is a kernel that got marked bad, because that one definitely has the problem. So make sure that you remember all known-bad kernels. Btw, we haven't had a lot of testign of the termination condition for git bisect, so it's possible it's off by a commit or two. However, the commit you actually ended up on is literally just two commits before 2.6.13-rc5, which makes me suspect that it's not the termination condition, as much as the fact that it really was an earlier kernel that had the problem, but you bisected it as good because the problem just didn't trigger quickly enough.. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for x86_64? But perhaps they share something? My guess is that it is maybe the DRM changes that have done it... the 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested on a number of configurations (none of them by me... I can't test what I don't have...) Can you do me a favour and check 2.6.13-rc6 with the git-drm.patch from -mm? http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc5/2.6.13-rc5-mm1/broken-out/git-drm.patch If this is a 32/64-bit issue I think that patch might help, I'm not convinced I can't see how the DRM would ever start blanking the screen, it doesn't have any code in that area at all.. but stranger things have surprised me... Is there any difference in your Xorg.0.log files before/after this... There is also an issue at: http://bugme.osdl.org/show_bug.cgi?id=4965 which was caused by the pci assign resources patch on x86... I'm not sure if this is similiar.. Dave. Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rc6 keeps hanging and blanking displays - bisection complete
I'm a little surprised, as a ppc64 fix theoretically shouldn't matter for x86_64? But perhaps they share something? My guess is that it is maybe the DRM changes that have done it... the 32/64-bit code in 2.6.13-rc6 may have issues, but they've been tested on a number of configurations (none of them by me... I can't test what I don't have...) Actually after looking back 2.6.13-rc4-mm1 which you say works doesn't contain any of the later 32/64-bit changes.. so maybe you can try just applying the git-drm.patch from that tree to see if it makes a difference... I'm getting less and less sure this is caused by the drm, (have you built with DRM disabled completely??) Do you have any fb support in-kernel (I know you might have answered this already but I'm getting a bit lost on this thread...) Dave. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
