[Partially solved] Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-13 Thread Rogério Brito

Hi, William.

On Feb 12 2005, William Park wrote:
> Your 'dmesg' says
> Warning: Secondary channel requires an 80-pin cable for operation.
> I assume it is.

Well, I just finished compiling the 2.6.11-rc4 kernel and the problem
persisted. This time, I enabled ACPI debugging and it indeed generates more
details.

Right after the problem persisted, I turned off the second HD (which was
the master of the secondary channel of the Promise controller) and the
problem automagically went away. :-(

One other thing is that the BIOS still configures the drive as UDMA 4, but
Linux downgrades that to UDMA 2. I'm not sure why.

Using hdparm manually with "hdparm -c1 -u1 -d1 -X udma4 /dev/hde" enables
things that the kernel doesn't and seems to be working wonderfully.

I don't know what I should do right now. I have put the newer dmesg logs on
. Should I contact anybody else?
I do need the second drive on, though.

I'm CC'ing Bartlomiej Zolnierkiewicz, as he is listed in the MAINTAINERS
file as the IDE maintainer.


Thanks for any comments and help, Rogério Brito.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-13 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
> Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
> without it.  My motherboard exhibits runaway IRQ with it.

Ok, now I've just downloaded the -rc4 patch and while selecting the options
to compile, I saw what MSI means. No, I didn't have MSI enabled.

I guess tha I could try a compile with it enabled? I enabled the ACPI
debugging messages, just in case it helps.

I will now compile the new kernel. Let's see if the debugging messages help
here.


Hope this information is useful, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-13 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
> On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote:
> > To prevent the matters of loosing track of what is being done, I only
> > changed one option at a time. I put the dmesg logs of all my attempts
> > at .
> > 
> > Please let me know if I can provide any other useful information.
> 
> Your 'dmesg' says
> Warning: Secondary channel requires an 80-pin cable for operation.
> I assume it is.

Indeed, I have two HDs plugged on the Promise controller. One of them (the
first one) has a 80-pin cable and the bios configures it to use UDMA 4.

Since I only have one 80-ribbon cable, the second HD uses a 40-ribbon cable
and is configured as the master of the other channel of the Promise
controller (to avoid having problems with the first one and to increase the
performance, since IDE does not have the ability to "disconnect" devices).

Perhaps that is the problem? I will try to turn off the second drive for a
moment, but I guess that there shouldn't be such problems.

One thing that is curious is that since both HDs are on different channels
of the Promise controller (as masters), the BIOS configures the first one
(with the 80-pin cable) as UDMA 4 and the second one (with the 40-pin
cable) as UDMA 2.

Then, when Linux boots, it downgrades both devices to UDMA 2, including the
one with the 80-ribbon cable. Is that expected behaviour?

> Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
> without it.  My motherboard exhibits runaway IRQ with it.

I don't know what MSI is (I only know of a manufacturer of motherboards
called MSI), but my motherboard is an Asus A7V with chipset VIA KT133 (not
the latter revision, VIA KT133A).


Thank you very much for your help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-13 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
 On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote:
  To prevent the matters of loosing track of what is being done, I only
  changed one option at a time. I put the dmesg logs of all my attempts
  at http://www.ime.usp.br/~rbrito/ide-problem/.
  
  Please let me know if I can provide any other useful information.
 
 Your 'dmesg' says
 Warning: Secondary channel requires an 80-pin cable for operation.
 I assume it is.

Indeed, I have two HDs plugged on the Promise controller. One of them (the
first one) has a 80-pin cable and the bios configures it to use UDMA 4.

Since I only have one 80-ribbon cable, the second HD uses a 40-ribbon cable
and is configured as the master of the other channel of the Promise
controller (to avoid having problems with the first one and to increase the
performance, since IDE does not have the ability to disconnect devices).

Perhaps that is the problem? I will try to turn off the second drive for a
moment, but I guess that there shouldn't be such problems.

One thing that is curious is that since both HDs are on different channels
of the Promise controller (as masters), the BIOS configures the first one
(with the 80-pin cable) as UDMA 4 and the second one (with the 40-pin
cable) as UDMA 2.

Then, when Linux boots, it downgrades both devices to UDMA 2, including the
one with the 80-ribbon cable. Is that expected behaviour?

 Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
 without it.  My motherboard exhibits runaway IRQ with it.

I don't know what MSI is (I only know of a manufacturer of motherboards
called MSI), but my motherboard is an Asus A7V with chipset VIA KT133 (not
the latter revision, VIA KT133A).


Thank you very much for your help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-13 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
 Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
 without it.  My motherboard exhibits runaway IRQ with it.

Ok, now I've just downloaded the -rc4 patch and while selecting the options
to compile, I saw what MSI means. No, I didn't have MSI enabled.

I guess tha I could try a compile with it enabled? I enabled the ACPI
debugging messages, just in case it helps.

I will now compile the new kernel. Let's see if the debugging messages help
here.


Hope this information is useful, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


[Partially solved] Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-13 Thread Rogério Brito

Hi, William.

On Feb 12 2005, William Park wrote:
 Your 'dmesg' says
 Warning: Secondary channel requires an 80-pin cable for operation.
 I assume it is.

Well, I just finished compiling the 2.6.11-rc4 kernel and the problem
persisted. This time, I enabled ACPI debugging and it indeed generates more
details.

Right after the problem persisted, I turned off the second HD (which was
the master of the secondary channel of the Promise controller) and the
problem automagically went away. :-(

One other thing is that the BIOS still configures the drive as UDMA 4, but
Linux downgrades that to UDMA 2. I'm not sure why.

Using hdparm manually with hdparm -c1 -u1 -d1 -X udma4 /dev/hde enables
things that the kernel doesn't and seems to be working wonderfully.

I don't know what I should do right now. I have put the newer dmesg logs on
http://www.ime.usp.br/~rbrito/ide-problem/. Should I contact anybody else?
I do need the second drive on, though.

I'm CC'ing Bartlomiej Zolnierkiewicz, as he is listed in the MAINTAINERS
file as the IDE maintainer.


Thanks for any comments and help, Rogério Brito.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread William Park
On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote:
> On Feb 12 2005, William Park wrote:
> > This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
> > then try 'pci=noacpi'.
> 
> Hi, Willian.
> 
> First of all, thank you very much for both your attention and help.
> 
> Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just
> compiled and I tried using many boot parameters like "acpi=noirq",
> "irqpoll", "pci=noacpi", "acpi=off" and setting the BIOS of my motherboard
> to "Plug'n'Play OS = Yes" (instead of "Off", which is my default).
> 
> To prevent the matters of loosing track of what is being done, I only
> changed one option at a time. I put the dmesg logs of all my attempts at
> .
> 
> Please let me know if I can provide any other useful information.

Your 'dmesg' says
Warning: Secondary channel requires an 80-pin cable for operation.
I assume it is.

Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
without it.  My motherboard exhibits runaway IRQ with it.

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
> This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
> then try 'pci=noacpi'.

Hi, Willian.

First of all, thank you very much for both your attention and help.

Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just
compiled and I tried using many boot parameters like "acpi=noirq",
"irqpoll", "pci=noacpi", "acpi=off" and setting the BIOS of my motherboard
to "Plug'n'Play OS = Yes" (instead of "Off", which is my default).

To prevent the matters of loosing track of what is being done, I only
changed one option at a time. I put the dmesg logs of all my attempts at
.

Please let me know if I can provide any other useful information.


Thank you very much again for any help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread William Park
On Sat, Feb 12, 2005 at 08:47:15PM -0200, Rog?rio Brito wrote:
> On Feb 12 2005, William Park wrote:
> > On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> > > For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> > > some -mm trees and also -ac) I have been getting the message "irq 10:
> > > nobody cared!".
> > 
> > Try 'acpi=noirq'.
> 
> Unfortunately, I have already tried that and I still get stack traces
> like this one (this time, booted without any acpi-related option):
...
> ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
> PCI: setting IRQ 10 as level-triggered
> ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10

This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
then try 'pci=noacpi'.

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
> On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> > For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> > some -mm trees and also -ac) I have been getting the message "irq 10:
> > nobody cared!".
> 
> Try 'acpi=noirq'.

Unfortunately, I have already tried that and I still get stack traces like
this one (this time, booted without any acpi-related option):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Probing IDE interface ide1...
hdc: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
PDC20265: IDE controller at PCI slot :00:11.0
PCI: :00:11.0 has unsupported PM cap regs version (1)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt :00:11.0[A] -> GSI 10 (level, low) -> IRQ 10
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared (try booting with the "irqpoll" option.
 [] __report_bad_irq+0x31/0x77
 [] note_interrupt+0x75/0x99
 [] __do_IRQ+0x95/0xc1
 [] do_IRQ+0x19/0x24
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2c/0x7d
 [] do_softirq+0x22/0x26
 [] do_IRQ+0x1e/0x24
 [] common_interrupt+0x1a/0x20
 [] enable_irq+0x88/0x8d
 [] probe_hwif+0x2f7/0x383
 [] ata_attach+0xa3/0xbd
 [] probe_hwif_init_with_fixup+0x10/0x74
 [] ide_setup_pci_device+0x72/0x7f
 [] pdc202xx_init_one+0x15/0x18
 [] ide_scan_pcidev+0x34/0x59
 [] ide_scan_pcibus+0x1c/0x92
 [] probe_for_hwifs+0xb/0xd
 [] ide_init+0x44/0x59
 [] do_initcalls+0x4b/0x99
 [] init+0x0/0xce
 [] init+0x27/0xce
 [] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I can provide any information that is necessary about my system to fix the
problem.

I just finished compiling kernel 2.6.11-rc3-mm2 and I will report back if
there is any difference.


Thank you very much for any help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread William Park
On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> Dear developers,
> 
> For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> some -mm trees and also -ac) I have been getting the message "irq 10:
> nobody cared!".
> 
> The message says that I should pass the irqpoll option to the kernel and
> even if I do, I still get the stack trace and the "irq 10: nobody cared!"
> message. :-(
> 
> The message seems to be related to the Promise PDC20265 driver and it
> appeared right after I moved my HDs from my motherboard's VIA controllers
> to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
> controllers and 2 Promise PDC20265 controllers.
> 
> I already tried enabling and disabling ACPI, but it seems that the problem
> just doesn't go away. :-(
> 
> I am including the dmesg log of my system with this message. I am CC'ing
> the linux-ide list, but I'm only subscribed to linux-kernel. I would
> appreciate CC's, if possible.
> 
> 
> Thank you very much for any help, Rog?rio.
> 
> P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
> kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'.

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread William Park
On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
 Dear developers,
 
 For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
 some -mm trees and also -ac) I have been getting the message irq 10:
 nobody cared!.
 
 The message says that I should pass the irqpoll option to the kernel and
 even if I do, I still get the stack trace and the irq 10: nobody cared!
 message. :-(
 
 The message seems to be related to the Promise PDC20265 driver and it
 appeared right after I moved my HDs from my motherboard's VIA controllers
 to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
 controllers and 2 Promise PDC20265 controllers.
 
 I already tried enabling and disabling ACPI, but it seems that the problem
 just doesn't go away. :-(
 
 I am including the dmesg log of my system with this message. I am CC'ing
 the linux-ide list, but I'm only subscribed to linux-kernel. I would
 appreciate CC's, if possible.
 
 
 Thank you very much for any help, Rog?rio.
 
 P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
 kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'.

-- 
William Park [EMAIL PROTECTED], Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread William Park
On Sat, Feb 12, 2005 at 08:47:15PM -0200, Rog?rio Brito wrote:
 On Feb 12 2005, William Park wrote:
  On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
   For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
   some -mm trees and also -ac) I have been getting the message irq 10:
   nobody cared!.
  
  Try 'acpi=noirq'.
 
 Unfortunately, I have already tried that and I still get stack traces
 like this one (this time, booted without any acpi-related option):
...
 ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
 PCI: setting IRQ 10 as level-triggered
 ACPI: PCI interrupt :00:11.0[A] - GSI 10 (level, low) - IRQ 10

This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
then try 'pci=noacpi'.

-- 
William Park [EMAIL PROTECTED], Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
 This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
 then try 'pci=noacpi'.

Hi, Willian.

First of all, thank you very much for both your attention and help.

Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just
compiled and I tried using many boot parameters like acpi=noirq,
irqpoll, pci=noacpi, acpi=off and setting the BIOS of my motherboard
to Plug'n'Play OS = Yes (instead of Off, which is my default).

To prevent the matters of loosing track of what is being done, I only
changed one option at a time. I put the dmesg logs of all my attempts at
http://www.ime.usp.br/~rbrito/ide-problem/.

Please let me know if I can provide any other useful information.


Thank you very much again for any help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread William Park
On Sat, Feb 12, 2005 at 09:50:43PM -0200, Rog?rio Brito wrote:
 On Feb 12 2005, William Park wrote:
  This looks awefully like 'acpi' is on.  If 'acpi=noirq' does not work,
  then try 'pci=noacpi'.
 
 Hi, Willian.
 
 First of all, thank you very much for both your attention and help.
 
 Unfortunately, I have already tried booting the 2.6.11-rc3-mm2 that I just
 compiled and I tried using many boot parameters like acpi=noirq,
 irqpoll, pci=noacpi, acpi=off and setting the BIOS of my motherboard
 to Plug'n'Play OS = Yes (instead of Off, which is my default).
 
 To prevent the matters of loosing track of what is being done, I only
 changed one option at a time. I put the dmesg logs of all my attempts at
 http://www.ime.usp.br/~rbrito/ide-problem/.
 
 Please let me know if I can provide any other useful information.

Your 'dmesg' says
Warning: Secondary channel requires an 80-pin cable for operation.
I assume it is.

Do you have MSI on by any chance?  (CONFIG_PCI_MSI)  If so, try kernel
without it.  My motherboard exhibits runaway IRQ with it.

-- 
William Park [EMAIL PROTECTED], Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-12 Thread Rogério Brito
On Feb 12 2005, William Park wrote:
 On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
  For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
  some -mm trees and also -ac) I have been getting the message irq 10:
  nobody cared!.
 
 Try 'acpi=noirq'.

Unfortunately, I have already tried that and I still get stack traces like
this one (this time, booted without any acpi-related option):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Probing IDE interface ide1...
hdc: Hewlett-Packard CD-Writer Plus 9100, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
PDC20265: IDE controller at PCI slot :00:11.0
PCI: :00:11.0 has unsupported PM cap regs version (1)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt :00:11.0[A] - GSI 10 (level, low) - IRQ 10
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared (try booting with the irqpoll option.
 [c012c1e9] __report_bad_irq+0x31/0x77
 [c012c2bc] note_interrupt+0x75/0x99
 [c012bd80] __do_IRQ+0x95/0xc1
 [c010469d] do_IRQ+0x19/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c011a03c] __do_softirq+0x2c/0x7d
 [c011a0af] do_softirq+0x22/0x26
 [c01046a2] do_IRQ+0x1e/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c012be85] enable_irq+0x88/0x8d
 [c020fb94] probe_hwif+0x2f7/0x383
 [c020adb4] ata_attach+0xa3/0xbd
 [c020fc30] probe_hwif_init_with_fixup+0x10/0x74
 [c021234b] ide_setup_pci_device+0x72/0x7f
 [c0207c26] pdc202xx_init_one+0x15/0x18
 [c03792f5] ide_scan_pcidev+0x34/0x59
 [c0379336] ide_scan_pcibus+0x1c/0x92
 [c0379266] probe_for_hwifs+0xb/0xd
 [c03792ac] ide_init+0x44/0x59
 [c03646d9] do_initcalls+0x4b/0x99
 [c0100272] init+0x0/0xce
 [c0100299] init+0x27/0xce
 [c0101245] kernel_thread_helper+0x5/0xb
handlers:
[c020cec8] (ide_intr+0x0/0xee)
Disabling IRQ #10
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I can provide any information that is necessary about my system to fix the
problem.

I just finished compiling kernel 2.6.11-rc3-mm2 and I will report back if
there is any difference.


Thank you very much for any help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-06 Thread Rogério Brito
On Feb 05 2005, William Park wrote:
> On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rogério Brito wrote:
> > The message seems to be related to the Promise PDC20265 driver and it
> > appeared right after I moved my HDs from my motherboard's VIA controllers
> > to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
> > controllers and 2 Promise PDC20265 controllers.
> > 
> > I already tried enabling and disabling ACPI, but it seems that the problem
> > just doesn't go away. :-(
> 
> Try 'acpi=noirq'.  It did it for me (Abit VP6 dual-p3, Via VT82C694X,
> Via VT82C686B).

I tried to boot with acpi=noirq, but it didn't work for me. Here is the
relevant part of the dmesg output (and the whole dmesg is attached to this
message):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(...)
Kernel command line: BOOT_IMAGE=Linux root=2103 acpi=noirq
(...)
PDC20265: IDE controller at PCI slot :00:11.0
PCI: :00:11.0 has unsupported PM cap regs version (1)
PCI: Found IRQ 10 for device :00:11.0
PCI: Sharing IRQ 10 with :00:0b.0
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared (try booting with the "irqpoll" option.
 [] __report_bad_irq+0x31/0x77
 [] note_interrupt+0x75/0x99
 [] __do_IRQ+0x95/0xc1
 [] do_IRQ+0x19/0x24
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2c/0x7d
 [] do_softirq+0x22/0x26
 [] do_IRQ+0x1e/0x24
 [] common_interrupt+0x1a/0x20
 [] enable_irq+0x88/0x8d
 [] probe_hwif+0x2f7/0x383
 [] ata_attach+0xa3/0xbd
 [] probe_hwif_init_with_fixup+0x10/0x74
 [] ide_setup_pci_device+0x72/0x7f
 [] pdc202xx_init_one+0x15/0x18
 [] ide_scan_pcidev+0x34/0x59
 [] ide_scan_pcibus+0x1c/0x92
 [] probe_for_hwifs+0xb/0xd
 [] ide_init+0x44/0x59
 [] do_initcalls+0x4b/0x99
 [] init+0x0/0xce
 [] init+0x27/0xce
 [] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
irq 10: nobody cared (try booting with the "irqpoll" option.
 [] __report_bad_irq+0x31/0x77
 [] note_interrupt+0x75/0x99
 [] __do_IRQ+0x95/0xc1
 [] do_IRQ+0x19/0x24
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2c/0x7d
 [] do_softirq+0x22/0x26
 [] do_IRQ+0x1e/0x24
 [] common_interrupt+0x1a/0x20
 [] enable_irq+0x88/0x8d
 [] ide_config_drive_speed+0x168/0x30d
 [] pdc202xx_tune_chipset+0x38c/0x396
 [] probe_hwif+0x341/0x383
 [] ata_attach+0xa3/0xbd
 [] probe_hwif_init_with_fixup+0x10/0x74
 [] ide_setup_pci_device+0x72/0x7f
 [] pdc202xx_init_one+0x15/0x18
 [] ide_scan_pcidev+0x34/0x59
 [] ide_scan_pcibus+0x1c/0x92
 [] probe_for_hwifs+0xb/0xd
 [] ide_init+0x44/0x59
 [] do_initcalls+0x4b/0x99
 [] init+0x0/0xce
 [] init+0x27/0xce
 [] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
Warning: Secondary channel requires an 80-pin cable for operation.
hdg reduced to Ultra33 mode.
irq 10: nobody cared (try booting with the "irqpoll" option.
 [] __report_bad_irq+0x31/0x77
 [] note_interrupt+0x75/0x99
 [] __do_IRQ+0x95/0xc1
 [] do_IRQ+0x19/0x24
 [] common_interrupt+0x1a/0x20
 [] __do_softirq+0x2c/0x7d
 [] do_softirq+0x22/0x26
 [] do_IRQ+0x1e/0x24
 [] common_interrupt+0x1a/0x20
 [] enable_irq+0x88/0x8d
 [] ide_config_drive_speed+0x168/0x30d
 [] pdc202xx_tune_chipset+0x38c/0x396
 [] config_chipset_for_dma+0x216/0x227
 [] pdc202xx_config_drive_xfer_rate+0x37/0x6c
 [] probe_hwif+0x368/0x383
 [] ata_attach+0xa3/0xbd
 [] probe_hwif_init_with_fixup+0x10/0x74
 [] ide_setup_pci_device+0x72/0x7f
 [] pdc202xx_init_one+0x15/0x18
 [] ide_scan_pcidev+0x34/0x59
 [] ide_scan_pcibus+0x1c/0x92
 [] probe_for_hwifs+0xb/0xd
 [] ide_init+0x44/0x59
 [] do_initcalls+0x4b/0x99
 [] init+0x0/0xce
 [] init+0x27/0xce
 [] kernel_thread_helper+0x5/0xb
handlers:
[] (ide_intr+0x0/0xee)
Disabling IRQ #10
ide3 at 0x8000-0x8007,0x7802 on irq 10
hde: max request size: 128KiB
hde: 25429824 sectors (13020 MB) w/418KiB Cache, CHS=25228/16/63, UDMA(33)
hde: cache flushes not supported
 hde: hde1 hde2 hde3 hde4
hdg: max request size: 128KiB
hdg: 58633344 sectors (30020 MB) w/418KiB Cache, CHS=58168/16/63, UDMA(33)
hdg: cache flushes not supported
 hdg: hdg1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

So, it seems that I'm always getting this, whether I use acpi=off,
acpi=noirq or the irqpoll options passed to the kernel. Would there be
anything else that I should try?


Thank you very much for the help, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Linux version 2.6.11-rc3-mm1-1 

Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-06 Thread Rogério Brito
On Feb 05 2005, William Park wrote:
 On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rogério Brito wrote:
  The message seems to be related to the Promise PDC20265 driver and it
  appeared right after I moved my HDs from my motherboard's VIA controllers
  to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
  controllers and 2 Promise PDC20265 controllers.
  
  I already tried enabling and disabling ACPI, but it seems that the problem
  just doesn't go away. :-(
 
 Try 'acpi=noirq'.  It did it for me (Abit VP6 dual-p3, Via VT82C694X,
 Via VT82C686B).

I tried to boot with acpi=noirq, but it didn't work for me. Here is the
relevant part of the dmesg output (and the whole dmesg is attached to this
message):

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
(...)
Kernel command line: BOOT_IMAGE=Linux root=2103 acpi=noirq
(...)
PDC20265: IDE controller at PCI slot :00:11.0
PCI: :00:11.0 has unsupported PM cap regs version (1)
PCI: Found IRQ 10 for device :00:11.0
PCI: Sharing IRQ 10 with :00:0b.0
PDC20265: chipset revision 2
PDC20265: 100% native mode on irq 10
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0x7400-0x7407, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x7408-0x740f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
ide2 at 0x8800-0x8807,0x8402 on irq 10
Probing IDE interface ide3...
hdg: QUANTUM FIREBALLlct15 30, ATA DISK drive
irq 10: nobody cared (try booting with the irqpoll option.
 [c012c1e9] __report_bad_irq+0x31/0x77
 [c012c2bc] note_interrupt+0x75/0x99
 [c012bd80] __do_IRQ+0x95/0xc1
 [c010469d] do_IRQ+0x19/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c011a03c] __do_softirq+0x2c/0x7d
 [c011a0af] do_softirq+0x22/0x26
 [c01046a2] do_IRQ+0x1e/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c012be85] enable_irq+0x88/0x8d
 [c020fb94] probe_hwif+0x2f7/0x383
 [c020adb4] ata_attach+0xa3/0xbd
 [c020fc30] probe_hwif_init_with_fixup+0x10/0x74
 [c021234b] ide_setup_pci_device+0x72/0x7f
 [c0207c26] pdc202xx_init_one+0x15/0x18
 [c03792f5] ide_scan_pcidev+0x34/0x59
 [c0379336] ide_scan_pcibus+0x1c/0x92
 [c0379266] probe_for_hwifs+0xb/0xd
 [c03792ac] ide_init+0x44/0x59
 [c03646d9] do_initcalls+0x4b/0x99
 [c0100272] init+0x0/0xce
 [c0100299] init+0x27/0xce
 [c0101245] kernel_thread_helper+0x5/0xb
handlers:
[c020cec8] (ide_intr+0x0/0xee)
Disabling IRQ #10
irq 10: nobody cared (try booting with the irqpoll option.
 [c012c1e9] __report_bad_irq+0x31/0x77
 [c012c2bc] note_interrupt+0x75/0x99
 [c012bd80] __do_IRQ+0x95/0xc1
 [c010469d] do_IRQ+0x19/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c011a03c] __do_softirq+0x2c/0x7d
 [c011a0af] do_softirq+0x22/0x26
 [c01046a2] do_IRQ+0x1e/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c012be85] enable_irq+0x88/0x8d
 [c020dbe3] ide_config_drive_speed+0x168/0x30d
 [c0207266] pdc202xx_tune_chipset+0x38c/0x396
 [c020fbde] probe_hwif+0x341/0x383
 [c020adb4] ata_attach+0xa3/0xbd
 [c020fc30] probe_hwif_init_with_fixup+0x10/0x74
 [c021234b] ide_setup_pci_device+0x72/0x7f
 [c0207c26] pdc202xx_init_one+0x15/0x18
 [c03792f5] ide_scan_pcidev+0x34/0x59
 [c0379336] ide_scan_pcibus+0x1c/0x92
 [c0379266] probe_for_hwifs+0xb/0xd
 [c03792ac] ide_init+0x44/0x59
 [c03646d9] do_initcalls+0x4b/0x99
 [c0100272] init+0x0/0xce
 [c0100299] init+0x27/0xce
 [c0101245] kernel_thread_helper+0x5/0xb
handlers:
[c020cec8] (ide_intr+0x0/0xee)
Disabling IRQ #10
Warning: Secondary channel requires an 80-pin cable for operation.
hdg reduced to Ultra33 mode.
irq 10: nobody cared (try booting with the irqpoll option.
 [c012c1e9] __report_bad_irq+0x31/0x77
 [c012c2bc] note_interrupt+0x75/0x99
 [c012bd80] __do_IRQ+0x95/0xc1
 [c010469d] do_IRQ+0x19/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c011a03c] __do_softirq+0x2c/0x7d
 [c011a0af] do_softirq+0x22/0x26
 [c01046a2] do_IRQ+0x1e/0x24
 [c010337a] common_interrupt+0x1a/0x20
 [c012be85] enable_irq+0x88/0x8d
 [c020dbe3] ide_config_drive_speed+0x168/0x30d
 [c0207266] pdc202xx_tune_chipset+0x38c/0x396
 [c020757e] config_chipset_for_dma+0x216/0x227
 [c02075c6] pdc202xx_config_drive_xfer_rate+0x37/0x6c
 [c020fc05] probe_hwif+0x368/0x383
 [c020adb4] ata_attach+0xa3/0xbd
 [c020fc30] probe_hwif_init_with_fixup+0x10/0x74
 [c021234b] ide_setup_pci_device+0x72/0x7f
 [c0207c26] pdc202xx_init_one+0x15/0x18
 [c03792f5] ide_scan_pcidev+0x34/0x59
 [c0379336] ide_scan_pcibus+0x1c/0x92
 [c0379266] probe_for_hwifs+0xb/0xd
 [c03792ac] ide_init+0x44/0x59
 [c03646d9] do_initcalls+0x4b/0x99
 [c0100272] init+0x0/0xce
 [c0100299] init+0x27/0xce
 [c0101245] kernel_thread_helper+0x5/0xb
handlers:
[c020cec8] (ide_intr+0x0/0xee)
Disabling IRQ #10
ide3 at 0x8000-0x8007,0x7802 on irq 10
hde: max request size: 128KiB
hde: 25429824 sectors (13020 MB) w/418KiB Cache, CHS=25228/16/63, UDMA(33)
hde: cache flushes not supported
 hde: hde1 hde2 hde3 hde4
hdg: max request size: 128KiB
hdg: 58633344 sectors (30020 MB) w/418KiB Cache, 

Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-05 Thread William Park
On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
> Dear developers,
> 
> For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
> some -mm trees and also -ac) I have been getting the message "irq 10:
> nobody cared!".
> 
> The message says that I should pass the irqpoll option to the kernel and
> even if I do, I still get the stack trace and the "irq 10: nobody cared!"
> message. :-(
> 
> The message seems to be related to the Promise PDC20265 driver and it
> appeared right after I moved my HDs from my motherboard's VIA controllers
> to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
> controllers and 2 Promise PDC20265 controllers.
> 
> I already tried enabling and disabling ACPI, but it seems that the problem
> just doesn't go away. :-(
> 
> I am including the dmesg log of my system with this message. I am CC'ing
> the linux-ide list, but I'm only subscribed to linux-kernel. I would
> appreciate CC's, if possible.
> 
> 
> Thank you very much for any help, Rog?rio.
> 
> P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
> kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'.  It did it for me (Abit VP6 dual-p3, Via VT82C694X,
Via VT82C686B).

-- 
William Park <[EMAIL PROTECTED]>, Toronto, Canada
Slackware Linux -- because I can type.
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-05 Thread Rogério Brito
On Feb 05 2005, Rogério Brito wrote:
> I am including the dmesg log of my system with this message.
(...)

Ooops! Forgot to include the dmesg in the previous message. :-(


Thanks again, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Linux version 2.6.11-rc3-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #1 Thu Feb 3 01:41:08 BRST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009e800 (usable)
 BIOS-e820: 0009e800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0ffec000 (usable)
 BIOS-e820: 0ffec000 - 0ffef000 (ACPI data)
 BIOS-e820: 0ffef000 - 0000 (reserved)
 BIOS-e820: 0000 - 1000 (ACPI NVS)
 BIOS-e820:  - 0001 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65516
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61420 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 ASUS  ) @ 0x000f6a90
ACPI: RSDT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec000
ACPI: FADT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec080
ACPI: BOOT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec040
ACPI: DSDT (v001   ASUS A7V  0x1000 MSFT 0x010b) @ 0x
ACPI: PM-Timer IO Port: 0xe408
Built 1 zonelists
Kernel command line: BOOT_IMAGE=Linux root=2103 irqpoll
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to d000 (01201000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 605.655 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 256196k/262064k available (1674k kernel code, 5308k reserved, 728k 
data, 140k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1196.03 BogoMIPS (lpj=598016)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff c1c7f9ff    
 
CPU: After vendor identify, caps: 0183f9ff c1c7f9ff    
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0183f9ff c1c7f9ff  0020  
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) Processor stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e20)
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of "lspci" to [EMAIL PROTECTED]
** so I can fix the driver.
TC classifier action (bugs to netdev@oss.sgi.com cc [EMAIL PROTECTED])
pnp: 00:02: ioport range 0xe400-0xe47f could not be reserved
pnp: 00:02: ioport range 0xe800-0xe80f has been reserved
Simple Boot Flag at 0x3a set to 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14 <[EMAIL PROTECTED]>
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
Initializing Cryptographic API
PCI: Disabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: Maximum main 

irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-05 Thread Rogério Brito
Dear developers,

For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
some -mm trees and also -ac) I have been getting the message "irq 10:
nobody cared!".

The message says that I should pass the irqpoll option to the kernel and
even if I do, I still get the stack trace and the "irq 10: nobody cared!"
message. :-(

The message seems to be related to the Promise PDC20265 driver and it
appeared right after I moved my HDs from my motherboard's VIA controllers
to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
controllers and 2 Promise PDC20265 controllers.

I already tried enabling and disabling ACPI, but it seems that the problem
just doesn't go away. :-(

I am including the dmesg log of my system with this message. I am CC'ing
the linux-ide list, but I'm only subscribed to linux-kernel. I would
appreciate CC's, if possible.


Thank you very much for any help, Rogério.

P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
kallsyms to see if the problem persists with this release.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-05 Thread William Park
On Sat, Feb 05, 2005 at 08:45:58PM -0200, Rog?rio Brito wrote:
 Dear developers,
 
 For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
 some -mm trees and also -ac) I have been getting the message irq 10:
 nobody cared!.
 
 The message says that I should pass the irqpoll option to the kernel and
 even if I do, I still get the stack trace and the irq 10: nobody cared!
 message. :-(
 
 The message seems to be related to the Promise PDC20265 driver and it
 appeared right after I moved my HDs from my motherboard's VIA controllers
 to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
 controllers and 2 Promise PDC20265 controllers.
 
 I already tried enabling and disabling ACPI, but it seems that the problem
 just doesn't go away. :-(
 
 I am including the dmesg log of my system with this message. I am CC'ing
 the linux-ide list, but I'm only subscribed to linux-kernel. I would
 appreciate CC's, if possible.
 
 
 Thank you very much for any help, Rog?rio.
 
 P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
 kallsyms to see if the problem persists with this release.

Try 'acpi=noirq'.  It did it for me (Abit VP6 dual-p3, Via VT82C694X,
Via VT82C686B).

-- 
William Park [EMAIL PROTECTED], Toronto, Canada
Slackware Linux -- because I can type.
-
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/


irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-05 Thread Rogério Brito
Dear developers,

For some kernel versions (say, since 2.6.10 proper, all the 2.6.11-rc's,
some -mm trees and also -ac) I have been getting the message irq 10:
nobody cared!.

The message says that I should pass the irqpoll option to the kernel and
even if I do, I still get the stack trace and the irq 10: nobody cared!
message. :-(

The message seems to be related to the Promise PDC20265 driver and it
appeared right after I moved my HDs from my motherboard's VIA controllers
to the Promise controllers. I have an Asus A7V board, with 2 VIA 686a
controllers and 2 Promise PDC20265 controllers.

I already tried enabling and disabling ACPI, but it seems that the problem
just doesn't go away. :-(

I am including the dmesg log of my system with this message. I am CC'ing
the linux-ide list, but I'm only subscribed to linux-kernel. I would
appreciate CC's, if possible.


Thank you very much for any help, Rogério.

P.S.: I am, right now, re-compiling 2.6.11-rc3-mm1 with the extra pass of
kallsyms to see if the problem persists with this release.
-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-
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/


Re: irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1)

2005-02-05 Thread Rogério Brito
On Feb 05 2005, Rogério Brito wrote:
 I am including the dmesg log of my system with this message.
(...)

Ooops! Forgot to include the dmesg in the previous message. :-(


Thanks again, Rogério.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Linux version 2.6.11-rc3-1 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-5)) #1 Thu Feb 3 01:41:08 BRST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009e800 (usable)
 BIOS-e820: 0009e800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0ffec000 (usable)
 BIOS-e820: 0ffec000 - 0ffef000 (ACPI data)
 BIOS-e820: 0ffef000 - 0000 (reserved)
 BIOS-e820: 0000 - 1000 (ACPI NVS)
 BIOS-e820:  - 0001 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65516
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61420 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
ACPI: RSDP (v000 ASUS  ) @ 0x000f6a90
ACPI: RSDT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec000
ACPI: FADT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec080
ACPI: BOOT (v001 ASUS   A7V  0x30303031 MSFT 0x31313031) @ 0x0ffec040
ACPI: DSDT (v001   ASUS A7V  0x1000 MSFT 0x010b) @ 0x
ACPI: PM-Timer IO Port: 0xe408
Built 1 zonelists
Kernel command line: BOOT_IMAGE=Linux root=2103 irqpoll
Local APIC disabled by BIOS -- you can enable it with lapic
mapped APIC to d000 (01201000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 605.655 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 256196k/262064k available (1674k kernel code, 5308k reserved, 728k 
data, 140k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 1196.03 BogoMIPS (lpj=598016)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0183f9ff c1c7f9ff    
 
CPU: After vendor identify, caps: 0183f9ff c1c7f9ff    
 
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0183f9ff c1c7f9ff  0020  
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Duron(tm) Processor stepping 00
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e20)
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf1180, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050125
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Via IRQ fixup
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 13 devices
PCI: Using ACPI for IRQ routing
** PCI interrupts are no longer routed automatically.  If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device().  As a temporary
** workaround, the pci=routeirq argument restores the old
** behavior.  If this argument makes the device work again,
** please email the output of lspci to [EMAIL PROTECTED]
** so I can fix the driver.
TC classifier action (bugs to netdev@oss.sgi.com cc [EMAIL PROTECTED])
pnp: 00:02: ioport range 0xe400-0xe47f could not be reserved
pnp: 00:02: ioport range 0xe800-0xe80f has been reserved
Simple Boot Flag at 0x3a set to 0x1
Machine check exception polling timer started.
IA-32 Microcode Update Driver: v1.14 [EMAIL PROTECTED]
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
apm: overridden by ACPI.
Initializing Cryptographic API
PCI: Disabling Via external APIC routing
ACPI: Power Button (FF) [PWRF]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 16 throttling states)
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: Maximum main memory to