Bug 11047 - pata_it821x with Maxtor 7270AV: irq 11: nobody cared
pata_it821x with Maxtor 7270AV: irq 11: nobody cared
Status: RESOLVED UNREPRODUCIBLE
Product: IO/Storage
Classification: Unclassified
Component: Serial ATA
All Linux
: P1 normal
Assigned To: Alan
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-06 14:41 UTC by Ondrej Zary
Modified: 2012-05-11 23:43 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.29
Tree: Mainline
Regression: No


Attachments

Description Ondrej Zary 2008-07-06 14:41:07 UTC
Hardware Environment: IT8212F-based controller in pass-through mode (pata_it821x.noraid=1) with Maxtor 7270AV hard drive connected

Problem Description: Kernel crashes on boot with the following text:

pata_it821x: forcing bypass mode.
pata_it821x: controller in pass through mode.
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:12.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> 
IRQ 11
irq 11: nobody cared (try booting with the "irqpoll" option)
Pid: 1, comm: swapper Not tainted 2.6.25.3-pentium #5
 [<c012f48f>] __report_bad_irq+0x24/0x69
 [<c012f496>] __report_bad_irq+0x2b/0x69
 [<c012f680>] note_interrupt+0x1ac/0x1e4
 [<c012ee21>] handle_IRQ_event+0x1a/0x3f
 [<c012fcda>] handle_level_irq+0x0/0x8a
 [<c012fd27>] handle_level_irq+0x4d/0x8a
 [<c01051bb>] do_IRQ+0x78/0x9e
 [<c0103c53>] common_interrupt+0x23/0x30
 [<c013007b>] init_irq_proc+0x6/0x27
 [<c0115f59>] __do_softirq+0x2f/0x75
 [<c0105111>] do_softirq+0x3b/0x6d
 [<c012fcda>] handle_level_irq+0x0/0x8a
 [<c0115efc>] irq_exit+0x25/0x53
 [<c01051ce>] do_IRQ+0x8b/0x9e
 [<c0103c53>] common_interrupt+0x23/0x30
 [<c012f214>] setup_irq+0x11f/0x149
 [<c0120060>] cpu_clock_sample_group_locked+0x2/0xd3
 [<c023ce84>] ata_interrupt+0x0/0x1cc
 [<c012f2b5>] request_irq+0x77/0x93
 [<c023ce84>] ata_interrupt+0x0/0x1cc
 [<c012fe0c>] devm_request_irq+0x42/0x6e
 [<c02403a6>] ata_pci_activate_sff_host+0xb4/0x19f
 [<c023ce84>] ata_interrupt+0x0/0x1cc
 [<c0240850>] ata_pci_init_one+0x8c/0xd5
 [<c02475b5>] it821x_init_one+0x87/0x8c
 [<c01c632b>] pci_device_probe+0x36/0x55
 [<c021f6ce>] driver_probe_device+0x9c/0x112
 [<c021f824>] __driver_attach+0x50/0x83
 [<c021ed53>] bus_for_each_dev+0x31/0x52
 [<c021f582>] driver_attach+0x11/0x13
 [<c021f7d4>] __driver_attach+0x0/0x83
 [<c021f3c2>] bus_add_driver+0x91/0x193
 [<c021f9bd>] driver_register+0x45/0x9a
 [<c01c64bf>] __pci_register_driver+0x2b/0x58
 [<c0397600>] kernel_init+0x92/0x1d0
 [<c010fe52>] schedule_tail+0xe/0x39
 [<c01038a6>] ret_from_fork+0x6/0x20
 [<c039756e>] kernel_init+0x0/0x1d0
 [<c039756e>] kernel_init+0x0/0x1d0
 [<c0103d77>] kernel_thread_helper+0x7/0x10
 =======================
handlers:
[<c023ce84>] (ata_interrupt+0x0/0x1cc)
Disabling IRQ #11
scsi2 : pata_it821x
scsi3 : pata_it821x
ata3: PATA max UDMA/133 cmd 0x6800 ctl 0x6c00 bmdma 0x7800 irq 11
ata4: PATA max UDMA/133 cmd 0x7000 ctl 0x7400 bmdma 0x7808 irq 11
Comment 1 Tejun Heo 2008-08-29 07:16:09 UTC
Does "acpi=noirq" help?  If not, does "irqpoll" help?
Comment 2 Ondrej Zary 2008-09-03 12:00:25 UTC
It works fine with other hard drives. Should I try that options anyway?
Comment 3 Tejun Heo 2008-09-04 01:17:24 UTC
Hmm... in that case, acpi=noirq probably won't help much but irqpoll should.  Maybe the drive is raising IRQ spuriously.  Controllers with legacy TF interface just aren't equipped to cope with such situations.  I suppose this is always reproducible?  Does the drive work when paired with different controller?
Comment 4 Alan 2008-09-23 03:27:32 UTC
Grabbing this one
Comment 5 Alan 2009-03-17 09:12:16 UTC
Please try 2.6.29 when it comes out
Comment 6 Ondrej Zary 2009-04-11 21:22:59 UTC
This bug is still present in 2.6.29.

Note You need to log in before you can comment on or make changes to this bug.