2006-02-10 21:41:47

by Marc Burkhardt

[permalink] [raw]
Subject: [BUG GIT] Unable to handle kernel paging request at virtual address e1380288

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

Marc


Attachments:
(No filename) (73.00 B)
crash.txt (3.54 kB)
Download all attachments

2006-02-10 22:06:45

by Alexey Dobriyan

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

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.

2006-02-10 22:42:34

by Marc Burkhardt

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

* Alexey Dobriyan <[email protected]> [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

2006-02-11 09:01:24

by Kyle Moffett

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

On Feb 10, 2006, at 17:42, Marc Koschewski wrote:
> * Alexey Dobriyan <[email protected]> [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


2006-02-11 15:10:04

by Marc Burkhardt

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

* Kyle Moffett <[email protected]> [2006-02-11 04:01:16 -0500]:

> On Feb 10, 2006, at 17:42, Marc Koschewski wrote:
> >* Alexey Dobriyan <[email protected]> [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

2006-02-11 15:19:38

by Douglas McNaught

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

Marc Koschewski <[email protected]> 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

2006-02-11 15:29:37

by Marc Burkhardt

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

* Doug McNaught <[email protected]> [2006-02-11 10:19:29 -0500]:

> Marc Koschewski <[email protected]> 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

2006-02-11 15:39:22

by Douglas McNaught

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

Marc Koschewski <[email protected]> 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

2006-02-11 21:10:59

by Andrew Morton

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

Doug McNaught <[email protected]> wrote:
>
> Marc Koschewski <[email protected]> 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.

2006-02-11 22:53:18

by Carlos Martín Nieto

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

On Saturday 11 February 2006 22:10, Andrew Morton wrote:
> Doug McNaught <[email protected]> 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 |