Re: 2.6.15-mm2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/01/2006 10:31 a.m., Andrew Morton wrote:
Reuben Farrelly <[email protected]> wrote:
...
QLogic Fibre Channel HBA Driver
ahci: probe of 0000:00:1f.2 failed with error -12

It's odd that the ahci driver returned -EBUSY.  Maybe this is due to "we
have legacy mode, but all ports are unavailable" in ata_pci_init_one().

I've now removed this driver from my .config via menuconfig, I certainly don't have the hardware and have no idea whatsoever how it came to be built in. Although I guess it shouldn't be blowing up even if that is the case?

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:
c0234702
*pde = 00000000
Oops: 0000 [#1]
SMP
last sysfs file:
Modules linked in:
CPU:    1
EIP:    0060:[<c0234702>]    Not tainted VLI
EFLAGS: 00010206   (2.6.15-mm2)
EIP is at make_class_name+0x28/0x8d
eax: 00000000   ebx: ffffffff   ecx: ffffffff   edx: c19d9224
esi: 00000009   edi: 00000000   ebp: 00000000   esp: c1921d9c
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 1, threadinfo=c1921000 task=c1920a70)
Stack: <0>c19d9224 c03a9158 c19d9224 c03a9158 c03a9160 c0234925 c03a90e0 00000000
        <0>00000246 c19d9224 c19d9000 c19d9030 00000002 c02349db c19d90e4 c0253218
        <0>c19d92c0 00000000 00000000 c0276693 00000000 c0279391 c035749f c1961640
Call Trace:
  [<c0234925>] class_device_del+0x9f/0x14d
  [<c02349db>] class_device_unregister+0x8/0x10
  [<c0253218>] scsi_remove_host+0xb8/0xf8
  [<c0276693>] ata_host_remove+0xe/0x18
  [<c0279391>] ata_device_add+0x2d3/0xb99
  [<c02b6fb0>] pci_mmcfg_write+0xd3/0x103
  [<c01eb713>] pci_bus_write_config_byte+0x4e/0x58
  [<c02b67d3>] pcibios_set_master+0x74/0x8c
  [<c027a2e5>] ata_pci_init_one+0x32c/0x38e
  [<c01eb7ea>] pci_bus_read_config_word+0x62/0x6c
  [<c01ef8bd>] pci_get_subsys+0x6c/0xe0
  [<c027e334>] piix_init_one+0x18e/0x33a
  [<c01ef259>] pci_device_probe+0x40/0x5b
  [<c0233ed7>] driver_probe_device+0x35/0x98
  [<c0234038>] __driver_attach+0x8a/0x8c
  [<c02339a7>] bus_for_each_dev+0x39/0x57
  [<c0233e4c>] driver_attach+0x16/0x1a
  [<c0233fae>] __driver_attach+0x0/0x8c
  [<c023365b>] bus_add_driver+0x6f/0x126
  [<c01ef3f1>] __pci_register_driver+0x7d/0xac
  [<c04023e9>] piix_init+0xc/0x1e
  [<c01003c8>] init+0xff/0x324
  [<c01002c9>] init+0x0/0x324
  [<c0100d35>] kernel_thread_helper+0x5/0xb
Code: 89 c8 c3 55 57 56 53 83 ec 04 89 04 24 89 c2 8b 40 48 8b 38 31 ed bb ff ff ff ff 89 d9 89 e8 f2 ae f7 d1 49 89 ce 8b 7a 08 89 d9 <f2> ae f7 d1 49 89 ca 8d 4e 02 8d 04 0a ba d0 00 00 00 e8 22 cf

ata_device_add() has given up, has called ata_host_remove() and then we
presumably oopsed over incompletely initialised class stuff.  It's likely
that this oops is a second bug - a consequence of the -EBUSY.


2. Notice above how the sky2 driver is being bailed out:

ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 177
sky2 Cannot find PowerManagement capability, aborting.
sky2: probe of 0000:04:00.0 failed with error -5

This has happened a number of times in the last few days, and I suspect is unrelated to the oops that followed above.

This driver worked fine in 2.6.15-rc5-mm3, and seems to work OK when built as a module. But most of the time (not all the time) it doesn't like being statically built in and fails with the above error. Changes to this driver have been fairly small lately so I'm not sure if it's the driver or something else like ACPI that is the root cause.

Could be acpi, yes.

Parenthetically, I wouldn't have thought that this error should be fatal
for the driver.

lspci -vv shows that when the driver fails we see this:

Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR-

and when it works we see this:

Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

I'm not sure if that's a consequence of the fail, or the cause of it.

3. The boot up process with -mm2 was pretty lengthy, I had two periods of time when the whole system just came to a crawl, first time was when starting cups, and it came back to life and continued booting about 30s later. Next when starting hpijs it didn't come to life at all and I had to reboot. No output to the console for either, unfortunately.

Don't know, sorry.  But this kernel had oopsed, hadn't it?

I reloaded multiple times, the oopsing only occurred till I did a full cold boot, and then it came right (but until then I had the oops twice in a row across a warm reboot).

If I have time to play later on today I'll see if I can get more info.

reuben


-
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux