Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
LOL, I'm in Sunnyvale, CA right now. I work for Ensim.Com. OK, here is all the technical info on my box. Sorry it took so long to respond. Had a department meeting to attend. MSI 694D Pro running Dual FC-PGA PIII-733 CPUs with 1GB of Corsair RAM. HDD is a Western Digital WDC300BB-00AU1 ATA100 drive (running it on the VIA controlled ATA33/66 controller since the kernel doesn't support the ATA100 very well.) Chipsets are the VIA VT82C686A and the Promise PDC20265 NIC is a NetGear FA-310TX Advansys UW SCSI Card Yamaha CRW8424S CDRW Voodoo3 2000 AGP 16MB AGP video card. APM/ACPI turned OFF in BIOS, NOT using the ATA100 controller Symptoms: Consistantly recurring kernel deaths resulting in hard lock of box. On Thu, 25 Jan 2001, Andre Hedrick wrote: > > Where the flip are you form this power starved portion of the world? > Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA > chipsets. > > What chipset or host is causing you the problem? > > VIA pr Promise? > > On Thu, 25 Jan 2001, David D.W. Downey wrote: > > > > > > > OK, I see you guys releasing patches for the AMD + VIA problem, but this > > problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s > > and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When > > are we going to see something for the MSI boards? > > > > My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset > > and the Promise PDC20265 ATA100 onbard controller. > > > > I need some sort of help with this. I'm getting kernel deaths left and > > right and no hope in sight here. > > > > I though it might possibly be a mix of SCSI + IDE causing troubles so I > > borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys > > SCSI card (not sure of the make offhand. I can find the box when I get > > home as I'm at work right now.) > > > > I would code up a fix if I knew what the hell I was doing when it came to > > coding which I do NOT. > > > > Vojtech, can you please work with me on this issue? Or if you are too > > busy, can you put me in contact with someone who can help? I've got a > > $3000 machine sitting here that I can not do a damn thing with until I > > stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation > > not at the kernel or anyone involved with the VIA stuff. Please don't take > > it that way.) > > > > David Downey > > > > > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > > > Andre Hedrick > Linux ATA Development > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
Where the flip are you form this power starved portion of the world? Also the subject is AMD and VIA chipsets not AMD CPU's running on VIA chipsets. What chipset or host is causing you the problem? VIA pr Promise? On Thu, 25 Jan 2001, David D.W. Downey wrote: > > > OK, I see you guys releasing patches for the AMD + VIA problem, but this > problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s > and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When > are we going to see something for the MSI boards? > > My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset > and the Promise PDC20265 ATA100 onbard controller. > > I need some sort of help with this. I'm getting kernel deaths left and > right and no hope in sight here. > > I though it might possibly be a mix of SCSI + IDE causing troubles so I > borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys > SCSI card (not sure of the make offhand. I can find the box when I get > home as I'm at work right now.) > > I would code up a fix if I knew what the hell I was doing when it came to > coding which I do NOT. > > Vojtech, can you please work with me on this issue? Or if you are too > busy, can you put me in contact with someone who can help? I've got a > $3000 machine sitting here that I can not do a damn thing with until I > stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation > not at the kernel or anyone involved with the VIA stuff. Please don't take > it that way.) > > David Downey > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Thu, Jan 25, 2001 at 01:54:36PM -0800, David D.W. Downey wrote: > > > OK, I see you guys releasing patches for the AMD + VIA problem, but this > problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s > and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When > are we going to see something for the MSI boards? > > My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset > and the Promise PDC20265 ATA100 onbard controller. > > I need some sort of help with this. I'm getting kernel deaths left and > right and no hope in sight here. > > I though it might possibly be a mix of SCSI + IDE causing troubles so I > borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys > SCSI card (not sure of the make offhand. I can find the box when I get > home as I'm at work right now.) > > I would code up a fix if I knew what the hell I was doing when it came to > coding which I do NOT. > > Vojtech, can you please work with me on this issue? Or if you are too > busy, can you put me in contact with someone who can help? I've got a > $3000 machine sitting here that I can not do a damn thing with until I > stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation > not at the kernel or anyone involved with the VIA stuff. Please don't take > it that way.) Sure, I'll need a more precise description, though. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
OK, I see you guys releasing patches for the AMD + VIA problem, but this problem is NOT just limited to the AMD problem. I'm using Intel PIII-733s and the VIA VT82C686A chipset. No AMD CPUs in ANY of my VIA boxes. When are we going to see something for the MSI boards? My board in particular is the MSI 694D Pro using the VIA VT82C686A chipset and the Promise PDC20265 ATA100 onbard controller. I need some sort of help with this. I'm getting kernel deaths left and right and no hope in sight here. I though it might possibly be a mix of SCSI + IDE causing troubles so I borrowed a 18GB SCSI drive from a buddy and attached it to my Advansys SCSI card (not sure of the make offhand. I can find the box when I get home as I'm at work right now.) I would code up a fix if I knew what the hell I was doing when it came to coding which I do NOT. Vojtech, can you please work with me on this issue? Or if you are too busy, can you put me in contact with someone who can help? I've got a $3000 machine sitting here that I can not do a damn thing with until I stop these blasted kernel deaths! (Yeah I'm pissed, but at the situation not at the kernel or anyone involved with the VIA stuff. Please don't take it that way.) David Downey - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Wed, Jan 24, 2001 at 01:58:09PM -0800, Andre Hedrick wrote: > In the past there were hardcoded timing values for the allowable for the > VIA cores that were defined by VIA. They were taken from their internal > lookup tables. You have stated that you have allowed for "slop" in the > timing to attempt to soften the driver, that is your decision you are > totally responsible for keeping that chipset alive. > > I suspect that you have not seen and know that you have not hear in person > the issues that arise for pushing or slacking the timing on the HOST side > of the world. However, I do expect that you understand that at slower > transfer rates you have a greater margin for error-tolerance. However the > game completely changes once Mode 3 and higher are used. The margins are > ever so narrow. Thus by following the exact letter and value you remove > suspect from the driver. You can always check the /proc/ide/via listing to check that the values are the same as in the specs. Actually there is not much to get wrong with UDMA timing - it's just one register's value on VIA chipsets. > Additionally with the auto_crc_downgrade feature now in 2.4.x if they only > get iCRC errors the main driver will force the transfer rate down to > stablize the timings. This was put in to correct for all the real crap > mainboards that everyone buys and expects them to work at full speed. > Well the do not, and fudging the timing tables to make crap work and > then cause ones that are within the tolerance of the cable skews is not > acceptable. You will continue to fight this battle and lose, but consider > doing so gracefully. > > Put the hardcoded timing values back in as default, and allow for the > option to use the dynamic fudged ones by the enduser. The default are > generally stable, the fudged ones I can not comment. There are no 'fudged' values. The values the chipset is programmed to, when the idebus= option is set to the default 33 MHz are exactly the same as in the specs. Really. I hope the auto_crc_downgrade will help things, at least on those drives, that don't crash their firmware in the case of a iCRCed transfer. Anyway, what about adding a XFER_UDMA_SLOW mode that would set the chipset to say 150 or 180 ns per UDMA cycle? At least AMD specs mention such a possibility. It's better than using MWDMA, and if XFER_UDMA_0 is still too fast for the drive, it'd be a good 'last fallback'. > Lastly the IDE-PCI clocking is independent of the FBS or PCI-Bus clocking. > The three timing ranges given by VIA for 25, 33, 41 are to morph the > IDE-PCI clock back to 33. Thus PCI-Bus of 25 increases cycle time to > achieve the 33, as the 41 reduces time to achieve the 33. I know what I > want to say, whether I did or not succeed is an issue. So if you do not > follow me (as most usually fail to follow me :-(( ) just ask. Yes. The IDE timing should be always the same, independent on the PCI clock. However, it is programmed in terms of PCI cycles, so yes, the only thing my driver does is exactly this compensation for the PCI speed so that the IDE timing stays constant. Yes, my driver is doing exactly what you say. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Wed, 24 Jan 2001, Vojtech Pavlik wrote: > On Wed, Jan 24, 2001 at 10:04:50AM -0800, Andre Hedrick wrote: > > > > Well, I know this. But I fear hardcoded timings won't really help here, > > > unless everyone out there ran their chipsets at 33 MHz, in which case the > > > > You have to run the ATA Chipset at 33MHz or it will fail in 99% of all > > cases. > > No. Though I'd advise everyone to stick with 33MHz PCI when they can > because it is safe. But even the VIA specs mention 25, 37.5 and 41.5 PCI > speeds. > > > This is not the FSB running at 66/83/100/133. So hardcode is > > correct. > > If you set a MVP3 or MVP4 chipset to 83 MHz FSB, you'll get 41.5 MHz > or 27.6 MHz PCI. And there are chips speced for 75 and 83 MHz FSB's - > Cyrix 6x86MX etc. > > No way to get 33 here, if you *don't* want to over/under-clock the CPU. Vojtech, In the past there were hardcoded timing values for the allowable for the VIA cores that were defined by VIA. They were taken from their internal lookup tables. You have stated that you have allowed for "slop" in the timing to attempt to soften the driver, that is your decision you are totally responsible for keeping that chipset alive. I suspect that you have not seen and know that you have not hear in person the issues that arise for pushing or slacking the timing on the HOST side of the world. However, I do expect that you understand that at slower transfer rates you have a greater margin for error-tolerance. However the game completely changes once Mode 3 and higher are used. The margins are ever so narrow. Thus by following the exact letter and value you remove suspect from the driver. Additionally with the auto_crc_downgrade feature now in 2.4.x if they only get iCRC errors the main driver will force the transfer rate down to stablize the timings. This was put in to correct for all the real crap mainboards that everyone buys and expects them to work at full speed. Well the do not, and fudging the timing tables to make crap work and then cause ones that are within the tolerance of the cable skews is not acceptable. You will continue to fight this battle and lose, but consider doing so gracefully. Put the hardcoded timing values back in as default, and allow for the option to use the dynamic fudged ones by the enduser. The default are generally stable, the fudged ones I can not comment. Oh and overclockers can goto hell on a bobsled for all I care because current scope as define by the top is that overclock is not the default case of use. Lastly the IDE-PCI clocking is independent of the FBS or PCI-Bus clocking. The three timing ranges given by VIA for 25, 33, 41 are to morph the IDE-PCI clock back to 33. Thus PCI-Bus of 25 increases cycle time to achieve the 33, as the 41 reduces time to achieve the 33. I know what I want to say, whether I did or not succeed is an issue. So if you do not follow me (as most usually fail to follow me :-(( ) just ask. Regards, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Wed, Jan 24, 2001 at 10:04:50AM -0800, Andre Hedrick wrote: > > Well, I know this. But I fear hardcoded timings won't really help here, > > unless everyone out there ran their chipsets at 33 MHz, in which case the > > You have to run the ATA Chipset at 33MHz or it will fail in 99% of all > cases. No. Though I'd advise everyone to stick with 33MHz PCI when they can because it is safe. But even the VIA specs mention 25, 37.5 and 41.5 PCI speeds. > This is not the FSB running at 66/83/100/133. So hardcode is > correct. If you set a MVP3 or MVP4 chipset to 83 MHz FSB, you'll get 41.5 MHz or 27.6 MHz PCI. And there are chips speced for 75 and 83 MHz FSB's - Cyrix 6x86MX etc. No way to get 33 here, if you *don't* want to over/under-clock the CPU. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, 21 Jan 2001, Vojtech Pavlik wrote: > On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote: > > > Vojtech, I worry that the dynamic timing that you are calculating could > > bite you. > > Well, I know this. But I fear hardcoded timings won't really help here, > unles everyone out there ran their chipsets at 33 MHz, in which case the You have to run the ATA Chipset at 33MHz or it will fail in 99% of all cases. This is not the FSB running at 66/83/100/133. So hardcode is correct. Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, 21 Jan 2001, Andre Hedrick wrote: > > > 1. Only a software guy would call it 'bounce'.. sounds funny ;-) > > Er...I help design some of the hardware and the rules, so I do more than > just software. So does 'echo' or 'reflections'sound better than 'bounce'? Yes. (I wasn't cracking on you.. the term just tickled my funny bone) -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
In another dimension, Andre Hedrick <[EMAIL PROTECTED]> remarked: > > > On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote: > > > 1. Only a software guy would call it 'bounce'.. sounds funny ;-) > > Er...I help design some of the hardware and the rules, so I do more than > just software. So does 'echo' or 'reflections'sound better than 'bounce'? EEs talk about ground bounce and the like all the time. "reflections" are also fine. "Signal integrity" is the in-the-know phrase. Of course, most of us weren't english majors, so noone really cares all that much how you say it. Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, 21 Jan 2001, Vojtech Pavlik wrote: > On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote: > > On Sun, 21 Jan 2001, Vojtech Pavlik wrote: > > > > > On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote: > > > > > > > chipset ---\ > > > > | > > > > \-IDC-header > > > > > > > > chipset ---+ > > > >| > > > >+--IDC-header > > > > > > > > These are nearly the same but the corners cause bounce and iCRC's > > > > I don't see how anyone can influence risetime falltime or impedance > > matching [1] issues via software timing changes. > > > > (the top drawing is what you see on a poorly designed board.. long > > rise/fall times often cause worse problems than [slight] ringing) > > > > > Well, there are other ways the motherboard maker can screw up the > > > traces, and often this happens: > > > > > > chipset \ > > > | > > > chipset --\ | > > > | \-- header > > > \ header > > > > > > > Can you compensate for these things (to any degree?) in software? > > Not really. Slowing the data rate down is in my opinion the only way to > compensate for this. Btw, the chipset only controls the write data rate > with UDMA. The read rate is controlled by the drive. > > > 1. Only a software guy would call it 'bounce'.. sounds funny ;-) Er...I help design some of the hardware and the rules, so I do more than just software. So does 'echo' or 'reflections'sound better than 'bounce'? Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, Jan 21, 2001 at 01:42:41PM +0100, Mike Galbraith wrote: > On Sun, 21 Jan 2001, Vojtech Pavlik wrote: > > > On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote: > > > > > chipset ---\ > > > | > > > \-IDC-header > > > > > > chipset ---+ > > >| > > >+--IDC-header > > > > > > These are nearly the same but the corners cause bounce and iCRC's > > I don't see how anyone can influence risetime falltime or impedance > matching [1] issues via software timing changes. > > (the top drawing is what you see on a poorly designed board.. long > rise/fall times often cause worse problems than [slight] ringing) > > > Well, there are other ways the motherboard maker can screw up the > > traces, and often this happens: > > > > chipset \ > > | > > chipset --\ | > > | \-- header > > \ header > > > > Can you compensate for these things (to any degree?) in software? Not really. Slowing the data rate down is in my opinion the only way to compensate for this. Btw, the chipset only controls the write data rate with UDMA. The read rate is controlled by the drive. > 1. Only a software guy would call it 'bounce'.. sounds funny ;-) -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, Jan 21, 2001 at 10:46:06AM +0100, Vojtech Pavlik wrote: > Ok, the VIA driver from clean 2.2.18 does nothing. It doesn't even use > hardcoded timings. It doesn't touch any timing tables. It just blindly > enables prefetch and writeback in the chips. The thing works because it > relies on BIOS to set things up correctly, and this is often the case, > yes. If BIOS is often correct: Is it possible to read these values and compare them to the values linux calculates? If both match: OK, continue. If they are different: Either BIOS or linux is wrong, print a warning and disable DMA (or go to some other kind of 'safe mode'). Just an idea, I don't know anything about chipsets and IDE timings ;-) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, Jan 21, 2001 at 10:51:12AM +, Alan Chandler wrote:
> On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:
>
>
> >that's not the topic: Andre's talking about pci-clock-based timing
> >constants the the driver programs into the ide controller - a matter
> >of an extra few/more nanoseconds.
>
> I know, but when looking hard for a problem in one place and not
> finding it, it is sometimes helpful to consider other options.
>
> I am getting errors under 2.4.0 which didn't appear in 2.2.17 - and as
> far as I could see from hdparm - both were at UDMA mode 2 (I assume
> thats what the * means - the man page wasn't very clear). My drives
> only handle up to this mode, and I was wondering if the new driver was
> trying to run them at a mode higher than they were supposed to go.
>
> This massive difference in timing seemed significant.
No, but to me it seems that even though UDMA2 mode is selected in the
drive in 2.2.17 (that's what the * means), the kernel doesn't use DMA,
and thus everything works in PIO4. This would well explain the speed
difference.
> >quite slow in either case, at least for modern hardware (which is
> >all in the 20-40 MB/s range). this looks like a PIO vs DMA difference
> >to me, not even UDMA. of course, hdparm can tell you what mode you're in.
>
> I did discover a difference - 2.2.17 set the drives with multisector
> off, 2.4.0 was setting multisector on.
Multisector is valid only in PIO modes. If both were doing some kind of
DMA, it wouldn't change anything.
> However, I have redone the
> timing with multisector turned on in the 2.2.17 case and the
> difference is still there.
>
> Under 2.2.17 with multisector turned on
>
>
> /dev/hda:
>
> Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
> BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
> MultSect=16
> DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
> tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
> mword2
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
> UDMA modes: mode0 mode1 *mode2
>
> --
>
> /dev/hda:
> Timing buffered disk reads: 64 MB in 19.88 seconds = 3.22 MB/sec
>
>
> Under 2.4.0
>
>
> /dev/hda:
>
> Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
> Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
> RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
> BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
> MultSect=16
> DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
> CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
> tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
> mword2
> IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
> UDMA modes: mode0 mode1 *mode2
>
> --
>
> /dev/hda:
> Timing buffered disk reads: 64 MB in 6.58 seconds = 9.73 MB/sec
>
>
>
> I don't suppose the fact that my hdparm is oldish (3.6 I think) have
> any bearing on this?
No, 3.6 is OK I think.
--
Vojtech Pavlik
SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, 20 Jan 2001 20:18:34 -0500 (EST), you wrote:
>that's not the topic: Andre's talking about pci-clock-based timing
>constants the the driver programs into the ide controller - a matter
>of an extra few/more nanoseconds.
I know, but when looking hard for a problem in one place and not
finding it, it is sometimes helpful to consider other options.
I am getting errors under 2.4.0 which didn't appear in 2.2.17 - and as
far as I could see from hdparm - both were at UDMA mode 2 (I assume
thats what the * means - the man page wasn't very clear). My drives
only handle up to this mode, and I was wondering if the new driver was
trying to run them at a mode higher than they were supposed to go.
This massive difference in timing seemed significant.
>
>quite slow in either case, at least for modern hardware (which is
>all in the 20-40 MB/s range). this looks like a PIO vs DMA difference
>to me, not even UDMA. of course, hdparm can tell you what mode you're in.
>
I did discover a difference - 2.2.17 set the drives with multisector
off, 2.4.0 was setting multisector on. However, I have redone the
timing with multisector turned on in the 2.2.17 case and the
difference is still there.
Under 2.2.17 with multisector turned on
/dev/hda:
Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
MultSect=16
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
mword2
IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 *mode2
--
/dev/hda:
Timing buffered disk reads: 64 MB in 19.88 seconds = 3.22 MB/sec
Under 2.4.0
/dev/hda:
Model=IBM-DHEA-38451, FwRev=HP8OA20C, SerialNo=SH0SH0X1795
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=28
BuffType=3(DualPortCache), BuffSize=472kB, MaxMultSect=16,
MultSect=16
DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=16514064
tDMA={min:120,rec:120}, DMA modes: sword0 sword1 sword2 mword0 mword1
mword2
IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4
UDMA modes: mode0 mode1 *mode2
--
/dev/hda:
Timing buffered disk reads: 64 MB in 6.58 seconds = 9.73 MB/sec
I don't suppose the fact that my hdparm is oldish (3.6 I think) have
any bearing on this?
Alan
[EMAIL PROTECTED]
http://www.chandler.u-net.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, Jan 20, 2001 at 02:57:07PM -0800, Andre Hedrick wrote: > Vojtech, I worry that the dynamic timing that you are calculating could > bite you. Well, I know this. But I fear hardcoded timings won't really help here, unles everyone out there ran their chipsets at 33 MHz, in which case the calculation gains the exact same results (you can compare that) as the hardcoded numbers for UDMA timings. > Timings are exact especially at modes 3/4/5 the margins go to > an effective zero for varition or wiggle room. The state diagrams from > Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it > constrained. You need to assume absolutes because the various board > makers screw up the skew tables by the PCB lane traces. > > By assuming only absolutes, all vendors that do bad designs will show and > the user can not and "should" not be allowed to hold the driver in a state > that can damage filesystems or lock the box. Since I have never addressed > this issue in public it is no obvious why I hardcoded timings and did not > let tehm float, but I hope it is clearer now. Ok, the VIA driver from clean 2.2.18 does nothing. It doesn't even use hardcoded timings. It doesn't touch any timing tables. It just blindly enables prefetch and writeback in the chips. The thing works because it relies on BIOS to set things up correctly, and this is often the case, yes. > chipset ---\ > | > \-IDC-header > > chipset ---+ >| >+--IDC-header > > These are nearly the same but the corners cause bounce and iCRC's Well, there are other ways the motherboard maker can screw up the traces, and often this happens: chipset \ | chipset --\ | | \-- header \ header So the different traces have different lengths and thus some bits arrive earlier than others to the header, causing the same CRC errors. Also it seems that some boards don't use exactly 33.3 MHz PCI clock, but something like 33.7 or even more, which causes some drives to fail with them if the chipset is set to the 0xe0 (2 pciclk/ideclk) value. This is because they use very cheap base 14MHz crystals. As I said before - if you leave 'idebus' at 33, the calculated timings are exactly the same as the hardcoded values would be (I think there is a difference in PIO2 mode, where the calculation gives a slightly larger active time and shorter recovery, but this is OK with the specs). And this is also why the cheaply made motherboards fail. (They don't care to make that VIA UDMA66 ide working correctly when they have a UDMA100 HPT370 onboard)? ... btw, if we ever implement UDMA slowdown code based on CRC errors, we should differentiate between CRC errors on read and CRC errors on write, because each are caused by a different problem ... -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, 20 Jan 2001 14:57:07 -0800 (PST), Andre Hedrick wrote: ... > >Vojtech, I worry that the dynamic timing that you are calculating could >bite you. Timings are exact especially at modes 3/4/5 the margins go to >an effective zero for varition or wiggle room. The state diagrams from >Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it >constrained. You need to assume absolutes because the various board >makers screw up the skew tables by the PCB lane traces. > I am not sure this is just a question of small variations. The hdparm -t differences between these two versions is quite significant. This evidence would imply that the two approaches are making fundemental different decisions about what my hardware can do! Under 2.2.17 /dev/hda: Timing buffered disk reads: 64 MB in 21.86 seconds = 2.93 MB/sec /dev/hdc: Timing buffered disk reads: 64 MB in 20.81 seconds = 3.08 MB/sec Under 2.4.0 /dev/hda: Timing buffered disk reads: 64 MB in 6.58 seconds = 9.73 MB/sec /dev/hdc: Timing buffered disk reads: 64 MB in 6.59 seconds = 9.71 MB/sec Alan [EMAIL PROTECTED] http://www.chandler.u-net.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, 20 Jan 2001, Vojtech Pavlik wrote: > On Sat, Jan 20, 2001 at 06:45:10PM +, Alan Chandler wrote: > > On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: > > > > >On Sat, 20 Jan 2001, Alan Chandler wrote: > > > > > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM > > >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only > > >> do UDMA mode 2. I am not overclocking or anything - all should be > > >> running at default speeds with an Athlon 900. > > >> > > >> Just to be clear - I am NOT getting any errors when I switch back to > > >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur > > >> every few minutes when there is significant disk activity. > > > > > >But that kernel uses the stock driver that was the original second > > >generation correct? > > > > > >Andre Hedrick > > >Linux ATA Development > > > > > > > Sorry, I realise now what I said was ambiguous. To be clear > > > > 2.2.17 - absolutely standard as shipped in debian - no errors This is with the original ide.2.2.17.??.date.patch and not the morfing timing code you have started. > > 2.4.0 - standard (downloaded tar.bz2) - ERRORS > > 2.4.0 - as standard except for three files in tar.bz2 attachment to > > Vojtech Pavlik's mail which were placed in drivers/ide directory - > > ERRORS. > > Alan > > Wonderful! A case where I can compare a working setup with a nonworking > one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx, > cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the > 2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the > differences and possibly fix the new driver. Vojtech, I worry that the dynamic timing that you are calculating could bite you. Timings are exact especially at modes 3/4/5 the margins go to an effective zero for varition or wiggle room. The state diagrams from Quantum that created the Ultra DMA 0,1,2,3,4,5 show how darn tight it constrained. You need to assume absolutes because the various board makers screw up the skew tables by the PCB lane traces. By assuming only absolutes, all vendors that do bad designs will show and the user can not and "should" not be allowed to hold the driver in a state that can damage filesystems or lock the box. Since I have never addressed this issue in public it is no obvious why I hardcoded timings and did not let tehm float, but I hope it is clearer now. chipset ---\ | \-IDC-header chipset ---+ | +--IDC-header These are nearly the same but the corners cause bounce and iCRC's Cheers, Andre Hedrick Linux ATA Development - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sat, Jan 20, 2001 at 06:45:10PM +, Alan Chandler wrote: > On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: > > >On Sat, 20 Jan 2001, Alan Chandler wrote: > > > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM > >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only > >> do UDMA mode 2. I am not overclocking or anything - all should be > >> running at default speeds with an Athlon 900. > >> > >> Just to be clear - I am NOT getting any errors when I switch back to > >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur > >> every few minutes when there is significant disk activity. > > > >But that kernel uses the stock driver that was the original second > >generation correct? > > > >Andre Hedrick > >Linux ATA Development > > > > Sorry, I realise now what I said was ambiguous. To be clear > > 2.2.17 - absolutely standard as shipped in debian - no errors > 2.4.0 - standard (downloaded tar.bz2) - ERRORS > 2.4.0 - as standard except for three files in tar.bz2 attachment to > Vojtech Pavlik's mail which were placed in drivers/ide directory - > ERRORS. > Alan Wonderful! A case where I can compare a working setup with a nonworking one! :) Could you please send me the usual stuff (dmesg, lspci -vvxxx, cat /proc/ide/via, hdparm -i /dev/hd*, hdparm -t /dev/hd*) for both the 2.2 case and the 2.4.0+VIA-latest case? That'll allow me to find the differences and possibly fix the new driver. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Thu, 20 Jan 2011 09:51:03 -0800 (PST), you wrote: >On Sat, 20 Jan 2001, Alan Chandler wrote: > >> I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM >> deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only >> do UDMA mode 2. I am not overclocking or anything - all should be >> running at default speeds with an Athlon 900. >> >> Just to be clear - I am NOT getting any errors when I switch back to >> the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur >> every few minutes when there is significant disk activity. > >But that kernel uses the stock driver that was the original second >generation correct? > >Andre Hedrick >Linux ATA Development > Sorry, I realise now what I said was ambiguous. To be clear 2.2.17 - absolutely standard as shipped in debian - no errors 2.4.0 - standard (downloaded tar.bz2) - ERRORS 2.4.0 - as standard except for three files in tar.bz2 attachment to Vojtech Pavlik's mail which were placed in drivers/ide directory - ERRORS. Alan [EMAIL PROTECTED] http://www.chandler.u-net.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[preview] Latest AMD & VIA IDE drivers with UDMA100 support
on Fri Jan 19 2001 - 10:56:10 EST Vojtech Pavlik ([EMAIL PROTECTED]) wrote > ... >I'm sending you (and others who might be interested) my latest VIA and >IDE drivers. The VIA driver (v3.15) should have a complete support for >UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full >UDMA100 support on the amd766 ViperPlus chip. > > >They're also a little more foolproof with respect to the 'idebus' >setting, which is quite a misnomer, btw. > > >Care to try them out? If by "trying them out" you mean dropping them in the drivers/ide subdirectory of the 2.4.0 source and rebuilding the kernel, then they still cause my machine to give CRC errors. I'm running with an Abit K7 (uses via82c686a in southbridge) with IBM deskstar 8.4gb disks (DHEA-38451) as masters in ide0 and 1. They only do UDMA mode 2. I am not overclocking or anything - all should be running at default speeds with an Athlon 900. Just to be clear - I am NOT getting any errors when I switch back to the 2.2.17 kernel (debian standard) - with a 2.4.0 kernel they occur every few minutes when there is significant disk activity. Alan [EMAIL PROTECTED] http://www.chandler.u-net.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[preview] Latest AMD & VIA IDE drivers with UDMA100 support
Hi Andre! I'm sending you (and others who might be interested) my latest VIA and IDE drivers. The VIA driver (v3.15) should have a complete support for UDMA100 on the vt82c686b chip, the AMD driver (v1.5) should have full UDMA100 support on the amd766 ViperPlus chip. They're also a little more foolproof with respect to the 'idebus' setting, which is quite a misnomer, btw. Care to try them out? Andre, you're the only one I know of having the 766 chip, so please test this driver, I'd like to know if it really works ... thanks. -- Vojtech Pavlik SuSE Labs via-amd-ide.tar.bz2
