Hello,
I think, I'm experiencing the same problem:
09:16:34 : NETDEV WATCHDOG: eth0: transmit timed out
09:16:34 : eth0: Got tx_timeout. irq:
09:16:34 : eth0: Ring at 37e5
09:16:34 : eth0: Dumping tx registers
09:16:34 : 0: 00ff 0003 025003ca
2007/11/21, noah <[EMAIL PROTECTED]>:
> 2007/11/21, Alan Cox <[EMAIL PROTECTED]>:
> > > I've had other freezes before but this was the first time I was able
> > > to see what was actually going on.
> > > IRQ 21 appears to be shared between sata_nv and ethernet.
> > >
> > > Does this mean my
2007/11/21, noah [EMAIL PROTECTED]:
2007/11/21, Alan Cox [EMAIL PROTECTED]:
I've had other freezes before but this was the first time I was able
to see what was actually going on.
IRQ 21 appears to be shared between sata_nv and ethernet.
Does this mean my hardware/BIOS is broken
Hello,
I think, I'm experiencing the same problem:
09:16:34 : NETDEV WATCHDOG: eth0: transmit timed out
09:16:34 : eth0: Got tx_timeout. irq:
09:16:34 : eth0: Ring at 37e5
09:16:34 : eth0: Dumping tx registers
09:16:34 : 0: 00ff 0003 025003ca
Phillip Susi wrote:
> Tejun Heo wrote:
>> Surprise, surprise. There's no way to tell whether the controller
>> raised interrupt or not if command is not in progress. As I said
>> before, there's no IRQ pending bit. While processing commands, you can
>> tell by looking at other status registers
Tejun Heo wrote:
Surprise, surprise. There's no way to tell whether the controller
raised interrupt or not if command is not in progress. As I said
before, there's no IRQ pending bit. While processing commands, you can
tell by looking at other status registers but when there's nothing in
Tejun Heo wrote:
Surprise, surprise. There's no way to tell whether the controller
raised interrupt or not if command is not in progress. As I said
before, there's no IRQ pending bit. While processing commands, you can
tell by looking at other status registers but when there's nothing in
Phillip Susi wrote:
Tejun Heo wrote:
Surprise, surprise. There's no way to tell whether the controller
raised interrupt or not if command is not in progress. As I said
before, there's no IRQ pending bit. While processing commands, you can
tell by looking at other status registers but when
Phillip Susi wrote:
> Tejun Heo wrote:
>> Because SFF ATA controller don't have IRQ pending bit. You don't know
>> whether IRQ is raised or not. Plus, accessing the status register which
>> clears pending IRQ can be very slow on PATA machines. It has to go
>> through the PCI and ATA bus and
On Fri 2007-11-30 10:00:55, Mark Lord wrote:
> Pavel Machek wrote:
>> On Fri 2007-11-30 13:13:44, Alan Cox wrote:
Why does a single spurious interrupt cause it to be shut down? I can
>>> It doesn't.
>>>
see if the interrupt is stuck on and keeps interrupting constantly, but
if
Tejun Heo wrote:
Because SFF ATA controller don't have IRQ pending bit. You don't know
whether IRQ is raised or not. Plus, accessing the status register which
clears pending IRQ can be very slow on PATA machines. It has to go
through the PCI and ATA bus and come back. So, unconditionally
Pavel Machek wrote:
On Fri 2007-11-30 13:13:44, Alan Cox wrote:
Why does a single spurious interrupt cause it to be shut down? I can
It doesn't.
see if the interrupt is stuck on and keeps interrupting constantly, but
if it's just the occasional spurious interrupt, why not just ignore it
On Fri 2007-11-30 13:13:44, Alan Cox wrote:
> > Why does a single spurious interrupt cause it to be shut down? I can
>
> It doesn't.
>
> > see if the interrupt is stuck on and keeps interrupting constantly, but
> > if it's just the occasional spurious interrupt, why not just ignore it
> >
> Why does a single spurious interrupt cause it to be shut down? I can
It doesn't.
> see if the interrupt is stuck on and keeps interrupting constantly, but
> if it's just the occasional spurious interrupt, why not just ignore it
> and move on?
The interrupt is usually level triggered so it
Phillip Susi wrote:
Tejun Heo wrote:
Because SFF ATA controller don't have IRQ pending bit. You don't know
whether IRQ is raised or not. Plus, accessing the status register which
clears pending IRQ can be very slow on PATA machines. It has to go
through the PCI and ATA bus and come back.
On Fri 2007-11-30 10:00:55, Mark Lord wrote:
Pavel Machek wrote:
On Fri 2007-11-30 13:13:44, Alan Cox wrote:
Why does a single spurious interrupt cause it to be shut down? I can
It doesn't.
see if the interrupt is stuck on and keeps interrupting constantly, but
if it's just the
Tejun Heo wrote:
Because SFF ATA controller don't have IRQ pending bit. You don't know
whether IRQ is raised or not. Plus, accessing the status register which
clears pending IRQ can be very slow on PATA machines. It has to go
through the PCI and ATA bus and come back. So, unconditionally
Pavel Machek wrote:
On Fri 2007-11-30 13:13:44, Alan Cox wrote:
Why does a single spurious interrupt cause it to be shut down? I can
It doesn't.
see if the interrupt is stuck on and keeps interrupting constantly, but
if it's just the occasional spurious interrupt, why not just ignore it
On Fri 2007-11-30 13:13:44, Alan Cox wrote:
Why does a single spurious interrupt cause it to be shut down? I can
It doesn't.
see if the interrupt is stuck on and keeps interrupting constantly, but
if it's just the occasional spurious interrupt, why not just ignore it
and move on?
Why does a single spurious interrupt cause it to be shut down? I can
It doesn't.
see if the interrupt is stuck on and keeps interrupting constantly, but
if it's just the occasional spurious interrupt, why not just ignore it
and move on?
The interrupt is usually level triggered so it
Phillip Susi wrote:
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
Phillip Susi wrote:
> Tejun Heo wrote:
>> Agreed. Nobody cared on ATA controllers is usually very effective at
>> taking the whole machine down. Is there any reason why we don't turn on
>> irqpoll on turned off IRQs automatically?
>
> Why does a single spurious interrupt cause it to be shut
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
see if the interrupt
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
see if the interrupt
Phillip Susi wrote:
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
Phillip Susi wrote:
Tejun Heo wrote:
Agreed. Nobody cared on ATA controllers is usually very effective at
taking the whole machine down. Is there any reason why we don't turn on
irqpoll on turned off IRQs automatically?
Why does a single spurious interrupt cause it to be shut down? I can
Pavel Machek wrote:
> Hi!
>
>>> kernel: [734344.717844] irq 21: nobody cared (try booting with the
>>> "irqpoll" option)
>>> kernel: [734344.717866]
>> Your machine decided to emit interrupt 21 without an apparent reason.
>> Whatever caused that made the kernel shut down IRQ 21 at which point
Pavel Machek wrote:
Hi!
kernel: [734344.717844] irq 21: nobody cared (try booting with the
irqpoll option)
kernel: [734344.717866]
Your machine decided to emit interrupt 21 without an apparent reason.
Whatever caused that made the kernel shut down IRQ 21 at which point the
disk drives
Hi!
> > kernel: [734344.717844] irq 21: nobody cared (try booting with the
> > "irqpoll" option)
> > kernel: [734344.717866]
>
> Your machine decided to emit interrupt 21 without an apparent reason.
> Whatever caused that made the kernel shut down IRQ 21 at which point the
> disk drives on
Hi!
kernel: [734344.717844] irq 21: nobody cared (try booting with the
irqpoll option)
kernel: [734344.717866]
Your machine decided to emit interrupt 21 without an apparent reason.
Whatever caused that made the kernel shut down IRQ 21 at which point the
disk drives on that IRQ were
2007/11/21, Alan Cox <[EMAIL PROTECTED]>:
> > I've had other freezes before but this was the first time I was able
> > to see what was actually going on.
> > IRQ 21 appears to be shared between sata_nv and ethernet.
> >
> > Does this mean my hardware/BIOS is broken somehow?
>
> Not neccessarily.
2007/11/21, Alan Cox [EMAIL PROTECTED]:
I've had other freezes before but this was the first time I was able
to see what was actually going on.
IRQ 21 appears to be shared between sata_nv and ethernet.
Does this mean my hardware/BIOS is broken somehow?
Not neccessarily. It could a bug
> I've had other freezes before but this was the first time I was able
> to see what was actually going on.
> IRQ 21 appears to be shared between sata_nv and ethernet.
>
> Does this mean my hardware/BIOS is broken somehow?
Not neccessarily. It could a bug in one of the drivers using IRQ 21
2007/11/20, Alan Cox <[EMAIL PROTECTED]>:
> > kernel: [734344.717844] irq 21: nobody cared (try booting with the
> > "irqpoll" option)
> > kernel: [734344.717866]
>
> Your machine decided to emit interrupt 21 without an apparent reason.
> Whatever caused that made the kernel shut down IRQ 21 at
> kernel: [734344.717844] irq 21: nobody cared (try booting with the
> "irqpoll" option)
> kernel: [734344.717866]
Your machine decided to emit interrupt 21 without an apparent reason.
Whatever caused that made the kernel shut down IRQ 21 at which point the
disk drives on that IRQ were no
I just had a strange freeze that killed networking and made software
RAID fail two of my harddisks.
There are a bunch of messages from the kernel which I extracted from
the system log after reboot at the end of this mail. I hit power off
in pure paranoia after the box froze, and then started to
I just had a strange freeze that killed networking and made software
RAID fail two of my harddisks.
There are a bunch of messages from the kernel which I extracted from
the system log after reboot at the end of this mail. I hit power off
in pure paranoia after the box froze, and then started to
kernel: [734344.717844] irq 21: nobody cared (try booting with the
irqpoll option)
kernel: [734344.717866]
Your machine decided to emit interrupt 21 without an apparent reason.
Whatever caused that made the kernel shut down IRQ 21 at which point the
disk drives on that IRQ were no longer
2007/11/20, Alan Cox [EMAIL PROTECTED]:
kernel: [734344.717844] irq 21: nobody cared (try booting with the
irqpoll option)
kernel: [734344.717866]
Your machine decided to emit interrupt 21 without an apparent reason.
Whatever caused that made the kernel shut down IRQ 21 at which point
I've had other freezes before but this was the first time I was able
to see what was actually going on.
IRQ 21 appears to be shared between sata_nv and ethernet.
Does this mean my hardware/BIOS is broken somehow?
Not neccessarily. It could a bug in one of the drivers using IRQ 21
(sata_nv
40 matches
Mail list logo
