You guys probably already know but i'm still having problems with the ide
timer in 2.5.5 :
hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
bug: kernel timer added twice at c01c7293.
NFS: NFSv3 not supported.
nfs warning: mount version older than kernel
hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
bug: kernel timer added twice at c01c7293.
The machine seems working fine but i get these messages at the end of the
kernel boot sequence. If you need more info just let me know.
- Davide
On Sat, 23 Feb 2002, Davide Libenzi wrote:
>
> You guys probably already know but i'm still having problems with the ide
> timer in 2.5.5 :
>
> hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
> bug: kernel timer added twice at c01c7293.
> NFS: NFSv3 not supported.
> nfs warning: mount version older than kernel
> hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
> bug: kernel timer added twice at c01c7293.
>
>
> The machine seems working fine but i get these messages at the end of the
> kernel boot sequence. If you need more info just let me know.
I know the issue because I just found it before you sent this post.
I will generate a patch for which should solve the problem.
Regards,
Andre Hedrick
Linux Disk Certification Project Linux ATA Development
Davide Libenzi wrote:
> You guys probably already know but i'm still having problems with the ide
> timer in 2.5.5 :
>
> hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
> bug: kernel timer added twice at c01c7293.
> NFS: NFSv3 not supported.
> nfs warning: mount version older than kernel
> hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
> bug: kernel timer added twice at c01c7293.
Hugh?
It would be helpfull if you could send me the System.map
corresponding to that, since this could make it clear
which particular timer function is involved.
lspci -v
hdparm -i /dev/hda
and so one are usefull as well of course.
I was already tempted to replace the above check by a BUG()...
Would you mind as well to just apply ide-clean-18 and ide-clean-19
on top of each other and recheck?
> Would you mind as well to just apply ide-clean-18 and ide-clean-19
> on top of each other and recheck?
We see that one on 2.4 if you enable some of the work in progress options.
It seems that the timeout path is forgetting to clear the old handler. I've
not pinned it down since its deep in the WIP stuff.
> Ahh... this is really helpfull. Indeed I see the same. At most
> places ide_set_handler get's just called without clearing
> it before. This means that the IRQ handler routine abused as timeout handler
In all the command cases thats because the previous command state has
completed. I'm pretty sure there is one path alone wrong and its in the
WIP DMA timeout stuff
Alan Cox wrote:
>>Would you mind as well to just apply ide-clean-18 and ide-clean-19
>>on top of each other and recheck?
>>
>
> We see that one on 2.4 if you enable some of the work in progress options.
> It seems that the timeout path is forgetting to clear the old handler. I've
> not pinned it down since its deep in the WIP stuff.
Ahh... this is really helpfull. Indeed I see the same. At most
places ide_set_handler get's just called without clearing
it before. This means that the IRQ handler routine abused as timeout handler
doesn't clear it as well. For example one could imagine that reset_pollfunc
get's called multiple times one after another on asynchronous interfaces.
Hmm but if one thinks a bit further: the timer is an entity related to a
command. If we stop sending commands with the assumption that master vers. slave
oprtations are mutual on each other, then it becomes abvious that this timeout
timer is indeed an entity, which should be hooked to a particular drive and not
just the interface (ide_hwif_t). So the fix will be a bit much
more involved. This may very well explain the problems of Zwambe as
well... (disks overlapping with CD-ROM operations).
Please correct me if my reasoning is wrong.
On Mon, 11 Mar 2002, Martin Dalecki wrote:
> Davide Libenzi wrote:
> > You guys probably already know but i'm still having problems with the ide
> > timer in 2.5.5 :
> >
> > hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
> > bug: kernel timer added twice at c01c7293.
> > NFS: NFSv3 not supported.
> > nfs warning: mount version older than kernel
> > hda: ide_set_handler: handler not null; old=c01c5e10, new=c01c5e10
> > bug: kernel timer added twice at c01c7293.
>
> Hugh?
>
> It would be helpfull if you could send me the System.map
> corresponding to that, since this could make it clear
> which particular timer function is involved.
>
> lspci -v
> hdparm -i /dev/hda
>
> and so one are usefull as well of course.
>
> I was already tempted to replace the above check by a BUG()...
>
> Would you mind as well to just apply ide-clean-18 and ide-clean-19
> on top of each other and recheck?
I'll post it asap, try to check out the Alan's hint though and let me
know.
- Davide
On Mon, 11 Mar 2002, Alan Cox wrote:
> In all the command cases thats because the previous command state has
> completed. I'm pretty sure there is one path alone wrong and its in the
> WIP DMA timeout stuff
I don't know if you guys have come across the ide timer added twice
problem personally, but its pretty easy to reproduce by dropping the
device from DMA to PIO. 100% reproducible over here with my ide cdrom.
Regards,
Zwane
On Tue, Mar 12, 2002 at 04:21:52PM +0200, Zwane Mwaikambo wrote:
> On Mon, 11 Mar 2002, Alan Cox wrote:
>
> > In all the command cases thats because the previous command state has
> > completed. I'm pretty sure there is one path alone wrong and its in the
> > WIP DMA timeout stuff
>
> I don't know if you guys have come across the ide timer added twice
> problem personally, but its pretty easy to reproduce by dropping the
> device from DMA to PIO. 100% reproducible over here with my ide cdrom.
It looks like this issue has moved over to 2.4-ac now.
I too am able to reproduce this on two drives in PIO mode.
There are only two drives, hda and hdc. I was copying from hda to md0 (one
half of a new RAID1 array that will (completed now as of this writing) be on
hda and hdc.
I can provide more information upon request.
Mike
2.4.19-pre4-ac3
Apr 3 03:43:19 gw kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on md(9,0), internal journal
Apr 3 03:43:19 gw kernel: EXT3-fs: mounted filesystem with ordered data mode.
Apr 3 03:44:58 gw kernel: hda: status timeout: status=0xd0 { Busy }
Apr 3 03:45:05 gw kernel: hda: ide_set_handler: handler not null; old=c01b9630, new=c01bab40
Apr 3 03:45:05 gw kernel: bug: kernel timer added twice at c01ba9a2.
Apr 3 03:45:05 gw kernel: hda: no DRQ after issuing MULTWRITE
Apr 3 03:45:05 gw kernel: ide0: reset: success
System.map:
c01ba940 T ide_set_handler
c01ba9c0 T current_capacity
00:00.0 Host bridge: Intel Corp. 430HX - 82439HX TXC [Triton II] (rev 03)
00:01.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
00:01.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]
00:01.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
00:06.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
00:07.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 02)
00:08.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 54)
00:0b.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
>From 2.4.19-pre3-ac4 (logs not saved from pre4-ac3, but can be reproduced
upon request...):
PIIX3: IDE controller on PCI bus 00 dev 09
PIIX3: chipset revision 0
PIIX3: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
hda: WDC AC32500H, ATA DISK drive
hdc: WDC AC32500H, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: Disabling (U)DMA for WDC AC32500H
hda: 4999680 sectors (2560 MB) w/128KiB Cache, CHS=620/128/63
hdc: Disabling (U)DMA for WDC AC32500H
hdc: 4999680 sectors (2560 MB) w/128KiB Cache, CHS=4960/16/63
Are you using "taskfile io" if so stop for now until I can give Alan a
patch update. If you are not using "taskfile io" it means there is a new
problem.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 4 Apr 2002, Mike Fedyk wrote:
> On Tue, Mar 12, 2002 at 04:21:52PM +0200, Zwane Mwaikambo wrote:
> > On Mon, 11 Mar 2002, Alan Cox wrote:
> >
> > > In all the command cases thats because the previous command state has
> > > completed. I'm pretty sure there is one path alone wrong and its in the
> > > WIP DMA timeout stuff
> >
> > I don't know if you guys have come across the ide timer added twice
> > problem personally, but its pretty easy to reproduce by dropping the
> > device from DMA to PIO. 100% reproducible over here with my ide cdrom.
>
> It looks like this issue has moved over to 2.4-ac now.
>
> I too am able to reproduce this on two drives in PIO mode.
>
> There are only two drives, hda and hdc. I was copying from hda to md0 (one
> half of a new RAID1 array that will (completed now as of this writing) be on
> hda and hdc.
>
> I can provide more information upon request.
>
> Mike
>
> 2.4.19-pre4-ac3
>
> Apr 3 03:43:19 gw kernel: EXT3 FS 2.4-0.9.17, 10 Jan 2002 on md(9,0), internal journal
> Apr 3 03:43:19 gw kernel: EXT3-fs: mounted filesystem with ordered data mode.
> Apr 3 03:44:58 gw kernel: hda: status timeout: status=0xd0 { Busy }
> Apr 3 03:45:05 gw kernel: hda: ide_set_handler: handler not null; old=c01b9630, new=c01bab40
> Apr 3 03:45:05 gw kernel: bug: kernel timer added twice at c01ba9a2.
> Apr 3 03:45:05 gw kernel: hda: no DRQ after issuing MULTWRITE
> Apr 3 03:45:05 gw kernel: ide0: reset: success
>
> System.map:
> c01ba940 T ide_set_handler
> c01ba9c0 T current_capacity
>
> 00:00.0 Host bridge: Intel Corp. 430HX - 82439HX TXC [Triton II] (rev 03)
> 00:01.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II] (rev 01)
> 00:01.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]
> 00:01.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II] (rev 01)
> 00:06.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
> 00:07.0 Ethernet controller: Intel Corp. 82557 [Ethernet Pro 100] (rev 02)
> 00:08.0 VGA compatible controller: S3 Inc. 86c764/765 [Trio32/64/64V+] (rev 54)
> 00:0b.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
>
> >From 2.4.19-pre3-ac4 (logs not saved from pre4-ac3, but can be reproduced
> upon request...):
>
> PIIX3: IDE controller on PCI bus 00 dev 09
> PIIX3: chipset revision 0
> PIIX3: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:pio, hdb:pio
> ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
> hda: WDC AC32500H, ATA DISK drive
> hdc: WDC AC32500H, ATA DISK drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hda: Disabling (U)DMA for WDC AC32500H
> hda: 4999680 sectors (2560 MB) w/128KiB Cache, CHS=620/128/63
> hdc: Disabling (U)DMA for WDC AC32500H
> hdc: 4999680 sectors (2560 MB) w/128KiB Cache, CHS=4960/16/63
>
On Thu, Apr 04, 2002 at 09:26:37PM -0800, Andre Hedrick wrote:
>
> Are you using "taskfile io" if so stop for now until I can give Alan a
> patch update. If you are not using "taskfile io" it means there is a new
> problem.
>
Yes I am.
I'm running the same kernel binary on another machine without any trouble.
So it's probably PIO mode that is triggering the problem. (As mentioned in
the 2.5 ide fla^W threads).
So, for now I'll just use the 19pre4-ac4 kernel instead on this machine
(drives don't support dma according to WIP list, and didn't work in dma mode
on nt4 either)
Mike
lspci for machine without trouble:
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev 02)
00:07.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 02)
00:0c.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 02)
00:0d.0 Ethernet controller: Intel Corp.: Unknown device 2459 (rev 08)
01:00.0 Display controller: Texas Instruments TVP4020 [Permedia 2] (rev 01)