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!
On Thu, 17 Feb 2005 10:32:51 +0100 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. 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 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 fÃvrier 2005 Ã 10:32 +0100, SÃren Schmidt a Ãcrit : > 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. 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!
> 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]"
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!
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!
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, 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: 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: 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: 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!
[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!
[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!
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!
My problem persist... Any other patch? or idea? Regards -- # dmesg | egrep -i "(ata|ad0)" -- atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 ad0: FAILURE - SET_MULTI status=51 error=4 ad0: 9787MB 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=51 error=84 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=51 error=84 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!
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!
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: UPDATE: ATA mkIII first official patches - please test!
Andrew Heybey <[EMAIL PROTECTED]> writes: > ATA mkIII has improved my Toshiba Tecra M2V running RELENG_5. > > Before, it would complain about "ATAPI_IDENTIFY TIMED OUT" on > ata1-slave (the cdrom is ata1-master) when booting (but still would > work). Even worse, when resuming from a memory suspend (S3) it would > lose ad0 and hence crash, with messages on the console: > > ad0: FAILURE - ATA_IDENTIFY timed out > ad0: WARNING - removed from configuration > > With mkIII, it now works fine: no complaints when booting and suspend/resume > to memory works. Interesting! The IBM TPX40 exhibits the above resume behaviour when using "device apic", but not without apic when running 5.3-RELEASE. Bengt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UPDATE2: ATA mkIII first official patches - please test!
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. Items in this release: o Fix ATA/ATAPI requests from userland. o Cleanup the attach/detach code further. o Add modules for atacard and atacbus o Fix the current/real geometry handling for CHS mode. o Add the ioctl interface back to ata-raid.c. o Update the ioctl API to match new RAID levels etc. o Add the infrastructure to allow create/delete/status of ATA RAID arrays. NOTE only Promise and FreeBSD Pseudo RAIDs supported at this time. o Update atacontrol to know about the new RAID levels etc NOTE: you need to recompile atacontrol with the new sys/ata.h, make world will take care of that. One warning applies to both this and the last snapshot. I accidentially released the RAID5 test code I had in there which allows to apparently use a RAID5 array. However it *ONLY* reads and writes the data part, it does *NOT* maintain the parity part. That means it will trash a RAID5 array for later real use as the parity wont match the data one there. Since the code is "out there" I've decided to let it stay, as it allows for testing of getting and using the metadata etc.. As usual use at your own risk, but feedback on this is very welcomed. Big thanks to all those that has participated so far! I'll be mostly AFK for the next two weeks on needed vacation, so dont panic if I dont respond as quickly as usual. Enjoy! -- -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: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> "M. Warner Losh" <[EMAIL PROTECTED]> writes: > I see. Let me see if I understand the implications: > > (1) This disk won't interoperate with other OSes on the pc98 > machine because the pc98 partition format specifies things > in terms of CHS, but doesn't specify an actual geometry. I don't test it yet, but I think it is no problem if right geometry translation is done. > (2) Further, since dp_scyl and dp_ecyl are both 16bits, we are > limited to 65535 cylinders. The above geometry of 387621 > violates this assumption. So you can really only use > 66059280 of the 390721968 sectors on this disk (or about 17%). I tried to use the disk with 16H/63S geometry but I cannot at all. It seems that the fdisk and/or disklabel write to strange place. > (3) It is insufficent to fix this in geom_pc98 because that is > not used until after the partition is placed on the disk > and fdisk_pc98 needs the geometry to place that partition. Yes. > (4) This only impacts newer ATA6 disks. ATA5 and older appear > to be working properly. ata6 disks need some other > mechanism to get this information, correct? Probably... I am sure that ATA6 disks at least need to get a geometry information from PC98 BIOS. > When I asked about the 'get the geometry from the BIOS' patches that > are circulating, I was told that it was hard to match the FreeBSD > device to the BIOS table. I think that it is hard to get a right geometry in all cases, many extended ATA cards are used, but it succeeds mostly. --- 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: UPDATE: ATA mkIII first official patches - please test!
On Thu, 10 Feb 2005 14:41:10 +0100, Søren Schmidt <[EMAIL PROTECTED]> wrote: > Freddie Cash wrote: > >>New version that fixes known problems so far etc now available: > > > > > > Just curious if this includes support for new chipsets or not. Not a > > big deal if it doesn't, just curious. > > > > I've got a Toshiba laptop that, unfortunately, uses the ATI IGP/IXP > > chipset, which only gets detected as UDMA33 (which is fine for my > > uses, so I'm not complaining). If this is supported, I'd be more than > > willing to lose ATAPICAM support to use it. :) > > Its not (yet) as I dont have any such HW here yet. I would like to get involved in adding some support. I've looked over the Linux 2.4 patch to add support for the ATI RS300 chipset (I've added the link to the PR on this issue). Most of the patch is adding feature display stuff, and the key bits are pretty small. But where do the chipset specifiic interfaces in FreeBSD reside? Can you provide any advice? Also, do you want a ATI RS300 chipset based system? Would an ASUS Pundit-R barebones unit (just a case and mb) be sufficent? > -- > > -Søren > Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
ATA mkIII has improved my Toshiba Tecra M2V running RELENG_5. Before, it would complain about "ATAPI_IDENTIFY TIMED OUT" on ata1-slave (the cdrom is ata1-master) when booting (but still would work). Even worse, when resuming from a memory suspend (S3) it would lose ad0 and hence crash, with messages on the console: ad0: FAILURE - ATA_IDENTIFY timed out ad0: WARNING - removed from configuration With mkIII, it now works fine: no complaints when booting and suspend/resume to memory works. Thanks Søren, andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
In message: <[EMAIL PROTECTED]> Takahashi Yoshihiro <[EMAIL PROTECTED]> writes: : In article <[EMAIL PROTECTED]> : Warner Losh <[EMAIL PROTECTED]> writes: : : > > The following is the result when use SATA 200GB disk on pc98. It is : > > clearly that recognizing a geometry fails. : > > : > > atapci0: port 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 : > > ad4: ATA-6 disk at ata2-master : > > ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B : > > ad4: 16 secs/int, 1 depth queue, SATA150 : > > : > > BIOS Geometries: : > > 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors : > : > Is this the geometry that the PC98 BIOS uses? : : Yes. I see. Let me see if I understand the implications: (1) This disk won't interoperate with other OSes on the pc98 machine because the pc98 partition format specifies things in terms of CHS, but doesn't specify an actual geometry. (2) Further, since dp_scyl and dp_ecyl are both 16bits, we are limited to 65535 cylinders. The above geometry of 387621 violates this assumption. So you can really only use 66059280 of the 390721968 sectors on this disk (or about 17%). (3) It is insufficent to fix this in geom_pc98 because that is not used until after the partition is placed on the disk and fdisk_pc98 needs the geometry to place that partition. (4) This only impacts newer ATA6 disks. ATA5 and older appear to be working properly. ata6 disks need some other mechanism to get this information, correct? When I asked about the 'get the geometry from the BIOS' patches that are circulating, I was told that it was hard to match the FreeBSD device to the BIOS table. Do I understand things correctly? Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> Warner Losh <[EMAIL PROTECTED]> writes: > > The following is the result when use SATA 200GB disk on pc98. It is > > clearly that recognizing a geometry fails. > > > > atapci0: port > > 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem > > 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 > > ad4: ATA-6 disk at ata2-master > > ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B > > ad4: 16 secs/int, 1 depth queue, SATA150 > > > > BIOS Geometries: > > 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors > > Is this the geometry that the PC98 BIOS uses? Yes. --- 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: UPDATE: ATA mkIII first official patches - please test!
From: Takahashi Yoshihiro <[EMAIL PROTECTED]> Subject: Re: UPDATE: ATA mkIII first official patches - please test! Date: Tue, 15 Feb 2005 21:08:05 +0900 (JST) > In article <[EMAIL PROTECTED]> > Søren Schmidt <[EMAIL PROTECTED]> writes: > > > >>>2. A geometry translation for pc98 is NOT enough. > > >>> > > >>> Currently, it works only under 4.3GB disk. > > > > Wrong, ATA mk3 does solve the problem but using the "current" geomtry > > set in the drives by the BIOS. However the code missed it in one place > > in ata-lowlevel.c when the code was moved there from ata-disk.c. > > This has been fixed and will be present in the next snapshot as I sadi > > earlier. > > > ATA-mkIII does NOT completely solve the problem. > > The word 54-58 of the IDENTIFY DEVICE parameter are valid only up to > ATA/ATAPI-5. They are obsolete parameters in ATA/ATAPI-6 and later. > So using them for a geometry translation has NO effect for recent > disks. That would explain why all the disks that I tried worked with the IDENTIFY DEVICE patches I posted elsewhere (from 1.6G to 120G). I don't have any ata6 disks. That's one mystery solved. :-) > The following is the result when use SATA 200GB disk on pc98. It is > clearly that recognizing a geometry fails. > > atapci0: port > 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem > 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 > ad4: ATA-6 disk at ata2-master > ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B > ad4: 16 secs/int, 1 depth queue, SATA150 > > BIOS Geometries: > 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors Is this the geometry that the PC98 BIOS uses? Warner ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> Søren Schmidt <[EMAIL PROTECTED]> writes: > >>>2. A geometry translation for pc98 is NOT enough. > >>> > >>> Currently, it works only under 4.3GB disk. > > Wrong, ATA mk3 does solve the problem but using the "current" geomtry > set in the drives by the BIOS. However the code missed it in one place > in ata-lowlevel.c when the code was moved there from ata-disk.c. > This has been fixed and will be present in the next snapshot as I sadi > earlier. ATA-mkIII does NOT completely solve the problem. The word 54-58 of the IDENTIFY DEVICE parameter are valid only up to ATA/ATAPI-5. They are obsolete parameters in ATA/ATAPI-6 and later. So using them for a geometry translation has NO effect for recent disks. The following is the result when use SATA 200GB disk on pc98. It is clearly that recognizing a geometry fails. atapci0: port 0xc000-0xc00f,0x602c-0x602f,0x6030-0x6037,0x6028-0x602b,0x6020-0x6027 mem 0x20411000-0x204113ff irq 10 at device 17.0 on pci0 ad4: ATA-6 disk at ata2-master ad4: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, SATA150 BIOS Geometries: 1:1778 0..6008=6009 cylinders, 0..255=256 heads, 1..255=255 sectors --- 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: UPDATE: ATA mkIII first official patches - please test!
On Wed, Feb 09, 2005 at 03:00:50PM +0100, S?ren Schmidt wrote: > S?ren Schmidt wrote: > New version that fixes known problems so far etc now available: > http://people.freebsd.org/~sos/ata-mk3k.tar.gz .. > As always, enjoy and let me know how it goes... This does indead fix my panic that I reported to you. I'd like to add a wishlist item, that is really needed for the sparc64 platform. Currently hw.ata.ata_dma is a binary knob. I'd like to see it changed so that if the value isn't 0 or 1, then the value is taken to be the fastest dma to use. Values would be 2, 33, 66, 100, 133 (for completeness). My Sun Blade100 has an ATA66 controller, but other than the original disk with Sun firmware, no other ATA66 capable disk will work in the machine with either ATAng or ATA-mkIII unless I force the speed to udma33 or slower. FreeBSD doesn't currently have a good way to achieve this that we can easily do for the installation CDROM. -- -- David([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: UPDATE: ATA mkIII first official patches - please test!
On Sun, Feb 13, 2005 at 07:08:33PM +0100, Anthony Ginepro wrote: > - Retrying "call doadump" under a kernel without touching ATA_R_DEBUG, > it worked eventually once and could be canceled. Most of the time, dump > can't be canceled and doesn't progress. > > Should I open a PR so that the issue can be tracked ? This is what I have to do with ATAng to dump to an IDE disk, via Peter Wemm. Maybe it will help you find a work around with mkIII. Index: ata-all.c === RCS file: /home/ncvs/src/sys/dev/ata/ata-all.c,v retrieving revision 1.234 diff -u -r1.234 ata-all.c --- ata-all.c 24 Nov 2004 10:47:26 - 1.234 +++ ata-all.c 3 Dec 2004 00:46:03 - @@ -375,6 +375,8 @@ struct ata_channel *ch; int ctlr; +if (panicstr) return; + /* flush cache on all devices */ for (ctlr = 0; ctlr < devclass_get_maxunit(ata_devclass); ctlr++) { if (!(ch = devclass_get_softc(ata_devclass, ctlr))) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
Le Samedi 12 fÃvrier 2005 Ã 11:07 +0100, SÃren Schmidt a Ãcrit : > Anthony Ginepro wrote: > > > ATA mk3 works fine on my system except two things : > > - it seems there's no more atapi-cam support (or it's still WIP ?), > > I dont know the status of that, you need to ask the author/maintainer.. > > > - dumps doesn't work (but never did on my system). > > Hmm, I'll look into that... Some more info : - I recompiled a kernel with #define ATA_R_DEBUG 0x1fff in ata-all.h in order to find if the kernel was stuck on an ata operation when dumping. When calling "doadump" with ATA_R_DEBUG there was constant activity (but can't remind well because it was scrolling too fast) and I can even cancel the dump, - Retrying "call doadump" under a kernel without touching ATA_R_DEBUG, it worked eventually once and could be canceled. Most of the time, dump can't be canceled and doesn't progress. Should I open a PR so that the issue can be tracked ? Anthony. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
Takahashi Yoshihiro wrote: In article <[EMAIL PROTECTED]> Søren Schmidt <[EMAIL PROTECTED]> writes: 2. A geometry translation for pc98 is NOT enough. Currently, it works only under 4.3GB disk. Same a 1. No. See kern/61960. Wrong, ATA mk3 does solve the problem but using the "current" geomtry set in the drives by the BIOS. However the code missed it in one place in ata-lowlevel.c when the code was moved there from ata-disk.c. This has been fixed and will be present in the next snapshot as I sadi earlier. -- -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: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> Søren Schmidt <[EMAIL PROTECTED]> writes: > > 2. A geometry translation for pc98 is NOT enough. > > > >Currently, it works only under 4.3GB disk. > > Same a 1. No. See kern/61960. --- 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: UPDATE: ATA mkIII first official patches - please test!
Takahashi Yoshihiro wrote: ATA-mkIII has three big problems. I'd call it minor issues on PC98 :) 1. It seems that CHS mode is broken. Only in the case of "virtual geometry" as used by PC98 only. The problem is that the the real not virtual geometry is used for the tranlation from LBA to CHS. 2. A geometry translation for pc98 is NOT enough. Currently, it works only under 4.3GB disk. Same a 1. 3. Modules for pc98 are broken. No, they are not done yet :) I've fixed the CHS issue locally its contained in the next snapshot... -- -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: UPDATE: ATA mkIII first official patches - please test!
In article <[EMAIL PROTECTED]> NAKAJI Hiroyuki <[EMAIL PROTECTED]> writes: > On pc98, the partitions on ad0 are not detected, while slices are > detected. > > In my case, because ad0s1a which is mounted on root is not detected, > mountroot() fails and cannot use the system. > > ad0: 814MB at ata0-master BIOSPIO ATA-mkIII has three big problems. 1. It seems that CHS mode is broken. I think that NAKAJI-san's trouble is due to it. I also got the following error on my pc98. ad1: 407MB at ata0-slave BIOSPIO ad1: 833616 sectors [6129C/8H/17S] 1 sectors/interrupt 1 depth queue # mount -t msdos /dev/ad1s1 /mnt msdosfs: /dev/ad1s1: Invalid argument # dd if=/dev/ad1s1 of=/dev/null dd: /dev/ad1s1: Input/output error 7+0 records in 7+0 records out 3584 bytes transferred in 0.027885 secs (128528 bytes/sec) kernel: ad1: FAILURE - READ status=59 error=10 LBA=143 2. A geometry translation for pc98 is NOT enough. Currently, it works only under 4.3GB disk. 3. Modules for pc98 are broken. I attach a patch to fix it. --- TAKAHASHI Yoshihiro <[EMAIL PROTECTED]> diff -urN sys.org/modules/ata/Makefile sys/modules/ata/Makefile --- sys.org/modules/ata/MakefileMon Jan 10 20:41:02 2005 +++ sys/modules/ata/MakefileSun Feb 6 12:38:01 2005 @@ -1,5 +1,10 @@ # $FreeBSD$ -SUBDIR = ata ataisa atapci atadisk atapicd atapifd atapist ataraid #atacam +SUBDIR = ata atapci atadisk atapicd atapifd atapist #atacam +.if ${MACHINE} == "pc98" +SUBDIR+= atacbus +.else +SUBDIR+= ataisa ataraid +.endif .include diff -urN sys.org/modules/ata/Makefile.inc sys/modules/ata/Makefile.inc --- sys.org/modules/ata/Makefile.incThu Jan 1 09:00:00 1970 +++ sys/modules/ata/Makefile.incSun Feb 6 12:35:56 2005 @@ -0,0 +1,3 @@ +# $FreeBSD$ + +.include "../Makefile.inc" diff -urN sys.org/modules/ata/atacbus/Makefile sys/modules/ata/atacbus/Makefile --- sys.org/modules/ata/atacbus/MakefileThu Jan 1 09:00:00 1970 +++ sys/modules/ata/atacbus/MakefileSun Feb 6 12:40:30 2005 @@ -0,0 +1,9 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../../dev/ata + +KMOD= atacbus +SRCS= ata-cbus.c +SRCS+= opt_ata.h ata_if.h device_if.h bus_if.h isa_if.h + +.include ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
Anthony Ginepro wrote: ATA mk3 works fine on my system except two things : - it seems there's no more atapi-cam support (or it's still WIP ?), I dont know the status of that, you need to ask the author/maintainer.. - dumps doesn't work (but never did on my system). Hmm, I'll look into that... -- -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: UPDATE: ATA mkIII first official patches - please test!
Le Mercredi 09 fÃvrier 2005 Ã 15:00 +0100, SÃren Schmidt a Ãcrit : > SÃren Schmidt wrote: > > > http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz > > http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz > > http://people.freebsd.org/~sos/ata-mk3j.tar.gz > > New version that fixes known problems so far etc now available: ATA mk3 works fine on my system except two things : - it seems there's no more atapi-cam support (or it's still WIP ?), - dumps doesn't work (but never did on my system). For dumps, it never works under kernel panics so I tried jumping right into DDB and "call doadump", it displays "Dumping 991MB", hard drive's led lights on however the disk doesn't write, and system doesn't print dots reporting some progress. I host these files if you need more information : http://renaissance.homeip.net:8080/freebsd/ata-mkIII/CUSTOM_20050210 http://renaissance.homeip.net:8080/freebsd/ata-mkIII/dmesg.20050212 Thanks for all your work and patience with us, users with esoteric hardware, Anthony. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
Dag-Erling Smørgrav wrote: Søren Schmidt <[EMAIL PROTECTED]> writes: New version that fixes known problems so far etc now available: ah, just commit it already. it works for me, so it must be good enough ;) DES heh :) Works for me, but one problem, slaves attached to a Seagate master, don't show up :/ Tried a verbose boot, but it hung. Controller is a 4 port highpoint rocketraid in jbod mode. Drives are cabled and jumpered correctly, also tried CS mode, no difference. This was on 5.3 stable, may try MK3 on 6.0 tonight, vanilla 6.0 is fine. MK3 patched 5.3 dmesg from yesterday FreeBSD 5.3-STABLE #20: Wed Feb 9 17:51:03 EST 2005 root@:/usr/src/sys/i386/compile/OPPRESSION Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1200.05-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 1073217536 (1023 MB) avail memory = 1044873216 (996 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: on motherboard npx0: INT 16 interface pcib0: pcibus 0 on motherboard pci0: on pcib0 agp0: port 0x1050-0x1053 mem 0xea10-0xea100fff,0xec00-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0 x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 7.3 (no driver attached) em0: port 0x1000-0x103f mem 0xe800-0xe801,0xe802-0xe803 irq 16 at device 8.0 on pci0 em0: Ethernet address: 00:07:e9:00:ae:36 em0: Speed:N/A Duplex:N/A pcib2: at device 16.0 on pci0 pci2: on pcib2 atapci1: port 0x2000-0x20ff,0x2880-0x2883,0x2888-0x288f,0x2884-0x2887,0x2890-0x2897 irq 17 at device 5.0 on pci2 ata2: on atapci1 ata3: on atapci1 atapci2: port 0x2400-0x24ff,0x2898-0x289b,0x28a0-0x28a7,0x289c-0x289f,0x28a8-0x28af irq 17 at device 5.1 on pci2 ata4: on atapci2 ata5: on atapci2 pci2: at device 8.0 (no driver attached) cpu0 on motherboard cpu1 on motherboard pmtimer0 on isa0 orm0: at iomem 0xe-0xe3fff,0xcc000-0xc,0xcb000-0xcbfff,0xca800-0xcafff,0xc-0xca7ff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) fdc1: cannot allocate I/O port (6 ports) Timecounters tick every 10.000 msec ad0: 76319MB at ata0-master UDMA100 ad4: 381554MB at ata2-master UDMA100 ad6: 190782MB at ata3-master UDMA100 ad8: 176700MB at ata4-master UDMA100 ad9: 95396MB at ata4-slave UDMA100 ad10: 156334MB at ata5-master UDMA133 ad11: 381554MB at ata5-slave UDMA100 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s1a As you can see the hitachi and maxtor mastered slaves showed up I don't have a recent non mk3 5.3 dmesg handy, but here is a working plain 6.0 dmesg from the same machine FreeBSD 6.0-CURRENT #1: Thu Feb 10 10:37:33 EST 2005 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/OP6 MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1200.05-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 1073217536 (1023 MB) avail memory = 1041399808 (993 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard cpu1 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 agp0: port 0x1050-0x1053 mem 0xea10-0xea100fff,0xec00-0xefff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 7.3 (no driver attached) em0: port 0x1000-0x103f mem 0xe800-0xe801,0xe802-0xe803 irq 16 at device 8.0 on pci0 em0: Ethernet address: 00:07:e9:00:ae:36 em0: Speed:N/A Duplex:N/A pcib2: at device 16.0 on pci0 pci2: on pcib2 atapci1: port 0x2000-0x20ff,0x2880-0x2883,0x2888-0x288f,0x2884-0x2887,0x2890-0x2897 irq 17 at device 5.0 on pci2 ata2: channel #0 on atapci1 ata3: ch
Re: UPDATE: ATA mkIII first official patches - please test!
Freddie Cash wrote: New version that fixes known problems so far etc now available: Just curious if this includes support for new chipsets or not. Not a big deal if it doesn't, just curious. I've got a Toshiba laptop that, unfortunately, uses the ATI IGP/IXP chipset, which only gets detected as UDMA33 (which is fine for my uses, so I'm not complaining). If this is supported, I'd be more than willing to lose ATAPICAM support to use it. :) Its not (yet) as I dont have any such HW here yet. -- -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: UPDATE: ATA mkIII first official patches - please test!
> New version that fixes known problems so far etc now available: Just curious if this includes support for new chipsets or not. Not a big deal if it doesn't, just curious. I've got a Toshiba laptop that, unfortunately, uses the ATI IGP/IXP chipset, which only gets detected as UDMA33 (which is fine for my uses, so I'm not complaining). If this is supported, I'd be more than willing to lose ATAPICAM support to use it. :) -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] [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: UPDATE: ATA mkIII first official patches - please test!
Søren Schmidt <[EMAIL PROTECTED]> writes: > As always, enjoy and let me know how it goes... Peachy. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #3: Thu Feb 10 10:51:56 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/xps Preloaded elf kernel "/boot/xps/kernel" at 0xc0786000. Preloaded elf module "/boot/xps/vesa.ko" at 0xc07861c4. Preloaded elf module "/boot/xps/acpi.ko" at 0xc078626c. Preloaded elf module "/boot/xps/acpi_perf.ko" at 0xc0786314. Calibrating clock(s) ... i8254 clock: 1193190 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3591024219 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.60GHz (3591.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 2145959936 (2046 MB) Physical memory chunk(s): 0x1000 - 0x0009, 651264 bytes (159 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00825000 - 0x7da2afff, 2099273728 bytes (512518 pages) avail memory = 2099228672 (2001 MB) Table 'FACP' at 0xfcce7 Table 'SSDT' at 0xfffc9563 Table 'APIC' at 0xfcd5b MADT: Found table at 0xfcd5b MP Configuration Table version 1.4 found at 0xc00f APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled MADT: Found CPU APIC ID 1 ACPI ID 2: enabled MADT: Found CPU APIC ID 1 ACPI ID 3: disabled MADT: Found CPU APIC ID 7 ACPI ID 4: disabled ACPI APIC Table: APIC: CPU 0 has ACPI ID 1 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb757 pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f:e2f4 Rev = 1.0 Other BIOS signatures found: MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 8 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: level lapic: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger cpu0 BSP: ID: 0x VER: 0x00050014 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x8400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001 pcm: 0x0001 io: null: VESA: information block 56 45 53 41 00 03 1c 02 00 c0 01 00 00 00 22 00 00 01 00 01 01 09 6b 01 00 00 94 00 00 00 e0 51 00 00 00 01 01 01 03 01 05 01 07 01 10 01 11 01 12 01 13 01 14 01 15 01 16 01 17 01 18 01 19 01 VESA: 73 mode(s) found VESA: v3.0, 16384k memory, flags:0x1, mode table:0xc0721622 (122) VESA: ATI ATOMBIOS VESA: \M-p\^_\M-* \^_\M-* random: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1):mode 1 addr port (0x0cf8) is 0x80010054 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=25848086) pcibios: BIOS version 2.10 Found $PIR table, 13 entries at 0xc00feb00 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded0 31A 0x60 3 4 5 6 7 9 10 11 14 15 embedded0 31B 0x61 3 4 5 6 7 9 10 11 14 15 embedded0 31C 0x68 3 4 5 6 7 9 10 11 14 15 embedded0 29A 0x69 3 4 5 6 7 9 10 11 14 15 embedded0 29B 0x6a 3 4 5 6 7 9 10 11 14 15 embedded0
Re: UPDATE: ATA mkIII first official patches - please test!
Søren Schmidt <[EMAIL PROTECTED]> writes: > New version that fixes known problems so far etc now available: ah, just commit it already. it works for me, so it must be good enough ;) DES -- Dag-Erling Smørgrav - [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: UPDATE: ATA mkIII first official patches - please test!
Tim Welch wrote: A problem still exists with 48-bit addressing. This url details a fix I've been using for the last 4 months or so with no issues yet. http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html Are you stil experiencing problems with atamkIII ? In that case its a different problem since atamkIII (as well as current) has this fixed.. -- -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: UPDATE: ATA mkIII first official patches - please test!
Emanuel Strobl wrote: Am Mittwoch, 9. Februar 2005 15:00 schrieb Søren Schmidt: [...] As always, enjoy and let me know how it goes... It's running here on several RELENG_5 machines. Like with j I also can't find any problems with k :) But the strange 16MB/s limit on my ICH2 (i815 B-step (tualatin)) machine still exists and still if I use the command "atacontrol mode 0 udma5 udma5" the limit vanishes but only when typed interactively, no go by setting the udma5 mode (which is actualy already set at probing) in any rc script. Still reproducale but I have absolutely no idea how this can be :( Hmm, strange, anyhow I've managed to scavenge an ICH2 based board here, I just need to locate a CPU that fits then I'll look into this mess.. -- -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: UPDATE: ATA mkIII first official patches - please test!
On 02/09/05 16:34, Tim Welch wrote: On Wed, 2005-02-09 at 15:00 +0100, Søren Schmidt wrote: Søren Schmidt wrote: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz New version that fixes known problems so far etc now available: 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 The diffs hasn't changed, so for those that has already applied those you can just untar the tarfile (still relative to /usr/src). Fixes include: o atapi-cd eject/close o SiI controllers lost some (slow) SATA disks in probe o panic when detaching disk not part of a RAID. o Cable detection failure on channels with both master and slave. As always, enjoy and let me know how it goes... A problem still exists with 48-bit addressing. This url details a fix I've been using for the last 4 months or so with no issues yet. http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html Problem was fixed in -CURRENT a couple months ago: http://docs.freebsd.org/cgi/mid.cgi?200412090731.iB97V7pB035207 MFC anyone? Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
On Wed, 2005-02-09 at 15:00 +0100, Søren Schmidt wrote: > Søren Schmidt wrote: > > > http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz > > http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz > > http://people.freebsd.org/~sos/ata-mk3j.tar.gz > > New version that fixes known problems so far etc now available: > > 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 > > The diffs hasn't changed, so for those that has already applied those > you can just untar the tarfile (still relative to /usr/src). > > > Fixes include: > > o atapi-cd eject/close > > o SiI controllers lost some (slow) SATA disks in probe > > o panic when detaching disk not part of a RAID. > > o Cable detection failure on channels with both master and slave. > > As always, enjoy and let me know how it goes... > A problem still exists with 48-bit addressing. This url details a fix I've been using for the last 4 months or so with no issues yet. http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html Thanks, Tim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE: ATA mkIII first official patches - please test!
Am Mittwoch, 9. Februar 2005 15:00 schrieb Søren Schmidt: [...] > > As always, enjoy and let me know how it goes... It's running here on several RELENG_5 machines. Like with j I also can't find any problems with k :) But the strange 16MB/s limit on my ICH2 (i815 B-step (tualatin)) machine still exists and still if I use the command "atacontrol mode 0 udma5 udma5" the limit vanishes but only when typed interactively, no go by setting the udma5 mode (which is actualy already set at probing) in any rc script. Still reproducale but I have absolutely no idea how this can be :( Thanks for your work :)) -Harry pgpUeI7nEweQY.pgp Description: PGP signature
UPDATE: ATA mkIII first official patches - please test!
Søren Schmidt wrote: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz New version that fixes known problems so far etc now available: 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 The diffs hasn't changed, so for those that has already applied those you can just untar the tarfile (still relative to /usr/src). Fixes include: o atapi-cd eject/close o SiI controllers lost some (slow) SATA disks in probe o panic when detaching disk not part of a RAID. o Cable detection failure on channels with both master and slave. As always, enjoy and let me know how it goes... -- -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: ATA mkIII first official patches - please test!
Søren Schmidt <[EMAIL PROTECTED]> writes: > There is no patch for ata-all.c there is a replacement. I will > eventually get that updated (so you can run cvs diff ?)... OK, thanks. DES -- Dag-Erling Smørgrav - [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: ATA mkIII first official patches - please test!
Dag-Erling Smørgrav wrote: Søren Schmidt <[EMAIL PROTECTED]> writes: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz sys/dev/ata/ata-all.c rev 1.235 conflicts, could you please update the -CURRENT patch? There is no patch for ata-all.c there is a replacement. I will eventually get that updated (so you can run cvs diff ?)... -- -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: ATA mkIII first official patches - please test!
Søren Schmidt <[EMAIL PROTECTED]> writes: > http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz > http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz > http://people.freebsd.org/~sos/ata-mk3j.tar.gz sys/dev/ata/ata-all.c rev 1.235 conflicts, could you please update the -CURRENT patch? DES -- Dag-Erling Smørgrav - [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: ATA mkIII first official patches - please test!
Sorry to be a BOFH, but could you guys stop crossposting on this topic? I think -current is more suitable for this. Thanks. * Hides in corner * ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: Since I cannot debug this, I have no way of finding out whats wrong. I will look at it when ACPI allows me to use suspend/resume again, until then I'll concentrated on things that I can work on... where's my refund? :-) more seriously, shall we do a fund to get you a laptoy on which acpi happens to work this week? Find such a machine might be very hard, if not plain impossible :/ I already have 3 laptops here (of which none has worked for several month regarding suspend/resume) so I have plenty. However getting laptops to those thats supposed to maintain ACPI might be an idea, but we should make certain that it would help first ;) -- -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: ATA mkIII first official patches - please test!
> Since I cannot debug this, I have no way of finding out whats wrong. > I will look at it when ACPI allows me to use suspend/resume again, until > then I'll concentrated on things that I can work on... where's my refund? :-) more seriously, shall we do a fund to get you a laptoy on which acpi happens to work this week? randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: diff -u -r1.20 ata-all.c --- ata-all.c 2005/02/03 17:02:31 1.20 +++ ata-all.c 2005/02/07 14:27:57 @@ -630,7 +630,7 @@ void ata_udelay(int interval) { -if (1 || interval < (100/hz) || ata_delayed_attach) +if (interval < (100/hz) || ata_delayed_attach) DELAY(interval); else tsleep(&interval, PRIBIO, "ataslp", interval/(100/hz)); no fix hangs in ad0: TIMEOUT - WRITE DMA retrying (2 retries left) LBA=7434015 disk light on solid. no response to anything no idea Since I cannot debug this, I have no way of finding out whats wrong. I will look at it when ACPI allows me to use suspend/resume again, until then I'll concentrated on things that I can work on... -- -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: ATA mkIII first official patches - please test!
> diff -u -r1.20 ata-all.c > --- ata-all.c 2005/02/03 17:02:31 1.20 > +++ ata-all.c 2005/02/07 14:27:57 > @@ -630,7 +630,7 @@ > void > ata_udelay(int interval) > { > -if (1 || interval < (100/hz) || ata_delayed_attach) > +if (interval < (100/hz) || ata_delayed_attach) > DELAY(interval); > else > tsleep(&interval, PRIBIO, "ataslp", interval/(100/hz)); > no fix hangs in ad0: TIMEOUT - WRITE DMA retrying (2 retries left) LBA=7434015 disk light on solid. no response to anything randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
Arne Schwabe wrote: SÃren Schmidt <[EMAIL PROTECTED]> writes: Randy Bush wrote: After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as "built in" nothing really changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. Does it work with stock ATA ? I cant work on suspend/resume as it has been broken due to ACPI brokenness since september last year on all my laptops... Same here, worked before the patch. Does not work with the patch. Hmm, the attached patch is the only real difference, which actually shouldn't pose a problem (and fixes broken APM).. Let me know if that changes anything, other than that you are free to bug the ACPI gang to make ACPI work on the HW I have available for development... -SÃren diff -u -r1.20 ata-all.c --- ata-all.c 2005/02/03 17:02:31 1.20 +++ ata-all.c 2005/02/07 14:27:57 @@ -630,7 +630,7 @@ void ata_udelay(int interval) { -if (1 || interval < (100/hz) || ata_delayed_attach) +if (interval < (100/hz) || ata_delayed_attach) DELAY(interval); else tsleep(&interval, PRIBIO, "ataslp", interval/(100/hz)); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
SÃren Schmidt <[EMAIL PROTECTED]> writes: > Randy Bush wrote: After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): >>> >>> Hmm, do you have ATA compiled in or as modules. I could easily >>> imagine that modules could have problems, but as "built in" nothing >>> really changed... >> my patched t41, current with ata in the kernel, locks up with disk >> light on solid on resume. > > Does it work with stock ATA ? > I cant work on suspend/resume as it has been broken due to ACPI > brokenness since september last year on all my laptops... Same here, worked before the patch. Does not work with the patch. Arne -- compiling millions of tiny c-programs...done checking for a working configure script... not found ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
>> my patched t41, current with ata in the kernel, locks up with disk >> light on solid on resume. > Does it work with stock ATA ? it did last week, before i rebuilt with patch > I cant work on suspend/resume as it has been broken due to ACPI > brokenness since september last year on all my laptops... yep. been there, have the tee-shirt randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as "built in" nothing really changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. Does it work with stock ATA ? I cant work on suspend/resume as it has been broken due to ACPI brokenness since september last year on all my laptops... -- -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: ATA mkIII first official patches - please test!
>> After suspend, my ThinkPad X40 now hangs with following logs (copied >> by hand): > Hmm, do you have ATA compiled in or as modules. I could easily imagine > that modules could have problems, but as "built in" nothing really > changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
>>> On Sun, 06 Feb 2005 14:29:03 +0100, Søren Schmidt <[EMAIL PROTECTED]> said: > Hideyuki KURASHINA wrote: > > Hi, Søren > > > I've tested your patches using same config file as before, and it seems > > work fine except on resume. > > Hmm, thats one corner I cant test, suspend/resume dies horribly in ACPI > on all 3 notebooks I have since september last year or thereabouts... Hmm... > > After suspend, my ThinkPad X40 now hangs with following logs (copied > > by hand): > > Hmm, do you have ATA compiled in or as modules. I could easily imagine > that modules could have problems, but as "built in" nothing really > changed... As I mentioned above, I compiled ATA bus support & ATA disk driver into kernel statically. Setting both `debug.acpi.do_powerstate' and `hw.pci.do_powerstate' to `0' doesn't help, either. -- rushani ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
Hideyuki KURASHINA wrote: Hi, Søren I've tested your patches using same config file as before, and it seems work fine except on resume. Hmm, thats one corner I cant test, suspend/resume dies horribly in ACPI on all 3 notebooks I have since september last year or thereabouts... After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as "built in" nothing really changed... -- -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: ATA mkIII first official patches - please test!
Hi, Søren >>> On Thu, 03 Feb 2005 21:52:57 +0100, Søren Schmidt <[EMAIL PROTECTED]> said: > ATA-mkIII first official snapshot. [...] > No changes are needed to your config file, unless you want ATA as modules. I've tested your patches using same config file as before, and it seems work fine except on resume. After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): (Fn + F4 key combo to enter suspend) acpi_ec0: info: new max delay is 80 us IBM:NOTIFY:80 notify:1004 acpi_lid0: wake_prep enabled for \_SB_.LID_ (S3) acpi_button0: wake_prep enabled for \_SB_.SLPB (S3) (Fn key to resume back ) AcpiOsDerivePciId: bus 0 dev 31 func 1 acpi_printcpu() debug dump gdt[0077:c0667c20] idt[07ff:c0677fe0] ldt[0030] tr[0020] elf[0086] eax[0001] ebx[] ecx[] edx[0004] esi[c1beedc8] edi[80045003] ebp[d4ebbc3c] esp[d4ebbc10] cr0[8005003b] cr2[0804a314] cr3[14f1b000] cr4[0691] cs[0008] ds[0010] es[0010] fs[0018] gs[008f] ss[0010] acpi_printcpu() debug dump gdt[0077:c0667c20] idt[07ff:c0667fe0] ldt[0030] tr[0020] elf[0002] eax[0046] ebx[] ecx[] edx[c1991cf0] esi[c1beedc8] edi[80045003] ebp[d4ebbc3c] esp[d4ebbc10] cr0[8005003b] cr2[0804a314] cr3[14f1b000] cr4[0091] cs[0008] ds[0010] es[0010] fs[0018] gs[008f] ss[0010] acpi_lid0: run_prep cleaned up for \_SB_.LID_ acpi_button0: run_prep cleand up for \_SB_.SLPB acpi_ec0: info: new max delay is 100 us While ``bus 0 dev 31 func 1'' is atapic0 (Intel ICH4 UDMA100 controller), it seems there's no helpful ATA related message though. However, I got curious behaviors, i.e. o Hard disk actively drives, thus HDD indicator nearly holds on lighting o A status indicator for event blinks on and off, periodicaly I'm using kernel & modules as of yesterday (HEAD). Without applying your patches, the resume works fine. Is this problem included in your task list, or am I alone? My config file and complete dmesg on start up (booted with -v flag) is attached below, -- rushani # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $rushani: TPX40,v 1.6 2004/12/08 09:27:42 hideyuki Exp $ # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.413.2.6.2.2 2004/10/24 18:02:52 scottl Exp $ machine i386 #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident TPX40 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_4BSD # 4BSD scheduler options INET# InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories #optionsMD_ROOT # MD is a potential root device #optionsNFSCLIENT # Network Filesystem Client #optionsNFSSERVER # Network Filesystem Server #optionsNFS_ROOT# NFS usable as /, requires NFSCLIENT #optionsMSDOSFS # MSDOS Filesystem #optionsCD9660 # ISO 9660 Filesystem #optionsPROCFS # Process filesystem (requires PSEUDOFS) #optionsPSEUDOFS# Pseudo-filesystem framework options GEOM_GPT# GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=2000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support #optionsSYSVSHM # SYSV-style shared memory #optionsSYSVMSG # SYSV-style message queues #optionsSYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options
Re: ATA mkIII first official patches - please test!
Søren Schmidt wrote: ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. Is this coming in 5.4-RELEASE? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
Ben Stuyts wrote: On 3 Feb 2005, at 21:52, Søren Schmidt wrote: o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. Will RAID mirrors built using atacontrol on standard ata controllers still work? Specifically in my case on 5.3-stable: Not as is, but its easily added, uncomment line 597 in ata-raid.c and it will be picked up as before... -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: ATA mkIII first official patches - please test!
On Thu, 2005-02-03 at 21:52 +0100, SÃren Schmidt wrote: > ATA-mkIII first official snapshot. > > This is the much rumoured ATA update that I've been working on for some time. > > It contains a number of new things, and lacks a few features of the old code. > > New items include: > > o ATA is now fully newbus'd and split into modules. > This means that on a modern system you just load "atapci and ata" > to get the base support, and then one or more of the device > subdrivers "atadisk atapicd atapifd atapist ataraid". > All can be loaded/unloaded anytime, but for obvious reasons you > dont want to unload atadisk when you have mounted filesystems. > > o The device identify part of the probe has been rewritten to fix > the problems with odd devices the old had, and to try to remove > so of the long delays some HW could provoke. > > o SATA devices can be hot inserted/removed and devices will be created/ > removed in /dev accordingly. NOTE only supported on controllers that > has this feature: Promise and Silicon Image for now. > > o ATA RAID support has been rewritten and and now supports these > metadata formats: > "Adaptec HostRAID" > "Highpoint V2 RocketRAID" > "Highpoint V3 RocketRAID" > "Intel MatrixRAID" > "Integrated Technology Express" > "LSILogic V2 MegaRAID" > "LSILogic V3 MegaRAID" > "Promise FastTrak" > "Silicon Image Medley" > > o The reinit code has been worked over to be much more robust. > > o The timeout code has been overhauled for races. > > o Lots of fixes for bugs found while doing the modulerization and > reviewing the old code. > > > Missing features form current ATA: > > o atapi-cd no longer has support for ATAPI changers. Todays its > much cheaper and alot faster to copy those CD images to disk > and serve them from there. Besides they dont seem to be made > anymore, maybe for that exact reason. > > o ATA RAID can only read metadata not write them. This means that > arrays can be picked up from the BIOS, but they cannot be created > from FreeBSD. This is being worked on for the final release as is > RAID5 support for Promise/Highpoing/SiI controllers. > > o The atapi-cam author has been informed and has had early access > to this work but so far atapicam is not supported with these > changes. However I do have my own atacam that puts both ATA and ATAPI > devices under CAM, but its really just academic at this point. > > And then there all the things that I've happily forgotten about :) > > The snapshot is available as a patch for RELENG_5 and for CURRENT, and > a common tarfile of the new ATA code. > > http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz > http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz > http://people.freebsd.org/~sos/ata-mk3j.tar.gz > > Both patches and the tarfile is relative to /usr/src. > You might want to remove the contents of sys/dev/ata/ before unpacking > the tarfile. > > No changes are needed to your config file, unless you want ATA as modules. > > As usual, even if it works on all the HW I have here in the lab, thats by > far not the same as it works on YOUR system. So use glowes and safety shoes > and if it breaks I dont want the pieces, but would like to hear the nifty > details on how exactly it got that way :) > > Enjoy! > Works beautifully here (AVERATEC 3150H with VIA 8235). Timeouts on non-existing slaves are gone for good. Patch for -current (as of yesterday) failed to compile afterward (log attached), but removing sys/dev/ata/* and untaring archive worked just fine. -- Alexandre "Sunny" Kovalenko (ÑÐÐÐÑ Ð) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
> From: Randy Bush <[EMAIL PROTECTED]> > Date: Fri, 4 Feb 2005 16:04:56 -0800 > Sender: [EMAIL PROTECTED] > > makes my tp41 running current boot without crashing. i > demand a refund! :-) Randy, We have refunded your money so often that we're running out of empty pockets to get the funds from. :-) Seriously, my T30 seems happier, too, although time will tell since it was not nearly as unhappy as yours was. (It only barked and locked up occasionally and never crashed on boot.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
makes my tp41 running current boot without crashing. i demand a refund! :-) randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
On 3 Feb 2005, at 21:52, Søren Schmidt wrote: o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. Will RAID mirrors built using atacontrol on standard ata controllers still work? Specifically in my case on 5.3-stable: atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 ad0: 117246MB [238216/16/63] at ata0-master UDMA100 ad2: 117246MB [238216/16/63] at ata1-master UDMA100 and: [aurora:~]138: sudo atacontrol status 0 ar0: ATA RAID1 subdisks: ad0 ad2 status: READY Thanks, Ben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
On 02/03/05 14:52, Søren Schmidt wrote: ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. It contains a number of new things, and lacks a few features of the old code. New items include: o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load "atapci and ata" to get the base support, and then one or more of the device subdrivers "atadisk atapicd atapifd atapist ataraid". All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE only supported on controllers that has this feature: Promise and Silicon Image for now. o ATA RAID support has been rewritten and and now supports these metadata formats: "Adaptec HostRAID" "Highpoint V2 RocketRAID" "Highpoint V3 RocketRAID" "Intel MatrixRAID" "Integrated Technology Express" "LSILogic V2 MegaRAID" "LSILogic V3 MegaRAID" "Promise FastTrak" "Silicon Image Medley" o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing features form current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. o The atapi-cam author has been informed and has had early access to this work but so far atapicam is not supported with these changes. However I do have my own atacam that puts both ATA and ATAPI devices under CAM, but its really just academic at this point. And then there all the things that I've happily forgotten about :) The snapshot is available as a patch for RELENG_5 and for CURRENT, and a common tarfile of the new ATA code. http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz Both patches and the tarfile is relative to /usr/src. You might want to remove the contents of sys/dev/ata/ before unpacking the tarfile. No changes are needed to your config file, unless you want ATA as modules. As usual, even if it works on all the HW I have here in the lab, thats by far not the same as it works on YOUR system. So use glowes and safety shoes and if it breaks I dont want the pieces, but would like to hear the nifty details on how exactly it got that way :) Enjoy! Running RELENG_5 on a dual P3 machine (Abit VP6). I am using the onboard HighPoint HPT370 and had both channels of the onboard VIA 82C686B disabled in the BIOS. It hung solidly during boot attempting to probe the VIA controller (detected a GENERIC IDE controller on isa0 or something like that). When I enabled the primary channel on the VIA in the BIOS, it zipped right through the boot like normal. Other than that hang, I have not noticed any problems during the course of normal (albeit limited) usage. Some quick dd runs with bs=2048 indicated 53MB/s read and 45MB/s write with a single Hitachi 7K250 drive. It's not a big deal to leave the VIA controller enabled (it doesn't share interrupts even without APIC), but ideally it should be ignored when disabled (ACPI issue?). If you'd like me to do more, let me know. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
On Thu, 3 Feb 2005 18:40:43 -0800, Pascal Hofstee <[EMAIL PROTECTED]> wrote: > The only thing i was curious about is if there is any way to build the > kernel-module using ATA_STATIC_ID .. (as i used to do in my normal > kernel-configs) Ok .. I whacked myself with the proverbial clue-stick .. and simply put the ATA_STATIC_ID line back into my kernel-config. Even though i chose not to build ata-support not into the actual kernel the opt_ata.h file is of course still used in building the actual kernel-modules. Excuse the line noise :) -- Pascal Hofstee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
On Thu, 03 Feb 2005 21:52:57 +0100, Søren Schmidt <[EMAIL PROTECTED]> wrote: > ATA-mkIII first official snapshot. Using it without any problems on a few days old 6.0-CURRENT (P2 400 MHz) I decided to take the plunge and go for the kernel-module-approach. The only thing i was curious about is if there is any way to build the kernel-module using ATA_STATIC_ID .. (as i used to do in my normal kernel-configs) Beyond that, it works like a charm :) -- Pascal Hofstee ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA mkIII first official patches - please test!
On Thu, Feb 03, 2005 at 09:52:57PM +0100, S?ren Schmidt wrote: > > As usual, even if it works on all the HW I have here in the lab, thats by > far not the same as it works on YOUR system. So use glowes and safety shoes > and if it breaks I dont want the pieces, but would like to hear the nifty > details on how exactly it got that way :) > THANK YOU! This is the first time since 7 Dec 04 that I've been able to boot a current -CURRENT on my Dell Inspiron 4150 laptop. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATA mkIII first official patches - please test!
ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. It contains a number of new things, and lacks a few features of the old code. New items include: o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load "atapci and ata" to get the base support, and then one or more of the device subdrivers "atadisk atapicd atapifd atapist ataraid". All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE only supported on controllers that has this feature: Promise and Silicon Image for now. o ATA RAID support has been rewritten and and now supports these metadata formats: "Adaptec HostRAID" "Highpoint V2 RocketRAID" "Highpoint V3 RocketRAID" "Intel MatrixRAID" "Integrated Technology Express" "LSILogic V2 MegaRAID" "LSILogic V3 MegaRAID" "Promise FastTrak" "Silicon Image Medley" o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing features form current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. o The atapi-cam author has been informed and has had early access to this work but so far atapicam is not supported with these changes. However I do have my own atacam that puts both ATA and ATAPI devices under CAM, but its really just academic at this point. And then there all the things that I've happily forgotten about :) The snapshot is available as a patch for RELENG_5 and for CURRENT, and a common tarfile of the new ATA code. http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz Both patches and the tarfile is relative to /usr/src. You might want to remove the contents of sys/dev/ata/ before unpacking the tarfile. No changes are needed to your config file, unless you want ATA as modules. As usual, even if it works on all the HW I have here in the lab, thats by far not the same as it works on YOUR system. So use glowes and safety shoes and if it breaks I dont want the pieces, but would like to hear the nifty details on how exactly it got that way :) Enjoy! -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"