Re: UPDATE2: ATA mkIII first official patches - please test!
Søren Schmidt [EMAIL PROTECTED] wrote: Søren Schmidt wrote: [...] New version available for testing: http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz http://people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. What is the plan on this? If I test, then I have a one-off - is this something that if it passes will be MFC'd back into STABLE, is it slated as an optional ATA driver set (e.g. choose at kernel build time), or??? I have problems with some SATA boards taking write errors, but not the onboard motherboard controllers on two systems I have here. The PCI cards, however, do it reliably. These boards worked well under 4.x, and so for me anyway 5.x is a step backward in this regard. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netMy home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://www.spamcuda.net SPAM FREE mailboxes - FREE FOR A LIMITED TIME! http://genesis3.blogspot.comMusings Of A Sentient Mind ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Le Jeudi 17 fvrier 2005 10:32 +0100, Sren Schmidt a crit : Sren Schmidt wrote: New version available for testing: http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz http://people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. ata-mk3l works fine on my computer except still dumping (call doadump under DDB). I retried without your patches with RELENG_5 kernel and call doadump works. I remind also that a long ago I had to do like David O'Brien, commenting flushcache commands on shutdown in order to dump when kernel panics. Ask me if you need more information than precedent post or want me to try patches. Anthony. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
On Thu, 17 Feb 2005 10:32:51 +0100 Sren Schmidt [EMAIL PROTECTED] wrote: Sren Schmidt wrote: [...] New version available for testing: http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz http://people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. Hello, I tried this on a freshly downloaded RELENG_5_3 src tree and got the following: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/ata/ata-card.c /usr/src/sys/dev/ata/ata-card.c:56: error: `PCMCIA_PRODUCT_IODATA3_CBIDE2' undeclared here (not in a function) /usr/src/sys/dev/ata/ata-card.c:56: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:56: error: (near initialization for `ata_pccard_products[2].pp_product') /usr/src/sys/dev/ata/ata-card.c:56: error: `PCMCIA_CIS_IODATA3_CBIDE2' undeclared here (not in a function) /usr/src/sys/dev/ata/ata-card.c:56: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:56: error: (near initialization for `ata_pccard_products[2].pp_cis') /usr/src/sys/dev/ata/ata-card.c:56: error: initializer element is not constant /usr/src/sys/dev/ata/ata-card.c:56: error: (near initialization for `ata_pccard_products[2]') ... and a lot more err. Since I am not too skilled doing things like this my apologies was this a false alarm. I did this on a 5.3beta7 system that I am forced to use due to interrupt problems with my SiI 3112 SATA150 controller and Samsung drive, I earlier reported. (B7 exhibits TIMEOUT - WRITE_DMA retrying but the system, despite frequent being stalled for seconds, still usable.) So after downloading RELENG_5_3 source tree in the /usr/src I untarred ata-mk3l.tar.gz and also here applied patch ata-mk3l.diff-releng5.gz (both file being the latest, the latter a plain text file despite its name). Patching went OK. After buildworld done, buildkernel failed as above. Could you help me how to overcome this? Thank you! Zsolt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
In article [EMAIL PROTECTED] Søren Schmidt [EMAIL PROTECTED] writes: New version available for testing: http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz http://people.freebsd.org/~sos/ata-mk3l.tar.gz o Add modules for atacard and atacbus Modules for pc98 are still broken because modules/ata/Makefile.inc is missing. See my patch. o Fix the current/real geometry handling for CHS mode. The problem is fixed. Thanks. --- TAKAHASHI Yoshihiro [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
On Thu, Feb 17, 2005 at 10:32:51AM +0100, S?ren Schmidt wrote: S S?ren Schmidt wrote: S S New version available for testing: S S http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz S http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz S http://people.freebsd.org/~sos/ata-mk3l.tar.gz S S Items in this release: S S o Fix ATA/ATAPI requests from userland. S o Cleanup the attach/detach code further. Great work! At the first blush my problem with panic on attach/detach has been fixed. Thanks. -- With respect, Pizik Ilya. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
My problem persist... Any other patch? or idea? Regards -- # dmesg | egrep -i (ata|ad0) -- atapci0: VIA 82C686A UDMA66 controller port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 ad0: FAILURE - SET_MULTI status=51READY,DSC,ERROR error=4ABORTED ad0: 9787MB QUANTUM FIREBALLlct20 10 APL.0900 at ata0-master UDMA66 ATA PseudoRAID loaded Mounting root from ufs:/dev/ad0s1a ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17968511 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17968991 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17969375 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17971135 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17971763 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17971935 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17972127 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17975551 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17975551 ad0: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=17975551 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17977343 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17978303 ad0: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=17978303 ad0: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=17978303 -- -- # pciconf -lv -- [EMAIL PROTECTED]:7:1: class=0x01018a card=0x chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82 EIDE Controller (All VIA Chipsets)' class= mass storage subclass = ATA -- Søren Schmidt wrote: Søren Schmidt wrote: http://people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3k.diff-current.gz http://people.freebsd.org/~sos/ata-mk3k.tar.gz New version available for testing: http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz http://people.freebsd.org/~sos/ata-mk3l.tar.gz -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Marcus Grando wrote: My problem persist... Any other patch? or idea? Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
[EMAIL PROTECTED] wrote: Marcus Grando wrote: My problem persist... Any other patch? or idea? Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... Just an observation, but my Promise ATA-100 controller will drive 1 UDMA-66 and one UDMA-100 disk fine at UDMA-33 with the cable on the wrong way round (oops) using the previous update. Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Marcus Grando wrote: My problem persist... Any other patch? or idea? Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... Just an observation, but my Promise ATA-100 controller will drive 1 UDMA-66 and one UDMA-100 disk fine at UDMA-33 with the cable on the wrong way round (oops) using the previous update. Well, the problem with wrong way around is that determining what the cable is fails in unpredictable ways, as long as your transfer rates are reduced there is no problems. However if a higher transferate is used than the cable is spec'd for you get ICRC errors as this was originally about. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Hi Søren Schmidt wrote: Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... I test all combinations (with/without apic | with/without ACPI), and problems persist. It will be that the problem is not with the compatibility of the controller with my HD? I changed 3 times the cable. I don't think that cable is problem. -- # atacontrol cap 0 0 -- ATA channel 0, Master, device ad0: Protocol ATA/ATAPI revision 5 device model QUANTUM FIREBALLlct20 10 serial number 551110736472 firmware revision APL.0900 cylinders 16383 heads 16 sectors/track 63 lba supported 20044080 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes yes read ahead yes yes Tagged Command Queuing (TCQ) no no 0/0x00 SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 0/0x00 automatic acoustic management yes no 0/0x00 0/0x00 -- -- controller -- atapci0: VIA 82C686A UDMA66 controller port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x chip=0x05711106 rev=0x06 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82 EIDE Controller (All VIA Chipsets)' class= mass storage subclass = ATA -- -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Marcus Grando wrote: Hi Søren Schmidt wrote: Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... I test all combinations (with/without apic | with/without ACPI), and problems persist. OK. It will be that the problem is not with the compatibility of the controller with my HD? Have you tried other disks on this board ? Have you tried this disk on another board ? Is the disk in a drawer/enclosure of sorts ? I changed 3 times the cable. I don't think that cable is problem. Depends, you need proper 80 conductor cables no longer than 45cm's, the blue connector goes at the controller end, and the black/grey goes on the master/slave device. ICRC errors are because the checksum on the data does match, which means that the communication path between disk and controller is malfunctioning. The usual suspect is the cable, but it can also be bad or loose connectors, or a flaky/unstable PSU. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Hi, Søren Schmidt wrote: Have you tried other disks on this board ? I test another disk (SAMSUNG SV8004H) in secondary and work with UDMA66. Have you tried this disk on another board ? I have another computer with 4.11-STABLE / QUANTUM FIREBALLlct10 30 and occurs same problem. -- ad0s1g: UDMA ICRC error writing fsbn 29286847 of 4391104-4391263 (ad0s1 bn 29286847; cn 29054 tn 6 sn 37) retrying ad0s1g: UDMA ICRC error writing fsbn 37273791 of 8384576-8384607 (ad0s1 bn 37273791; cn 36977 tn 15 sn 30) retrying ad0s1g: UDMA ICRC error writing fsbn 93610575 of 36552968-36552971 (ad0s1 bn 93610575; cn 92867 tn 10 sn 9) retrying -- Is the disk in a drawer/enclosure of sorts ? No, disk connected directly on cable. It will be that the problem is not with all FIREBALL QUANTUM? Because all my FIREBALL QUANTUM have this problem. -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Marcus Grando wrote: I test another disk (SAMSUNG SV8004H) in secondary and work with UDMA66. OK, so the problem is not general of nature... Have you tried this disk on another board ? I have another computer with 4.11-STABLE / QUANTUM FIREBALLlct10 30 and occurs same problem. -- ad0s1g: UDMA ICRC error writing fsbn 29286847 of 4391104-4391263 (ad0s1 bn 29286847; cn 29054 tn 6 sn 37) retrying ad0s1g: UDMA ICRC error writing fsbn 37273791 of 8384576-8384607 (ad0s1 bn 37273791; cn 36977 tn 15 sn 30) retrying ad0s1g: UDMA ICRC error writing fsbn 93610575 of 36552968-36552971 (ad0s1 bn 93610575; cn 92867 tn 10 sn 9) retrying It will be that the problem is not with all FIREBALL QUANTUM? Because all my FIREBALL QUANTUM have this problem. Hmm, I newer thought much about the Fireball's but they should work as such, however there are other examples of those not getting along. Do they work if you run them at UDMA33 ? in that case leave them there.. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Hi, On Thu, 17 Feb 2005, 10:32+0100, S?ren Schmidt wrote: S?ren Schmidt wrote: http: //people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http: //people.freebsd.org/~sos/ata-mk3k.diff-current.gz http: //people.freebsd.org/~sos/ata-mk3k.tar.gz New version available for testing: http: //people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http: //people.freebsd.org/~sos/ata-mk3l.diff-current.gz http: //people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. atadisk.ko and atapicd.ko still do not depend on atapci.ko. So if you don't ask to load atapci.ko in loader.conf you will get a panic because the kernel won't find the root fs. I added MODULE_DEPEND() on atapci macro to ata-disk.c and this solved the problem. Perhaps this is just a feature. -- Maxim Konovalov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Maxim Konovalov wrote: Hi, On Thu, 17 Feb 2005, 10:32+0100, S?ren Schmidt wrote: S?ren Schmidt wrote: http: //people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http: //people.freebsd.org/~sos/ata-mk3k.diff-current.gz http: //people.freebsd.org/~sos/ata-mk3k.tar.gz New version available for testing: http: //people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http: //people.freebsd.org/~sos/ata-mk3l.diff-current.gz http: //people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. atadisk.ko and atapicd.ko still do not depend on atapci.ko. So if you don't ask to load atapci.ko in loader.conf you will get a panic because the kernel won't find the root fs. I added MODULE_DEPEND() on atapci macro to ata-disk.c and this solved the problem. Perhaps this is just a feature. Yes its a feature, if you make everything depend on each other there is no reason to have it as seperate modules... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
atadisk.ko and atapicd.ko still do not depend on atapci.ko. So if you don't ask to load atapci.ko in loader.conf you will get a panic because the kernel won't find the root fs. I added MODULE_DEPEND() on atapci macro to ata-disk.c and this solved the problem. Perhaps this is just a feature. MODULE_DEPEND should only be there when when there's a link time dependency between modles. If you were to add the atapci.ko as a depend, then you destroy the ability to boot on machines that don't have a pci bus in the kernel Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
