[BUG GIT] Unable to handle kernel paging request at virtual address e1380288

View: New views
10 Messages — Rating Filter:   Alert me  

[BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Marc Koschewski :: Rate this Message:

| View Threaded | Show Only this Message

I just wanted to mount an external USB HDD... this was what I got:

Marc

[4297455.608000] usb 2-1: new full speed USB device using uhci_hcd and address 2
[4297455.813000] usb 2-1: configuration #1 chosen from 1 choice
[4297455.819000] Unable to handle kernel paging request at virtual address e1380288
[4297455.819000]  printing eip:
[4297455.819000] c01ee88e
[4297455.819000] *pde = 1f7f3067
[4297455.819000] *pte = 00000000
[4297455.819000] Oops: 0000 [#1]
[4297455.819000] PREEMPT
[4297455.819000] Modules linked in: irtty_sir sir_dev thermal fan button processor ac battery ipv6 nls_cp437 cifs ip_conntrack_irc ip_conntrack_ftp ip_conntrack nfnetlink dvb_usb_dibusb_mb dib3000mb dvb_usb_dibusb_common dib3000mc dib3000_common dvb_usb dvb_core i2c_core dvb_pll snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_seq_device ircomm_tty ircomm irda crc_ccitt hidp bnep hci_uart rfcomm l2cap bluetooth cpufreq_stats cpufreq_performance cpufreq_powersave cpufreq_ondemand cpufreq_conservative speedstep_ich speedstep_lib freq_table i8k nvidia backlight lcd mousedev evdev serial_cs eth1394 pcmcia firmware_class ohci1394 ieee1394 parport_pc parport 3c59x mii yenta_socket rsrc_nonstatic pcmcia_core snd_intel8x0m snd_intel8x0 snd_ac97_codec snd_ac97_bus snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc hw_random ide_cd cdrom psmouse serio_raw floppy pcspkr rtc uhci_hcd usbcore intel_agp agpgart unix
[4297455.819000] CPU:    0
[4297455.819000] EIP:    0060:[<c01ee88e>]    Tainted: P      VLI
[4297455.819000] EFLAGS: 00010282   (2.6.16-rc2-marc-g418aade4-dirty #46)
[4297455.819000] EIP is at kref_get+0x8/0x4a
[4297455.819000] eax: e1380288   ebx: e1380288   ecx: 00000000   edx: 00000000
[4297455.819000] esi: e138027c   edi: df15ae08   ebp: d7031414   esp: df15add0
[4297455.819000] ds: 007b   es: 007b   ss: 0068
[4297455.819000] Process khubd (pid: 984, threadinfo=df15a000 task=dfd2e030)
[4297455.819000] Stack: <0>e1380280 df15ae08 c02da465 e11b86e8 e1380280 c02da54a e1380288 00000000
[4297455.819000]        df15ae08 c025243b c0251ce5 df15ae08 d7031414 00000000 e0e56138 e0e56138
[4297455.819000]        e11b86dc d70314d8 d7031414 d703147c 00000000 c02524a2 e0e56040 00000000
[4297455.819000] Call Trace:
[4297455.819000]  [<c02da465>] klist_dec_and_del+0x16/0x1a
[4297455.819000]  [<c02da54a>] klist_next+0x3a/0x6c
[4297455.819000]  [<c025243b>] __device_attach+0x0/0x5
[4297455.819000]  [<c0251ce5>] bus_for_each_drv+0x6b/0x81
[4297455.819000]  [<c02524a2>] device_attach+0x62/0x66
[4297455.819000]  [<c025243b>] __device_attach+0x0/0x5
[4297455.819000]  [<c0251b76>] bus_add_device+0x33/0x137
[4297455.819000]  [<c0250e0d>] device_add+0xf3/0x15b
[4297455.819000]  [<e0e3fbf8>] usb_set_configuration+0x363/0x4e6 [usbcore]
[4297455.819000]  [<e0e3a495>] usb_new_device+0x22f/0x2c7 [usbcore]
[4297455.819000]  [<e0e3bb50>] hub_thread+0x869/0xdca [usbcore]
[4297455.819000]  [<c0101bb2>] __switch_to+0x1f/0x220
[4297455.819000]  [<c02dacc3>] schedule+0x383/0x66a
[4297455.819000]  [<c012c348>] autoremove_wake_function+0x0/0x4b
[4297455.819000]  [<c012c138>] kthread+0xaf/0xd4
[4297455.819000]  [<e0e3b2e7>] hub_thread+0x0/0xdca [usbcore]
[4297455.819000]  [<c012c089>] kthread+0x0/0xd4
[4297455.819000]  [<c0101005>] kernel_thread_helper+0x5/0xb
[4297455.819000] Code: 24 04 48 6c 2e c0 c7 04 24 48 3b 2f c0 e8 e6 af f2 ff e8 62 5b f1 ff eb b8 c7 44 24 0c 35 00 00 00 eb d3 53 83 ec 10 8b 5c 24 18 <8b> 03 85 c0 74 07 ff 03 83 c4 10 5b c3 c7 44 24 0c 20 00 00 00
[4297455.819000]  <6>note: khubd[984] exited with preempt_count 1
[4297460.352000] SCSI subsystem initialized
[4297460.371000] Initializing USB Mass Storage driver...

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Alexey Dobriyan-2 :: Rate this Message:

| View Threaded | Show Only this Message

On Fri, Feb 10, 2006 at 10:41:22PM +0100, Marc Koschewski wrote:
> I just wanted to mount an external USB HDD... this was what I got:

> [4297455.819000] EIP:    0060:[<c01ee88e>]    Tainted: P      VLI

Kindly reproduce without proprietary modules loaded.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Marc Koschewski :: Rate this Message:

| View Threaded | Show Only this Message

* Alexey Dobriyan <adobriyan@...> [2006-02-11 01:25:15 +0300]:

> On Fri, Feb 10, 2006 at 10:41:22PM +0100, Marc Koschewski wrote:
> > I just wanted to mount an external USB HDD... this was what I got:
>
> > [4297455.819000] EIP:    0060:[<c01ee88e>]    Tainted: P      VLI
>
> Kindly reproduce without proprietary modules loaded.

I knew this would be the response. :) Unfortunately I cannot reproduce. I just
remounted the disk 6 times, via fstab and 'by hand'. Also rebooted with the
thing attached and just plugged it into the running system. No chance ... always
worked as expected.

Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Kyle Moffett :: Rate this Message:

| View Threaded | Show Only this Message

On Feb 10, 2006, at 17:42, Marc Koschewski wrote:
> * Alexey Dobriyan <adobriyan@...> [2006-02-11 01:25:15 +0300]:
>
>> On Fri, Feb 10, 2006 at 10:41:22PM +0100, Marc Koschewski wrote:
>>> I just wanted to mount an external USB HDD... this was what I got:
>>> [4297455.819000] EIP:    0060:[<c01ee88e>]    Tainted: P      VLI
>>
>> Kindly reproduce without proprietary modules loaded.
>
> I knew this would be the response. :)

So why did you bother posting in the first place?
   Patient:  Doctor, it hurts when I do this.
   Doctor:   So don't do that!
   Patient:  I knew that's what you'd say!
   Doctor:   ... so why'd you waste my time?

> Unfortunately I cannot reproduce. I just remounted the disk 6  
> times, via fstab and 'by hand'. Also rebooted with the thing  
> attached and just plugged it into the running system. No chance ...  
> always worked as expected.

Since you cannot reproduce your problem, we cannot help you.  I  
strongly suspect the proprietary module based on general suspicion  
and paranoia.  I recommend doing without it if possible.

Cheers,
Kyle Moffett

--
Debugging is twice as hard as writing the code in the first place.  
Therefore, if you write the code as cleverly as possible, you are, by  
definition, not smart enough to debug it.
   -- Brian Kernighan


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Marc Koschewski :: Rate this Message:

| View Threaded | Show Only this Message

* Kyle Moffett <mrmacman_g4@...> [2006-02-11 04:01:16 -0500]:

> On Feb 10, 2006, at 17:42, Marc Koschewski wrote:
> >* Alexey Dobriyan <adobriyan@...> [2006-02-11 01:25:15 +0300]:
> >
> >>On Fri, Feb 10, 2006 at 10:41:22PM +0100, Marc Koschewski wrote:
> >>>I just wanted to mount an external USB HDD... this was what I got:
> >>>[4297455.819000] EIP:    0060:[<c01ee88e>]    Tainted: P      VLI
> >>
> >>Kindly reproduce without proprietary modules loaded.
> >
> >I knew this would be the response. :)
>
> So why did you bother posting in the first place?
>   Patient:  Doctor, it hurts when I do this.
>   Doctor:   So don't do that!
>   Patient:  I knew that's what you'd say!
>   Doctor:   ... so why'd you waste my time?

PLease respond like this to any other mail with any proprietary module loaded.
WTF?! I just wanted to let you know... not more, not less.

I could also stop testing -mm and -git from now on. Unfortunately all my
machines have an nVidia graphics. Should all other people as well stop
reporting? Linux without X is useless to me. Sure, I could use the xorg module.
But it mostly sucks performance wise.

Moreover, I don't know in what way a PCI graphics adapter is pissing off USB
devices. Is there a chance to?

Calm down...

>
> >Unfortunately I cannot reproduce. I just remounted the disk 6  
> >times, via fstab and 'by hand'. Also rebooted with the thing  
> >attached and just plugged it into the running system. No chance ...  
> >always worked as expected.
>
> Since you cannot reproduce your problem, we cannot help you.  I  
> strongly suspect the proprietary module based on general suspicion  
> and paranoia.  I recommend doing without it if possible.

I didn't know I cannot reprocude this when I sent the report. Please update the
docs so people know to only report bugs/probs in case they're easyily to be
reproduced.

Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Douglas McNaught :: Rate this Message:

| View Threaded | Show Only this Message

Marc Koschewski <marc@...> writes:

> Moreover, I don't know in what way a PCI graphics adapter is pissing off USB
> devices. Is there a chance to?

Sure.  Drivers run in kernel mode and, if buggy, can scribble all over
any part of kernel memory, causing problems in completely unrelated
places.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Marc Koschewski :: Rate this Message:

| View Threaded | Show Only this Message

* Doug McNaught <doug@...> [2006-02-11 10:19:29 -0500]:

> Marc Koschewski <marc@...> writes:
>
> > Moreover, I don't know in what way a PCI graphics adapter is pissing off USB
> > devices. Is there a chance to?
>
> Sure.  Drivers run in kernel mode and, if buggy, can scribble all over

Sure thing.

> any part of kernel memory, causing problems in completely unrelated
> places.

But the trace I sent didn't (directly) do any memory allocation so the case was
clear to me.

From a developers point of view I totally agree that doing some bad code 'here'
might crash us 'there'. But the backtrace didn't look like this to me...

Marc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Douglas McNaught :: Rate this Message:

| View Threaded | Show Only this Message

Marc Koschewski <marc@...> writes:

> But the trace I sent didn't (directly) do any memory allocation so
> the case was clear to me.
>
> From a developers point of view I totally agree that doing some bad
> code 'here' might crash us 'there'. But the backtrace didn't look
> like this to me...

You have no idea what might have happened a second ago, or a minute
ago, or five minutes ago.  Corrupted memory is like a
time-bomb--things don't always break right away.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Andrew Morton-8 :: Rate this Message:

| View Threaded | Show Only this Message

Doug McNaught <doug@...> wrote:

>
> Marc Koschewski <marc@...> writes:
>
> > But the trace I sent didn't (directly) do any memory allocation so
> > the case was clear to me.
> >
> > From a developers point of view I totally agree that doing some bad
> > code 'here' might crash us 'there'. But the backtrace didn't look
> > like this to me...
>
> You have no idea what might have happened a second ago, or a minute
> ago, or five minutes ago.  Corrupted memory is like a
> time-bomb--things don't always break right away.
>

Probability this bug was caused by the nvidia module: 0.1%
Probability this bug was caused by USB or SCSI: 99.9%

SCSI and USB device management remain quite buggy and we need all the help
we can get in finding and fixing these problems.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

by Carlos Martín Nieto :: Rate this Message:

| View Threaded | Show Only this Message

On Saturday 11 February 2006 22:10, Andrew Morton wrote:

> Doug McNaught <doug@...> wrote:
> > You have no idea what might have happened a second ago, or a minute
> > ago, or five minutes ago.  Corrupted memory is like a
> > time-bomb--things don't always break right away.
> >
>
> Probability this bug was caused by the nvidia module: 0.1%
> Probability this bug was caused by USB or SCSI: 99.9%
>
> SCSI and USB device management remain quite buggy and we need all the help
> we can get in finding and fixing these problems.

I once had a PCI probe function OOPS with the nvidia module loaded. Previous
run was alright, and rebooting with exact same setup worked the next time and
never failed again for the time I was using the nvidia module on that
computer.

I can't be positive that it was the nvidia module, but the probability of it
having to do with it is quite high. It at least triggered something.

   cmn
--
Carlos Martín Nieto    |   http://www.cmartin.tk
Hobbyist programmer    |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/