TESTERS WANTED for ATAng preview 2
The story continues with Preview 2 - from the README: Now the functionality is almost equal to that of stock ATA, I'm getting close to being ready to expose this on the -current users, so please give this a go to shake out the last nasties. I've fixed alot of minor issue that testers have reported back (thanks!!), plus a few chipset issued found over the last days. Grap the latest from ftp.deepcore.dk/pub/ATAng and apply the diff files to your src tree, remove the contents of sys/dev/ata and extract the ATAng-*tgz file there, then do the usual drill to get a new kernel... As usual it might kill your dog, abduct your kids and whatnot :) Let me know how this works out for you! Enjoy!! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 2
It seems Andrew Kenneth Milton wrote: linking kernel ata-all.o: In function `ata_identify_devices': ata-all.o(.text+0x107e): undefined reference to `ad_attach' ata-all.o(.text+0x1116): undefined reference to `ad_attach' I'm guessing this is because I have; device ata #device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives I guess it wants atadisk enabled in the kernel config (trying now). This config works with ata-old-gen though. I've fixed this locally, thanks for pointing it out! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
It seems Gavin Atkinson wrote: On Wed, 13 Aug 2003, Soeren Schmidt wrote: It seems Gavin Atkinson wrote: With the new ATA code, the boot now hangs. I now get on a verbose bootup: ata1-master: FAILURE - ATAPI_IDENTIFY status=1ERROR error=0 Okies, what if you make that CDROM a slave ? That seems to work fine: ata1: spurious interrupt - status=0x7f error=0x7f reason=0x7f ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 acd0: CDROM SAMSUNG CD-ROM SC-152A at ata1-slave PIO4 OK, your CDROM doesn't like to be a sole master it appears... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: driver maintainers, please help
It seems Lukas Ertl wrote:
Hi there,
this is a call for help from the various driver maintainers. In a recent
discussion on -doc it has come out that several manpages are not in sync
with what's listed in the 5.1 Hardware Notes, and I'm currently trying to
update those manpages. Unfortunately, for some devices (especially older
ones) I'd need some info that I just can't find on the web, so I hope some
of the maintainers or authors can give me a hint (and of course anyone
else who knows).
What I would like to know so far:
*) ata(4) - what are the supported UDMA levels for SiS 652, 751, and 752?
{ ATA_SIS652, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 652 }
{ ATA_SIS751, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 751 }
{ ATA_SIS752, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 752 }
Or so it seems, it depends on the southbridge on the board, so this is
the max, but depending on the actual HW it can be UDMA5.
Of course, it would be very helpful here if the driver maintainers could
have a look at their manpages and compare them to the Hardware Notes and
catch up with what isn't in the respective man page.
The ATA driver is in violent flux currently, but I will update the
man page when I'm done with the changes..
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
It seems Jason Dambrosio wrote: On Fri, Aug 08, 2003 at 09:55:11PM +0200, Soeren Schmidt wrote: The first preview release of ATAng is now available on: ftp://ftp.deepcore.dk/pub/ATAng I cvsup'd to HEAD and applied the conf-patch and put in your new ATA source, but when I recompiled my kernel and rebooted, the server just locked up with the following dmesg: atapci0: Promise PDC20376 SATA150 controller port 0xe400-0xe47f,0xe800-0xe80f,0xec00-0xec3f mem 0xdffa-0xdffb,0xdffdf000-0xdffd irq 11 at device 13.0 on pci0 ata2: at 0xdffdf000 on atapci0 ata3: at 0xdffdf000 on atapci0 ata4: at 0xdffdf000 on atapci0 OK, Try the new .tgz I just uploaded, I'm pretty sure that solves the problem for you.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
TESTERS WANTED for ATAng preview 1
The first preview release of ATAng is now available on: ftp://ftp.deepcore.dk/pub/ATAng From the README there: ATAng preview 1 release Before these rather radical changes to the ATA driver hits the tree, here is the opportunity to test them out, give usefull feedback and for the depending subsytems to adjust to the new ways of things (burncd atapicam are good examples). Now why all these changes suddenly ? 1. Get GIANT out of the ATA driver. This was pretty tedious in the old version (I tried that long ago and found it way too painfull). With this new structure it was a walk in the park since handling of ATA commands/requests are now split up in a queue part and a lowlevel part. This makes the places where locks are needed a lot more obvious to locate, making it easier to implement and maintain. 2. Provide the framework for supporting new ATA controllers that has facilities for chaining commands and HW XOR's etc. This called for some radical changes to the basic framework which fitted nicely with item 1 above. Most of the hooks needed for exotic HW are now present, and the next step will be for drivers to use this to get an edge over conventional ATA controllers. Promise Inc. has kindly provided HW and documentation for their latests chips that has lots of interesting features that we can now start to use. Much more on this when these basic bits has settled.. 3. Merge of ATA and ATAPI code. As an effect of the new framework there is now a single entrypoint for ATA/ATAPI commands. This will extend to userland where it will be possible to issue both ATA and ATAPI commands just as before with just ATAPI ones. This will add the ability to do all kinds of stuff from userland, like SMART etc, however it will also provide a nice way of trashing your system :) The code for this is not included in this preview as I still need to settle on the API for this. 4. During all this lots of bugs and problems in the old code has been found and fixed. 5. The way ATA RAID support works today need to change as well to make full use of fx Promise's new chips. This is NOT done yet, in fact the ata-raid.? driver is still the same, bugs and all. To try this out you need to apply the conf-patch file to your sys tree then delete the contents of dev/ata and put the contents of the ATAng-timestamp.tgz in there instead. You might want to include device ataraid in your kernel config file if you use ATA RAID's. Config make your kernel as usual. Now, some things are not completly done yet, some things will not be done at all and there are bound to be bugs lurking, so use protective measures for safe engagement, you have been warned 8) Constructive feedback as always very welcome!! Enjoy! -Søren -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAng
It seems Matt Douhan wrote: [ PGP not available, raw data follows ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I cvsup'd current src today and applied the conf-patch and replaced the /usr/src/sys/dev/ata/* now in my dmesg output I see this, Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks, buffers remaining... 13 13 done Thats all perfectly normal, which part are you worried about ? And thanks for the disks etc btw, I dont recall you replying to my former mial about that. BTW what would you like to get in the sponsored by line when I commit the Adaptec RAID support code ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
It seems Gavin Atkinson wrote: I'm using ATAng-20030809-1.tgz on top-of-tree current on hardware detected with the old ATA code as: atapci0: Intel ICH5 UDMA100 controller port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: Intel ICH5 SATA150 controller port 0xdc00-0xdc0f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 irq 10 at device 31.2 on pci0 ata2: at 0xec00 on atapci1 ata3: at 0xe400 on atapci1 ata1-master: timeout waiting for interrupt ata1-master: ATAPI identify failed ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 (ata1-master is a CD-ROM drive, and freebsd has been unable to detect it since I installed FreeBSD onto this machine about two weeks ago). With the new ATA code, the boot now hangs. I now get on a verbose bootup: ata1-master: FAILURE - ATAPI_IDENTIFY status=1ERROR error=0 Okies, what if you make that CDROM a slave ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: driver maintainers, please help
It seems Lukas Ertl wrote:
On Wed, 13 Aug 2003, Soeren Schmidt wrote:
*) ata(4) - what are the supported UDMA levels for SiS 652, 751, and 752?
{ ATA_SIS652, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 652 }
{ ATA_SIS751, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 751 }
{ ATA_SIS752, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 752 }
Or so it seems, it depends on the southbridge on the board, so this is
the max, but depending on the actual HW it can be UDMA5.
Thanks, Soren.
The ATA driver is in violent flux currently, but I will update the
man page when I'm done with the changes..
So would you like to handle docs/55512 yourself?
It will be dealt with when I'm done with these changes, so in a way yes...
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
if_xl borked in current!!
Upgraded laptop from 5.1 to -current was as usual a bad idea, this time the xl driver broke (and wi is still useless BTW) leaving me with no networks working :( CURRENT: xl0: 3Com 3c575C Fast Etherlink XL port 0x1000-0x107f mem 0x88002000-0x8800207f,0x88002080-0x880020ff irq 11 at device 0.0 on cardbus1 xl0: reset didn't complete xl0: command never completed! xl0: command never completed! xl0: eeprom failed to come ready xl0: failed to read station address device_probe_and_attach: xl0 attach returned 6 cbb1: CardBus card activation failed 5.1-RELEASE xl0: 3Com 3c575C Fast Etherlink XL port 0x1000-0x107f mem 0x88002000-0x8800207f,0x88002080-0x880020ff irq 11 at device 0.0 on cardbus1 xl0: Ethernet address: 00:50:04:5c:f4:6b miibus0: MII bus on xl0 tdkphy0: TDK 78Q2120 media interface on miibus0 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Ideas ? or better yet a patch for the messup ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 1
It seems Gavin Atkinson wrote: On Wed, 13 Aug 2003, Soeren Schmidt wrote: It seems Gavin Atkinson wrote: ata1: spurious interrupt - status=0x7f error=0x7f reason=0x7f ad0: 19881MB Maxtor 6E020L0 [40395/16/63] at ata0-master UDMA100 acd0: CDROM SAMSUNG CD-ROM SC-152A at ata1-slave PIO4 OK, your CDROM doesn't like to be a sole master it appears... I hate it when people respond with this, but I'm going to join them and say It works under Windows... Also, under the new code, this problem prevents the booting of the machine, but under the old code the machine carries on booting after giving up on the drive. Is it possible for this failure mode to not prevent the booting of the machine at least? Of cause, I'm looking at that right now actually, but all my ATAPI drives seems to work unfortunately :( -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device7.1on pci0
It seems Doug White wrote: On Sun, 3 Aug 2003, ryan chris wrote: with dma enabled, a sysinstall will only work under the minimal install, and after a certain point, apparently using too much hard drive space (showed up with a tar -xvf ports.tar) causes a panic with anic errors Have you tried replacing the IDE cable(s)? I've seen panics and other erratic behavior due to bad cables, or a defective 60 pin cable, or even a 30 pin cable that somehow got detected as a 60 pin. Uhm, the cables are 40 vs 80 conductors :) Anyhow I'm pretty sure this problem is because of the buggy VIA 82C686B southbridge and a matching BIOS that doesn't setup the right workarounds for it to function like intended. Clearly the tweaks we install are not enough on this baby. Recommended action is to update (well sometimes downgrade) the BIOS to a version that makes things work... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dma error
It seems ryan chris wrote: versions this happened on: 4.8-release, 5.1-release, 5.1-current with dma enabled, panics with anic errors occur left and right during intensive hdd i/o... examples are during a non-minimal sysinstall, and during a tar -xvf of the entire ports collection this is on an asus a7v-ve ( http://www.hp.com/cposupport/personal_computing/support_doc/bph07371.html ) -bash-2.05b$ dmesg|grep atapci atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 disabling dma seemed to fix the problem You have one of the bug ridden VIA 82c686B southbridges, and the normal procedure for fixing this problem is to get a new BIOS that programs the chipset correctly.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3112 controller
It seems Petri Helenius wrote: Should there be an option to run atacontrol in sysinstall? hmm, maybe... So that drives could be assigned to a mirror / stripe set before installing without having to build the mirror on another machine first? (in this case the BIOS does not help) You cant boot from a stripe on a controller that doesn't have a BIOS to do it. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3112 controller
It seems Petri Helenius wrote: Just saw the support for the controller go in. Does the driver support any RAID1 style mirroring? Only our own ATA RAID (see atacontrol).. I do have an Adaptec 1210 that has RAID capabilities and I have deciphered their RAID config info, but support is not finished yet. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: questions on S-ATA and ICH5 (now owns hardware :)
It seems John Reynolds wrote: Hi all, a few weeks back I had asked whether -current supported ICH5's S-ATA and Søren stated that he'd put code in to detect it and it should work but there wasn't a lot of feedback yet from users. Well, I have some feedback. I just got a new spiffy 120Gb Seagate S-ATA drive today and I can say that -current (as of 7/22/2003) does at least see the drive plugged into the controller and I can build filesystems, copy/delete files to my heart's content. However, I'm not sure if everything is entirely correct. I'm attaching a verbose dmesg (somewhat trimmed). The first thing I notice is that I see the following bits: atapci1: Intel ICH5 SATA150 controller port 0xd000-0xd00f,0xcc00-0xcc03,0xc800-0xc807,0xc400-0xc403,0xc000-0xc007 irq 9 at device 31.2 on pci0 ... ata2: at 0xc000 on atapci1 ad4: success setting UDMA133 on Intel ICH5 chip ad4: ST3120023AS/3.01 ATA-6 disk at ata2-master ad4: 114473MB (234441648 sectors), 232581 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, UDMA133 ad4: piomode=12 dmamode=34 udmamode=70 cblid=1 Shouldn't this drive be found as a SATA150 device? Well, technically yes, but in practice the modes the drives reports back as supported are the old UDMA ones, however the interface will run at SATA150 speed no matter what. I've not found a surefire way to tell this apart yet that also gives resonable results if you use a SATA-PATA dongle and other wierd comboes now possible... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata tagged queuing support question
It seems mitrohin a.s. wrote:
ata-disk.c
/* use tagged queueing if allowed and supported */
#if 0 /* disable tags for now */
if (ata_tags ad_tagsupported(adp)) {
adp-num_tags = atadev-param-queuelen;
adp-flags |= AD_F_TAG_ENABLED;
adp-device-channel-flags |= ATA_QUEUED;
if (ata_command(atadev, ATA_C_SETFEATURES,
0, 0, ATA_C_F_DIS_RELIRQ, ATA_WAIT_INTR))
ata_prtdev(atadev, disabling release interrupt failed\n);
if (ata_command(atadev, ATA_C_SETFEATURES,
0, 0, ATA_C_F_DIS_SRVIRQ, ATA_WAIT_INTR))
ata_prtdev(atadev, disabling service interrupt failed\n);
}
#endif
tagged queueing broken in -current? i have IBM ICxAV drives and want
to use this feature. can i enable this block?
It doesn't work for now, and question is if it will ever be enabled
again as it causes more problems than it solves.
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata tagged queuing support question
It seems mitrohin a.s. wrote: On Thu, Jul 24, 2003 at 04:08:01PM +0200, Marcin Dalecki wrote: tagged queueing broken in -current? i have IBM ICxAV drives and want to use this feature. can i enable this block? Don't. It's very frequently broken by *hardware* and not worth the trouble in terms of performance. hmm... but RELENG_4 enable this... Yes, and its problematic there as well, but I havn't gotten around to do anything about it yet (ENOTIME)... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HPT372 bug summary [was: RE: escalation stage 2]
It seems Harald Schmalzbauer wrote: I also think the RAID configuration is stored on the disks since when I create a non-DOS compatible slice (starting at 0 not 63) the RAID configuration vanishes. Yes the Highpoint BIOS uses sector 9 to hold the RAID config, so if you use that for other data storage you are lost.. (blaim Highpoint sufficiently here). Now I assume that there are two different RAID configurations, one stored on disk by the controllers BIOS and anotherone which FreeBSD stores elsewhere (e.g: with the sil0680 I can well create slices starting at 0). No, the info is *always* stored on disk, but when you make a FreeBSD native ATA RAID its put at the end of disk, and the disksize is reduced so you cannot overwrite it (so does Promise controllers) Now when one drive fails both configurations are marked degraded but in a different manner (because there is one array named RAID1_1 and a second which is named FreeBSD) And that's why FreeBSD panics until I delete the mirror relationship. Well Highpoints way of dealing with broken arrays and lost disks are less than optimal, I've tried to do my best in the ATA driver to fool the HPT system, but its not perfect... Since this is my most important server I can't help you the next weeks. On sunday I'll buy a SIL0680 based controller because I did the same test with it and it's working. Now I'm currently setting up FreeBSD and building a kernel with DDB. If you are not using 5.1-current the sil680 is dangerous until I get time to backport some critical fixes... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: errors using wi driver in -CURRENT
It seems Bruce Cran wrote: Just to chime in here, I've spent 2 weeks of various trial and errors to get two Lucent Wavelan's (one 4.8, one -current) to talk to each other. Dispite my more or less futile experiments this would not work no matter what (even asking on -mobile and trying what came up there didn't help). Since I can use the cards perfectly between two 4.8 boxes (and have been for about 2 years), my take is that the wi driver in -current is borked useless, at least for some cards (It worked in 5.0 but broke on the way to 5.1 IIRC). just my .01 EUR... I've just reinstalled a 'desktop server' from FreeBSD 4.8 to -CURRENT, and am finding quite a few problems with the 802.11b driver.I'm trying to use it as a access point, so I've tried setting the flag0,adhoc mediaopt, since ibss-master which I had used under 4.8 didn't work. This appeared to work, but other computers couldn't connect. Now, using just 'adhoc' other computers can connect, but whenever any use the network, the rate shown in 'ifconfig wi0' drops to 2MBit/s and I only get about 100KB/s bandwidth. Also, whenever I try to reset the media and/or mediaopt settings using eg 'ifconfig wi0 media DS/11Mbps mediaopt adhoc', the driver or card seems to go a bit buggy, with messages like: wi0: bad alloc 2f2 != 1f7, cur 0 nxt 0 wi0: device timeout wi0: device timeout wi0: timeout in wi_cmd 0x0021; event status 0x0008 when I run 'ifconfig' wi0 output stalls for a few seconds, locking the system, while another kernel error message appears. I'm using the card with a PCI converter card, and the card itself is: wi0: MELCO WLI-PCM-L11 at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:01:02:03:04:05 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (8.36.1) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps on initial configuration, the Media line of ifconfig is: media: IEEE 802.11 Wireless Ethernet DS/11Mbps adhoc (none) when I was recently getting ~35KB/s to the card, the 'OACTIVE' flag on the interface was set. I can provide more information which can help in diagnosing the problem, if required. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Silicon Image SiI 3112 Serial ATA controller support?
It seems Arjan van Leeuwen wrote: Hi, Is the Silicon Image SiI 3112 Serial ATA controller supported in -CURRENT, or is anybody working on support? I have one here (on a Asus A7N8X mainboard), but the controller is not recognized at boot. If I can help anyone with information about the system, that'd be very nice - I'd like to have support for those fast Western Digital Raptors :). I committed support for that couple of days ago: ata-chipset.c: revision 1.32 date: 2003/07/02 10:50:44; author: sos; state: Exp; lines: +114 -46 Update the SATA support code to work more correctly with real SATA disks now that I can test it. Add support for the SiI 3112 SATA chip using memory mapped I/O. Update the support for the SiI 0680 to use the memio interface as well. Sponsored by: David Leimbach [EMAIL PROTECTED] (3112 based controller) Sponsored by: FreeBSD Systems (www.FreeBSDsystems.com) (SATA disks) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Promise SX6000 - error 128 lba 0
It seems Gorm J. Siiger wrote: I have installed FreeBSD 5.1 from CD onto a machine with a Promise SX6000 controller with a RAID5 on 360GB. The installation went very well, but when the machine start to boot from the disk, the console shows: You cant boot from a sx6000 controller, our bootblocks does something stupid that the sx6000 BIOS doesn't understand... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Promise SX6000 - error 128 lba 0
It seems Gorm J. Siiger wrote: You cant boot from a sx6000 controller, our bootblocks does something stupid that the sx6000 BIOS doesn't understand... Damn, can I put the bootblock on another device ? CD for example. Sure, you can mount the pst devices as soon as the kernel is running, so you just need to get the thing off the ground (CD, floppy, ZIP, flash whatever) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: features of ICH5/ICH5-R supported in -current or 5.1-RELEASE?
It seems John Reynolds wrote: Hi all, I'm wondering if some of the features of the ICH5 found in the springdale and canterwood platforms (i865/i875) are currently supported in either 5.1-RELEASE or -CURRENT? I've read through some of the ATA code commits and see a few comments related to ICH5 and I believe I spotted where the plain ATA controller is recognized (and in theory fully supported as this shouldn't have changed from ICH4). But I still have questions about the following: 1) S-ATA: Is the S-ATA controller in ICH5 supported and if not, are there plans to support it? If not, is the problem documentation or hardware to test with? I have committed code to support the SATA part of the ICH5, but so far noone has been able to test it and get back to me with results.. 2) RAID: The ICH5-R supports RAID0 (and I guess RAID1 as well). Will this be a supported platform for RAID? If possible yes, either I need docs on how the RAID config are laid out on disk, or someone needs to reverseengineer how its done, then support for that format is easily added to ata-raid.c.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
It seems Bill Paul wrote:
In message [EMAIL PROTECTED], M. Warner Losh writes:
Here's a better patch, basesd on wpaul's input. Bill, can you try it
an see if it works for you? If so, i would be better to commit this
one. If not, I'll work with you to fix it.
FYI, I have a no-name (PCMCIA/CD-ROM) drive that also requires
failure of the second IO range to be made non-fatal. How about just
deleting the `else' clause as in the patch below? It seems that
this can only affect CD-ROM drives that were otherwise not working,
so it should be fairly safe.
This patch also tests good with my drive.
Thats what I proposed on the unnamed IRC channel yesterday, its fine by
me as well, can we agree to commit just this then ?
Index: ata-card.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/dev/ata/ata-card.c,v
retrieving revision 1.14
diff -u -r1.14 ata-card.c
--- ata-card.c 17 Jun 2003 12:33:53 - 1.14
+++ ata-card.c 26 Jun 2003 23:00:01 -
@@ -131,10 +131,6 @@
start + ATA_ALTOFFSET, ATA_ALTIOSIZE);
}
}
-else {
- bus_release_resource(dev, SYS_RES_IOPORT, rid, io);
- return ENXIO;
-}
/* allocate the altport range */
rid = ATA_ALTADDR_RID;
-Søren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads up: checking in change to ata-card.c
I do have problems with the wording you use in the comments in that patch mentioned below, I will even say that I will remove that as soon as it appears *and* shoot the committer so it doesn't happen again to use your choice of wording.. Now, I dont think this way is productive at all, and would appreciate if we could have a civilized way of doing this instead... This is exactly the crap that makes one wonder if the time used on the project is well spent... -Søren It seems Bill Paul wrote: A long time ago, circa FreeBSD 4.3, my Sony PCMCIA CD-ROM drive with brain-damaged Teac ATA controller drive worked, and the people were content and all was right with the land. Then my 4.4 CD set arrived, and I was disappointed to find the install kernel would lock up after the driver was probed. Complaints were made and epithets were hurled, and lo, in 4.5-RELEASE, all was well once again. Then came 4.6-RELEASE, and it was broken again. Then came 4.6.2, and it was still broken. And in 4.7. And 4.8. And 5.0. (Yeah yeah, shut up.) I just got my 5.1-RELEASE CDs and guess what? My CD-ROM drive STILL doesn't work!!! Guys, there's nothing more frustrating than getting a brand new CD set in the mail and not being able to install via CD. So I'm not leaving it up to chance anymore. I have a patch to make my drive work here: http://www.freebsd.org/~wpaul/ata-card.c.diff-5.1 I have no idea what the altio port remapping goop in ata_pccard_probe() is supposed to accomplish, but I'm telling you all right now, it doesn't work with my drive. I have specifically added to code to skip the remapping for drives with the product string of NinjaATA- (the problem with the Teac controller is that its vendor/product ID is 0x/0x, so there's really no better way to indentify it). This patch changes this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 device_probe_and_attach: ata2 attach returned 6 Into this: ata2: NinjaATA- at port 0x180-0x187,0x386-0x387 irq 9 function 0 config 33 on pccard0 acd0: CDROM CD-224E at ata2-master PIO4 Now, I'm sending out this notification that I _WILL_ check this patch in before I leave the office today. I'm not asking for permission. I've been waiting for half a dozen releases for this to get fixed. When 5.2-RELEASE arrives in my mailbox, it _WILL_ install from CD-ROM on my laptop or so help me I will find the responsible parties and force them to listen to RMS sing Free The Software -- _live_ -- until their ears bleed. I have tested this patch. It compiles. It works. I can mount CDs successfully and transfer stuff from them to my heart's content. I've reduced the change down to the absolute minimum and insured that it won't affect any other drives except mine. It's going in. Period. I am not leaving it up for debate, because if I do, all that will happen is that people will argue over what the more correct fix should be, and at this point I _just_ _don't_ _care_. I want my drive to work, and this does it. Understand? Good. This concludes my announcement. Thank you all for your attention. Don't forget to tip the waitress. -Bill P.S.: Be sure to join us next time when I ream out whoever it was that broke support for my 3Com 3c575C cardbus ethernet NIC. -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = If stupidity were a handicap, you'd have the best parking spot. = ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem installing 4.7/4.8, etc
It seems Thomas Dickey wrote: I'm setting up a new machine, and none of the current *BSD's install on it. Linux works. The *BSD's choke during the device identification. Perhaps someone on this list knows why. Attaching a copy of dmesg output from one of the Linux's I installed. The *BSD's appear to be missing an interrupt in the IDE/PCI bus hardware (about which I know little ;-) Hmm from the dmesg's it looks like a fairly new SiS chipset which is only supported in 5.1 forward, doesn't that work ? and if not how exactly does it fail ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problem installing 4.7/4.8, etc
It seems Hideyuki KURASHINA wrote: From your attached dmesg, PCI: Using IRQ router SIS [1039/0008] at 00:02.0 [...] SIS5513: IDE controller on PCI bus 00 dev 15 PCI: Found IRQ 5 for device 00:02.5 SIS5513: chipset revision 0 SIS5513: not 100% native mode: will probe irqs later SiS5513 ide0: BM-DMA at 0x4000-0x4007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0x4008-0x400f, BIOS settings: hdc:DMA, hdd:pio My first machine, that is about 8 years old model, has SiS 5513. It works here since I installed FreeBSD snapshot as of the end of 2003/05. Uhm I dont think this is such an old chip actually, all SiS ATA parts say they are a 5513 :/ but sadly it comes in many flavors... Recent FreeBSD 4.x would fail to boot because it does not have src/sys/dev/ata/ata-chip.c, I think. Soren, My understanding is OK, isn't it? Yes, the ATA drivers chipset support part has been radically changed and updated in 5.1/current, the old 4.x ATA driver doesn't understand the newer SiS parts (and the support for some of the old is wrong as well)... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA DMA broken/kernel panic with 5.1-R/5.1-C and VIA 82C586B
It seems Nicolai E M Plum wrote: Hi I installed 5.1-RELEASE from the CD images, and have problems using DMA on my ATA discs. I get the same problem on several discs, both several years old and brand new, across several vendors. 4.6-RELEASE handles the discs fine. Relevant excepts from the boot messages are below, the entire thing can be seen at http://www.esperi.org/nicolai/misc/dmesg.eriador FreeBSD 5.1-RELEASE #0: Thu Jun 5 02:55:42 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC ... atapci0: VIA 82C586B UDMA33 controller port 0xfcd0-0xfcdf mem 0xfbffe000-0xfbff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ... Timecounters tick every 10.000 msec ad0: 114473MB ST3120022A [232581/16/63] at ata0-master UDMA33 ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. done ... [ this repeats ] ad1: trying fallback to PIO mode ata0: resetting devices .. done Mounting root from ufs:/dev/ad0s1a I noticed some ATA problems solved in -current recently, so I tried compiling a kernel from sources about 2 days ago. Booting from that (GENERIC) kernel, I do not get Mounting root.., instead I get (approximately, can't cut/paste that console): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x8:0xdeadcode stack pointer = 0x10:0xc736bc38 frame pointer = 0x19:0xc736bc50 current process = 21 (irc14: ata0) kernel: type 12 trap, code=0 Is this a known problem, perhaps specific to the 82C586B ATA controller? This looks strange, I dont have semilar HW here to verify the problem so I'm a bit in the dark. Is it possible you can build a kernel with ddb in it so we can get a traceback of the panic ? -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interesting problem
It seems David Leimbach wrote: So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? There is no ATA support that is not included in the stock GENERIC kernel, so I'm not sure what you mean here ? It would be helpfull to know what controller and disk we are talking about, 'a' SATA controller and disk isn't really helpfull :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interesting problem
It seems dave wrote: It seems David Leimbach wrote: So... I have this nice SATA drive and controller which I believe is supported by FreeBSD but not in the default build for releases. What is the best way to cross-build a version of FreeBSD's release ISOs that will include drivers not included in the default distribution? Or is it possible to supply a driver during sysinstall time to have FreeBSD recognize my hard disk? There is no ATA support that is not included in the stock GENERIC kernel, so I'm not sure what you mean here ? It would be helpfull to know what controller and disk we are talking about, 'a' SATA controller and disk isn't really helpfull :) Interesting... I thought for certain someone had told me there was a driver for the Silicon Image Sil 3112A Controller in FreeBSD. No, that one is no supported (yet). The disk is a Western Digital Raptor http://www.westerndigital.com/en/products/serialata/ EnterpriseDrives.asp#spec So far it works quite nicely with Mandrake 9.1. I have another disk I can load FreeBSD onto. How would I go about getting/adding support for this controller? Get me a 3112 based controller on my desk :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Flushing CD-ROM?
It seems Sergey Matveychuk wrote: Why 5.1 flush acd0 on shutdown? - syncing disk, buffers remaining... done Uptime ... acd0: timeout waiting for cmd=e7 s=01 e=04 acd0: flushing device failed The operating system has halted. - Well, it's cd-writer really, but there is no disk there any way. The reason is that the I support flush bit in the cap page cannot really be trusted, so I issue the flush command to all devices just to sure that those that can flush does. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA broken on alpha?
It seems Peter Wemm wrote: Do you need more details or is that enough of a clue? I can see what the problem is, I'll have to look to find the reason... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Broken DMA devices
It seems The Anarcat wrote: On Tue Mar 25, 2003 at 08:16:28AM +0100, Soeren Schmidt wrote: It seems The Anarcat wrote: Can't the ata drivers detect that condition or recognize the set of drives that are broken instead of penalizing everyone else? ATAPI DMA is more likely to be broken than to be working, it is a function of both controller chip and device, in some situations even a function of what master/slave device combo we have.. There is a reason that almost all OS's out there has it disabled as default :) Thanks for those precisions... This could be a FAQ, pertaining also to how to enable it. So it's enabled system-wide? Can't it be done at the bus or device level? You can set the transfer mode of any ATA/ATAPI device with atacontrol... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken DMA devices
It seems The Anarcat wrote: hw.ata.atapi_dma=1# Run the CD-ROM/DVD in DMA mode to /boot/loader.conf. This should be in almost EVERY /boot/loader.conf. The default is 0 (PIO) because DMA is broken on at least a few early CD readers, but it is very rare to have it fail. (I've never seen it.) Can't the ata drivers detect that condition or recognize the set of drives that are broken instead of penalizing everyone else? ATAPI DMA is more likely to be broken than to be working, it is a function of both controller chip and device, in some situations even a function of what master/slave device combo we have.. There is a reason that almost all OS's out there has it disabled as default :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 2106] RE: ACPI-CA import/new diff?
It seems Takanori Watanabe wrote: Would you try it? http://people.freebsd.org/~takawata/acpi-20030321.diff http://people.freebsd.org/~takawata/acpica-freebsd-20030321.tar.gz Just did here, ASUS P4S8X board, With the CVS version power off doesnt work, it prints the power system off using ACPI waits a couble seconds, prints that the ACPI poweroff function timed out and reboots :( With the above applied it is even worse, it prints the power system off using ACPI and then hangs the system without powering off :( :( Besides this both seems to work, except they both find dual CPU's which I dont have :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
It seems [EMAIL PROTECTED] wrote:
On 15-Mar-2003 Soeren Schmidt wrote:
atapci0: SiS 961 UDMA100 controller port 0xff00-0xff0f at device 2.5 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: DMA limited to UDMA33, non-ATA66 cable or device
ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA33
ad1: DMA limited to UDMA33, non-ATA66 cable or device
ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave UDMA33
ata1-master: DMA limited to UDMA33, non-ATA66 cable or device
acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master UDMA33
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
ad0: DMA limited to UDMA33, non-ATA66 cable or device
ad0: 38166MB ST340823A [77545/16/63] at ata0-master UDMA33
Could I have you both try this patch and mail me the entire output og
dmesg with it applied ? (patch against a clean -current)
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.14
diff -u -r1.14 ata-chipset.c
--- ata-chipset.c 12 Mar 2003 15:45:52 - 1.14
+++ ata-chipset.c 16 Mar 2003 10:49:02 -
@@ -95,8 +95,8 @@
static void ata_sis_setmode(struct ata_device *, int);
static int ata_mode2idx(int);
static int ata_check_80pin(struct ata_device *, int);
-static int ata_find_dev(device_t, u_int32_t, u_int32_t);
-static struct ata_chip_id *ata_match_chip(device_t, struct ata_chip_id *);
+static int ata_find_dev(device_t, u_int32_t, u_int32_t, int);
+static struct ata_chip_id *ata_match_chip(device_t, struct ata_chip_id *, int);
static int ata_default_interrupt(device_t);
static void ata_pci_serialize(struct ata_channel *, int);
@@ -171,7 +171,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -321,7 +321,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -428,7 +428,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -601,7 +601,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -768,7 +768,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -887,7 +887,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -944,7 +944,7 @@
char *desc, buffer[64];
uintptr_t devid = 0;
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
/* if we are on a SuperTrak SX6000 dont attach */
@@ -1188,7 +1188,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1276,7 +1276,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1489,9 +1489,9 @@
{ ATA_SIS646, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 645DX },/* ext south */
{ ATA_SIS645, 0x00, SIS_SOUTH, 0, ATA_UDMA6, SiS 645 }, /* ext south */
{ ATA_SIS640, 0x00, SIS_SOUTH, 0, ATA_UDMA4, SiS 640 }, /* ext south */
- { ATA_SIS635, 0x00, SIS100NEW, 0, ATA_UDMA5, SiS 635 }, /* unknown */
+ { ATA_SIS635, 0x00, SIS100NEW, 0, ATA_UDMA5, SiS 635 }, /* 1chip */
{ ATA_SIS633, 0x00, SIS100NEW, 0, ATA_UDMA5, SiS 633 }, /* unknown */
- { ATA_SIS630, 0x30, SIS100NEW, 0, ATA_UDMA5, SiS 630S }, /* 1chip */
+ { ATA_SIS630, 0x30, SIS100OLD, 0, ATA_UDMA5, SiS 630S }, /* 1chip */
{ ATA_SIS630, 0x00, SIS66,0, ATA_UDMA4, SiS 630
Re: SiS5591(?) ATA
It seems [EMAIL PROTECTED] wrote: jmmr# dmesg | egrep '(ad0|ata|ATA)' pci0: mass storage, ATA at device 2.5 (no driver attached) ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 ad0: 38166MB ST340823A [77545/16/63] at ata0-master PIO4 acd0: CDROM ASUS CD-S500/A at ata1-master PIO4 Please make sure that ata-chipset.c is rev 1.14 which corrected a bug in the chip ident function... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SiS5591(?) ATA
It seems [EMAIL PROTECTED] wrote:
On 15-Mar-2003 Soeren Schmidt wrote:
Please make sure that ata-chipset.c is rev 1.14 which corrected a
bug in the chip ident function...
ata-chipset.c 1.14 was checked in on March 12 my kernel is from two days after.
So I guess it is included. I cvsuped the same sources I used to compile my
current system and it is 1.14.
Hmm, OK, try this patch:
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.14
diff -u -r1.14 ata-chipset.c
--- ata-chipset.c 12 Mar 2003 15:45:52 - 1.14
+++ ata-chipset.c 15 Mar 2003 19:02:13 -
@@ -95,8 +95,8 @@
static void ata_sis_setmode(struct ata_device *, int);
static int ata_mode2idx(int);
static int ata_check_80pin(struct ata_device *, int);
-static int ata_find_dev(device_t, u_int32_t, u_int32_t);
-static struct ata_chip_id *ata_match_chip(device_t, struct ata_chip_id *);
+static int ata_find_dev(device_t, u_int32_t, u_int32_t, int);
+static struct ata_chip_id *ata_match_chip(device_t, struct ata_chip_id *, int);
static int ata_default_interrupt(device_t);
static void ata_pci_serialize(struct ata_channel *, int);
@@ -171,7 +171,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -321,7 +321,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -428,7 +428,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -601,7 +601,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -768,7 +768,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -887,7 +887,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -944,7 +944,7 @@
char *desc, buffer[64];
uintptr_t devid = 0;
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
/* if we are on a SuperTrak SX6000 dont attach */
@@ -1188,7 +1188,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1276,7 +1276,7 @@
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1501,7 +1501,7 @@
{ 0, 0, 0, 0, 0, 0 }};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, -1)))
return ENXIO;
if (idx-cfg1 == SIS_SOUTH) {
@@ -1511,7 +1511,7 @@
sprintf(buffer, SiS 96X %s controller,ata_mode2str(idx-max_dma));
}
else {
- if (ata_find_dev(dev, ATA_SISSOUTH, 0x10))
+ if (ata_find_dev(dev, ATA_SISSOUTH, 0x10, pci_get_slot(dev)))
idx-cfg1 = SIS133OLD;
else {
idx-max_dma = ATA_UDMA5;
@@ -1659,7 +1659,7 @@
{ 0, 0, 0, 0, 0, 0 }};
char buffer[64];
-if (!(idx = ata_match_chip(dev, ids)))
+if (!(idx = ata_match_chip(dev, ids, pci_get_slot(dev
return ENXIO;
sprintf(buffer, %s %s controller, idx-text, ata_mode2str(idx-max_dma));
@@ -1808,16 +1808,16 @@
}
static int
-ata_find_dev(device_t dev, u_int32_t devid, u_int32_t revid)
+ata_find_dev(device_t dev, u_int32_t devid, u_int32_t revid, int slot)
{
device_t *children;
-int nchildren, i, slot = pci_get_slot(dev);
+int nchildren, i;
if (device_get_children(device_get_parent(dev), children, nchildren
Re: SiS5591(?) ATA
It seems FUJITA Kazutoshi wrote: become better. but still it does't work in UDMA100. atapci0: SiS 961 UDMA100 controller port 0xff00-0xff0f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 78533MB IC35L080AVVA07-0 [159560/16/63] at ata0-master UDMA33 ad1: DMA limited to UDMA33, non-ATA66 cable or device ad1: 39266MB IC35L040AVER07-0 [79780/16/63] at ata0-slave UDMA33 ata1-master: DMA limited to UDMA33, non-ATA66 cable or device acd0: DVD-R MATSHITADVD-RAM SW-9571 at ata1-master UDMA33 Hmm, the cable detection sems to be failing somehow... Now is the chip found correctly ? is it *really* a SiS 961 (old ATA100 model)? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
It seems Bruce R. Montague wrote:
I'll look into it, thanks for reporting!
Hi, the current -current ata driver panics at boot
when using the CS5530 (National GX1, ex-cyrix).
This driver worked in the past on -current, likely
up until the major rework that appears to be
underway as of 20-Feb-2003 (that is, the creation
of ata-chipset.c, etc.)
Routine ata_cyrix_setmode() in ata-chipset.c
appears to be assuming that channel-dma has a
valid pointer to a struct ata_dma_funcs, and
that channel-r_bmio is a valid bus resource
id. This is not the case, both channel-dma and
channel-r_bmio (bus master I/O supported) are
0, which will result in panics. The first use (and
panic) occurs at:
atadev-channel-dma-alignment = 16;
ata_cyrix_setmode+0x8b: movl $0x10,0x20(%eax)
on my build (%eax is 0).
These panics occur regardless of the setting of
TUNABLE_INIT() ata_dma.
Routine ata_dmainit(), which mallocs the struct
ata_dma_funcs is (likely correctly) never called.
If required due to DMA support, it is allocated
during the driver probe via ctlr-dmainit(ch)
in ata_pcisub_probe() in ata-pci.c.
To make the system come up, I replaced
ata_cyrix_setmode() with the following:
static void
ata_cyrix_setmode(struct ata_device *atadev, int mode)
{
int error;
mode = ata_limit_mode(atadev, mode, ATA_UDMA2);
error = ata_command(atadev, ATA_C_SETFEATURES, 0, mode,
ATA_C_F_SETXFER, ATA_WAIT_READY);
if (bootverbose)
ata_prtdev(atadev, %s setting %s on Cyrix chip\n,
(error) ? failed : success, ata_mode2str(mode));
atadev-mode = mode;
}
This seems to work, I am using the system without
apparent problems, but it is strictly a by guess
and by god fix - I haven't studied or understood
the whole new ata driver scaffolding.
What is (a) correct fix? Is there a better and
more complete thing envisoned? Is there a tunable
I don't understand? Or a feature flag? Is the
current cyrix code in transit and untested?
Should ata_dma or r_bmio be checked in the
setmode codepath? Can I help assure this is fixed
right? I can at least test, if need be.
As a minor question, is the style to allocate
malloced data structures (such as ata_dma_funcs)
in the probe code instead of attach code, as seems
to be the intent in this driver, and leave permanent
bus resource allocation until the attach? (in this
case the ata_pcisub_probe() never reaches the
allocation code because it checks and finds r_bmio
is 0).
- bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
It seems Bruce R. Montague wrote: Routine ata_cyrix_setmode() in ata-chipset.c appears to be assuming that channel-dma has a valid pointer to a struct ata_dma_funcs, and that channel-r_bmio is a valid bus resource id. This is not the case, both channel-dma and channel-r_bmio (bus master I/O supported) are 0, which will result in panics. The first use (and panic) occurs at: OK, just looked a bit more closely at this, if the r_bmio address is not set in the chipset registers something is wrong as these are used to setup PIO and DMA timings in the chipset. So if your BIOS doesn't set the bmio address, there is *no way* I can set any modes on your HW, ie you need to use whatever mode the BIOS has setup for you. Could you please dump the pci reg 0x20 (with pciconf) and verify that it is endeed 0 ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA CS5530 (cyrix) driver panic (ata_cyrix_setmode())
It seems Bruce R. Montague wrote:
/* is busmastering supported ? */
if ((cmd (PCIM_CMD_PORTEN | PCIM_CMD_BUSMASTEREN)) ==
(PCIM_CMD_PORTEN | PCIM_CMD_BUSMASTEREN)) {
failed because cmd was 0x01 instead of 0x05 (the
PORTEN | BUSMASTEREN is 0x05). The 5530 datasheet
(well, SC1200 datasheet) says cmd bit 2 (Bus
Master) must be set to 1... why isnt it?
Changing the code at the top of ata_pci_attach()
from:
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
to:
pci_write_config(dev, PCIR_COMMAND, 0x05, 2 );
cmd = pci_read_config(dev, PCIR_COMMAND, 2);
causes the driver to not to panic on ata_cyrix_setmode();
it appears to complete both the probe and attach boot
operations.
Now the driver is dying (the system is hanging)
at the first attempt to use dma, that is, after
the first call to ata_dmastart(). The
ata_dmastart() completes ok, but the system
immediatly hangs (it appears up, but spinning at
interrupt level or somesuch, I can sometimes break
into ddb or scroll the console a bit before things
totally freeze). I'll see what else I can find.
Thats probably because the HW hasn't been setup to be able to
do busmastering.
The older version of -current doesn't have this
problem. I'll see if I can find why. It's the
same hardware, I can boot either system and the
old ata driver works ok. I'm debugging the new
-current under the old working -current. Did
something change in the PCI initialization that's
likely a cause?
Setting up busmastering and the enabled bit is a BIOS thing, I
only test for it being enabled and that has not changed in the
ATA driver for a lg time.
Now the driver fails to survive a missing DMA bit, and thats a
bug alright, the following patch should solve that:
Index: ata-chipset.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.11
diff -u -r1.11 ata-chipset.c
--- ata-chipset.c 3 Mar 2003 11:51:08 - 1.11
+++ ata-chipset.c 9 Mar 2003 21:58:52 -
@@ -480,7 +480,10 @@
if (ata_default_interrupt(dev))
return ENXIO;
-ctlr-setmode = ata_cyrix_setmode;
+if (ctlr-r_bmio)
+ ctlr-setmode = ata_cyrix_setmode;
+else
+ ctlr-setmode = ata_generic_setmode;
return 0;
}
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Big IDE drive + little IDE controller + freebsd
It seems James Satterfield wrote: Hmm there is a workaround in -current for using 48bit access to the old promises, however it should only engage when you access areas beyond 137G on the drives. However using 48bit modes on older controllers are not really a good idea as they tend to do wierd things... Okay... Perhaps I'm just a dumbass with a failing drive? For the longest time, I've thought the hardware needed to support the large drives. From the reading I've just done, that doesn't seem to be the case. I certainly hope this brand new drive isn't failing tho. I really hate doing hardware warranty returns. James. On Fri, 7 Mar 2003 14:20:24 -0800 James Satterfield [EMAIL PROTECTED] wrote: I've got a 160GB ide drive in my FBSD box. It's got an old ide controller that doesn't support big ide drives. Yet freebsd recognizes the drives full capacity, allows me to partition it, and newfs it. After writing about 47GB of data to the drive, I start getting these. ad5: WRITE command timeout tag=0 serv=0 - resetting ata2: resetting devices .. atapci1: Promise UDMA66 controller port 0xef00-0xef3f,0xefe0-0xefe3,0xefa8-0xefaf,0xefe4-0xefe7,0xeff0-0xeff7 mem 0xffae-0xffaf irq 10 at device 20.0 on pci0 ad5: 156334MB Maxtor 4G160J8 [317632/16/63] at ata2-slave UDMA66 James. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA MODE_SENSE_BIG timeout
It seems David Xu wrote: (snip snap) acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: CD-RW SONY CD-RW CRX140E at ata1-slave PIO4 Hmm, can you use the acd1 device normally or does it fail (how) ? -Søren It is very rare that the CD-RW will be found now, kernel is always stuck there, so I must pull the device off or disable Second IDE in BIOS, I can not use it. OK, from the above it looked like it was found after the retries.. I'll try to reproduce the problem here, but so far no luck at that.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA problems
It seems Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: No tags, like you said. Previously, with a tags-capable kernel, enabling tags would cause a continuous stream of timeouts and resets on both disks. Just for kicks, I removed the #if 0 in ata-disk.c and got exactly the same symptoms as before: ad0: READ command timeout tag=0 serv=1 - resetting ad0: invalidating queued requests That why it is disabled, its not working for the time being. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA problems
It seems Dag-Erling Smorgrav wrote: Scotty [EMAIL PROTECTED] writes: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. Disable tags (add hw.ata.tags=0 to /boot/loader.conf). Never worked for me either (ASUS P5A, ALi M1543 southbridge, IBM DTTA and IC35L disks) Tags are disabled in -current in ata-disk.c so if the sources are up to date that cannot be the problem. Please update and then at least provide a dmesg if it still fails. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA MODE_SENSE_BIG timeout
It seems David Xu wrote: (snip snap) acd1: read data overrun 34/0 acd1: MODE_SENSE_BIG command timeout - resetting ata1: resetting devices .. done acd1: CD-RW SONY CD-RW CRX140E at ata1-slave PIO4 Hmm, can you use the acd1 device normally or does it fail (how) ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Me Too: HPT372 UDMA detection problem on current (was Re: High %interrupt when building world)
It seems Shizuka Kudo wrote: --- Bruce Cran [EMAIL PROTECTED] wrote: Just to add to this, when I run the above 'dd' command, I see top reporting 35-40% interrupt usage on the drive on the RAID controller, while it's 3-5% for the drive on the VIA controller, and the drive itself is: 0 READY ad4: 58644MB IC35L060AVER07-0 [119150/16/63] at ata2-master UDMA100 Bruce Cran To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I have sysctl -a showing hw.ata.ata_dma: 1, but atacontrol mode showing PIO4 for the drives attached to HP370A. Setting them to mode udma6 was just ignored. Fixed! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HPT372 UDMA detection problem on current
It seems Akinori MUSHA wrote: Hi, Using the latest CURRENT on my box, the ata driver fails to enable UDMA for the ATA133 disks connected to an on-board HPT372 controller. Besides, UDMA is not enabled for the CD/DVD-ROM drive which is capable of UDMA4 either, but this may be a feature or a default, I guess. Fixed! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Yet another ATA-related Kernel trap 12 :-(
It seems Terry Lambert wrote: Vladimir Kushnir wrote: Setup: Fujitsu MPG3409AT E disk on external CMD649 controller (the only HD). Kernel trap while booting with timeout for ad0 device. Setting hw.ata.ata_dma=0 solves the problem. Sources last cvsupped last night (after the last ATA-related commits). Dmesg output attached, but that's about all I can provide - no serial console here. This is probably related to the inverted sense-test that was recently fixed. Nope. FWIW: the CMD640 series of chips is well known to mung DMA, if an interrupt occurs during a transfer. I can't say for certain that the CMD649 has this problem, so you might want to look at the vendor errata for the chips. Personally, I avoid the CMD64x controllers entirely, so as to avoid getting a bad one, since I have no idea if there is actually a good one in existance. 8-(. The old CMD640 should be avoided at all costs, the newer CMD646 has problems thats taken care of pr revision. The newer CMD648/649 are OK but are not the best performers... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sis chipset
It seems Martin Blapp wrote: Hi, Is there a chance to get the built in 100MBit network adapter in the chipset working somehow? I thought I've fixed the support so it should work ? If not, do you have a pciconf -lv output for me ? It works on -current for me... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sis chipset
It seems Christoph P. Kukulies wrote: I have two network cards plugged in. But board has the builtin 100MBit, Soeren, it's the same board I sent to you. I will lookup in the bios (later) if I have disabled the on board NIC inadvertently (if that's possible) but at present make world is running. You must have disabled it (its possible in my BIOS but I upgraded to the latest in the hope that ACPI would work) I have: [EMAIL PROTECTED]:4:0: class=0x02 card=0x80a71043 chip=0x09001039 rev=0x91 hdr=0x00 sis0: SiS 900 10/100BaseTX port 0x9800-0x98ff mem 0xf500-0xf5000fff at dev ice 4.0 on pci0 pcib0: slot 4 INTA is routed to irq 5 sis0: Ethernet address: 00:e0:18:b5:0e:36 miibus0: MII bus on sis0 rlphy0: RTL8201L 10/100 media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UDMA66 vs ATAPI_DEVICE(atadev)?
It seems Andrew Gallatin wrote: After recent ATA commits, my Promise UDMA66 controller is now running its drives in PIO4 mode. Previously, UDMA66 was working fine. Here's a dmesg snippet: atapci0: Promise UDMA66 controller port 0xdf00-0xdf3f,0xdfe0-0xdfe3,0xdfa8-0xd faf,0xdfe4-0xdfe7,0xdff0-0xdff7 mem 0xfc8a-0xfc8b irq 2 at device 2.0 on pci0 ata2: at 0xdff0 on atapci0 ata3: at 0xdfa8 on atapci0 .. ad4: 19092MB ST320414A [38792/16/63] at ata2-master PIO4 The controller itself looks like this: [EMAIL PROTECTED]:2:0: class=0x018000 card=0x4d33105a chip=0x4d38105a rev=0x01 hdr=0x00 vendor = 'Promise Technology Inc' device = 'PDC20262 FastTrak66 EIDE Controller' class= mass storage I've found that I can recover from this problem by forcing ATAPI_DEVICE() to always return 1. It seems to want to return 0 for devices not on the primary ata controller. I'm confused.. What's the point of ATAPI_DEVICE()? Am I not allowed to use extra controllers anymore? ATAPI_DEVICE is used on those controllers that cannot do ATAPI DMA, the test here is bogusly reversed, I'll fix asap... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Yet another ATA-related Kernel trap 12 :-(
It seems Vladimir Kushnir wrote: Setup: Fujitsu MPG3409AT E disk on external CMD649 controller (the only HD). Kernel trap while booting with timeout for ad0 device. Setting hw.ata.ata_dma=0 solves the problem. Sources last cvsupped last night (after the last ATA-related commits). Dmesg output attached, but that's about all I can provide - no serial console here. I just committed a fix for that. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: the ata driver is broken
It seems Takahashi Yoshihiro wrote: I got the following error. The kernel config has no pci device but ATA_NOPCI option. Fixed. I just completely forgot that ISA only systems exists... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA problems
It seems Wesley Morgan wrote: This morning I booted a kernel built last night, and it panicked when trying to mount the root filesystem after this: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting devices .. ad0: removed from configuration done cvsup'd, built a new kernel, and now instead of a panic I get (with some extra stuff): Disable DMA for now, I'm working on a fix for this problem.. Are you willing to test patches to solve this problem ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems Alexander Leidinger wrote: On Sun, 23 Feb 2003 17:41:07 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: It seems that I managed to break the tagged queueing support somehow, so please disable tags while I look hunt for the problem.. For some of us it is broken since long ago... as you know. I hope you find the real problem which affects all of us, now that you are able to see it yourself. This is a new problem as far as I can tell, its most likely something I overlooked during the last round of changes... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems Paul A. Howes wrote: All; These two kernel options seem to have solved the problem. Builds now run smoothly and error-free. I read the comments in NOTES about these options and something clicked: I recall that most Pentium processors will only deal with 4 kB pages. Aren't 4 MB pages a feature of the Xeon processor, as it can address much more memory? If that is the case, then these options should be the default, and their inverse provided in the kernel configuration file (ENABLE_PSE ENABLE_PG_G). Just for the record but my [EMAIL PROTECTED]/533 512MB/DDR does *not* show this problem no matter how hard I beat it. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems leafy wrote: Try this: DON'T remove /usr/obj before doing a buildworld, just let it accumulate. It will show up someday (it's not deterministic). Even sh(1) can die during the build a long with make(1) and as and gcc. My P4 never showed such behaviour if I properl y remove /usr/obj before a build. Doesn't make any difference, the only way I (so far) has been able to reproduce this is by severely overclocking the CPU and RAM... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems Paul A. Howes wrote: Soren, I have a machine that uses a SiS 648, but it has other problems... I'm one of the unlucky individuals who bought the ASUS implementation of this board, and ended up with a flaky P.O.S. Uhm the board here is and ASUS P4S8X and it works like a charm -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems leafy wrote: Doesn't make any difference, the only way I (so far) has been able to reproduce this is by severely overclocking the CPU and RAM... -Søren I didn't believe it either at first. But I had kernel #54 before I first got thi s weird behavior. Ever since I have only kernel #0. If you do buildworld/buildkernel installworld/installkernel twice a day, you mig ht get to it sometime around 20 days. Well the box has been doing about 50 buildworlds aday in a loop for the last 4-5 days, I guess that should do it no ? :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cc: Internal error: Illegal instruction (program as)
It seems Terry Lambert wrote: Soeren Schmidt wrote: It seems Paul A. Howes wrote: I have a machine that uses a SiS 648, but it has other problems... I'm one of the unlucky individuals who bought the ASUS implementation of this board, and ended up with a flaky P.O.S. Uhm the board here is and ASUS P4S8X and it works like a charm You guys aren't listening again. It's a CPU implementation bug. Well, and you aren't telling again :( So, if you have the info you claim to have, it should be very easy to tell us exactly what conditions make this error surface, so we can test and find out if this is for real once and for all.. If not, well I dont need to tell you what to do then do I ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems Michael Class wrote: Hello Soeren, I am sorry, but the last demsg output I have sent was not complete. I had captured that from /var/log/messages which does not seem to contain everything... Enclosed is a new one done with a serial console. Here I think the culprit can be seen as lines like: (probe2:ata2:0:0:0): CAM Status 0x39 Anything I can do to help investigate this further? Loose atapi-cam please and let me know if that helps -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems that I managed to break the tagged queueing support somehow, so please disable tags while I look hunt for the problem.. I'll commit a disable tags patch to -current in a few... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! ATA driver updates...
I have corrected a number of problems on Serverworks ALI chipsets and it has been committed to -current. There is an outstanding problem with having tags enabled on ATA disks, and I have temporarily disabled tags support until I nail that nasty problem. So please update your sources and let me know if there is still any problems.. Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Mounting Root fails with error 22 (EINVAL)
It seems Anders Andersson wrote: On Sat, Feb 22, 2003 at 01:02:33PM +0100, [EMAIL PROTECTED] wrote: If you say int broke in the 20feb timeframe I think sos' ATA megacommit is the main suspect... Yes, sos ATA commit is what broke my sparc64 also (already informed sos in private mail), but he didnt have any direct ideas about the cause. Your problem is different, you dont see the disks due to missing interrupts, here the disks are found and read from but it falls apart later... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! ATA driver changes committed.
The first round of ATA updates/fixes has been committed, please let me know if you find any problems with it... The commitlog say: This moves all chipset specific code to a new file 'ata-chipset.c'. Extensive use of tables and pointers to avoid having the same switch on chipset type in several places, and to allow substituting various functions for different HW arch needs. Added PIO mode setup and all DMA modes. Support for all known SiS chipsets. Thanks to Christoph Kukulies for sponsoring a nice ASUS P4S8X SiS648 based board for this work! Tested on: i386, PC98, alpha and sparc64 -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATA PATCH updated!!
For those with ALI and ICH problems please try the updated patch: ftp://freebsd.dk/pub/ATA/ata-ng-diff-030214-1.gz Thanks! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PLEASE TEST - ATA driver patch (ATANG)...
I've prepared a patch that brings the ATA driver to the next level. This is mainly to prepare for other platforms which demanded some changes to the driver infrastructure. It also fixes lots of outstanding problems and adds support several new chipsets including SiS (thanks to Christoph Kukulies for sponsoring a brand new SiS648 based board making that possible!) Please test it out and remember that this is WIP, so use protective glasses and rubber gloves, you have been warned. I'd very much like reports on success/failure including a dmesg from the system, thanks! The patch can be fetched here: ftp://freebsd.dk/pub/ATA/ata-ng-diff-030213-1.gz Enjoy! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PLEASE TEST - ATA driver patch (ATANG)...
It seems Sheldon Hearn wrote: On (2003/02/13 14:00), Soeren Schmidt wrote: I've prepared a patch that brings the ATA driver to the next level. You've brought ata in under cam? ;-) That wouldn't be forward moving now would it ? Sorry, couldn't resist. Ditto. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PLEASE TEST - ATA driver patch (ATANG)...
It seems David Schultz wrote: Thus spake Soeren Schmidt [EMAIL PROTECTED]: I've prepared a patch that brings the ATA driver to the next level. This is mainly to prepare for other platforms which demanded some changes to the driver infrastructure. It also fixes lots of outstanding problems and adds support several new chipsets including SiS (thanks to Christoph Kukulies for sponsoring a brand new SiS648 based board making that possible!) Please test it out and remember that this is WIP, so use protective glasses and rubber gloves, you have been warned. Cool. I'll try these patches out this weekend. Is there a chance you could integrate the other half of the patch I sent you in January---the part that sends a FLUSH CACHE command to all disks at shutdown time? This measure should ensure that disks with large caches write out all data before the power to them is cut. Or are you working on a better way of solving this problem? There's also the problem jjramsey reported where some (perhaps broken) hardware required a small delay following the completion of an IDENTIFY command before the correct data are available to read, but that problem doesn't concern me directly. I have a list a mile long of fixes/suggestions/hacks, I'll get to them but this needes to be done first to move along... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kern/43345: Support for the SiS 651 ATA controller
It seems Aaron D. Gifford wrote: Then on one of the messages, I noticed a link to Patrick Bihan-Faou's problem report, read it, and tried out his patch under 5.0-CURRENT (having completed my install of 5.0-RELEASE and updated to -CURRENT). Of course the line numbers were a bit different, but a hand patch of the two files was quick and easy. A quick kernel recompile, BIOS re-enable of UDMA, and boot proved the patch worked! The patch does *not* work, the reason you have it sortof working is that the driver writes to the wrong regs, and your BIOS set up the mode correctly.. I have a working solution here, and it will get committed to -current as soon as I have it tested some more. This cannot easily be backported to -stable since it is part of a major rewrite of parts of the ATA driver. However when it has proven to be working, I'll try to get the SiS part backported to the older ATA driver in -stable, time permitting... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The cbus driver for pc98
It seems Takahashi Yoshihiro wrote: I have made the cbus driver for pc98 based on i386 isa driver. This completely removes that PC98 depends on isa driver and also corrects directory layouts (pc98/i386 - pc98/pc98 and pc98/pc98 - pc98/cbus). Soeren, please review the ata part. http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz That looks good to me, it does conflict with my current ATA version soon to be released but I'll try to integrate it there as well. It would be nice if we could get rid of the old wd* crap at the same time, forcing user to the new system seems to be the only way to get me proper error reports :/ -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
SiS pciconf's request ending :)
Thanks to all those that replied with pciconf output from various SiS chipsets (and thanks to those that sent from other systems as well :) ). I now have a significant amount of data to use for the SiS chipset support, and am working on it over the next days.. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA code is buggy and slower
It seems Dong Lin wrote: My 5.0R kernel complains about READ timeout and resetting when I try to dd the disk. But everything *works* if I boot the same equipment with 4.5R and 4.7R. It seems that the error can occur on any sector I pick as long as I keep reading it inside a loop, a sign of timing problems. The 5.0 ATA code is so different that I am not sure where to start. If someone can show me a way to run the 4.7 ATA code under 5.0, I am willing to debug it. My equipment: Promise ATA66 controller(0x4d38105a r01), WDC WD400BB ATA/100, ATA66 cable. Also, my simple dd measurements show that performance is going down: dd if=/dev/ad4 of=/dev/null bs=8m 4.5R: 49 MB/s 4.7R: 39 MB/s 5.0R: does not finish Grap the ATA driver (sys/dev/ata) from -currrent, there is a bug in the 48bit support code for old promises thats not fixed in 5.0. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Request for info from SiS chipset owners
I'm currently in the midst of an ATA chipset support mega rewrite/update, and the last item on the list is SiS support. That where _you_ come into the picture, I need a pciconf -l from your SiS based system! Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata0: resetting device - ASUS P4S8X
It seems Christoph Kukulies wrote: I bought new hardware for a server today, an ASUS P4S8X with an 1.8 GHZ P4 CPU, nothing fancy I would say, which has an onboard RAID controller (Promise) but I'm not using it for the moment. I attached an IBM 60GB Deskstar ATA/IDE disk to the IDE 1 port. FreeBSD 5.0R boots until the point where it says: ad0: READ command timeout tag=0 serv=0 - resetting ata0: resetting device Thats because that board uses a new SiS chips which is not supported yet. I'm currently working on it, but since I have no SiS based HW here in the lab it takes time and is not the top most priority... Meanwhile turn off DMA in loader.conf and then mail me the output from pciconf -l from that system... Hint to sponsors: I need a SiS based motherboard !! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
It seems Alexander Leidinger wrote: On Sun, 12 Jan 2003 20:35:41 +0100 (CET) Soeren Schmidt [EMAIL PROTECTED] wrote: Could your Zip disk be missing or bad? Usually I don't have a zip disk in the drive at boot time... I give it a try (tomorrow). I've tried both here, works just fine on a newly compiled current It seems I have no luck... not even that you can't reproduce the tagged queueing problem, you also can't reproduce this problem. Whats wrong with my system? :-( Dunno, but it is the 13'th today :) I've tried with a disk in the drive, same behavior. I'm going to update to todays sources, and start from a clean kernel compile directory... let's see how far I get then. Form a system compile from source 0800 today: ad0: 13042MB IBM-DPTA-371360 [26500/16/63] at ata0-master UDMA33 afd0: 96MB IOMEGA ZIP 100 ATAPI [32/64/96] at ata0-slave PIO0 acd0: CD-RW Hewlett-Packard DVD Writer 100 at ata1-slave PIO4 pst0: 17385MB PROMISE TECH. I2O RAID DEVICE [2216/255/63] on pstpci0 Mounting root from ufs:/dev/ad0a Thats without media in the ZIP drive, boots just fine, system in VIA 694 based so that should give me enough trouble :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
It seems [EMAIL PROTECTED] wrote: posted is also that you are running the atapi ZIP-drive as master and Soeren as slave, so maybe this could be a hint that something goes wrong with initialisation when atapi floppy-drives are attached as masters. That makes no difference I still cant get it to fail :( acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 13042MB IBM-DPTA-371360 [26500/16/63] at ata0-master UDMA66 afd0: 96MB IOMEGA ZIP 100 ATAPI [32/64/96] at ata1-master PIO0 Mounting root from ufs:/dev/ad0a -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA seems to lock up the system at boot (KT133A)
It seems Alexander Leidinger wrote: On Sun, 12 Jan 2003 06:49:18 -0800 walt [EMAIL PROTECTED] wrote: Could your Zip disk be missing or bad? Usually I don't have a zip disk in the drive at boot time... I give it a try (tomorrow). I've tried both here, works just fine on a newly compiled current -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Nate Lawson wrote: On Tue, 7 Jan 2003, Soeren Schmidt wrote: For those that are brave enough to play with this I just created the following small change to ata-raid.c. Now it will always rebuild the array on creation, using the first disk as the master image. This allows you to turn any set of ATA disks into a mirror on the fly.. Remember to rename you filesystems in fstab before booting :) Thanks, couple comments: * You should be able to use M_WAITOK in your mallocs for all funcs called by ioctl since you have a process context Good point.. * Shouldn't you only do the rebuild automatically if the raid type is AR_F_FREEBSD_RAID? It's not necessary if it's hw raid, right? If you create the RAID from within FreeBSD on a running system it is needed for all controllers. I also need to defer access through *strategy while doing the setup, and let it loose when the build is running. * Should this be optional so that it's not rebuilt every time you run atacontrol create? Yes, this was a quick fix, I need an extra argument from atacontrol to flag rebuilding. I'm in the process of refining the RAID ioctl interface so that I can use it for the SuperTrak (ie intelligent) controllers as well, we dont need more XXXcontrol programs... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Soeren Schmidt wrote:
It should work on 4.7 forward, but its been a while since I played with it.
Another thing is that its a pain to make a mirror on an already running
system (which is often wanted), so I plan to add an option to atacontrol
to tell where to get the master from, and then do an automatic rebuild
during the create phase ie:
atacontrol create RAID1 ad0 ad2 source ad0
This will create a mirror using ad0 and ad2, and start a rebuild to
build the master with data from ad0. This way you can do a normal
install, add a second (identical or bigger) disk, and make a
mirror out of those. You just have to change your fstab before
rebooting (ad0 - ar0) in order to boot...
For those that are brave enough to play with this I just created the
following small change to ata-raid.c. Now it will always rebuild the
array on creation, using the first disk as the master image. This
allows you to turn any set of ATA disks into a mirror on the fly..
Remember to rename you filesystems in fstab before booting :)
Index: ata-raid.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-raid.c,v
retrieving revision 1.50
diff -u -r1.50 ata-raid.c
--- ata-raid.c 2 Oct 2002 07:44:17 - 1.50
+++ ata-raid.c 7 Jan 2003 10:02:50 -
@@ -374,7 +374,14 @@
rdp-flags |= AR_F_READY;
ar_table[array] = rdp;
+
+/* kick off rebuild here */
+if (setup-type == 2) {
+ rdp-disks[1].flags = ~AR_DF_ONLINE;
+ rdp-disks[1].flags |= AR_DF_SPARE;
+}
ar_attach_raid(rdp, 1);
+ata_raid_rebuild(array);
setup-unit = array;
return 0;
}
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: Søren, This is a real temptation. Let me be sure that I'm understanding correctly. I have an old machine, but running today's current, with only one disk, ad0. Could I do the following? o- Add ad2 o- run atacontrol create RAID1 ad0 ad2 source ad0 o- change ad0s1a to ar0s1a through ad0s1f to ar0s1f in fstab o- reboot and enjoy my new mirror. Exactly, modulo the source ad0 bit which is not in atacontrol (yet), it will always the the first disk (ad0 here) in the mirror as the master to make the mirror from. If ar0 were to die, I would just take it out connect ar2 and boot as ? I could then do the same with a new mirror, I suppose? If one of the disks die, you can boot on the degraded mirror, one caveat is that your BIOS might not want to boot from ad2 just from ad0, if thats the case swap the drives, and boot... Then when you are up, atacontrol detach the failed device, swap it with a new one, atacontrol attach, atacontrol rebuild, voila... Another way is to boot the degraded mirror, then when its up you do a atacontrol delete to get rid of the mirror, remember to change your fstab back to adX instead of arX, and reboot... If I'm understanding correctly, I could use any disk ad0 as the mirror. Is that correct? Yes, as it is currently it must be on another non-RAID controller, or the BIOS on there will get mighty confused only having part of a RAID config on it :) One last question, what prompted you to preceed the patch with For those that are brave enough to play with this, where could it come back and bit me? :-) Doing stuff to your root filesystems is always dangerous, so you have been warned :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: | Doing stuff to your root filesystems is always dangerous, so you | have been warned :) Thanks, Søren. Indeed I have:-) I'll give it a try over the coming weekend after backing up everything:). Will this patch be committed to the tree, before then? Maybe, I'm still thinking about if I should make it an option in atacontrol to do the mirror rebuild on create... This is really great news. I sometimes feel like I live under a rock, I didn't realize that atacontrol raid was working so well. Do you know of any documentation on setting it up on a new system install, especially atacontrol RAID1+0? man atacontrol :) However if you want to use RAID1+0 and you want to be able to boot from it you *need* a RAID capable controller BIOS, there is no way to make a stock BIOS boot from a RAID0... If you need it on install you probably also need at RAID capable controller, if you define the RAID BIOS there, it will show up in sysinstall.. I haven't used vinum because of the root partition limitations and the complexity of the first configuration although I have been on the verge several times. BTW, is this an integration of vinum? To not have to be limited to hw raid by having similar flexibility and ease of use with software raid will be/is, IMO, fantastic. No, the RAID part of the ATA driver has nothing to do with vinum. Vinum has several limitations that make it useless in this context. Mainly that the RAID config layout on disk need to be of different formats depending on what controller BIOS we have, and there is no place to put all the extra volume stuff that vinum needs. The ATA RAID code is very generic instead, with backends that converts the internal RAID info to/from the needed info on disk depending on controller type. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: | man atacontrol :) I did that but it sounded too easy :) It actually is :) | However if you want to use RAID1+0 and you want to be able to | boot from it you *need* a RAID capable controller BIOS, there is | no way to make a stock BIOS boot from a RAID0... | If you need it on install you probably also need at RAID capable | controller, if you define the RAID BIOS there, it will show up | in sysinstall.. The solution that pops into my mind is to have a small ad0 for boot and / partition. and ad1,ad2,ad3 as raid0+1 or ad1 and 2 as raid1 raid1 should solve my problem. Would either of these be configurable on sysinstall to have the /var and /usr partitions on the raid disks? If not that should be easy enough after a minimal install and reboot on ad0. You need 4 disks for RAID0+1, and if you want to see the RAID's in sysinstall you need to have them created first, either by having a real ATA RAID controller, or having made it beforehand on the disks in possibly another machine or from a minimal install. Once the RAID's has been setup, sysinstall will pick them up.. (Maybe one can boot the fixit thingy and run atacontrol from the live filesystem, havn't tried)... | No, the RAID part of the ATA driver has nothing to do with vinum. | Vinum has several limitations that make it useless in this context. | Mainly that the RAID config layout on disk need to be of different | formats depending on what controller BIOS we have, and there is no | place to put all the extra volume stuff that vinum needs. | The ATA RAID code is very generic instead, with backends that converts | the internal RAID info to/from the needed info on disk depending | on controller type. Thanks for the clarification, Søren. Please forgive my basic, uninitiated questions. I really should probably have been paying more attention as these features were being added. No problem, feel free to ask, we add so many features to FreeBSD all the time it can be hard to follow them all... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? If you use ATA drives you can use atacontrol to make the mirror on two ATA disks, but there are some gotcha's, see atacontrol(1) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: On Mon, Jan 06, 2003 at 07:29:51PM +0100, Soeren Schmidt wrote: It seems Nate Lawson wrote: I'd like to have a mirrored root partition. I tried ccd(4) but the boot blocks couldn't find the fs. Any idea how much work it would take to enable booting a ccd root? Also, does vinum already support this? If you use ATA drives you can use atacontrol to make the mirror on two ATA disks, but there are some gotcha's, see atacontrol(1) Using non-raid controllers for building raid-arrays would be a cool feature if `atacontrol rebuild` would work... Is there simple way, i.e. without copying the content of the array to a temporary location, to recover from disk-failures when doing raid1 on non-raid controllers ? The problem is that if its the drive that on you primary channel that dies, not all BIOS's can be taught to boot from the other drive on the secondary channel. The solution is to swap the drives... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems [EMAIL PROTECTED] wrote: if `atacontrol rebuild` would work... Is there simple way, i.e. without copying the content of the array to a temporary location, to recover from disk-failures when doing raid1 on non-raid controllers ? The problem is that if its the drive that on you primary channel that dies, not all BIOS's can be taught to boot from the other drive on the secondary channel. The solution is to swap the drives... Well, and how would one rebuild the array after swaping the drive from the secondary channel to the primary and hooking up a replacement drive to the secondary channel or if one doesn't want to boot from the array at all ? You can boot off the half-mirror and the rebuild with atacontrol once the system is up (its done in the background so you can continue to run but access speed will be degraded). If you want to not use the array you just delete it with atatcontrol and the disk will be seen as a normal ATA drive again. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Cordless Keyboard + Mouse
It seems Daren Desjardins wrote: Has anyone been able to get the Logitech Cordless Elite Duo, or any cordless kb/mouse combos to work? I have the Cordless Elite Duo however the system only detects my keyboard, and I have to use a corded mouse. I have been searching around and yet to find anything on getting the combos to work. Sure, I use a logitech cordless keyboard and wheel mouse, not sure of the exact model though, works like a charm... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Andrew P. Lentvorski, Jr. wrote: Probably your best choice right now if you have a real RAID controller on your motherboard. The BIOS takes care of most of the nasty booting details. If you don't have a real RAID controller on the motherboard, stop now. Rebuilds don't work if you don't have a real RAID controller. You can recover, but it requires some dancing with dd (search the archives). Advantages: BIOS handles bootup issues. Very little required from OS Disadvantages: Hardware required. Proprietary. Will not rebuild a broken array without hardware RAID Not true, you can boot off a broken mirror on a non-RAID ATA controller, and then rebuild on the fly with atacontrol once the system is up, you do not need the RAID BIOS for rebuilding a broken mirror. Proprietary, well, in the case of using a stock ATA controller for this its certainly not :) The only caveat is that not all motherboard BIOS's allow you to boot from anything but the disk on the primary ATA channel. If you have such an animal you need to swap drives if it is the primary channel drive that is dead. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mirrored root fs?
It seems Andrew P. Lentvorski, Jr. wrote: On Tue, 7 Jan 2003, Soeren Schmidt wrote: Not true, you can boot off a broken mirror on a non-RAID ATA controller, and then rebuild on the fly with atacontrol once the system is up Is this new (ie. since August 22, 2002)? I attempted to do this back then and I couldn't actually get a rebuild to work for stock ATA controllers. At that point, I kept getting: atacontrol: ioctl(ATARAIDREBUILD): Operation not supported by device See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=698625+0+archive/2002/freebsd-stable/20020825.freebsd-stable for details on my abortive attempts to get this to work. Will I get different results if I try this procedure again, now? Alternatively, what did I do wrong in the original procedure? It should work on 4.7 forward, but its been a while since I played with it. Another thing is that its a pain to make a mirror on an already running system (which is often wanted), so I plan to add an option to atacontrol to tell where to get the master from, and then do an automatic rebuild during the create phase ie: atacontrol create RAID1 ad0 ad2 source ad0 This will create a mirror using ad0 and ad2, and start a rebuild to build the master with data from ad0. This way you can do a normal install, add a second (identical or bigger) disk, and make a mirror out of those. You just have to change your fstab before rebooting (ad0 - ar0) in order to boot... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panic during ata_resume (sound)
It seems Gavin Atkinson wrote: This looks like a problem in the sound system, as the ATA driver prints the last 'done' line it has finished its resume code, and the trace points at the mixer_reinit func... That the ATA driver then locks in the dump code can have lots of reasons, difficult to tell from the info provided Another panic. Kernel from 19th Dec. Laptop suspended itself (for no reason), and upon resume got this: (again, laptop could not manage to do the dump, so this is hand transcribed) wakeup from sleeping state (slept 00:02:53) ata0: resetting devices .. done ata1: resetting devices .. done Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01fb093 stack pointer = 0x10:0xc874db48 frame pointer = 0x10:0xc874db68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 13 (swi6: tty:sio clock) Stopped at _mtx_lock_flags + 0x43 cmpl $0xc03d16a0, 0(ebx) _mtx_lock_flags() at _mtx_lock_flags+0x43 mixer_reinit() at ds_ps_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() bus_generic_resume() apm_resume() apm_processevent() apm_do_suspend() apm_timeout() softclock() ithread_loop() fork_exit() fork_trampoline() _mtx_lock_flags+0x43 corresponds to the compare of the line KASSERT(m-mtx_object.lo_class == lock_class_mtx_sleep, in kern_mutex.c. It looks like m == NULL. I can't get any more information sadly, again the machine hung while trying to reset ther ATA channel for the dump. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SIS 962 chipset, problems ...
It seems Martin Blapp wrote: --- sys/dev/ata/ata-dma.c.origMon Dec 23 14:44:39 2002 +++ sys/dev/ata/ata-dma.c Mon Dec 23 15:49:20 2002 @@ -632,7 +632,9 @@ ata_find_dev(parent, 0x06351039, 0) || /* SiS 635 */ ata_find_dev(parent, 0x06401039, 0) || /* SiS 640 */ ata_find_dev(parent, 0x06451039, 0) || /* SiS 645 */ + ata_find_dev(parent, 0x06461039, 0) || /* SiS 646 */ ata_find_dev(parent, 0x06501039, 0) || /* SiS 650 */ + ata_find_dev(parent, 0x06511039, 0) || /* SiS 651 */ ata_find_dev(parent, 0x07301039, 0) || /* SiS 730 */ ata_find_dev(parent, 0x07331039, 0) || /* SiS 733 */ ata_find_dev(parent, 0x07351039, 0) || /* SiS 735 */ --- sys/dev/ata/ata-pci.c.origMon Dec 23 16:40:04 2002 +++ sys/dev/ata/ata-pci.c Mon Dec 23 16:39:27 2002 @@ -188,7 +188,9 @@ ata_find_dev(dev, 0x06351039, 0) || ata_find_dev(dev, 0x06401039, 0) || ata_find_dev(dev, 0x06451039, 0) || + ata_find_dev(dev, 0x06461039, 0) || ata_find_dev(dev, 0x06501039, 0) || + ata_find_dev(dev, 0x06511039, 0) || ata_find_dev(dev, 0x07301039, 0) || ata_find_dev(dev, 0x07331039, 0) || ata_find_dev(dev, 0x07351039, 0) || This does not work correctly, your ATA timings are way out of wack since botht ATA100 and ATA133 SiS chips uses different register layouts... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ata driver
It seems Takahashi Yoshihiro wrote:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
Is it only for ATA/IDE disks ?
Does it depend on the size of the disks ?
Only for the internal IDE controller. The internal IDE controller on
pc98 uses the fixed geometry which is 8 heads and 17 sectors. If the
size of the disk is larger than 4.2GB (65535C x 8H x 17S x 512B), a
different geometry depend on the disk is used.
OK, could you try this patch then (and probably still rip out the
stuff in GEOM)...
Index: ata-all.h
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-all.h,v
retrieving revision 1.55
diff -u -r1.55 ata-all.h
--- ata-all.h 3 Dec 2002 20:19:37 - 1.55
+++ ata-all.h 17 Dec 2002 14:29:12 -
@@ -213,9 +213,10 @@
intflags; /* controller flags */
#defineATA_NO_SLAVE0x01
#defineATA_USE_16BIT 0x02
-#defineATA_ATAPI_DMA_RO0x04
-#defineATA_QUEUED 0x08
-#defineATA_DMA_ACTIVE 0x10
+#defineATA_USE_PC98GEOM0x04
+#defineATA_ATAPI_DMA_RO0x08
+#defineATA_QUEUED 0x10
+#defineATA_DMA_ACTIVE 0x20
struct ata_device device[2]; /* devices on this channel */
#defineMASTER 0x00
Index: ata-cbus.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-cbus.c,v
retrieving revision 1.1
diff -u -r1.1 ata-cbus.c
--- ata-cbus.c 3 Dec 2002 20:19:37 - 1.1
+++ ata-cbus.c 17 Dec 2002 14:28:21 -
@@ -239,7 +239,7 @@
ch-unit = i;
}
free(children, M_TEMP);
-ch-flags |= ATA_USE_16BIT;
+ch-flags |= ATA_USE_16BIT | ATA_USE_PC98GEOM;
ch-intr_func = ata_cbus_intr;
ch-lock_func = ata_cbus_banking;
return ata_probe(dev);
Index: ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.138
diff -u -r1.138 ata-disk.c
--- ata-disk.c 6 Dec 2002 19:29:53 - 1.138
+++ ata-disk.c 17 Dec 2002 14:34:27 -
@@ -124,6 +124,11 @@
adp-sectors = atadev-param-sectors;
adp-total_secs = atadev-param-cylinders * adp-heads * adp-sectors;
adp-max_iosize = 256 * DEV_BSIZE;
+if (adp-device-channel-flags ATA_USE_PC98GEOM
+ adp-total_secs 17 * 8 * 65536) {
+ adp-sectors = 17;
+ adp-heads = 8;
+}
bioq_init(adp-queue);
lbasize = (u_int32_t)atadev-param-lba_size_1 |
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: ATACD issues slowly coming back...
It seems Vadim Belman wrote: Bruce Cran wrote: Your CD drive should indeed support UDMA33 - my DVD drive supports UDMA33, and my CDRW supports multi-word DMA, even though my BIOS only ever configures it for PIO4, and my DVD for UDMA33. FreeBSD only ever configures them for PIO during bootup, but, using the atacontrol program, it configures them both for maximum speed, even knowing they _can_ only do UDMA33,WDMA2. If you have a look at sysctl hw.ata tree, it'll give you the clue on how to overcome this behaviuor. In simple words, what you need is to poot hw.ata.atapi_dma=1 in your /boot/loader.conf and have the nirvana of automatic DMA detection... And remember the warning that it does not always work as expected, ATAPI DMA is a many headed monster... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Link failure in ata driver
It seems Kris Kennaway wrote: ata-all.o: In function `ata_boot_attach': ata-all.o(.text+0x1590): undefined reference to `ata_raid_attach' ata-all.o(.text+0x1594): undefined reference to `ata_raid_attach' Yes, I've seen it there is two other issues I'd like to fix also, I'll ask re@ for approval later today... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Another INVARIANTS panic with ata driver
It seems Andrew Gallatin wrote: Kris Kennaway writes: I got this on one of the gohan machines overnight. These machines have failing disks -- I get a lot of hard read errors, but the INVARIANTS panic could better be replaced by something else. I reported another instance of this to sos a few weeks ago but didn't hear a reply. I posted a patch for this earlier this week. No reply from sos yet. Try the following patch (its against stable but should work on current). The problem is that ata_raiddisk_attach fails, causing the adp to be freed, so ad_print is called with a bogus pointer. adp is an alias fro atadev-driver, so checking that atadev-driver != NULL is one way to fix this panic. I have a semilar fix here, re@ will decide if it can go in... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATACD issues slowly coming back...
It seems Cliff L. Biffle wrote: I mentioned earlier on the list that the ATA issues I'd been having with 4.7 had disappeared since installing 5.0. They're still much less frequent -- i.e. I can burn CDs now -- but I just got one of the old messages and wanted to submit it for your perusal. cliff50 kernel: acd0: READ_BIG - MEDIUM ERROR asc=0x11 ascq=0x00 error=0x00 This means the driver couldn't read a chunk of data of the media due to it being bad (damaged/scratched/dirty)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: ata_dmasetup: transfer active on this device!
It seems Ian Dowse wrote: Hi Søren, I get the above panic every few days when resuming, especially if the disk was active while the laptop was suspending - it's easy to reproduce by starting some disk-intensive activity and then hitting the suspend button. I see that IWASAKI-san posted patches for this a few months ago - do you have any plans to incorporate his work? Uhm, its somewhere on my list, but IIRC there was something not quite right with that patch, I'll underline it on my whiteboard :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
