Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
Arno J. Klaassen wrote: Hello, Alexander Sabourenkov [EMAIL PROTECTED] writes: Hello. I have ported the workaround for the hardware bug that causes data corruption on Promise SATA300 TX4 cards to RELENG_7. Bug description: SATA300 TX4 hardware chokes if last PRD entry (in a dma transfer) is larger than 164 bytes. This was found while analysing vendor-supplied linux driver. Workaround: Split trailing PRD entry if it's larger that 164 bytes. Two supplied patches do fix problem on my machine. definitely an improvement, but not sufficient (for my setup ) : amd64-releng_6 on an ASUS A8V UP (box ran rock-stable for years i386-releng_5 with same hardware apart TX4 and drives) from dmesg : atapci0: Promise PDC40718 SATA300 controller port 0xe000-0xe07f,0xd800-0xd8ff mem 0xfbb0-0xfbb00fff,0xfba0-0xfba1 irq 18 at device 13.0 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 ata4: ATA channel 2 on atapci0 ata5: ATA channel 3 on atapci0 atapci1: VIA 6420 SATA150 controller port 0xd400-0xd407,0xd000-0xd003,0xc800-0xc807,0xc400-0xc403,0xc000-0xc00f,0xb800-0xb8ff irq 20 at device 15.0 on pci0 ata6: ATA channel 0 on atapci1 ata7: ATA channel 1 on atapci1 atapci2: VIA 8237 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: ATA channel 0 on atapci2 ata1: ATA channel 1 on atapci2 [ ... ] ad0: 38166MB Seagate ST3402111A 3.AAJ at ata0-master UDMA100 ad6: 476940MB WDC WD5000AAKS-00TMA0 12.01C01 at ata3-master SATA300 ad12: 305245MB WDC WD3200JD-22KLB0 08.05J08 at ata6-master SATA150 booting from ad0 and simple gconcat over ad6 and ad12. Improvement : I now can fsck /dev/concat/data without ad6 being detached Persistent problem : when I rsync an nfs-mounted disk to /dev/concat/data, I get after about some Gigs of data have been transfered : Nov 2 16:39:55 charlotte kernel: ad6: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA=268435392 Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA retrying (0 retries left) LBA=268435392 Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA status=ffBUSY,READY,DMA_READY,DSC,DRQ,CORRECTABLE,INDEX,ERROR error=ffICRC,UNCORRECTABLE,MEDIA_CHANGED,NID_NOT_FOUND,MEDIA_CHANGE_REQEST,ABORTED,NO_MEDIA,ILLEGAL_LENGTH LBA=268435392 Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset=137438920704, length=131072)]error = 5 Nov 2 16:40:50 charlotte kernel: ad6: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=268435648 Nov 2 16:40:50 charlotte kernel: ad6: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=268435648 Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: WARNING - SET_MULTI taskqueue timeout - completing request directly Nov 2 16:40:50 charlotte kernel: ad6: FAILURE - WRITE_DMA48 timed out LBA=268435648 Nov 2 16:40:50 charlotte kernel: g_vfs_done():concat/data[WRITE(offset=137439051776, length=131072)]error = 5 ... I will test again with #define PDC_MAXLASTSGSIZE 32*4 (just to see if that makes a difference) Regards, Arno Just a guess here, I bet that patch helped, but there are compound problems reguarding SATA on amd64 in 7.x Do a quick search for [sata] (especially g_vfs_done) in the PR database. Hopefully this removed a layer of bugs so the other ones are easyer to fix. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timers and semtimedop(2)
On Thu, Nov 01, 2007 at 01:41:10PM -0400, Michael B Allen wrote: I need semtimedop(2). I'm thinking I can just do a semop with a SIGINT maybe. I presume you mean SIGALRM. Can someone suggest a good method for setting up a timer to deliver the signal? What sort of timers does FreeBSD offer? Assuming you aren't planning on creating a new syscall: man setitimer There's also kqueue EVFILT_TIMER but that is probably only useful if you are already using kqueue for other purposes. -- Peter pgpPCQ0lTKlfr.pgp Description: PGP signature
pkg_add doesn't keep dependent pkgs
Hi, pkg_add -rK seems not to keep the packages dependencies so as the package itself. i found this: http://lists.freebsd.org/pipermail/freebsd-bugbusters/2006-August/000178.html but no answer since then. I don't if this is a bug, or not even implemented feature? Thanks alot -- System Programmer -- I'm Searching For Perfection, So Even If U Need Portability U've To Use Assembly ;-) -- http://libosdk.berlios.de ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: WOL not working with 3Com NIC
On Fri, Nov 02, 2007 at 09:16:59PM -0500, M E wrote: Hello Stefan, Hello, I'm Cc'ing hackers@ in my reply to your mail so people can overhear this conversation. It would be great to get some help. I am able to get will wake on: magic, when typing ifconfig in FreeNAS (built on FreeBSD); however, I am still unable to wake up the box. I know that xl does not work yet. The driver hears you requesting WOL and internally makes a note to configure WOL at shutdown time. But configuring the device for WOL does not work correctly for some reason. I haven't yet figured out what exactly the problem is, even with looking at the specs. The NIC is a 3Com EtherLink XL 10/100 PCI For Complete PC Management NIC (3C905C-TX). I've found 3 spare ones of those at uni I could bring home to test with. There have been requests for fxp (Intel) support, too, and by accident I also found one of those cards at uni in a spare server no one was using. But the hard disk in my development box is dying, I have to get it replaced. And my desktop got a new motherboard a while ago. The old one had bad capacitors, it was totally unstable so I returned it. I only later realised that the new one has no WOL connector! Doh! So now I finally have some cards, but no hardware to use them with. It used to be the other way around for like a year or more. Meh :-/ I need to find some time to buy a disk and set up my dev box again before I can continue working on this. Do you have any sugestions? My free time is scarce at the moment. More eyes and brains to throw at the problem would really, really help. There are data sheets for 3com cards at http://people.freebsd.org/~wpaul/3Com/ If someone found something obviously wrong in the xl_enable_wol() routine it would help an awful lot. I already went over it twice but I cannot find the error. It could also be something else the driver is doing behind my back that prevents WOL from working. I'm not experienced enough in device drivers to really understand all the subtleties of the whole thing. For those who don't know, the WOL patch is here: http://stsp.name/wol/ -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpOKC0DxOzZr.pgp Description: PGP signature
Re: Patch RFC: Promise SATA300 TX4 hardware bug workaround.
Arno J. Klaassen wrote: Rather than the marginal HW part, it seems, for me, closely related to MB/BIOS (as well (Alexander apperently has about the same setup as I have for this test)): [...] I vaguely remember from another PR that the Promise card does something with PCI-bursting which fbsd does not detect and/or handle correctly (and beyond my simple skills as dumb tester, but maybe the linux-sources contain a clue about that as well). Analysis of chip initialization in vendor-supplied, Linux and FreeBSD drivers shows that FreeBSD's one: - does not enable something called 'BMR_BURST', - performs hotplug init in one write (instead of two read-modify-writes ), - does an extra write (offset 0x54) which is not done in other drivers. Analysis text: http://lxnt.info/tx4/chipinit.text Patch with ported chipinit (dangerous to use with anything from Promise other than sata300 tx4 !!): http://lxnt.info/tx4/freebsd/chipinit.patch (cumulative) http://lxnt.info/tx4/freebsd/ata-chipset.c+chipinit (patched source) Note two things: 1. I have not compiled or tested this patch. Please do. 2. I may have missed this bug because I'm frequently rebooting between Linux and FreeBSD, and what Linux driver initialized may have lasted the reboots. -- ./lxnt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
timezone printing in date messed up?
$ sh 'EOF' for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -j -f %s `expr 1194163200 + 600 \* $a` done EOF Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PST 2007 --- Sun Nov 4 01:40:00 PST 2007 --- Sun Nov 4 01:50:00 PST 2007 --- Sun Nov 4 01:00:00 PDT 2007 --- Sun Nov 4 01:10:00 PDT 2007 --- Sun Nov 4 01:20:00 PDT 2007 --- Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 02:00:00 PST 2007 $ Look at the lines with ---! This is with the latest timezone files. OS X Leopard has the same bug. I assume this is a bug and not due to an act of congress that mandates a flip flop timezone? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timezone printing in date messed up?
$ sh 'EOF' for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -j -f %s `expr 1194163200 + 600 \* $a` done EOF snip buggy output OS X Leopard has the same bug ... How did you test it in Leopard? I tried it in Tiger, intending to contribute another data point, and I got: date: illegal option -- j usage: date [-nu] [-r seconds] [+format] date [cc]yy]mm]dd]hh]mm[.ss] The Tiger manpage gives no obvious equivalent to FreeBSD's -j ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timezone printing in date messed up?
OS X Leopard has the same bug ... How did you test it in Leopard? I tried it in Tiger, intending to contribute another data point, and I got: Leopard's /bin/date accepts -j. You can try compiling FreeBSD date on Tiger. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: timezone printing in date messed up?
OS X Leopard has the same bug ... How did you test it in Leopard? I tried it in Tiger, intending to contribute another data point, and I got: Leopard's /bin/date accepts -j. You can try compiling FreeBSD date on Tiger. I had decided against that, since it would propagate the bug if it happened to be in the FreeBSD /bin/date. It turns out the output conversion can be tested using -r: for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -r `expr 1194163200 + 600 \* $a` done and this gives correct results in both Tiger and 6.1: Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PDT 2007 Sun Nov 4 01:40:00 PDT 2007 Sun Nov 4 01:50:00 PDT 2007 Sun Nov 4 01:00:00 PST 2007 Sun Nov 4 01:10:00 PST 2007 Sun Nov 4 01:20:00 PST 2007 Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 02:00:00 PST 2007 but the original command, run in 6.1, exhibits the bug: for a in 0 1 2 3 4 5 6 7 8 9 10 11 12 do date -j -f %s `expr 1194163200 + 600 \* $a` done Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 01:00:00 PDT 2007 Sun Nov 4 01:10:00 PDT 2007 Sun Nov 4 01:20:00 PDT 2007 Sun Nov 4 01:30:00 PST 2007 Sun Nov 4 01:40:00 PST 2007 Sun Nov 4 01:50:00 PST 2007 Sun Nov 4 02:00:00 PST 2007 Maybe this helps someone familiar with the internals of /bin/date fix it in time for next fall :) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
