Re: ATA driver update for 7.2RELEASE available
On 15Jul, 2009, at 11:33 , Marat N.Afanasyev wrote: Søren Schmidt wrote: Over the past months I've gotten huge amounts of requests for ATA related things, so I've whipped up what I use here for FreeBSD 7.2- Release. This is a total replacement of the ATA driver, modulerized as in - current, but based on my WIP not from what might have happend to - current since I gave up maintainership. There is a number of new chipsets supported in here that I dont think is in any of the official sources (havn't checked in quite some time though), mostly newish ATI, nVidia and Marvell chips (yeah those buggers with both ATA SATA ports). You can find and install.sh script and a tarball of the needed files at: http://www.deepcore.dk/pub/ATA Put both in /usr/src and run install.sh. As I dont subscribe to any of the mailing lists nor does my FreeBSD.org mail address seem to work anymore, you will need to reply to me directly if needed. As always - Enjoy! -Søren i think i'm dumb, but can you tell me how can atapicam be enabled with this implementation of ata? i couldn't still find a way :( You could just grap atapi-cam.c from stock 7.2 and use that I guess (as a module or compiled in), newer used it though... -Søren -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ATA driver update for 7.2RELEASE available
On 27Jun, 2009, at 14:29 , Bruce Cran wrote: On Fri, 26 Jun 2009 22:11:08 +0200 Søren Schmidt s...@deepcore.dk wrote: This is a total replacement of the ATA driver, modulerized as in - current, but based on my WIP not from what might have happend to - current since I gave up maintainership. It's great to see the driver be modularised since removing unneeded drivers (for example, on powerpc and embedded platforms) can save ~200KB. Yep, thats the main idea behind this move, minimizing the footprint. With this and some of the _NO_ options to the world build an almost reasonable sized FreeBSD can be made. FreeBSD seems to have grown *alot* of fat over the last years, not to mention ports where installing one small application gets you both a pony and a barn to keep it in as a bonus 8^) Could you add some documentation for the modules in /sys/conf/NOTES please? I looked through the sources and put together the patch for 8.0 which is avaiable at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/133162 but it sounds like some more drivers will need to be added for 7.2. Good catch, included in my WIP here, when/if I get to put up another release of this it will be in there, thanks! PS: For official inclusion in FreeBSD someone with a commit bit will have to look into this. -Søren -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ATA driver update for 7.2RELEASE available
Over the past months I've gotten huge amounts of requests for ATA related things, so I've whipped up what I use here for FreeBSD 7.2- Release. This is a total replacement of the ATA driver, modulerized as in - current, but based on my WIP not from what might have happend to - current since I gave up maintainership. There is a number of new chipsets supported in here that I dont think is in any of the official sources (havn't checked in quite some time though), mostly newish ATI, nVidia and Marvell chips (yeah those buggers with both ATA SATA ports). You can find and install.sh script and a tarball of the needed files at: http://www.deepcore.dk/pub/ATA Put both in /usr/src and run install.sh. As I dont subscribe to any of the mailing lists nor does my FreeBSD.org mail address seem to work anymore, you will need to reply to me directly if needed. As always - Enjoy! -Søren -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [ATA] and re(4) stability issues
On 10Dec, 2008, at 10:11 , Victor Balada Diaz wrote: Thanks for explaining me what the flags do. I'm not skilled enough to create the DMA quirks but if you could give me some patches i'll test them. Also if you have any other idea on what could i test or how can i debug this it would be more than welcome. Comment out the following two lines in ata_ahci_dmainit(): if (ATA_INL(ctlr-r_res2, ATA_AHCI_CAP) ATA_AHCI_CAP_64BIT) ch-dma-max_address = BUS_SPACE_MAXADDR; And you will not use 64bit DMA even if the chipset supports it. However I have not seen any chipsets supporting this fail, YMMV as usual :) -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Western Digital hard disks and ATA timeouts
On 7Nov, 2008, at 20:12 , Peter Wemm wrote: On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote: [..] As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and is not adjustable without editing the ATA code yourself and increasing the value. The FreeNAS folks have made patches available to turn the timeout value into a sysctl. Soren and/or others, please increase this timeout value. Five seconds has now been deemed too aggressive a default. And please consider migrating the timeout value into a sysctl. The 5 second timeout has been a problem for quite a while actually. I've had a number of instances where I've had to increase it to 20 or 30 seconds when recovering from marginal drives. The longest successful recovery attempt I've seen was 26 seconds, I believe on a Maxtor drive a few years ago. (successful == the drive spent 26 seconds but eventually successfully read the sector). Even the IBM death star drives could take much longer than 5 seconds to do a recovery 5 years ago. 5 seconds has never been a good default. I think the timeout should be increased to at least 30 seconds. My windows box has a timeout that goes for several minutes. If there is concern about FreeBSD appearing to hang, I could imagine that a console warning message could be printed after 5 seconds. But just say drive has not yet responded. But give it more time. In this day and age we're generally not playing games with udma33 vs 66, notched cables, poor CRC support etc. SATA seems to have eliminated all that. Hmm, it might make sense to increase the timeout on SATA connections to 2 or 3 minutes by default. Actually I do have a patch around that logs the timeout on the console after the normal timeout (5secs), then just goes on to wait for double the timeout and log again etc etc, final timeout was IIRC 60 secs but could be anything. -Søren___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ICH7M limited to SATA-150?
I'll look into it -Søren -- On 31/10/2008, at 00.00, Michael Butler [EMAIL PROTECTED] wrote: Jeremy Chadwick wrote: On Thu, Oct 30, 2008 at 01:47:48PM -0700, Xin LI wrote: Personally I don't really think ICH7M is capable to do SATA-300. Intel datasheet 307013, page 191 says: Supported Supported 3 Gb/s Transfer Rate (Desktop Only) (Desktop Only) My understanding is that ICH7- *M* does not support SATA-300 at all. Xin Li is correct -- the mobile version doesn't do SATA300. Then there is a correction required to /sys/dev/ata/ata_chipset.c - mine identifies itself as: [EMAIL PROTECTED]:0:31:2:class=0x010180 card=0xff101179 chip=0x27c48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM/GHM (ICH7-M Family) Serial ATA Storage Controller' class = mass storage subclass = ATA .. where 0x27c4 is legacy mode and 0x27c5 is AHCI mode, Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Promise SX4060 on 7.1-BETA2
On Thu, Oct 23, 2008 at 9:03 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Thu, Oct 23, 2008 at 02:01:55PM -0400, David Boyd wrote:
I am attempting to install 7.1-BETA2 (from CD) onto a PC with a Promise
SX4060 RAID controller and two Seagate 120GB ATA disk drives.
The boot from CD keeps repeating the following (error) messages: (I'm
retyping here)
{snip -- for dmesg errors, see URL below}
You're the second person to report this problem recently. The other
person (see below) reported the same thing, also using a PATA
controller, and also using Seagate disks (though different models).
We now have two reproducible test cases where users are seeing continual
errors from the controller when attempting to set the transfer mode,
enable read and write caching, and SET_MULTI. The only similarity so
far is that they're both PATA users.
In Kristian's case, his disks were in a usable state, but we ultimately
determine the Silicon Image controller might be responsible for what he
was seeing (the SMART errors we saw in his logs could've been from any
time in the past; he saw errors on multiple disks, and not all of those
disks shown SMART log errors)... while David's not using a Silicon Image
controller at all.
Kristian's setup:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046023.html
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046027.html
Silicon Image 0680 ATA100 (problem was also seen on Promise PDC20270)
ad4: Seagate ST3320620A 3.AAF at ata2-master PIO4
ad5: Seagate ST3320620A 3.AAF at ata2-slave PIO4
ad6: Seagate ST3750640A 3.AAE at ata3-master PIO4
ad7: Seagate ST3320620A 3.AAD at ata3-slave PIO4
David's setup (what we know so far):
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046140.html
Promise SX4060
ad4: 114473MB Seagate ST3120814A 3.AAJ at ata2-master PIO4
ad8: 114473MB Seagate ST3120814A 3.AAJ at ata4-master PIO4
Soren/Andrey, can either of you comment on this? If at all possible, it
would be good to get this hammered out before 7.1-RELEASE is tagged.
Does it work if booted on a 8-current kernel ?
The driver path's used by the SiI0680 and the SX4060 are *very* different,
mind you.
-Søren
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for testing: ata(4) MFC
On 10Oct, 2008, at 13:58 , Jeremy Chadwick wrote: On Sun, Oct 05, 2008 at 10:12:11PM -0700, Jeremy Chadwick wrote: On Mon, Oct 06, 2008 at 09:03:20AM +0400, Andrey V. Elsukov wrote: Jeremy Chadwick wrote: Also, does your patch include any fixes (intentional or inadvertent) for Intel MatrixRAID? This has been a sore spot for FreeBSD for quite some time, and I'm curious to know if that has been fixed. There is only one fix for Intel Matrix RAID: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121899 Ahh, yeah, I've seen that one as well. I'll apply the patch and let you know if the behaviour documented in the PR happens. I'm sorry I haven't gotten around to testing this -- my day (night) job has kept me incredibly busy, and I've had hardly any time at home to work on personal projects. It sucks. I'll try to make time for testing either today or tomorrow. I'm not sure how far this has gone into 7 yet, but it would be a real cool thing(tm) to have the latest ATA module work back into 7.1 as well. Its a no brainer actually with no functional changes other than the possibility to load chipset specific code as modules. I know that a few HW vendors out there would *LOVE* this so they could make modules for their HW to support FreeBSD on new fancy HW, mind you that might be binary modules but still better than no support at all. That would also offload the work on yours truely to concentrate on new functionality etc instead of hunting new HW support all the time. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Request for testing: ata(4) MFC
On 5Oct, 2008, at 13:04 , Marius Strobl wrote: On Sat, Oct 04, 2008 at 07:38:09PM +0400, Andrey V. Elsukov wrote: Hi, All. I prepared patch to make MFC of ata(4) driver into RELENG_7 before 7.1-RELEASE. Depending on results of the testing patch will be commited or not (if some regressions will be detected). So if you want or just can test it, please try and report here. One regression of the post-PM code is that support for some Promise controllers is broken in that probing drives causes a hang. In my case it's a FasTrak S150 TX4 with a PDC20319 but there are also other variants affected, see f.e.: http://lists.freebsd.org/pipermail/freebsd-current/2008-May/ 085923.html I'm aware of the Promise problems and its on my TODO list, just havn't gotten around to it yet. When I have the current floating patch for splitting up ata-chipset.c in vendor specific files I'll have a go on that report (makes it lots easier to work with). -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MCP55 SATA data corruption in FreeBSD 7
Hi I'll look into that providing I can find HW to work on, IIRC I have one in the ATA collection but I have to verify when I get to the lab. -Søren On 1Jul, 2008, at 11:01 , Daniel Eriksson wrote: I am having problems with silent data corruption on (some) drives connected to an MCP55 SATA controller. I have two servers, both running RELENG_7_0/amd64. One has the 570 Ultra chipset, the other has 570 SLI. Both chipsets have the MCP55 SATA controller. The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 drives hooked up to the MCP55 controller and it is working just fine. The server with 570 SLI chipset has a bunch of new SATA-300 drives hooked up to the MCP55 controller and it is giving me silent data corruption (easily detectable by running ZFS scrub, every time I run it new checksum errors show up). I know the drives are good because when they are hooked up to another controller they work just fine. Unfortunately the drives does not have a jumper for setting SATA-150 speed (they are Samsung 1 TB drives), and trying to force the drives to SATA-150 speed with the patch provided by the manufacturer does not seem to work (the drives still negotiate SATA-300 speed). I will try to get my hands on another older SATA-150 drive (or a new that can be jumpered) to verify if the culprit is the MCP55 revision (see below) or the interface speed. NOT working (570 SLI) - [EMAIL PROTECTED]:0:5:0: class=0x010185 card=0x72501462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA Working (570 Ultra) --- [EMAIL PROTECTED]:0:5:0: class=0x010185 card=0xcb8410de chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA This is most likely related to kern/120296 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120296) and kern/ 121396 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121396). If someone else is having data corruption problems with drives connected to an MCP55 controller it might be worth testing if limiting the drives to SATA-150 makes a difference. It will most likely take me a while before I can verify this. --- Daniel Eriksson (http://www.toomuchdata.com/) -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MCP55 SATA data corruption in FreeBSD 7
Hi OK, the only modern nVidia board I have is MCP51 based, however it uses the same codepath as the MCP55. Anyhow, there has been fixes fro these in -current, thats not in any of the releng's yet. Please try the attached patch, or even better try a -current kernel. -Søren ff Description: Binary data On 1Jul, 2008, at 11:01 , Daniel Eriksson wrote: I am having problems with silent data corruption on (some) drives connected to an MCP55 SATA controller. I have two servers, both running RELENG_7_0/amd64. One has the 570 Ultra chipset, the other has 570 SLI. Both chipsets have the MCP55 SATA controller. The server with 570 Ultra chipset has a bunch of older 250GB SATA-150 drives hooked up to the MCP55 controller and it is working just fine. The server with 570 SLI chipset has a bunch of new SATA-300 drives hooked up to the MCP55 controller and it is giving me silent data corruption (easily detectable by running ZFS scrub, every time I run it new checksum errors show up). I know the drives are good because when they are hooked up to another controller they work just fine. Unfortunately the drives does not have a jumper for setting SATA-150 speed (they are Samsung 1 TB drives), and trying to force the drives to SATA-150 speed with the patch provided by the manufacturer does not seem to work (the drives still negotiate SATA-300 speed). I will try to get my hands on another older SATA-150 drive (or a new that can be jumpered) to verify if the culprit is the MCP55 revision (see below) or the interface speed. NOT working (570 SLI) - [EMAIL PROTECTED]:0:5:0: class=0x010185 card=0x72501462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA Working (570 Ultra) --- [EMAIL PROTECTED]:0:5:0: class=0x010185 card=0xcb8410de chip=0x037f10de rev=0xa3 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA Controller' class = mass storage subclass = ATA This is most likely related to kern/120296 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/120296) and kern/ 121396 (http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/121396). If someone else is having data corruption problems with drives connected to an MCP55 controller it might be worth testing if limiting the drives to SATA-150 makes a difference. It will most likely take me a while before I can verify this. --- Daniel Eriksson (http://www.toomuchdata.com/) -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE can not mount root on Cyrix 5530 ATA33 controller
On 25Jan, 2008, at 15:05 , John Baldwin wrote: On Wednesday 23 January 2008 03:52:39 pm Søren Schmidt wrote: On 23Jan, 2008, at 21:09 , Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshihiko Sarumaru wrote: Hello, I updated my Geode GX1 PC from RELENG_6_2 to RELENG_6_3 and found root mount failed after reboot. This problem was caused by a change to ata-pci.c to pick up wider old ata controller as ata-pci devices at ata_legacy() function, and roll backing that file resolved this problem for me. Which revision? Actually, its the fix to pci/pci.c that hasn't been backported to 6.x yet... Rev 1.343? It should apply to 6.x cleanly. Patch below: Yep, that one exactly. -Søren Index: pci.c === RCS file: /host/cvs/usr/cvs/src/sys/dev/pci/pci.c,v retrieving revision 1.292.2.23 diff -u -r1.292.2.23 pci.c --- pci.c 10 Jan 2008 21:17:12 - 1.292.2.23 +++ pci.c 25 Jan 2008 14:05:20 - @@ -1898,7 +1898,9 @@ /* ATA devices needs special map treatment */ if ((pci_get_class(dev) == PCIC_STORAGE) (pci_get_subclass(dev) == PCIS_STORAGE_IDE) - (pci_get_progif(dev) PCIP_STORAGE_IDE_MASTERDEV)) + ((pci_get_progif(dev) PCIP_STORAGE_IDE_MASTERDEV) || +(!pci_read_config(dev, PCIR_BAR(0), 4) + !pci_read_config(dev, PCIR_BAR(2), 4))) ) pci_ata_maps(pcib, bus, dev, b, s, f, rl, force, prefetchmask); else for (i = 0; i cfg-nummaps;) -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE can not mount root on Cyrix 5530 ATA33 controller
On 23Jan, 2008, at 21:09 , Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoshihiko Sarumaru wrote: Hello, I updated my Geode GX1 PC from RELENG_6_2 to RELENG_6_3 and found root mount failed after reboot. This problem was caused by a change to ata-pci.c to pick up wider old ata controller as ata-pci devices at ata_legacy() function, and roll backing that file resolved this problem for me. Which revision? Actually, its the fix to pci/pci.c that hasn't been backported to 6.x yet... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7 on Soekris net4801?
Ian Smith wrote: On Sat, 3 Nov 2007, Henrik Brix Andersen wrote: On Sun, Nov 04, 2007 at 02:59:36AM +1100, Ian Smith wrote: any particular/new issues with RELENG_7 on the Soekris net4801? Thought I should check before upgrading my T23 as a build platform .. I haven't done this before, and will be relying on the howtos for 6.X I recently upgraded two of my net4801s to RELENG_7 - the only problem I have seen so far, is that savecore(8) attempts to do non-aligned DMA transfers and fails. I haven't had time to dig further into this issue yet, though. Thanks, Brix. I'm wondering if that's still (again?) to do with item 3 at http://www.soekris.com/Issue0003.htm ? I've no idea whether a similar 'quick-fix' to that given for FreeBSD 4.X to /sys/dev/ata/ata-dma.c would work with the 5.5-S and 6.1-R code I have here, noting that the alignment is now specified in bytes rather than the earlier bytes-1, so '4' is presumably the value needed for dword alignment. Hmm, ok, trying to dig a little deeper .. rev 1.118 notes say: Add support for a the National Geode SC1100. Thanks to Soekris engineering for sponsoring a Soekris 4801 to make this support. but I couldn't find anywhere in 1.118 or in later versions up to 1.147 (RELENG_7, HEAD) that does anything other than 'ch-dma-alignment = 2;' (Not that me not finding it means much :) I also noticed at 1.137.2.2: Add support for using DMA on dump, greatly speeds up the dump process. Copying Soren in case he may have a bead on this, but it hardly seems any impediment to preparation or building for it when the box arrives. Actually aligment is set to 16 but a bit untraditionally in ata_national_setmode(). I should change that to do it in an ata_national_allocate() function which now can contain just a few lines. I'd figure that the problem is that the geode chip doesn't support 128 sector writes just up to 126, that is not honered from the dump rutine IIRC. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Help! My laptop drive may be dying.
Bruce M Simpson wrote: Hi, My laptop drive might be dying. It is a Samsung MP0804H which I have used for around 28 months without issue. Every now and then it will click and sound as though it is thermally recalibrating itself. I ran SMART diagnostics from smartmontools, and Samsung's own diag tools which all report the drive is OK (a full captive surface test). I see nothing untoward in the SMART info pages. Well, sounds like the drive is indeed dying, recalibrating noises like that is a bad sign, its most likely having real trouble reading certain areas of the medium. If your SMART output tells anything about read retries or number of remaps that could be an indicator of upcoming problems, however not all drives has that info in the SMART pages. In the real world scenario SMART can only tell you about the problem when the drive has given up on the data, there is almost newer any real prewarns to failure. Whilst Windows is able to tolerate the retrying of ATA commands which this click appears to be inducing, FreeBSD can easily get sick and just hang, which majorly gets in the way of real work. Depends on whats happening, you could try to up the timeout in ata-disk.c and see if it survives the errors that way, to at least try to save the data before its too late. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PATA support is broken on Intel DG9655S ?
Zahemszky Gábor wrote: Hi! I'd like to know, is it possible to use FreeBSD on on Intel DG9655SS motherboard with PATA devices. It has 1 PATA and 2 SATA ports, but the 6-stable kernel doesn't see any devices on PATA. It doesn't see neither my disk, nor my DVD-writer. I tried with normal mode, with legacy mode, doesn't matter. The kernel boots, and after it don't now any disks. Is that controller works in Current? Will it work in 6-stable in the near future? Soren? It is supported in -current, backport planned but no time currently. You could grap /sys/dev/ata/* from -current and use that in 6-stable, there might be a few nits with infrastructure diffs but should be minimal IIRC. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
Mikhail Teterin wrote: Over a year later this remains a problem -- exactly as described below... No other SATA devices are present -- the only other IDE device is the DVD drive. My main disks are SCSI. What's MUCH worse is that the (slowly) written data is also often corrupted... I use the drive to store our vast collection of photos and the backups. Every once in a while I encounter a corrupt JPEG file, and the backups are _always_ corrupt somewhere. Doing something like: dump 0auChf 16 0 - /home | bzip2 -9 /store/home.0.bz2 always produces a corrupt file (as per ``bzip2 -t''). I used to blame the drive's temperature, but it now sits in its own enclosure and stays under 40 Celsius. When the drive is accessed, there are (according to `systat -vm') many thousands of interrupts 17 -- on my system these are shared between pcm0 and ehci0. Why are these triggered by accessing SATA is unclear, but the Intr's share of the CPU time is often above 80% of one processor's total (I have 4 processors). As I mentioned a year ago, Knoppix was accessing the same drive at much higher speeds, so I don't believe, the problem is with the hardware... What HW was this again, there has been alot of updates/changes over the last year ? Could you try an up to date -current kernel on this, at least to get me a decent dmesg from ? If thats impossible take ATA from current modulus the busdma changes and use that on an up to date 6-stable. I cant tell what interrupts go where without a dmesg... Other than that, single bit/byte corruption are normally HW troubles of some kind, usually involving bad/incompatible memory or bad chipsets. However, if your drive has been overheated the media might have taken permanent damage that makes it loose data. What does SMART say on corrected errors etc (if the drive has that info). -Søren Please, advise. Thanks! -mi On Wednesday 01 March 2006 11:07, Mikhail Teterin wrote: = On Wednesday 01 March 2006, Søren Schmidt wrote: = = dd if=/dev/ad8 of=/dev/null bs=1m = = Well, as I said, there is no obvious problems with _reading_. The above = command reads at well over 60Mb/s: = = 1638924288 bytes transferred in 25.374856 secs (64588516 bytes/sec) = = _Writing_, however, remains pathetic: = = dd of=/dev/ad8 if=/dev/zero bs=1m = 631242752 bytes transferred in 91.039066 secs (6933757 bytes/sec) = = = The problem is the blocksize that gets in the way of utilizing full = = transfer speed. = = Did you really expect the blocksize to make an order of (decimal) magnitude = difference? :-) It made no difference at all :-( = = Brian Candler asked: = = Just to be clear: this is Knoppix running on the *same* machine as you've = = been testing FreeBSD? = = Correct. = = = Aside: why are you using cat under FreeBSD, but dd under Knoppix? I'd use dd = = everywhere for consistency. = = Cat was slightly faster in my tests on FreeBSD. I used dd under Knoppix for = dd's throughput reporting -- I'm not aware of a monitoring tool like `systat' = under Linux. = = Yours, = = -mi = . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pitiful performance of an SATA150 drive
Mikhail Teterin wrote: On Monday 26 March 2007 15:21, Søren Schmidt wrote: = What HW was this again, there has been alot of updates/changes over the = last year ? It is now a quad core (dual CPU) Opteron-275 using IWill's DK8X motherboard. http://www.google.com/search?q=iwill+dk8x The SATA controller(s) are by LSI, not NVidia's (unlike in Jeremy's case). Nopes its the stock AMD and a SiI chip.. Anyhow there has been some changes in that area that actually might fix an interrupt routing bogon. Please try the attached patch against an up to date 6-stable source and let me know if that helps... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALi SATA controller
Juraj Lutter wrote: On 2/27/07, Bruce M. Simpson [EMAIL PROTECTED] wrote: Søren Schmidt wrote: The problem is that your BIOS registers the resources used for AHCI operation but apparently hasn't really enabled them. Look for an option in the BIOS to turn on/off AHCI mode. There is no such option in the BIOS on this machine, as stated in the original thread. Lame BIOS writers :/ Yeah, I don't see it either. The only option regardige AHCI in BIOS is to choose whether the SATA controller will be in AHCI or RAID mode. Does it change anything if you shift between those two ? -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALi SATA controller
Bruce M. Simpson wrote: Hi, I have experienced the same regression since 6.2 was branched on an ASUS amd64 Vintage-PE1 box. Juraj Lutter wrote: Feb 26 21:45:25 river kernel: atapci0: AcerLabs M5229 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 31.0 on pci0 Feb 26 21:45:25 river kernel: ata0: ATA channel 0 on atapci0 Feb 26 21:45:25 river kernel: ata1: ATA channel 1 on atapci0 Feb 26 21:45:25 river kernel: atapci1: AcerLabs M5287 SATA150 controller port 0xc400-0xc40f,0xc000-0xc007,0xb800-0xb80f,0xb400-0xb407,0xb000-0xb01f mem 0xfe8ff400-0xfe8ff7ff irq 21 at device 31.1 on pci0 Feb 26 21:45:25 river kernel: atapci1: AHCI controller reset failure Feb 26 21:45:25 river kernel: device_attach: atapci1 attach returned 6 I'm sure I reported this to the list around 4th December 2006. My workaround was to install another SATA controller in the PCI-e slot and use that instead for the root disk. I think CURRENT also suffers from this problem. I think the last release which worked OK was 6.1. The problem is that your BIOS registers the resources used for AHCI operation but apparently hasn't really enabled them. Look for an option in the BIOS to turn on/off AHCI mode. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 RELEASE - READ_DMA timed out
Peter Ankerstål wrote: Pietro Cerutti wrote: On 1/14/07, Peter Ankerstål [EMAIL PROTECTED] wrote: ad0: FAILURE - READ_DMA timed out LBA=1000941 This kind of errors usually denote a hardware problem, either at the disk or at the controller level. Check sysutils/smartmontools in the ports. But there was no problem at all before the upgrade, and it works without any problem in safe mode and I have done fscks on the CF-card without any errors. The reason it works in safe mode is that DMA is not used there. Are you sure it worked with DMA before ? DMA access on CF cards needs signal lines to the CF slot thats not always implemented, fx on older soekris boards. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [summary] Re: burncd 'blank' not terminating ?
Luigi Rizzo wrote: summary: there was some discussion on how to fix the problem, in 6.x, with burncd -f /dev/acd0 -v blank getting stuck with this message blanking CD, please wait.. This used to work on 4.x. 6.x changes in two places: * the ioctl handler, acd_get_progress() in /sys/dev/ata/atapi-cd.c does a much stricter error checking, expecting the ATA_SENSE_VALID bit set in response to the ATAPI_READ_CAPACITY call. None of my DVD drives do that: acd0: DVDR HL-DT-ST DVDRAM GSA-4163B/A101 at ata1-master UDMA33 acd0: DVDR HL-DT-ST DVDRAM GSA-H10N/JL10 at ata0-slave UDMA33 even though they do report a valid progress status if you disable the check for ATA_SENSE_VALID, and in fact they do work under 4.x * usr.sbin/burncd/burncd.c waits for a transition of CDRIOCGETPROGRESS from 90..99 to 0, which fails to be detected because the ioctl() always returns 0 when ATA_SENSE_VALID is not set. In private mail, Soren mentioned that the spec (whatever it is called) says that the ATA_SENSE_VALID 'shall be set' when returning a valid value, so he is slightly dubious on removing the check in atapi-cd.c Also, it seems that the proper way to check for completion is to issue the TEST UNIT READY command, which is accessible through the CDIOCRESET ioct. I suggest the following two fixes: 1. change burncd.c as below, so that if CDRIOCGETPROGRESS does not return anything good, it calls CDIOCRESET to determine when the command is complete. This can be improved by calling CDIOCRESET unconditionally as a termination test FWIW just checking with TEST UNIT READY in general for progress will fail for lots of devices, but it might be that those have prober progress reporting so the sum of doing both is of benefit. 2. change atapi-cd.c to return something even if ATA_SENSE_VALID is unset. Apparently there is a lot of non-complying hardware around so restricting to what the spec says is like shooting ourselves in the foot. As I mentioned lots of devices does return garbage there so its more a question on which pool of devices you want to have working and which you wont, so its not a solution, rather a decision on which devices to support properly, I chose those that follow specs. Again, if burncd.c uses CDIOCRESET to determine the completion of the 'blank' operation, we don't care if the return value from CDRIOCGETPROGRESS is incorrect, because we don't rely on it. Right, but that will leave out reporting of progress which has been asked for lots of times since some of this takes time. As usual there is no easy solution, its a question on which devices work and which wont, and that unfortunatly changes over time... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on DOH! ata_alloc_request failed!
Jon Passki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey all, (I'm off list, please include me in any replies) (Søren, please let me know if you do not want to be emailed in the future directly! You seem to be the ATA RAID FreeBSD goto guy. Apologies if you did not want to be solicited). I just received a panic w/ this in /var/log/messages (uname and dmesg at the end of the email / book): Oct 21 04:17:05 prometheus kernel: DOH! ata_alloc_composite failed! I fixed a few nits in this area after 6.1-RELEASE, so you should upgrade to 6-stable or 6.2-betasomething to get this fixed. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing 6.1-R on Dell Powervault 745N
Lin Jui-Nan Eric wrote: Hi, On 10/19/06, Søren Schmidt [EMAIL PROTECTED] wrote: Nothing else that that it should work. I dont own any HW that uses this chip so I cannot test it out. The current support was done for the ARM port IIRC so things might be different on other systems. At any rate you definitly should try out 6.2-beta-something as 6.1 is getting old I have tried world kernel built yesterday (10/19), but the OS still can not recognize the hard disk. The dmesg and result of pciconf -lv: http://www.cs.nctu.edu.tw/~jnlin/cc/dmesg.log http://www.cs.nctu.edu.tw/~jnlin/cc/pciconf.log OK, I need the output from a verbose boot. That will tell if the disks are seen at all and just the attach phase is failing. I might have a few ideas depending on the outcome of that... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing 6.1-R on Dell Powervault 745N
Jeremy Chadwick wrote: On Wed, Oct 18, 2006 at 10:46:21PM +0800, Lin Jui-Nan Eric wrote: We have a Dell Powervault 745N and want to install FreeBSD 6.1-R. But the installer complains that it can not find out any hard disk. Since the dmesg contains ata2~5, I think the controller is recognized by FreeBSD, but it cannot get the SATA drive. The dmesg and result of running pciconf -lv is in this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=i386/103624 The controller (which you label in your PR as some funny RAID controller) is an Intel 31244: atapci0: Intel 31244 SATA150 controller mem 0xfe1ff000-0xfe1f irq 25 at device 2.0 on pci2 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ata4: ATA channel 2 on atapci0 ata5: ATA channel 3 on atapci0 Some history: this controller was discussed back in 2005: http://lists.freebsd.org/pipermail/freebsd-current/2005-June/050827.html The appropriate code appears to have been committed to FreeBSD as of June 2005: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h#rev1.49 There was a DMA-related fix for this controller committed in February 2006: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ata/ata-pci.h#rev1.49.2.7 Soren, do you have any ideas? Nothing else that that it should work. I dont own any HW that uses this chip so I cannot test it out. The current support was done for the ARM port IIRC so things might be different on other systems. At any rate you definitly should try out 6.2-beta-something as 6.1 is getting old -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: integer divide fault on 6.1
Joao Barros wrote: Hi all, I was contacted by Chris who had the same problem. Since I didn't follow up on my problem he asked me if it was solved and indeed it was solved by Søren and the fix has been committed to CURRENT: http://lists.freebsd.org/pipermail/cvs-all/2006-September/188353.html I'm hoping this gets MFC'ed in time for 6.2 It will be, I'm collecting fixes in -current that I'll get MFC'd soon... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
I plan to bacport *all* of ATA, as there are so many bugfixes that a resync is needed. ATA from -current fits right into 6-stable so its a nobrainer it just need a little more exposure... -Søren On 8/22/06, Ruslan Ermilov [EMAIL PROTECTED] wrote: On Mon, Aug 21, 2006 at 03:23:37PM -0400, David Gilbert wrote: Could someone please MFC at least v 1.168 of ata-chipset.c into RELENG_6? Specifically the Nvidia NFORCE-4 support? Most of the AMD64 motherboards I've gotten lately require this patch. I have been able to apply diff between 1.165 and 1.168 to RELENG-6 and it makes the chipset work. (this also requires 1.65 to 1.68 of ata-pci.h). Any takers? I'll do it in a few days if Soren doesn't do it earlier -- I also have plenty of such motherboards which want to meet 6.x. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /sys/dev/ata/ata-chipset.c 1.168 MFC?
Give me a few days and I'll get to it if I dont get any serious issues before that... -Søren On 8/22/06, Ruslan Ermilov [EMAIL PROTECTED] wrote: Hi Soren, On Tue, Aug 22, 2006 at 10:56:19AM +0200, S?ren Schmidt wrote: I plan to bacport *all* of ATA, as there are so many bugfixes that a resync is needed. ATA from -current fits right into 6-stable so its a nobrainer it just need a little more exposure... Do you have any ETA? Yes, I'm currently running HEAD version of sys/dev/ata/ on these motherboards. Thanks! Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems with an SATA drive on nVidia3 controller
Mikhail Teterin wrote: Hello! We have an amd64 machine with an nVidia3 SATA controller on motherboard. The drive just came from the manufacturer and the self-tests initiated via smartctl show no problems: atapci1: nVidia nForce3 Pro SATA150 controller port 0xcc00-0xcc07,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc0f,0xb800-0xb87f irq 22 at device 10.0 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ad6: 238475MB WDC WD2500SD-01KCC0 08.02D08 at ata3-master SATA150 Yet even newfs-ing it leads to DMA errors and the drive is unusable: % newfs -f 8192 -b 65536 /dev/ad6 /dev/ad6: 238475.2MB (488397168 sectors) block size 65536, fragment size 8192 using 81 cylinder groups of 2969.06MB, 47505 blks, 95232 inodes. super-block backups (for fsck -b #) at: 256, 6080896, 12161536, 18242176, 24322816, 30403456, 36484096, 42564736, 48645376, 54726016, 60806656, 66887296, 72967936, 79048576, 85129216, 91209856, 97290496, 103371136, 109451776, 115532416, 121613056, 127693696, 133774336, 139854976, 145935616, 152016256, 158096896, 164177536, 170258176, 176338816, 182419456, 188500096, 194580736, 200661376, 206742016, 212822656, 218903296, 224983936, 231064576, 237145216, 243225856, 249306496, 255387136, 261467776, 267548416,newfs: wtfs: 262144 bytes at sector 273629056: Input/output error % atacontrol reinit ata3 Master: ad6 WDC WD2500SD-01KCC0/08.02D08 Serial ATA v1.0 Slave: no device present % newfs -f 8192 -b 65536 /dev/ad6 /dev/ad6: 238475.2MB (488397168 sectors) block size 65536, fragment size 8192 using 81 cylinder groups of 2969.06MB, 47505 blks, 95232 inodes. super-block backups (for fsck -b #) at: 256, 6080896, 12161536, 18242176, 24322816, 30403456, 36484096, 42564736, 48645376, 54726016, 60806656, 66887296, 72967936, 79048576, 85129216, 91209856, 97290496, 103371136, 109451776, 115532416, 121613056, 127693696, 133774336, 139854976, 145935616, 152016256, 158096896, 164177536, 170258176, 176338816, 182419456, 188500096, 194580736, 200661376, 206742016, 212822656, 218903296, 224983936, 231064576, 237145216, 243225856, 249306496, 255387136, 261467776, 267548416,newfs: wtfs: 262144 bytes at sector 273629056: Input/output error After each such attempt, the kernel complains loudly: [...] ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=249306496 ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=261467776 ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=273629312 ad6: FAILURE - WRITE_DMA48 status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=273629312 Is this controller working for others? We connected the disk to it in preference to the Silicon Image connectors, which are also present on-board, because SI has poor reputation :-( Is this controller supposed to work? Thanks! What freebsd version are we talking about here ? (dmesg would have been nice). Have you tried another cable ? -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Re: Still ATAPICAM Lockup/Slowdown]
On Tor, 2006-03-30 at 11:09 +0100, Adam Retter wrote: Soren, I am using FreeBSD 6-STABLE and have a problem with the atapicam driver, I have been in contact with Thomas Quinot through the FreeBSD stable mailing list (his name was on the code for atapicam), I have sent him boot -v -h output as suggested, but he is not sure whats wrong - he has suggested that I contact you as you are responsible for the ATA sub-system. Would you be so good as to take a look at the attached forwarded message please? Looks like atapicam does some operation that locks/hangs the device(s) causing endless resets/retry loops.. Does the system boot correctly without atapicam in the kernel and are the devices accessible through the plain ATA/ATAPI devices ? -Søren Thanks Adam. email message attachment, Forwarded message - Re: Still ATAPICAM Lockup/Slowdown Forwarded Message From: Adam Retter [EMAIL PROTECTED] To: Thomas Quinot [EMAIL PROTECTED] Cc: freebsd-stable@freebsd.org Subject: Re: Still ATAPICAM Lockup/Slowdown Date: Wed, 22 Mar 2006 21:49:26 + Attached is my output from boot -h -v for my kernel with atapicam compiled in. Hope it sheds some light on the problem... On Wed, 2006-03-22 at 13:10 +0100, Thomas Quinot wrote: * Adam Retter, 2006-03-22 : For booting with or without the apaicam module compiled into the Kernel? With ATAPI/CAM would be more useful. Thanks, Thomas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: Re: Still ATAPICAM Lockup/Slowdown]
On Tor, 2006-03-30 at 12:07 +0100, Adam Retter wrote: On Thu, 2006-03-30 at 12:42 +0200, Søren Schmidt wrote: On Tor, 2006-03-30 at 11:09 +0100, Adam Retter wrote: Soren, I am using FreeBSD 6-STABLE and have a problem with the atapicam driver, I have been in contact with Thomas Quinot through the FreeBSD stable mailing list (his name was on the code for atapicam), I have sent him boot -v -h output as suggested, but he is not sure whats wrong - he has suggested that I contact you as you are responsible for the ATA sub-system. Would you be so good as to take a look at the attached forwarded message please? Looks like atapicam does some operation that locks/hangs the device(s) causing endless resets/retry loops.. Does the system boot correctly without atapicam in the kernel and are the devices accessible through the plain ATA/ATAPI devices ? Yes the system will boot fine without atapicam in the kernel and all devices are accessible. I only need atapicam for CD/DVD writting. OK, so the problem is in atapicam interaction somehow. Whats the next move, do I take what you have said back to Thomas Quinot? Yes, Thomas is the way to go. If the problem(s) needs something specific to be changed/fixed in ATA then is the time to get back to me so it can be incorporated. Of course I'll answer questions as to how interaction with ATA should be handled along the way if need be, but I dont have the time nor motivation to dig into how/why/if atapicam works... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata panic
Mike Tancsa wrote: At 11:38 PM 13/03/2006, Mike Tancsa wrote: Hi, I was trying out a recent RELENG_6 on a VIA mini ITX board with built in CF reader. If a CF is present, the box panics at boot (tried with 2 separate boards and different CFs just in case it was hardware). This is with a RELENG_6 from March 7th with the flash in I get a panic at bootup. Just updated the source to the latest RELENG_6 in case the changes fixed it, but no dice Hmm, thats not the intended behavior :) Thanks for the report, I'll look into this ASAP! -Søren GEOM: new disk ad0 ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-master: pio=PIO4 wdma=UNSUPPORTED udma=UNSUPPORTED cable=40 wire ad2: setting PIO4 on 8237 chip ad2: 244MB SanDisk SDCFB-256 Rev 0.00 at ata1-master PIO4 Fatal trap 18: integer divide fault while in kernel mode instruction pointer = 0x20:0xc069c01b stack pointer = 0x28:0xc0c20b78 frame pointer = 0x28:0xc0c20c14 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 = 0 (swapper) trap number = 18 panic: integer divide fault KDB: stack backtrace: panic(c06caf91,c06f370c,0,0,f) at 0xc0512343 = panic+0x103 trap_fatal(0,0,0,0,c07359a0) at 0xc0693485 = trap_fatal+0x225 trap(8,28,28,1,0) at 0xc06939b7 = trap+0x20f calltrap() at 0xc0682b6a = calltrap+0x5 --- trap 0x12, eip = 0xc069c01b, esp = 0xc0c20b78, ebp = 0xc0c20c14 --- __qdivrem(7a2b0,0,0,0,0) at 0xc069c01b = __qdivrem+0x3b __udivdi3(7a2b0,0,0,0) at 0xc069c4c2 = __udivdi3+0x16 ad_attach(c3199400,c3199400,c32a5000,0,c0c20d24) at 0xc046870b = ad_attach+0x44f device_attach(c3199400) at 0xc05270ae = device_attach+0x1be bus_generic_attach(c3228380,c3228380,,2,c3199400) at 0xc0527cc6 = bus_generic_attach+0x12 ata_identify(c3228380,0,c0c20d6c,c0524120,0) at 0xc04592c9 = ata_identify+0xcd ata_boot_attach(0,c0722c90,c0c20d88,c04e37f7,0) at 0xc0459441 = ata_boot_attach+0x4d run_interrupt_driven_config_hooks(0,c31459f0,c1ec00,c1e000,c25000) at 0xc0524120 = run_interrupt_driven_config_hooks+0x1c mi_startup() at 0xc04e37f7 = mi_startup+0xb3 begin() at 0xc0434095 = begin+0x2c Uptime: 3s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort -- Press a key on the console to reboot, -- or switch off the system now. . ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Showstopper ATA bug in 6.1-PRE?
Wilko Bulte wrote:
On Wed, Feb 08, 2006 at 10:44:05PM +0100, Sren Schmidt wrote..
Wilko Bulte wrote:
On Wed, Feb 08, 2006 at 10:02:08PM +0100, Sren Schmidt wrote..
Wilko Bulte wrote:
Hi Soren,
I just went to 6.1-PRE on my main machine, coming from 6.0-STABLE
of roughly end of december.
And I hit some stuff that really worries me:
- the freshly built kernel keels over with (hand transcribed):
ata3: reiniting channel SATA connect ...
SATA connected
sata_connect_devices 0x1 ATA_MASTER
ad6: req=0xC35ba0c8 SETFEATURES SETTRANSFERMODE semaphore timeout
!! DANGER Will RObinson !!
(... is where I cannot read my own handwriting, it scrolled quite fast on
the screen..)
Boot device is a SATA RAID1 on a Promise 2300.
Hmm, that should not happen. Could you try to backstep just ATA to
before the MFC, that is 24/1/06 and let me know if that helps please ?
First impression is that the problem is gone. None of the previously
reported errors are seen. I am running a level 0 dump from disk to disk
to see if the box remains stable. Given that this is my primary machine
I sure hope it will be :-)
Another snag is that my ad10 disk on 6.0-STABLE suddenly became ad12 on
6.1-PRE
Hmm that is because there is only 2 ports on your promise which is now
correctly identified, before it was errounsly found as 3 ports.
Ah, OK. I would suggest a note to the Release Note writers would be a good
thing, devices changing location after an upgrade in the -stable branch
is unnerving ;-)
Well, the good thing is that I can reproduce the error here, the bad
thing is that it slipped through testing on -current...
Oh, well, I'll look into it ASAP...
Thank you Soren!
OK, had a few this afternoon, could you try this patch and let me know
if it helps, at least it makes the problem go away on my testbed..
-Søren
Index: ata-chipset.c
===
RCS file: /nfs/export/ncvs/src/sys/dev/ata/ata-chipset.c,v
retrieving revision 1.156
diff -u -r1.156 ata-chipset.c
--- ata-chipset.c 6 Feb 2006 19:17:48 - 1.156
+++ ata-chipset.c 9 Feb 2006 13:20:06 -
@@ -2861,10 +2861,10 @@
{ ATA_PDC20377, 0, PRMIO, PRCMBO, ATA_SA150, PDC20377 },
{ ATA_PDC20378, 0, PRMIO, PRCMBO, ATA_SA150, PDC20378 },
{ ATA_PDC20379, 0, PRMIO, PRCMBO, ATA_SA150, PDC20379 },
- { ATA_PDC20571, 0, PRMIO, PRSATA2, ATA_SA150, PDC20571 },
+ { ATA_PDC20571, 0, PRMIO, PRCMBO2, ATA_SA150, PDC20571 },
{ ATA_PDC20575, 0, PRMIO, PRCMBO2, ATA_SA150, PDC20575 },
{ ATA_PDC20579, 0, PRMIO, PRCMBO2, ATA_SA150, PDC20579 },
- { ATA_PDC20771, 0, PRMIO, PRSATA2, ATA_SA300, PDC20771 },
+ { ATA_PDC20771, 0, PRMIO, PRCMBO2, ATA_SA300, PDC20771 },
{ ATA_PDC40775, 0, PRMIO, PRCMBO2, ATA_SA300, PDC40775 },
{ ATA_PDC20617, 0, PRMIO, PRPATA, ATA_UDMA6, PDC20617 },
{ ATA_PDC20618, 0, PRMIO, PRPATA, ATA_UDMA6, PDC20618 },
@@ -2925,6 +2925,7 @@
ata_promise_chipinit(device_t dev)
{
struct ata_pci_controller *ctlr = device_get_softc(dev);
+int fake_reg, stat_reg;
if (ata_setup_interrupt(dev))
return ENXIO;
@@ -2962,8 +2963,7 @@
ctlr-r_rid2, RF_ACTIVE)))
goto failnfree;
- switch (ctlr-chip-cfg2) {
- case PRSX4X: {
+ if (ctlr-chip-cfg2 == PRSX4X) {
struct ata_promise_sx4 *hpkt;
u_int32_t dimm = ATA_INL(ctlr-r_res2, 0x000c0080);
@@ -2998,58 +2998,55 @@
ctlr-setmode = ata_promise_setmode;
ctlr-channels = 4;
return 0;
- }
- case PRPATA:
- case PRCMBO:
- case PRSATA:
- /*
-* older mio type controllers need an interrupt intercept
-* function to compensate for the reset on read type interrupt
-* status register they have.
-*/
- if (bus_teardown_intr(dev, ctlr-r_irq, ctlr-handle) ||
+ }
+
+ /* mio type controllers need an interrupt intercept */
+ if (bus_teardown_intr(dev, ctlr-r_irq, ctlr-handle) ||
bus_setup_intr(dev, ctlr-r_irq, ATA_INTR_FLAGS,
ata_promise_mio_intr, ctlr, ctlr-handle)) {
device_printf(dev, unable to setup interrupt\n);
goto failnfree;
- }
- /* prime fake interrupt register */
- ATA_OUTL(ctlr-r_res2, 0x060, 0x);
- break;
}
-
- ctlr-allocate = ata_promise_mio_allocate;
- ctlr-reset = ata_promise_mio_reset;
- ctlr-dmainit = ata_promise_mio_dmainit;
- ctlr-setmode = ata_promise_mio_setmode;
-
switch (ctlr-chip-cfg2) {
case PRPATA:
ctlr-channels = ((ATA_INL(ctlr-r_res2, 0x48) 0x01) 0) +
((ATA_INL(ctlr-r_res2, 0x48) 0x02) 0) + 2;
- return 0;
-
+ goto sata150;
case PRCMBO:
-
Re: Showstopper ATA bug in 6.1-PRE?
Wilko Bulte wrote: On Thu, Feb 09, 2006 at 03:37:07PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: On Wed, Feb 08, 2006 at 10:44:05PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: On Wed, Feb 08, 2006 at 10:02:08PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: Hi Soren, I just went to 6.1-PRE on my main machine, coming from 6.0-STABLE of roughly end of december. And I hit some stuff that really worries me: - the freshly built kernel keels over with (hand transcribed): ata3: reiniting channel SATA connect ... SATA connected sata_connect_devices 0x1 ATA_MASTER ad6: req=0xC35ba0c8 SETFEATURES SETTRANSFERMODE semaphore timeout !! DANGER Will RObinson !! (... is where I cannot read my own handwriting, it scrolled quite fast on the screen..) Boot device is a SATA RAID1 on a Promise 2300. Hmm, that should not happen. Could you try to backstep just ATA to before the MFC, that is 24/1/06 and let me know if that helps please ? First impression is that the problem is gone. None of the previously reported errors are seen. I am running a level 0 dump from disk to disk to see if the box remains stable. Given that this is my primary machine I sure hope it will be :-) Another snag is that my ad10 disk on 6.0-STABLE suddenly became ad12 on 6.1-PRE Hmm that is because there is only 2 ports on your promise which is now correctly identified, before it was errounsly found as 3 ports. Ah, OK. I would suggest a note to the Release Note writers would be a good thing, devices changing location after an upgrade in the -stable branch is unnerving ;-) Well, the good thing is that I can reproduce the error here, the bad thing is that it slipped through testing on -current... Oh, well, I'll look into it ASAP... Thank you Soren! OK, had a few this afternoon, could you try this patch and let me know if it helps, at least it makes the problem go away on my testbed.. Is this relative to HEAD or RELENG_6? I cannot / will not go to HEAD with this machine (my main production box.. :-) Doesn't matter, ATA is the same on both... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Showstopper ATA bug in 6.1-PRE?
Wilko Bulte wrote: On Thu, Feb 09, 2006 at 03:45:53PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: On Thu, Feb 09, 2006 at 03:37:07PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: On Wed, Feb 08, 2006 at 10:44:05PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: On Wed, Feb 08, 2006 at 10:02:08PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: Hi Soren, I just went to 6.1-PRE on my main machine, coming from 6.0-STABLE of roughly end of december. And I hit some stuff that really worries me: - the freshly built kernel keels over with (hand transcribed): ata3: reiniting channel SATA connect ... SATA connected sata_connect_devices 0x1 ATA_MASTER ad6: req=0xC35ba0c8 SETFEATURES SETTRANSFERMODE semaphore timeout !! DANGER Will RObinson !! (... is where I cannot read my own handwriting, it scrolled quite fast on the screen..) Boot device is a SATA RAID1 on a Promise 2300. Hmm, that should not happen. Could you try to backstep just ATA to before the MFC, that is 24/1/06 and let me know if that helps please ? First impression is that the problem is gone. None of the previously reported errors are seen. I am running a level 0 dump from disk to disk to see if the box remains stable. Given that this is my primary machine I sure hope it will be :-) Another snag is that my ad10 disk on 6.0-STABLE suddenly became ad12 on 6.1-PRE Hmm that is because there is only 2 ports on your promise which is now correctly identified, before it was errounsly found as 3 ports. Ah, OK. I would suggest a note to the Release Note writers would be a good thing, devices changing location after an upgrade in the -stable branch is unnerving ;-) Well, the good thing is that I can reproduce the error here, the bad thing is that it slipped through testing on -current... Oh, well, I'll look into it ASAP... Thank you Soren! OK, had a few this afternoon, could you try this patch and let me know if it helps, at least it makes the problem go away on my testbed.. Is this relative to HEAD or RELENG_6? I cannot / will not go to HEAD with this machine (my main production box.. :-) Doesn't matter, ATA is the same on both... OK, I was not sure if they were 100% identical. The patch at first impression seems to have eliminated the problem. Good seems I'm on the right track at least. Interestingly enough ad10 remained ad10 with the patch applied? Yeah, thats intentional, I though we better not break POLA here.. I'll put some load on to see what happens. Let me know how that turns out, I'll clean things up a bit and get it committed to -current, then get permission to MFC when we are sure it fixes the problem... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Showstopper ATA bug in 6.1-PRE?
Wilko Bulte wrote: Hi Soren, I just went to 6.1-PRE on my main machine, coming from 6.0-STABLE of roughly end of december. And I hit some stuff that really worries me: - the freshly built kernel keels over with (hand transcribed): ata3: reiniting channel SATA connect ... SATA connected sata_connect_devices 0x1 ATA_MASTER ad6: req=0xC35ba0c8 SETFEATURES SETTRANSFERMODE semaphore timeout !! DANGER Will RObinson !! (... is where I cannot read my own handwriting, it scrolled quite fast on the screen..) Boot device is a SATA RAID1 on a Promise 2300. Hmm, that should not happen. Could you try to backstep just ATA to before the MFC, that is 24/1/06 and let me know if that helps please ? Another snag is that my ad10 disk on 6.0-STABLE suddenly became ad12 on 6.1-PRE Hmm that is because there is only 2 ports on your promise which is now correctly identified, before it was errounsly found as 3 ports. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Showstopper ATA bug in 6.1-PRE?
Wilko Bulte wrote: On Wed, Feb 08, 2006 at 10:02:08PM +0100, Sren Schmidt wrote.. Wilko Bulte wrote: Hi Soren, I just went to 6.1-PRE on my main machine, coming from 6.0-STABLE of roughly end of december. And I hit some stuff that really worries me: - the freshly built kernel keels over with (hand transcribed): ata3: reiniting channel SATA connect ... SATA connected sata_connect_devices 0x1 ATA_MASTER ad6: req=0xC35ba0c8 SETFEATURES SETTRANSFERMODE semaphore timeout !! DANGER Will RObinson !! (... is where I cannot read my own handwriting, it scrolled quite fast on the screen..) Boot device is a SATA RAID1 on a Promise 2300. Hmm, that should not happen. Could you try to backstep just ATA to before the MFC, that is 24/1/06 and let me know if that helps please ? First impression is that the problem is gone. None of the previously reported errors are seen. I am running a level 0 dump from disk to disk to see if the box remains stable. Given that this is my primary machine I sure hope it will be :-) Another snag is that my ad10 disk on 6.0-STABLE suddenly became ad12 on 6.1-PRE Hmm that is because there is only 2 ports on your promise which is now correctly identified, before it was errounsly found as 3 ports. Ah, OK. I would suggest a note to the Release Note writers would be a good thing, devices changing location after an upgrade in the -stable branch is unnerving ;-) Well, the good thing is that I can reproduce the error here, the bad thing is that it slipped through testing on -current... Oh, well, I'll look into it ASAP... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nVidia RAID + FreeBSD 6.0
Vulpes Velox wrote: On Sun, 29 Jan 2006 16:46:52 +1030 Daniel O'Connor [EMAIL PROTECTED] wrote: I am looking at getting a motherboard based on nForce 3 or 4, and I am wondering if the RAID will be usable? I don't mind if I have to use the BIOS to setup/rebuild the array, but I don't want to buy a system I can't use the RIAD for at all. I note from ata-raid.c that there is a meta-data read routine, but no write one - I think this means I can use it after it's been defined, but not rebuilt or create an array in the first place. I would also check what the chipset used for it is. [snip] Lets not mix things up here, this is about the nForce chipsets. The nForce RAID BIOS has problems with choosing the right drive to build from when a mirror fails, this will need a BIOS update to get fixed. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata (raid) patches
Michael Butler wrote: 1) the ata-raid driver currently leaks ata_composite and ata_request structures into neverland in a mirrored configuration. This can be observed using sysctl -a | grep ^ata_ and noting the increasing in-use count as time goes on. Eventually, this causes the kernel to run out of memory. This is fixed by tracking the request counts on each composite request. Looks pretty much on the spot, I'll look this one over and get it committed once I'm satisfied with it fixing the bug, thanks a bunch for hunting this one down ! 2) another part of this patch is to ata-queue where a channel lock is asserted in a (hopefully rare) rebuild process even if the dependencies flag is set (we're waiting for a read). Moving the test for a dependency outside of the lock saves waiting on it when nothing can be done. A small nit with near negligible impact but, when you're waiting for a rebuild ... I dont think you can measure this actually, but it doesn't hurt at least to move the lock outside. 3) another part of this patch is to ata-raid where the choice of drive from which to read favours one side of a mirror even when both drives are near the block(s) we want. Because the mirror is on another channel on the Highpoint controller, it performs (marginally :-() better when we toggle between them. Hmm, well, depends on what sort of behavior one wants to optimise for. I have a few other patches for optimisations but havn't decided what to eventually use yet. Guess its time for me to run some tests on this.. I'll look into get this integrated, again thanks for digging in and doing the hard work of finding the problem(s) !! -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA RAID problem in6.0-RC1 (ata_alloc_request/ata_raid_init_request)
Enrique Ayesta Perojo wrote: El Jueves 10 Noviembre 2005 16:06, Michael Butler escribió: David Taylor wrote: | [snip] | | I'm still seeing (lots) of these messages (below) on 6.0-RELEASE. | Should I just file a PR about it, and is there anything else that | would be useful to track down what's causing them? I get these with an HighPoint HPT372N UDMA133 controller .. what is your's? Michael I have the same problem with an Adaptec ATA RAID 1200A (HPT370), i'll try to upgrade to 6.0-STABLE to see if the problem has been solved, anyway, does anybody know if there is a patch for this? Something is not well here, I just inserted a rocketraid 1520 into my (newish) test box there, and even the HPT BIOS cant find the drives, it locks up the machine!! However a rocketraid 1540 sees the disks and apparently works just fine.. This suggest to me that there might be HW problems involved in this.. -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6-stable unstable with HighPoint HPT372N UDMA133 controller
On 07/11/2005, at 18:10, Michael Butler wrote: | I wrote: | | cvsup'd and built: FreeBSD 6.0-STABLE #4: Fri Nov 4 18:07:30 EST 2005 | | ~ [ .. ] | | | Nov 6 16:43:27 mail kernel: DOH! ata_alloc_request failed! | | Nov 6 16:43:27 mail kernel: FAILURE - out of memory in | ata_raid_init_request | | Nov 6 16:43:27 mail last message repeated 7 times | | Nov 6 16:43:27 mail kernel: Looking at the output of sysctl -a on a now almost idle machine I see: ITEMSIZE LIMIT USEDFREE REQUESTS ~ [ .. ] ata_composit:192,0, 12296,124,62341 ata_request: 200,0, 24592,108, 920945 ~ .. shouldn't these be freed at some point if there's minimal disk activity (and few dirty buffers, systat -vm says there are 7)? Or am I misreading this? That does indeed look wrong. However I cant reproduce the problem here on any of the machines I have 6.0 on, and I dont think a memory leeak that severe would have survived this far, but I've been wrong many times before... I'll look into it as soon as I have a little more time than today.. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP! 6.0-RELEASE coming
On 27/10/2005, at 21:12, Marcin Jessa wrote: On Thu, 27 Oct 2005 20:09:36 +0200 Felipe Alfaro Solana [EMAIL PROTECTED] wrote: Wanted to let everyone know that the testing on RC1 has gone well enough that we've decided to skip RC2 and go straight to 6.0-RELEASE. Everyone that we have talked to has applauded the stability and functionality of the system, so we are really pleased and really eager to wrap it up and get it out to everyone. Indeed, I've been using 6.0 since BETA1 for a very long time and it seems stable like a rock. Congratulations! One thing I noticed with the ata code on 6.x. Put in a CF to your PCMCIA to CF adaptor and try to boot your laptop. The kernel will immidiately core dump. This never happened on 5.x. #uname -a FreeBSD lapdance.yazzy.net 6.0-RC1 FreeBSD 6.0-RC1 #12: Wed Oct 12 09:06:40 UTC 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LAPDANCE i386 I've just committed a fix for this a few hours ago.. Søren Schmidt [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SiI 3114 woes
On 08/09/2005, at 13:37, Mars G. Miro wrote:
Yo list/Soren!
Has anybody successfully installed FreeBSD on the dual-Opteron TYAN
ThunderK8W S2885 ( http://www.tyan.com/products/html/thunderk8w.html )
using the onboard SiI 3114 SATA controller? This mobo is supposedly
supported:
http://www.freebsd.org/cgi/query-pr.cgi?pr=80857
But I have never been able to successfully install
FreeBSD({5.3/5.4/6.0Beta3/4} amd64/i386) on it, using SATA.
In my last attempt at installing 6.0Beta4 AMD64 on it, I get:
ad4: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=4ABORTED
LBA=105819039
g_vfs_done():ad4s1e[WRITE(offset=23695114240, length=2048)]error = 5
The drive apparently aborts the write, however this cant be the first
operation to it, so something else might have happend before this.
On my (granted UP AMD64) it works like a charm, so does it on x86 so
the driver is not completely broken at least :)
Get me the output from dmesg so I can see whats under the hood, might
help explain things.
Søren Schmidt
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atacontrol commands fault at NForce4
On 23/08/2005, at 19:19, Dmitry Morozovsky wrote: Hi there Soeren, using parallel ATA drive at our new TYAN motherboard I see [EMAIL PROTECTED]:/usr/src# atacontrol mode 0 atacontrol: Invalid device 0 the same for other channel-related commands such as [EMAIL PROTECTED]:/usr/src# atacontrol detach 1 atacontrol: Invalid channel 1 I miss the FreeBSD version, but if its recent you should man atacontrol. quick hints: atacontrol mode ad0 atacontrol detach ata1 - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ata breakage from RELENG_5 to RELENG_6
On 22/08/2005, at 22:24, Mike Tancsa wrote: I updated one of our boxes from RELENG_5 to 6. Couple of things I noticed was that the smartmontools and atacontrol seems to be broken now. I updated smartmon to the latest in the ports, but same problem. The ioctl ABI to ATA has changed, you need atacontrol and smartmontools to be in sync. atacontrol is just a recompile, smartmontools you want rev 1.17 or later of the Makefile... - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
On 10/08/2005, at 17:44, Scot Hetzel wrote: On 8/10/05, Karl Denninger [EMAIL PROTECTED] wrote: On Wed, Aug 10, 2005 at 09:51:03AM -0400, Mike Tancsa wrote: At 09:31 AM 10/08/2005, Karl Denninger wrote: Also, I've yet to see a developer commit on the list that they WILL fix it if such a controller board is forthcoming (and will return the board when they're done) - I've got two of these cards here (choose between Adaptec and Bustek) and would be happy to UPS one to someone IF I had a firm commitment that 6.x would NOT go out without this being addressed and that the board would be returned to me when work was complete. You demand to see support for this chipset fixed, yet, you cant pony up a measly hundred bucks to donate the card to the developer who is not being paid to develop anything. ---Mike I have demanded nothing Mike. I agree Mike's wording was a little strong, but we have seen you request strongly that some one fix this problem. Have you contacted Søren, to see if he has the troublesome hardware? Also contact Søren directly with your offer to supply a troublesome board, and/or access to a system that displays the problem. More than likely he would agree to return the board once he has a proper fix for the problem. Since I came in late in this, I need to know what kind of controller we are talking about, and if the problem is still present in 6.0. I plan to backport ATA from 6.0 to 5-stable when it has settled, so 6.0 is the one and only (pre)release to test with and get back to me with the result. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
On 10/08/2005, at 20:05, Scot Hetzel wrote: Since I came in late in this, I need to know what kind of controller we are talking about, and if the problem is still present in 6.0. I plan to backport ATA from 6.0 to 5-stable when it has settled, so 6.0 is the one and only (pre)release to test with and get back to me with the result. They have been talking about SII and Intel ICH6 chips. And a few have stated that they are having problems with the 6.0-Beta releases with these chips. Well, both work wonderfully here YMMV of course.. No, seriously I need *much* more accurate info than that, I need the dmesg from the failing system, and I need an exact description of the problem, preferably with logs, dumbs etc etc. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
On 10/08/2005, at 20:29, J. T. Farmer wrote: Scot Hetzel wrote: On 8/10/05, Søren Schmidt [EMAIL PROTECTED] wrote: Since I came in late in this, I need to know what kind of controller we are talking about, and if the problem is still present in 6.0. I plan to backport ATA from 6.0 to 5-stable when it has settled, so 6.0 is the one and only (pre)release to test with and get back to me with the result. They have been talking about SII and Intel ICH6 chips. And a few have stated that they are having problems with the 6.0-Beta releases with these chips. What, I'm chopped liver? :^ I'm getting these errors with a standard, _very_ not state of the art, Via KT266A/8235 chipset. PATA WDC 800 drive. All very standard stuff for a desktop. Was running WinXP without a problem for quite some time. Generic kernel. In fact when I tried to install 5.4 (and 5.4-SNAP from 5 July 9 July), it errored out as soon as the install kernel tried to write to the disk. FS's do not work when you can't write the superblocks out... Oh yeah, writing the disklabel also generated the same error. So it's not just the SATA raid type chipsets. It's plain vanilla ATA controllers, also. As I said I need reports on 6.0, the ATA driver as is in 5.4 is not supported by me unless you use the ATA mkIII patches.. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
On 10/08/2005, at 22:51, Karl Denninger wrote: Since I came in late in this, I need to know what kind of controller we are talking about, and if the problem is still present in 6.0. I plan to backport ATA from 6.0 to 5-stable when it has settled, so 6.0 is the one and only (pre)release to test with and get back to me with the result. - S?ren 6.0 BETA1 AND 5.4 BOTH fail with the SiI 3112 chipsets. Reliably. I have two controllers here that are from different manufacturers and both exhibit the same problem. The SAME disks (two different manufacturers - hitachi and maxtor) on a motherboard ICH5 adapter work perfectly, smartmontools says all 4 (I have two examples of each) are healthy, and both ALSO work perfectly on and are declared healthy by a 3ware 8502's internal diags and operating kernel (smartmontools won't talk to them on the 8502.) This is the subject of the PR I filed back in February. Again, if you want either a controller shipped to you OR access to a development machine (e.g. ssh in and play) which has the suspect configuration on it, the latter of which is probably the best option (since making it fail is simple) I'm willing to provide either - my only caveat is that if I send hardware I want it back when you're done, and I believe its reasonable to expect that 6.0 will get HELD in its release cycle until this is resolved. I have plenty of the sii3112's around, so thats not needed, however I've not managed to get ahold of a machine in which it fails reliably with ATA as is in 6.0. The latter offer (ssh access) has been on the table for several months. The former I just put on the table as I threw up my hands and bought a 3ware card - which means I now have TWO of the suspect cards and need only one for my own testing (in the sandbox) I'm willing to go WELL out of my way to make it possible for this to get fixed, since there appears to be an issue with access to hardware that breaks reliably. However, I, and others, would like to know that we're going to see the problem get resolved. I've already gone WAY out of my way to try to support the sii3112, and I'm not inclined to waste more of my precious spare time on it. However, if it really is that important to enough people to try to workaround the silicon bugs (which very likely isn't possible), get together and get me failing HW on my desk and time to work on it. Again - this is hardware that is STABLE and works under 4.x - in the case of my specific configuration I ran under 4.x for over a year without a single incident. With 5.4 and 6.0-BETA I can kill it inside of 2 minutes with nothing more complicated than a make -j4 buildworld. First. you cannot by any degree of the word call the sii3112 for STABLE hardware, its broken beyond repair or workarounds, and even the supplier acknowledges that fact. Second, you cannot possibly have used gmirror (as in the PR) on 4.x so what was the config back then ? Third, please get gmirror out of the loop (use atacontrol to create a mirror if need be) and let me know if that changes anything. Forth, another thing to try is fumbling with BIOS settings, some setups has been reported to start working when PCI timings is changed YMMV.. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ad10: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=11441599
On 11/08/2005, at 0:28, Randy Bush wrote: As I said I need reports on 6.0, the ATA driver as is in 5.4 is not supported by me unless you use the ATA mkIII patches.. you know, we just upgraded a system from 4.11 to 7.0 and see problems. we have been chasing cables, and never considered that we could blame all our problems on you and demand service! :-) I'd rather put it like this: you got what you payed for ;) ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729217 ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729217 ad2: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=7 ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729222 ad2: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=729222 ad2: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=84ICRC,ABORTED LBA=2 atapci0: Promise PDC20269 UDMA133 controller port 0x5020-0x5027,0x5014-0x50175 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 pci4: base peripheral, interrupt controller at device 30.0 (no driver attache) pcib6: ACPI PCI-PCI bridge at device 31.0 on pci4 pci6: ACPI PCI bus on pcib6 atapci1: Promise PDC20269 UDMA133 controller port 0x6020-0x6027,0x6014-0x60176 ata4: ATA channel 0 on atapci1 ata5: ATA channel 1 on atapci1 pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci7: ACPI PCI bus on pcib7 pci7: display, VGA at device 1.0 (no driver attached) isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci2: Intel ICH3 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x30 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 Could I have the *complete* dmesg please ? h i demand a full refund granted! just get it from where you bought it :) - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PST still not bootable?
On 24/07/2005, at 23:28, Mike Jakubik wrote: I'm curious if the Promise Supertrak SX6000 is still not bootable under FreeBSD 5.4 or 6. The man page never stated this before, and it would be nice to know. I don't think so, the problem is in our boot code, not in the sx6000. That said, some systems has problems getting through POST with a sx6000 in the wrong PCI slot. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch: fix ata panic with Thinkpad CD and DVD drives
Nate Lawson wrote: If you've been having memory modified after free panics on -current and have a Thinkpad, the attached patch should fix things for you. A quick check of RELENG_5 indicates that the bug is probably there also but I haven't tested for it there. The bug is triggered by timeouts in the ata_getparam() probe path. The ata_timeout() fires and ata_end_transaction() is called to get the status. However, it continues down into ata_pio_read() even though there is no data available since we had a timeout, not read completion. ata_pio_read() reads 512 bytes of probably bogus data. The important problem is that it also advances donecount. On subsequent timeouts (note there are 4 below), donecount advances into unallocated memory and so subsequent ata_pio_read() calls overwrite 512 bytes of someone else's memory. The fix is to exit immediately if ATA_R_TIMEOUT is set after reading the status in ata_end_transaction(). It shouldn't go into ata_pio_read() if there was a timeout. The patch does this. However, it only handles PIO timeouts since I wasn't sure the best way to proceed for unwinding DMA state and the like for the other cases. This is enough to fix the overwrite and subsequent panic on my systems. I've run heavy IO stress and DVD accesses for a while and no further panics. While looking into this, I found another potential problem. In one reinjection case, donecount wasn't reset to 0. The patch for ata-queue.c does this and I think it's necessary but don't hit this case in testing so I can't be sure. Finally, there's one whitespace nit that helps with clarity. These are similar bugs to one found back in August that had the same effect. Here's the closest reference I could find in the mail archives for this: http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-August/033033.html Just a note from here, these bugs are fixed in ATA mkIII so you could just have gleaned the solution from there (or maybe you did :)) -- -Søren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch: fix ata panic with Thinkpad CD and DVD drives
Nate Lawson wrote: Søren Schmidt wrote: Nate Lawson wrote: If you've been having memory modified after free panics on -current and have a Thinkpad, the attached patch should fix things for you. A quick check of RELENG_5 indicates that the bug is probably there also but I haven't tested for it there. The bug is triggered by timeouts in the ata_getparam() probe path. The ata_timeout() fires and ata_end_transaction() is called to get the status. However, it continues down into ata_pio_read() even though there is no data available since we had a timeout, not read completion.ata_pio_read() reads 512 bytes of probably bogus data. The important problem is that it also advances donecount. On subsequent timeouts (note there are 4 below), donecount advances into unallocated memory and so subsequent ata_pio_read() calls overwrite 512 bytes of someone else's memory. The fix is to exit immediately if ATA_R_TIMEOUT is set after reading the status in ata_end_transaction(). It shouldn't go into ata_pio_read() if there was a timeout. The patch does this. However, it only handles PIO timeouts since I wasn't sure the best way to proceed for unwinding DMA state and the like for the other cases. This is enough to fix the overwrite and subsequent panic on my systems. I've run heavy IO stress and DVD accesses for a while and no further panics. While looking into this, I found another potential problem. In one reinjection case, donecount wasn't reset to 0. The patch for ata-queue.c does this and I think it's necessary but don't hit this case in testing so I can't be sure. Finally, there's one whitespace nit that helps with clarity. These are similar bugs to one found back in August that had the same effect. Here's the closest reference I could find in the mail archives for this: http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-August/033033.html Just a note from here, these bugs are fixed in ATA mkIII so you could just have gleaned the solution from there (or maybe you did :)) Nope, but I'm glad you can corroborate these fixes are correct. Actually I cant, I havn't looked at what was committed since I already did fix these problems in the mkIII patches floating around.. Anyhow its in there and the committer has to deal with it until/if I commit mkIII to -current, I'm out of the loop until then... -- -Søren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
On 25/05/2005, at 4:17, alan bryan wrote: --- Søren Schmidt [EMAIL PROTECTED] wrote: Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII n patches? Yes, I've done quite a bit of changes that affects this on -current. However its done blindfolded since I dont have a nForce4 based system here yet (but should soon). - Søren How soon is soon? I may be able to send you some hardware too if that would be helpful. one of these days it should be in transit.. I tried a -CURRENT kernel today but didn't build/install world or anything else as I don't want to mess up this machines 5.4 installation. The result was that it now seems to identify all the atapici0 - atapici3 controllers and doesn't do the repeated DISCONNECTED/CONNECTED messages but it still panicked near the end of the bootup process, around the USB area. I called a friend today who has a spare SATA drive I can borrow so I'll be picking that up tomorrow and I'll swap out drives and do a fresh -CURRENT install tomorrow on that new drive to see if I can get it any further along towards a successful boot. I'll report back with my findings. OK, let me know, I'll be away from mail Thurday to Sunday, so if I dont respond as quickly as usual you know why... - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nForce 4, SATA Drive only runs at UDMA33?
On 24/05/2005, at 5:01, alan bryan wrote: Here's a recap of all the things I've tried and discovered in a bunch of testing today. Tried mkIII m patches and that doesn't show atapici1 or atapici2 - they just show as GENERIC with drives as UDMA33 Tried mkIII n patches and then atapici1 shows as nForce4 with SATA drives but has further problems detailed below. atapici2 always shows up in dmesg as GENERIC no matter what. ... Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII n patches? Yes, I've done quite a bit of changes that affects this on -current. However its done blindfolded since I dont have a nForce4 based system here yet (but should soon). - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On 22/05/2005, at 18:11, Joe Rhett wrote: You need to overwrite the metadata (se above) which are located in different places again depending on metadata format. So where is it located with the sil3114 controler? (same as 3112, but with 4 ports...) On Sun, May 22, 2005 at 12:45:05AM +0200, Søren Schmidt wrote: Depends on what BIOS you have on there, several exists for the SiI chips, -current or mkIII would tell you which. Just null out the last 63 sectors on the disks and you should be fine since all possible formats are in that range... I know how to do this using dd from the start of the disk. How do I do this at the end of the disk? man dd ? :) you need to get the size of the disk in sectors (hint atacontrol) then you do dd if=/dev/zero of=/dev/adN oseek=(size-63) - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RC2 freezing - ATA related?
On 21/05/2005, at 0:52, Peter Jeremy wrote: On Fri, 2005-May-20 14:53:09 -0600, Elliot Finley wrote: From: Peter Jeremy [EMAIL PROTECTED] On Fri, 2005-May-20 08:25:58 -0600, Elliot Finley wrote: I took the -L option off of my dump command in my daily dump script. I've gone two days without locking up which is unusual. I think that may be what was tickling the bug that was locking me up. Sometime you might like to do a 'dd if=/dev/ar0 of=/dev/null bs=32k' just to confirm that you don't have any unreadable blocks (though this seems unlikely). came up clean. transfer went 40MB/s. That seem to leave the finger pointing at the ATA driver. Paging Søren: Are you have to help Elliot? No, my only advise is to use the ATA mkIII patches or better yet - current.. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On 21/05/2005, at 1:10, Joe Rhett wrote: On Thu, May 19, 2005 at 08:21:13AM +0200, Søren Schmidt wrote: On 19/05/2005, at 2.20, Joe Rhett wrote: Soren, I've just retested all of this with 5.4-REL and most of the problems listed here are solved. The only problems appear to be related to these ghost arrays that appear when it finds a drive that was taken offline earlier. For example, pull a drive and then reboot the system. This depends heavily on the metadata format used, some of them simply doesn't have the info to avoid this and some just ignores the problem. .... You need to overwrite the metadata (se above) which are located in different places again depending on metadata format. So where is it located with the sil3114 controler? (same as 3112, but with 4 ports...) Depends on what BIOS you have on there, several exists for the SiI chips, -current or mkIII would tell you which. Just null out the last 63 sectors on the disks and you should be fine since all possible formats are in that range... Is there anything I can do with userland utilities? ATA mkIII is exactly about getting ata-raid rewritten from the old cruft that originally was written before even ATA-ng was done, so yes I'd expect it to behave better but not necessarily solve all your problems as some of them might be features of the metadata So what do I need to know to determine the problem? The metadata format for one, thats the most important factor for getting this to work, but some of them has no generation or anything so its hard if not impossible to avoid this problem. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RC2 freezing - ATA related?
On 22/05/2005, at 2:36, Thomas Hurst wrote: * Søren Schmidt ([EMAIL PROTECTED]) wrote: No, my only advise is to use the ATA mkIII patches or better yet - current.. In a similar vein, I'm seeing the same WRITE_DMA timeouts and system lockups using ATA mkIII patches as I did using the standard RELENG_5 driver, on two seperate systems. I'm getting the WRITE_DMA retries on a multi-gmirror Athlon system using a PCI SATA card; the two PATA drives on the system are fine: FreeBSD 5.4-STABLE #0: Thu Apr 28 06:31:53 BST 2005 atapci1: SiI 3112 SATA150 controller port 0xcc00-0xcc0f, 0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc07 mem 0xe7062000-0xe70621ff irq 11 at device 12.0 on pci0 ad4: 381554MB ST3400832AS/3.01 [775221/16/63] at ata2-master SATA150 ad6: 381554MB ST3400832AS/3.01 [775221/16/63] at ata3-master SATA150 .. ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=401743679 ad4: TIMEOUT - WRITE_DMA retrying (2 retries left) LBA=781421759 It seems harmless, but results in writes freezing for several seconds every couple of hundred MB (annoying with 360G of storage as you might imagine). It normally favours a single drive, but seems to bounce between ad4 and 6 for no apparant reason. Replacing the SATA card and cables has no effect. Attempting to drop the drives to PIO with atacontrol doesn't seem to do anything either (they remain at SATA150). The other system where I see the lockups (I used to get READ/WRITE_DMA timeouts with the lockup many moons ago, which seems to have started after a system update, but for the past 6+ months or so I just get the lockup) is an old BP6 (dual Celeron), on two different channels on two different drive: FreeBSD 5.4-STABLE #2: Tue Apr 26 17:59:25 BST 2005 atapci1: HighPoint HPT366 UDMA66 controller port 0xd800-0xd8ff,0xd400-0xd403,0xd000-0xd007 irq 18 at device 19.0 on pci0 atapci2: HighPoint HPT366 UDMA66 controller port 0xe400-0xe4ff,0xe000-0xe003,0xdc00-0xdc07 irq 18 at device 19.1 on pci0 ad4: 76319MB Seagate ST380011A 3.04 at ata2-master UDMA66 ad6: 114473MB Seagate ST3120026A 3.01 at ata3-master UDMA66 Setting these drives to PIO4 resolves the stability problems (which again only occurs under heavy disk activity, almost always on writes), but makes the system crawl. I'm planning on migrating it to gmirror, which I expect will make it behave more like the Athlon, but obviously I'd like to be able to use DMA reliably without resorting to RAID-1 everywhere. Save me Søren! You have picked some of the most dreaded HW out there thats for sure, so I'm not sure I can do that :) Anyhow, you should try a recent -current since some of the race/ timeout problems thats possible in 5.x has been fixed there. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
On 19/05/2005, at 2.20, Joe Rhett wrote: Soren, I've just retested all of this with 5.4-REL and most of the problems listed here are solved. The only problems appear to be related to these ghost arrays that appear when it finds a drive that was taken offline earlier. For example, pull a drive and then reboot the system. This depends heavily on the metadata format used, some of them simply doesn't have the info to avoid this and some just ignores the problem. 1. If you reboot the system you can delete the array cleanly, but it returns next time. I can't figure out how to make this information go away, and I've tried low-level formatting the disks :-( You need to overwrite the metadata (se above) which are located in different places again depending on metadata format. 2. Removing the array using atacontrol delete after an atacontrol reinit channel will always produce a page fault. For example, if you have only a single array in a system and you lose a drive, and then it returns later.. # atacontrol status 1 atacontrol: ioctl(ATARAIDSTATUS): Device not configured # atacontrol reinit 5 ...finds disk # atacontrol status 1 ar1: ATA RAID1 subdisks: DOWN DOWN status: DEGRADED # atacontrol delete 1 *Page Fault* We can't run -current, so I'm hoping to find options to work with this as is. If you know for a fact that this has changed in the mkIII patches then I'd be willing to investigate, but I will need to be certain. ATA mkIII is exactly about getting ata-raid rewritten from the old cruft that originally was written before even ATA-ng was done, so yes I'd expect it to behave better but not necessarily solve all your problems as some of them might be features of the metadata I know that you have no desire to work on this older code, but could you at least clue me in on how to get atacontrol to drop these ghost arrays? see above. - Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.4-RC2 freezing - ATA related?
Elliot Finley wrote: This has been happening since 5.3-R, I've been tuning different parameters to no avail. I've taken the disks off of the onboard ICH5 controller and put them a promise TX4 S150 controller, but still the same thing happens. The system freezes, but isn't totally dead. It'll still respond to pings, the screensaver still functions, but it won't respond to a CAD at the console. But if I press 'Enter' at the console, it'll give me a 'login:' prompt, but after entering the username, it never comes back with the 'password:' prompt. After manually resetting the system it boots and says 'Automatic file system check failed; help!' and drops into single user mode. Running fsck manually corrects errors on all volumes. Then it'll boot from that point. This seems to be triggered by daily periodic as it happens at 3:02-3:03AM each time. But it doesn't happen *every* morning. Hmm, sounds as a deadlock somewhere. On the ATA part, try the ATA mkIII patches on http://people.freebsd.org/~sos/ATA and see if that changes anything. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RAID 1 with Adaptec SATA 1210SA + FreeBSD 5.4 + ata mkIII OK
Gheorghe Ardelean wrote: Hi Soeren, I have to thank you for the work you put in the ata driver. Thanks! After patching the 5.4 sources with the new ata mkIII (http://people.freebsd.org/~sos/ATA) I am able to use the RAID 1 with my Adaptec SATA 1210SA. Good :) let me know if you run into problems with it! -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII suspend problem
Andrew Heybey wrote:
I just tried RELENG_5 as of last week and the latest (April 13) ATA
mkIII patches from http://people.freebsd.org/~sos/ATA/ on my laptop.
Unfortunately, it breaks suspend-to-RAM (S3).
History:
I first tried RELENG_5 on the laptop (a Toshiba Tecra M2V) in January
and suspend did not work (the laptop hung after reinitializing the ATA
controller). Then I tried the first release of ATA mkIII. That first
version of the new ATA code made suspend work, and I was happy.
Last week, I tried upgrading to the latest RELENG_5 and the newest ATA
mkIII code, and now after suspending the kernel panics when reiniting
the ATA device(s) in ata-all.c:ata_reinit(), about line 217:
/* reinit the children and delete any that fails */
if (!device_get_children(dev, children, nchildren)) {
mtx_lock(Giant); /* newbus suckage it needs Giant */
for (i = 0; i nchildren; i++) {
if (children[i] device_is_attached(children[i]))
if (ATA_REINIT(children[i])) {
if (ch-running-dev == children[i]) {
device_printf(ch-running-dev,
FAILURE - device detached\n);
ch-running-dev = NULL;
ch-running = NULL;
}
device_delete_child(dev, children[i]);
}
}
free(children, M_TEMP);
mtx_unlock(Giant); /* newbus suckage dealt with, release Giant */
}
The problem is that ch-running is NULL at this point.
Any suggestions on how to further debug or fix?
Thats been fixed since in -current just replace the line with:
if (ch-running ch-running-dev == children[i]) {
--
-Søren
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: more troubles with ATA
tofik suleymanov wrote: Good day Soren, i've applied ATA mkIII patch on freshly cvsuped 5.4-STABLE and experienced problems with onboard sata controller.Here is a fragment from dmesg output: atapci1: nVidia nForce3 Pro SATA150 controller port 0xe000-0xe00f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 22 at device 10.0 on pci0 ata2: ATA channel 0 on atapci1 atapci1: failed to enable memory mapping ! device_attach: ata2 attach returned 6 ata3: ATA channel 1 on atapci1 atapci1: failed to enable memory mapping ! device_attach: ata3 attach returned 6 while Fasttrack TX2200 controller recognized as Promise PDC 20571 SATA150 controller works fine. Before ATA mkIII patch the onboard controller recognized as: atapci1: GENERIC ATA CONTROLLER port 0xe000-0xe00f,0xb70-0xb73,0x970-0x977,0xbf0-0xbf3,0x9f0-0x9f7 irq 11 at device 10.0 on pci0 The motherboard is Gigabyte GA-K8NS nForce3 250 chipset with amd64 Athlon CPU. Any clues about making those two controllers work together ? It should work on -current, but I have no boards to check this on currently. I have no immediate plans for a new patch for 5.4-STABLE, as it misses the callout updates thats in -current and that ATA needs now. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UPDATE: ATA mkIII official patches for releng_5
I've just uploaded the latest ATA mkIII patches for releng_5 (and releng_5_4 for that matter). Since this work is now in -current there will only be releng_5 patches now and then if there is sufficient interest. Anyhow, they are on http:/people.freebsd.org/~sos/ATA Enjoy! -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch: fix ata panic with Thinkpad CD and DVD drives
Nate Lawson wrote: If you've been having memory modified after free panics on -current and have a Thinkpad, the attached patch should fix things for you. A quick check of RELENG_5 indicates that the bug is probably there also but I haven't tested for it there. The bug is triggered by timeouts in the ata_getparam() probe path. The ata_timeout() fires and ata_end_transaction() is called to get the status. However, it continues down into ata_pio_read() even though there is no data available since we had a timeout, not read completion. ata_pio_read() reads 512 bytes of probably bogus data. The important problem is that it also advances donecount. On subsequent timeouts (note there are 4 below), donecount advances into unallocated memory and so subsequent ata_pio_read() calls overwrite 512 bytes of someone else's memory. The fix is to exit immediately if ATA_R_TIMEOUT is set after reading the status in ata_end_transaction(). It shouldn't go into ata_pio_read() if there was a timeout. The patch does this. However, it only handles PIO timeouts since I wasn't sure the best way to proceed for unwinding DMA state and the like for the other cases. This is enough to fix the overwrite and subsequent panic on my systems. I've run heavy IO stress and DVD accesses for a while and no further panics. While looking into this, I found another potential problem. In one reinjection case, donecount wasn't reset to 0. The patch for ata-queue.c does this and I think it's necessary but don't hit this case in testing so I can't be sure. Finally, there's one whitespace nit that helps with clarity. These are similar bugs to one found back in August that had the same effect. Here's the closest reference I could find in the mail archives for this: http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-August/033033.html Just a note from here, these bugs are fixed in ATA mkIII so you could just have gleaned the solution from there (or maybe you did :)) -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patch: fix ata panic with Thinkpad CD and DVD drives
Nate Lawson wrote: Søren Schmidt wrote: Nate Lawson wrote: If you've been having memory modified after free panics on -current and have a Thinkpad, the attached patch should fix things for you. A quick check of RELENG_5 indicates that the bug is probably there also but I haven't tested for it there. The bug is triggered by timeouts in the ata_getparam() probe path. The ata_timeout() fires and ata_end_transaction() is called to get the status. However, it continues down into ata_pio_read() even though there is no data available since we had a timeout, not read completion.ata_pio_read() reads 512 bytes of probably bogus data. The important problem is that it also advances donecount. On subsequent timeouts (note there are 4 below), donecount advances into unallocated memory and so subsequent ata_pio_read() calls overwrite 512 bytes of someone else's memory. The fix is to exit immediately if ATA_R_TIMEOUT is set after reading the status in ata_end_transaction(). It shouldn't go into ata_pio_read() if there was a timeout. The patch does this. However, it only handles PIO timeouts since I wasn't sure the best way to proceed for unwinding DMA state and the like for the other cases. This is enough to fix the overwrite and subsequent panic on my systems. I've run heavy IO stress and DVD accesses for a while and no further panics. While looking into this, I found another potential problem. In one reinjection case, donecount wasn't reset to 0. The patch for ata-queue.c does this and I think it's necessary but don't hit this case in testing so I can't be sure. Finally, there's one whitespace nit that helps with clarity. These are similar bugs to one found back in August that had the same effect. Here's the closest reference I could find in the mail archives for this: http://lists.freebsd.org/mailman/htdig/freebsd-current/2004-August/033033.html Just a note from here, these bugs are fixed in ATA mkIII so you could just have gleaned the solution from there (or maybe you did :)) Nope, but I'm glad you can corroborate these fixes are correct. Actually I cant, I havn't looked at what was committed since I already did fix these problems in the mkIII patches floating around.. Anyhow its in there and the committer has to deal with it until/if I commit mkIII to -current, I'm out of the loop until then... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UPDATE2: ATA mkIII first official patches - please test!
Søren Schmidt wrote: http://people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3k.diff-current.gz http://people.freebsd.org/~sos/ata-mk3k.tar.gz New version available for testing: http://people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3l.diff-current.gz http://people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. Items in this release: o Fix ATA/ATAPI requests from userland. o Cleanup the attach/detach code further. o Add modules for atacard and atacbus o Fix the current/real geometry handling for CHS mode. o Add the ioctl interface back to ata-raid.c. o Update the ioctl API to match new RAID levels etc. o Add the infrastructure to allow create/delete/status of ATA RAID arrays. NOTE only Promise and FreeBSD Pseudo RAIDs supported at this time. o Update atacontrol to know about the new RAID levels etc NOTE: you need to recompile atacontrol with the new sys/ata.h, make world will take care of that. One warning applies to both this and the last snapshot. I accidentially released the RAID5 test code I had in there which allows to apparently use a RAID5 array. However it *ONLY* reads and writes the data part, it does *NOT* maintain the parity part. That means it will trash a RAID5 array for later real use as the parity wont match the data one there. Since the code is out there I've decided to let it stay, as it allows for testing of getting and using the metadata etc.. As usual use at your own risk, but feedback on this is very welcomed. Big thanks to all those that has participated so far! I'll be mostly AFK for the next two weeks on needed vacation, so dont panic if I dont respond as quickly as usual. Enjoy! -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Marcus Grando wrote: My problem persist... Any other patch? or idea? Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Marcus Grando wrote: My problem persist... Any other patch? or idea? Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... Just an observation, but my Promise ATA-100 controller will drive 1 UDMA-66 and one UDMA-100 disk fine at UDMA-33 with the cable on the wrong way round (oops) using the previous update. Well, the problem with wrong way around is that determining what the cable is fails in unpredictable ways, as long as your transfer rates are reduced there is no problems. However if a higher transferate is used than the cable is spec'd for you get ICRC errors as this was originally about. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Marcus Grando wrote: Hi Søren Schmidt wrote: Hmm, does it work without apic ? without ACPI ? And your cabling is correct and spec conformant ? The 686A' I have in the lab works just dandy... I test all combinations (with/without apic | with/without ACPI), and problems persist. OK. It will be that the problem is not with the compatibility of the controller with my HD? Have you tried other disks on this board ? Have you tried this disk on another board ? Is the disk in a drawer/enclosure of sorts ? I changed 3 times the cable. I don't think that cable is problem. Depends, you need proper 80 conductor cables no longer than 45cm's, the blue connector goes at the controller end, and the black/grey goes on the master/slave device. ICRC errors are because the checksum on the data does match, which means that the communication path between disk and controller is malfunctioning. The usual suspect is the cable, but it can also be bad or loose connectors, or a flaky/unstable PSU. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Marcus Grando wrote: I test another disk (SAMSUNG SV8004H) in secondary and work with UDMA66. OK, so the problem is not general of nature... Have you tried this disk on another board ? I have another computer with 4.11-STABLE / QUANTUM FIREBALLlct10 30 and occurs same problem. -- ad0s1g: UDMA ICRC error writing fsbn 29286847 of 4391104-4391263 (ad0s1 bn 29286847; cn 29054 tn 6 sn 37) retrying ad0s1g: UDMA ICRC error writing fsbn 37273791 of 8384576-8384607 (ad0s1 bn 37273791; cn 36977 tn 15 sn 30) retrying ad0s1g: UDMA ICRC error writing fsbn 93610575 of 36552968-36552971 (ad0s1 bn 93610575; cn 92867 tn 10 sn 9) retrying It will be that the problem is not with all FIREBALL QUANTUM? Because all my FIREBALL QUANTUM have this problem. Hmm, I newer thought much about the Fireball's but they should work as such, however there are other examples of those not getting along. Do they work if you run them at UDMA33 ? in that case leave them there.. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE2: ATA mkIII first official patches - please test!
Maxim Konovalov wrote: Hi, On Thu, 17 Feb 2005, 10:32+0100, S?ren Schmidt wrote: S?ren Schmidt wrote: http: //people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http: //people.freebsd.org/~sos/ata-mk3k.diff-current.gz http: //people.freebsd.org/~sos/ata-mk3k.tar.gz New version available for testing: http: //people.freebsd.org/~sos/ata-mk3l.diff-releng5.gz http: //people.freebsd.org/~sos/ata-mk3l.diff-current.gz http: //people.freebsd.org/~sos/ata-mk3l.tar.gz This time the diff must be reapplied as there are new changes in there. atadisk.ko and atapicd.ko still do not depend on atapci.ko. So if you don't ask to load atapci.ko in loader.conf you will get a panic because the kernel won't find the root fs. I added MODULE_DEPEND() on atapci macro to ata-disk.c and this solved the problem. Perhaps this is just a feature. Yes its a feature, if you make everything depend on each other there is no reason to have it as seperate modules... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
Takahashi Yoshihiro wrote: In article [EMAIL PROTECTED] Søren Schmidt [EMAIL PROTECTED] writes: 2. A geometry translation for pc98 is NOT enough. Currently, it works only under 4.3GB disk. Same a 1. No. See kern/61960. Wrong, ATA mk3 does solve the problem but using the current geomtry set in the drives by the BIOS. However the code missed it in one place in ata-lowlevel.c when the code was moved there from ata-disk.c. This has been fixed and will be present in the next snapshot as I sadi earlier. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
Takahashi Yoshihiro wrote: ATA-mkIII has three big problems. I'd call it minor issues on PC98 :) 1. It seems that CHS mode is broken. Only in the case of virtual geometry as used by PC98 only. The problem is that the the real not virtual geometry is used for the tranlation from LBA to CHS. 2. A geometry translation for pc98 is NOT enough. Currently, it works only under 4.3GB disk. Same a 1. 3. Modules for pc98 are broken. No, they are not done yet :) I've fixed the CHS issue locally its contained in the next snapshot... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
Emanuel Strobl wrote: Am Mittwoch, 9. Februar 2005 15:00 schrieb Søren Schmidt: [...] As always, enjoy and let me know how it goes... It's running here on several RELENG_5 machines. Like with j I also can't find any problems with k :) But the strange 16MB/s limit on my ICH2 (i815 B-step (tualatin)) machine still exists and still if I use the command atacontrol mode 0 udma5 udma5 the limit vanishes but only when typed interactively, no go by setting the udma5 mode (which is actualy already set at probing) in any rc script. Still reproducale but I have absolutely no idea how this can be :( Hmm, strange, anyhow I've managed to scavenge an ICH2 based board here, I just need to locate a CPU that fits then I'll look into this mess.. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPDATE: ATA mkIII first official patches - please test!
Tim Welch wrote: A problem still exists with 48-bit addressing. This url details a fix I've been using for the last 4 months or so with no issues yet. http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html Are you stil experiencing problems with atamkIII ? In that case its a different problem since atamkIII (as well as current) has this fixed.. -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
UPDATE: ATA mkIII first official patches - please test!
Søren Schmidt wrote: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz New version that fixes known problems so far etc now available: http://people.freebsd.org/~sos/ata-mk3k.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3k.diff-current.gz http://people.freebsd.org/~sos/ata-mk3k.tar.gz The diffs hasn't changed, so for those that has already applied those you can just untar the tarfile (still relative to /usr/src). Fixes include: o atapi-cd eject/close o SiI controllers lost some (slow) SATA disks in probe o panic when detaching disk not part of a RAID. o Cable detection failure on channels with both master and slave. As always, enjoy and let me know how it goes... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as built in nothing really changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. Does it work with stock ATA ? I cant work on suspend/resume as it has been broken due to ACPI brokenness since september last year on all my laptops... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Randy Bush wrote:
diff -u -r1.20 ata-all.c
--- ata-all.c 2005/02/03 17:02:31 1.20
+++ ata-all.c 2005/02/07 14:27:57
@@ -630,7 +630,7 @@
void
ata_udelay(int interval)
{
-if (1 || interval (100/hz) || ata_delayed_attach)
+if (interval (100/hz) || ata_delayed_attach)
DELAY(interval);
else
tsleep(interval, PRIBIO, ataslp, interval/(100/hz));
no fix
hangs in ad0: TIMEOUT - WRITE DMA retrying (2 retries left) LBA=7434015
disk light on solid. no response to anything
no idea
Since I cannot debug this, I have no way of finding out whats wrong.
I will look at it when ACPI allows me to use suspend/resume again, until
then I'll concentrated on things that I can work on...
--
-Søren
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: Since I cannot debug this, I have no way of finding out whats wrong. I will look at it when ACPI allows me to use suspend/resume again, until then I'll concentrated on things that I can work on... where's my refund? :-) more seriously, shall we do a fund to get you a laptoy on which acpi happens to work this week? Find such a machine might be very hard, if not plain impossible :/ I already have 3 laptops here (of which none has worked for several month regarding suspend/resume) so I have plenty. However getting laptops to those thats supposed to maintain ACPI might be an idea, but we should make certain that it would help first ;) -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Dag-Erling Smørgrav wrote: Søren Schmidt [EMAIL PROTECTED] writes: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz sys/dev/ata/ata-all.c rev 1.235 conflicts, could you please update the -CURRENT patch? There is no patch for ata-all.c there is a replacement. I will eventually get that updated (so you can run cvs diff ?)... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Hideyuki KURASHINA wrote: Hi, Søren I've tested your patches using same config file as before, and it seems work fine except on resume. Hmm, thats one corner I cant test, suspend/resume dies horribly in ACPI on all 3 notebooks I have since september last year or thereabouts... After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as built in nothing really changed... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Ben Stuyts wrote: On 3 Feb 2005, at 21:52, Søren Schmidt wrote: o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. Will RAID mirrors built using atacontrol on standard ata controllers still work? Specifically in my case on 5.3-stable: Not as is, but its easily added, uncomment line 597 in ata-raid.c and it will be picked up as before... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA mkIII first official patches - please test!
ATA-mkIII first official snapshot. This is the much rumoured ATA update that I've been working on for some time. It contains a number of new things, and lacks a few features of the old code. New items include: o ATA is now fully newbus'd and split into modules. This means that on a modern system you just load atapci and ata to get the base support, and then one or more of the device subdrivers atadisk atapicd atapifd atapist ataraid. All can be loaded/unloaded anytime, but for obvious reasons you dont want to unload atadisk when you have mounted filesystems. o The device identify part of the probe has been rewritten to fix the problems with odd devices the old had, and to try to remove so of the long delays some HW could provoke. o SATA devices can be hot inserted/removed and devices will be created/ removed in /dev accordingly. NOTE only supported on controllers that has this feature: Promise and Silicon Image for now. o ATA RAID support has been rewritten and and now supports these metadata formats: Adaptec HostRAID Highpoint V2 RocketRAID Highpoint V3 RocketRAID Intel MatrixRAID Integrated Technology Express LSILogic V2 MegaRAID LSILogic V3 MegaRAID Promise FastTrak Silicon Image Medley o The reinit code has been worked over to be much more robust. o The timeout code has been overhauled for races. o Lots of fixes for bugs found while doing the modulerization and reviewing the old code. Missing features form current ATA: o atapi-cd no longer has support for ATAPI changers. Todays its much cheaper and alot faster to copy those CD images to disk and serve them from there. Besides they dont seem to be made anymore, maybe for that exact reason. o ATA RAID can only read metadata not write them. This means that arrays can be picked up from the BIOS, but they cannot be created from FreeBSD. This is being worked on for the final release as is RAID5 support for Promise/Highpoing/SiI controllers. o The atapi-cam author has been informed and has had early access to this work but so far atapicam is not supported with these changes. However I do have my own atacam that puts both ATA and ATAPI devices under CAM, but its really just academic at this point. And then there all the things that I've happily forgotten about :) The snapshot is available as a patch for RELENG_5 and for CURRENT, and a common tarfile of the new ATA code. http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz Both patches and the tarfile is relative to /usr/src. You might want to remove the contents of sys/dev/ata/ before unpacking the tarfile. No changes are needed to your config file, unless you want ATA as modules. As usual, even if it works on all the HW I have here in the lab, thats by far not the same as it works on YOUR system. So use glowes and safety shoes and if it breaks I dont want the pieces, but would like to hear the nifty details on how exactly it got that way :) Enjoy! -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: READ_DMA timeouts caused by ALI southbridge (5.3-STABLE)
Pertti Kosunen wrote: My READ_DMA timeout problem with 160GB disk partitially solved. Asus A7A266 southbridge (ALi 1535D+) don't support DMA with LBA48. This is somehow worked around with Windows drivers, so is same possible in FreeBSD also? I guess their workaround is to use PIO mode to access the portions that need 48bit access. There is currently no provision in ATA for doing this on a quirk basis, but that could be added at some time. I'll stick it on my TODO list... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: drive failure during rebuild causes page fault
Doug White wrote: On Mon, 13 Dec 2004, Joe Rhett wrote: This is why I don't trust ATA RAID for fault tolerance -- it'll save your data, but the system will tank. Since the disk state is maintained by the OS and not abstracted by a separate processor, if a disk dies in a particularly bad way the system may not be able to cope. Yes, but SATA isn't limited by this problem. It does have a processor per disk. (this is all SATA, if I didn't make that clear) Actually on SATA its worse -- the disk just stops responding to everything and hangs. If you don't detect this condition then you go into an infinite wait. In any case, yes the ATA RAID code could use a massive robustness pass. So could the core ATA code. Patches accepted :) Actually I'm in the process of rewriting the ATA RAID code, so things are rolling, albeit slowly, time is a precious resource. I belive that it can be made pretty robust, but the rest of the kernel still have issues with disappearing devices etc thats out of ATA's realm. Anyhow. I can only test with the HW I have here in the lab, which by far covers all possible permutations, so testing etc by the community is very much needed here to get things sorted out... -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW
Peter Radcliffe wrote: Sren Schmidt [EMAIL PROTECTED] probably said: Well, you probably should take care of your sister first :) And no I dont have a paypal account, so far I've got by fine without it, by using other means as checks, wiretransfers etc etc... Do you have a list of things (particular devices or general categories) that would be useful for your work and an address ? :) Currently the most wanted list includes: SATA disks that supports NCQ and preferably also need 48bit addressing that is are bigger than 137G. Maxtors newest diamondmax 10 are a good bet here. SATA enclosures for hotswap support, Promise SuperSwap 4100 is a useable candidate as I can get docs on those. SATA ATAPI devices, CD/DVD drives/burners. Further down the line Port Multipliers etc, but we are not there yet.. The address I can give you in private mail if it gets that far -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW
Rob wrote: Hi guys, This is the first post I have seen on stable about SATA. (ok, maybe I'm not subscribed to the right lists) Anyway I bought a brand new beautiful Plextor DVD+RW SATA drive (PX712SA) for use on my AMD64+3800 machine. Win XP64-beta won't recognize it, and neither will FreeBSD 5.3-RELEASE, AMD64. I am wondering what I am doing wrong? If you are willing to help just email me and I can send dmesg and/or kernel config file to you and keep it off the list. I am using the socket 939 chip on an Abit AV8 mobo. Only one of the two SATA channels is used. I have two SCSI 160 drives, one for Windoze and one for FBSD. So the only thing normal IDE is used for is the floppy drive. SATA ATAPI devices are not supported yet. There are a few gotcha's though. Not all SATA controllers does support SATA ATAPI even if out driver would, so its a mixed blessing for now. Anyhow, as soon as I can get my hands on a SATA ATAPI device, be certain that I'll get support in there, for those controllers that support it that is. However SATA ATAPI devices are still extremely rare, at least in this part of the woods... -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW
Peter Radcliffe wrote: Sren Schmidt [EMAIL PROTECTED] probably said: SATA ATAPI devices are not supported yet. There are a few gotcha's though. Not all SATA controllers does support SATA ATAPI even if out driver would, so its a mixed blessing for now. Anyhow, as soon as I can get my hands on a SATA ATAPI device, be certain that I'll get support in there If it's something you'd like to work on I'd happily put some money towards sending a drive in your direction... I'm going to work on it soon thats for sure, however I have lots on the burner currently so its no rush. However all kinds of (S)ATA/ATAPI gear is always most welcome here in the lab, the levels of support I can provide is directly proportional to the amount of HW I have access to :) -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]/ SATA DVD+RW
Garance A Drosihn wrote: At 9:49 PM +0100 12/9/04, Søren Schmidt wrote: I'm going to work on it soon thats for sure, however I have lots on the burner currently so its no rush. However all kinds of (S)ATA/ATAPI gear is always most welcome here in the lab, the levels of support I can provide is directly proportional to the amount of HW I have access to :) I am not great at mailing things. My sister is still waiting for me to mail her christmas presents for *last* year... Do you have a paypal account? I could send some money that way, and then you could get whatever devices seem the most important to the work you have been doing. That way you might get something from me before SATA becomes obsolete... Well, you probably should take care of your sister first :) And no I dont have a paypal account, so far I've got by fine without it, by using other means as checks, wiretransfers etc etc... -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DMA errors with SATA on 5.x [one fix]
Garance A Drosihn wrote: At 1:01 AM -0600 12/7/04, Tim Welch wrote: I'm getting NID not found/DMA errors on 5-STABLE with a Seagate 200gb sata drive: ad2: FAILURE - WRITE_DMA status=51READY,DSC,ERROR error=10NID_NOT_FOUND LBA=268435455 This appears to be a result of 48-bit addressing. Any time a write is attempted to the sector above, I get multiple messages like this. It continues until I shut down. After a bit of googling I found this post: http://lists.freebsd.org/pipermail/freebsd-hackers/2004-October/008821.html and applied the change suggested. It seems to have fixed the problem, and I've had no troubles from this since Nov. 18th when I applied that patch. I'm running an Intel 875PBZ board with the ich5 controller. The drive in question is a Seagate ST3200822AS/3.01 (as reported by dmesg). So the question is, will this patch be committed anytime soon? That looks like a pretty safe patch to make. The message says he just reduced the 48-bit trigger level by one: Yes, I suggested that way back on the lists, and it seems to help those that had this problem. I have had it for quite some time in ATA-mkIII here as well, and since it has no real impact otherwise I've committed it to -current... -- -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA observations in FreeBSD 4.6-RC
It seems Eugene Grosbein wrote:
[ Charset KOI8-R unsupported, converting... ]
S?ren Schmidt wrote:
Of cause it should, and belive me I'm doing all I can to try get this
nailed. But I do have a real life as well, and a fulltime job, 3 kids,
vife and lots of other important things to care for, so excuse me if
I dont work 24 hours a day on this problem...
Of course. How about backing out new ATA code and stick with old
for the sake of 4.6-RELEASE stability?
Yeah, right, thats to prove that progress comes hard or what ?
Anyhow, could those haivng this problem try this patch:
Index: ata-disk.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v
retrieving revision 1.60.2.22
diff -u -r1.60.2.22 ata-disk.c
--- ata-disk.c 11 Apr 2002 08:45:32 - 1.60.2.22
+++ ata-disk.c 21 May 2002 15:51:52 -
@@ -707,17 +707,17 @@
int device = adp-device-unit;
if (adp-device-unit == ATA_MASTER) {
- if (adp-device-channel-devices ATA_ATA_SLAVE
- ((struct ad_softc *)
-(adp-device-channel-
- device[ATA_DEV(ATA_SLAVE)].driver))-flagsAD_F_TAG_ENABLED)
+ if ((adp-device-channel-devices ATA_ATA_SLAVE)
+ (adp-device-channel-device[SLAVE].driver)
+ ((struct ad_softc *) (adp-device-channel-
+device[SLAVE].driver))-flags AD_F_TAG_ENABLED)
device = ATA_SLAVE;
}
else {
- if (adp-device-channel-devices ATA_ATA_MASTER
- ((struct ad_softc *)
-(adp-device-channel-
- device[ATA_DEV(ATA_MASTER)].driver))-flagsAD_F_TAG_ENABLED)
+ if ((adp-device-channel-devices ATA_ATA_MASTER)
+ (adp-device-channel-device[MASTER].driver)
+ ((struct ad_softc *) (adp-device-channel-
+device[MASTER].driver))-flags AD_F_TAG_ENABLED)
device = ATA_MASTER;
}
if (device != adp-device-unit
-Søren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: ata(4) -STABLE subsystem and tags MFC
It seems Dmitry Morozovsky wrote: Hello there Soren, any chances patch for ata subsystem at date: 2002/04/18 19:11:45; that fixes tagged support for ata(4) will be MFC'd before 4.6-R? If you mean the patch that went into -current it doesn't apply to the -stable branch at all, it fixed a problem introduced by the busdma integration, not the problem that apparently hit some on -stable. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ata(4) -STABLE subsystem and tags MFC
It seems Dmitry Morozovsky wrote: SS If you mean the patch that went into -current it doesn't apply to SS the -stable branch at all, it fixed a problem introduced by the SS busdma integration, not the problem that apparently hit some on -stable. Well then it's another problem in -stable, and currently tagged ata is not workable in all our -stable environments with IBM disks :( Machines do not crash, but constantly reinitialising ATA subsystem just at trying to boot first FS at tagged disk. What info do you need so we can try to fix this? I need to be able to reproduce it here in my lab, and so far I havn't had any luck with that. There also doesn't seem to be any easy to find denominator between the systems that fail... The problem is probably timing related, perhaps I have gotten something a wee bit out of spec, but not enough for all systems to fail... Anyhow this is a bitch to debug -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: steps to rebuild a dead RAID1 array ?
It seems Mike Tancsa wrote: Yet, when I go to do a rebuild, raidtest3# atacontrol rebuild ar0 atacontrol: ioctl(ATARAIDREBUILD): Operation not supported by device raidtest3# I guess there needs to be some way to tell the controller to use ad6 as part of the rebuild no ? You need to do a atacontrol detach on the failed device, then an atacontrol attach on the new disk. BTW you dont need to boot inbetween :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: steps to rebuild a dead RAID1 array ?
It seems Mike Tancsa wrote: I guess there needs to be some way to tell the controller to use ad6 as part of the rebuild no ? You need to do a atacontrol detach on the failed device, then an atacontrol attach on the new disk. BTW you dont need to boot inbetween :) atacontrol: ioctl(ATARAIDREBUILD): Operation not supported by device raidtest3# raidtest3# atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 status: DEGRADED raidtest3# Also, I dont have a hot swappable case. These are just plain old drives. Ahh, oh, I see, yes thats the problem, you loose the SPARE attribute because of that... Hmm, we need a way to handle that... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvs commit: src/sbin/atacontrol atacontrol.8 atacontrol.c
It seems Mike Tancsa wrote: At 08:58 AM 4/2/02 +0200, Søren Schmidt wrote: If a disk in a RAID1 goes bad, the driver will continue to use the good half of the mirror, and log the fact that the mirror is now in degraded mode. You can then use atacontrol to detach the disk, add a new one, and use atacontrol to rebuild the array, all without having to take down the machine. If the last good disk fail, the driver will log that the array is broken, and return error on all accesses... And yes I'll add a get status/mode command :) Awesome! I just tried it on our test machine. raidtest2# atacontrol status ar0 ar0: ATA RAID1 subdisks: ad8 ad10 status: READY raidtest2# Also, I updated a few other boxes that have atapci0: VIA 82C686 ATA100 controller port 0xe000-0xe00f at device 7.1 on pci0 and so far so good! Also, what would you recommend for hot swapable trays ? The promise superswap enclosures, they are a bit pricy, but I support setting the LED color on the front for show the disk status, and you get get the fan speed/disk temperature/disk voltages form the superswap with atacontrol, very handy for servers :)... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: stable breaks HighPoint support
It seems Mike Tancsa wrote: It looks like something in stable seem to break High Point 404 support using the vendor's drivers and RAID administrator software. http://www.highpoint-tech.com/rr404_down.htm Highpoint's driver are for FreeBSD-4.5. They wont work with -stable and what is to become 4.6. The bright side is you wont even need them :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ATA still crashes on resume from suspend
It seems Kevin Oberman wrote: I saw that new versions of several ATA programs including ata-all.c had been loaded into stable. I hoped that this would fix the trap 12 when resuming from a suspend. No luck. Ian Dowses patches worked fine, but the code in stable still crashes. The fixes that I committed yesterday was for the vmware problems, the resume problem i not resolved yet. The patch floating around with using ATA_IMMEDIATE insted of ATA_WAIT_INTR might be the right solution, but I've not gotten so far yet... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
