From: Reuben Farrelly <reuben-lkml@reub.net>
To: Jeff Garzik <jgarzik@pobox.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@osdl.org>,
torvalds@osdl.org, gregkh@suse.de, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org
Subject: Re: [GIT PATCH] PCI patches for 2.6.15 - retry
Date: Tue, 17 Jan 2006 02:11:32 +1300 [thread overview]
Message-ID: <43CB9B84.2060107@reub.net> (raw)
In-Reply-To: <43C6C331.1030602@pobox.com>
On 13/01/2006 9:59 a.m., Jeff Garzik wrote:
> Alan Cox wrote:
>> On Iau, 2006-01-12 at 16:55 +1300, Reuben Farrelly wrote:
>>
>>> ata1: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x0 irq 0
>>> ata2: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x8 irq 0
>>> Unable to handle kernel NULL pointer dereference at virtual address
>>> 00000000
>>
>>
>> That is the critical bit. The SATA ports have no PCI resources assigned
>> for bus mastering (BAR 4). libata should have driven the device PIO in
>> this case but the resource should have been assigned.
>
> Agreed. This appears to be BIOS assigning bad values to SATA hardware.
>
> However, libata should recognize this and not attempt to iomap or drive
> the hardware, in that case, rather than oops.
>
> Jeff
Some testing tonight has shown up a bit more about where this regression crept in.
Below the table reads release on left hand side, and the result of a given
reboot on the right hand side after the dash. I had to do so many reboots to
be sure that the bug was there or not - as you can see from the -mm1 test it
doesn't always show up.
2.6.15 - OK OK OK OK OK
2.6.15-git1 - OK OK OK OK OK OK OK OK
2.6.15-git2 - OK
2.6.15-git6 - OK OK OK OK OK OK OK OK
2.6.15-git12 - OK OK OK OK OK OK OK
2.6.15-rc5-mm3 - OK OK OK(but oopsed in usb) OK OK(but oopsed in usb)
Those oopses in USB were only seen in this release so looks likely whatever
was causing them was fixed soon after.
2.6.15-mm1 - OK OK OOPSED OOPSED OOPSED all in ATA
2.6.15-mm2 + mm3 - [known to OOPS on this bug frequently but not tested in this
round]
2.6.15-mm4 - OOPSED OK OOPSED TIMEOUT TIMEOUT OOPS OK
2.6.15-mm1 with no git-acpi.patch - TIMEOUT TIMEOUT OOPSED TIMEOUT OK
OK means the system booted up to single user mode without issue, TIMEOUT means
that the controllers were assigned IRQ 50 and then failed to find any ATA disks
and OOPSED means that he SATA ports were not assigned IRQs at all and hence the
system oopsed out like this:
ahci: probe of 0000:00:1f.2 failed with error -12
ata1: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x0 irq 0
ata2: SATA max UDMA/133 cmd 0x0 ctl 0x2 bmdma 0x8 irq 0
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c023c873
*pde = 00000000
Oops: 0000 [#1]
<plus a trace and a whole lot more>
Full output on http://www.reub.net/files/kernel/outstanding-kernel-bugs.txt (as
usual)
In summary the good news is that 2.6.15-git12 (which is the latest linus tree)
is GOOD and does not seem to exhibit this problem. Not a single -git release
crapped out. It seems some regression was introduced into 2.6.15-mm1 which has
been carried forward through to -mm4 so far though but never pushed to Linus.
I guess it also suggests that it's not a hardware or bios issue given the sheer
number of successful reboots in a row, and I think reverting the git-acpi.patch
suggests that ACPI is not the cause of it, at least in this instance. But
that's about as far as I have gotten.
45 reboots later I'm finishing for tonight, but before I go back and hit it with
git bisect to narrow it down any further, Andrew/Jeff does this make it any
easier to pinpoint, and/or do you have any preliminary patches to test or ideas
as to what other subsystems could be involved?
Thanks,
Reuben
next prev parent reply other threads:[~2006-01-16 13:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-09 20:37 [GIT PATCH] PCI patches for 2.6.15 - retry Greg KH
2006-01-10 0:00 ` Linus Torvalds
2006-01-10 0:44 ` Andrew Morton
2006-01-10 1:49 ` Alan Cox
2006-01-10 1:49 ` Andrew Morton
2006-01-10 10:03 ` Reuben Farrelly
2006-01-12 3:55 ` Reuben Farrelly
2006-01-12 4:29 ` Andrew Morton
2006-01-12 4:55 ` Reuben Farrelly
2006-01-12 11:42 ` Alan Cox
2006-01-12 20:59 ` Jeff Garzik
2006-01-16 13:11 ` Reuben Farrelly [this message]
2006-01-12 20:55 ` Jeff Garzik
2006-01-13 0:16 ` Alan Cox
2006-01-10 2:28 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43CB9B84.2060107@reub.net \
--to=reuben-lkml@reub.net \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=gregkh@suse.de \
--cc=jgarzik@pobox.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox