Messages in this thread | | | Date | Tue, 7 Oct 2008 22:26:11 +0200 | From | Willy Tarreau <> | Subject | Re: [KERNEL] Re: [KERNEL] Re: Kernel freeze on 2.4.36.7 |
| |
Hi Klaus,
On Mon, Oct 06, 2008 at 09:19:07AM +0100, Klaus Ethgen wrote: > > > > Also, have you ever been running and older 2.4 kernel not causing this > > > > problem ? > > > > > > I did buy the scanner only days ago. I did not use older kernels since > > > then. (I have to compile some if it is needed.) > > > > OK, so we'll assume it's not a regression and has always been like that, > > which is the most likely. > > I'm not absolutely sure but when I remember correct I did use USB > keyboard before in older ages. But I do not be absolutely sure if I test > to unplug it that time.
OK. I found a USB keyboard so if I find a theorical corner case, I might be able to experiment.
> > OK. I see an nvidia module. Would this machine happen to run under X ? > > Yes. I need to use the nvidia module to use the machine. But I do not > use that crazy window manages than kde or gnome which do some special > think with your devices hidden from the user. > > > If so, did you configure X so that it directly references the HID devices ? > > What do you mean with "directly"? I use evdev for mouse but the keyboard > is just normal keyboard with some Xkb settings for the layout.
OK. I was asking if there was anything such as Device "/dev/hid/..." or Device "/dev/input/..." in the Keyboard section, but judging by your response, we might have almost the same basic X config file :-)
> > Also, could you tell us a bit more about the application, and how you have > > to proceed to avoid the problem ? Eg: quit the application then X, etc... > > Just sync several times in front of unplugging the device helps. I can > reproduce the bug right after a boot without logging in under X (Just > kdm running). But if I use sync the problem is gone. > > I imagine that it might be something to do with a incompatibility > between HID and one filesystem driver. I saw this issue in the past with > ext3 which was very dirty in the past.
That's the part I really don't get. It's quite amazing that finishing writes onto a file system avoids kernel panics on USB keyboard. Oh, could you check /proc/interrupts to ensure that your USB interrupts are not shared with any block device, just in case ? It would constitute a very thin beginning of a track for investigation.
> Actually I use reiserfs, ext3, and ext2. Might it be that there is some > shared memory used between that both subsystems? Ah, and before I forget > to mention, I use the cryptoloop-jari patch to use encrypted swap and > so.
Hmm interesting. Could you at least try to reproduce with swap turned off ? No idea why, but I'm just trying to bissect the problem.
> > OK. Before I ask you to do so, could you send me privately your System.map, > > a copy of /proc/ksyms and your vmlinux (not vmlinuz) ? > > Yup, I will send it later. But why vmlinuX and not vmlinuZ? I thought > that this both is the same.
No, vmlinuz is stripped and has some boot code prepended (reason why I asked specifically). vmlinux has all symbols and may easily be disassembled.
BTW, I confirm that I've received them in another mail, thanks.
I don't have much time right now, but I have the files and will check what can be found. I might get back to you for complementary information, though I need to get a few ideas of the problem first.
Regards, Willy
| |