Re: 6.2-RC1 em(4) issue - freezes during CD boot
On 12/13/06, Chris Buechler <[EMAIL PROTECTED]> wrote: Jack Vogel wrote: > I need the PCI ID of that NIC, just to be sure that I can't reproduce > this, but > I doubt it, pciconf -l Here's the pciconf -l from 6.2-RC1, custom kernel (copy of GENERIC, minus 'device em') [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x700d1022 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x74401022 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x03 card=0x chip=0x47581002 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:10:0: class=0x0e0001 card=0xc0661044 chip=0xa5011044 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:10:1:class=0x060400 card=0x0068 chip=0xa5001044 rev=0x01 hdr=0x01 [EMAIL PROTECTED]:16:0:class=0x060400 card=0x chip=0x74481022 rev=0x05 hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x chip=0x74491022 rev=0x07 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x246610f1 chip=0x920010b7 rev=0x78 hdr=0x00 > interesting question is what will happen when you load > the em driver afterwords :) Indeed, I was expecting Bad Things to happen. But no, after the kldload, the interface was detected, I put an IP on it and it's working fine. I bound an iperf server to that interface and ran an iperf client from a slower box with a gig card and got ~520 Mbps out of it (probably limited by the slower client box). So it seems to be working fine as long as it's not compiled into the kernel. Granted I haven't done any really extensive testing or use of it. Here's the pciconf -l after loading the em driver. [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x700d1022 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x74401022 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x03 card=0x chip=0x47581002 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:10:0: class=0x0e0001 card=0xc0661044 chip=0xa5011044 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:10:1:class=0x060400 card=0x0068 chip=0xa5001044 rev=0x01 hdr=0x01 [EMAIL PROTECTED]:16:0:class=0x060400 card=0x chip=0x74481022 rev=0x05 hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x chip=0x74491022 rev=0x07 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x246610f1 chip=0x920010b7 rev=0x78 hdr=0x00 This is quite odd, and as a matter of fact, because our test group is always testing drivers that are made here at Intel, I believe most often they have the driver as a module and not static... hmmm, so let me see if I have any luck reproducing it. Since its often the case that a kernel you rebuild is NOT the same as the one install ends you with it might be a good test to go ahead, redefine em back into the kernel and see if THAT new kernel hangs. Just be SURE and keep this other kernel available to boot up again :) I"ll look into this, but not right away, I have a high priority chunk of code I'm working on and that needs to get done in the next couple days, and then I'm having a couple long-needed weeks of vacation :) Happy Holidays, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Mounting smbfs as non-root
On Wed, 13 Dec 2006 20:11:46 +1100 Peter Jeremy <[EMAIL PROTECTED]> wrote: > mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): syserr = > Operation not permitted As far as I can tell, this has been the case since 4- or so, at least. Possibly as long as mount_smbfs has existed. The work-around that I used was to configure amd to do the mount (as root) on behalf of the user in question (me, at that time). These days I use smbclient or GNOMEVFS/nautilus instead, but they achieve somewhat different things... Cheers, -- Andrew ___ 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-RC1 em(4) issue - freezes during CD boot
Jack Vogel wrote: I need the PCI ID of that NIC, just to be sure that I can't reproduce this, but I doubt it, pciconf -l Here's the pciconf -l from 6.2-RC1, custom kernel (copy of GENERIC, minus 'device em') [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x700d1022 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x74401022 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x03 card=0x chip=0x47581002 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:10:0: class=0x0e0001 card=0xc0661044 chip=0xa5011044 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:10:1:class=0x060400 card=0x0068 chip=0xa5001044 rev=0x01 hdr=0x01 [EMAIL PROTECTED]:16:0:class=0x060400 card=0x chip=0x74481022 rev=0x05 hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x chip=0x74491022 rev=0x07 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x246610f1 chip=0x920010b7 rev=0x78 hdr=0x00 interesting question is what will happen when you load the em driver afterwords :) Indeed, I was expecting Bad Things to happen. But no, after the kldload, the interface was detected, I put an IP on it and it's working fine. I bound an iperf server to that interface and ran an iperf client from a slower box with a gig card and got ~520 Mbps out of it (probably limited by the slower client box). So it seems to be working fine as long as it's not compiled into the kernel. Granted I haven't done any really extensive testing or use of it. Here's the pciconf -l after loading the em driver. [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 [EMAIL PROTECTED]:1:0: class=0x060400 card=0x chip=0x700d1022 rev=0x00 hdr=0x01 [EMAIL PROTECTED]:7:0: class=0x060100 card=0x chip=0x74401022 rev=0x05 hdr=0x00 [EMAIL PROTECTED]:7:1: class=0x01018a card=0x74411022 chip=0x74411022 rev=0x04 hdr=0x00 [EMAIL PROTECTED]:7:3: class=0x068000 card=0x74431022 chip=0x74431022 rev=0x03 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x03 card=0x chip=0x47581002 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:9:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 [EMAIL PROTECTED]:10:0: class=0x0e0001 card=0xc0661044 chip=0xa5011044 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:10:1:class=0x060400 card=0x0068 chip=0xa5001044 rev=0x01 hdr=0x01 [EMAIL PROTECTED]:16:0:class=0x060400 card=0x chip=0x74481022 rev=0x05 hdr=0x01 [EMAIL PROTECTED]:0:0: class=0x0c0310 card=0x chip=0x74491022 rev=0x07 hdr=0x00 [EMAIL PROTECTED]:8:0: class=0x02 card=0x246610f1 chip=0x920010b7 rev=0x78 hdr=0x00 Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sshfs/nfs cause server lockup
On Thu, Dec 14, 2006 at 01:28:48AM +, Chris wrote: > It does make sense if thats the problem since the entire server even > locally stops working properly, and it always follows a unexpected > nfs/sshfs disconnection ie. network timeout. > > I am now running 6.2-RC that has the new file and currently at 1 day > 11hrs uptime. OK, thanks for following part of the advice I gave a month ago ;) Let us know if the problems persist. Kris pgp9zvea2CRuD.pgp Description: PGP signature
Re: sshfs/nfs cause server lockup
On 07/12/06, Anish Mistry <[EMAIL PROTECTED]> wrote: On Thursday 07 December 2006 13:36, Chris wrote: > On 23/11/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > > On Thu, Nov 23, 2006 at 04:38:48PM +0100, [EMAIL PROTECTED] wrote: > > > Chris <[EMAIL PROTECTED]> wrote: > > > >kris a development on this, someone else posted about a nfs > > > > problem and reading his post some starkling point he made > > > > about network cards, he stated he only gets the bug on sis rl > > > > and fxp. > > > > > > Sorry for the misunderstanding, but I think that the 'NFS via > > > TCP' thread covers other bugs, ie the inability to mount NFS v3 > > > over TCP. > > > > > > I've tested the cards above, and the person I replied to > > > encountered the same bug with a bge card. My solution was to > > > remove custom nfs settings in sysctl.conf. I don't know which > > > one was the culprit because I don't have the time to look into > > > it further. > > > > > > My poking uncovered a set of crashing bugs and potentially a > > > livelock. I would agree that NFS is very fragile in RELENG_6. > > > So far I've not run into an NFS server > > > deadlock you described. > > > > Are you sure these are NFS problems and not ethernet driver > > problems? > > > > Kris > > Had another lockup today, reattached to screen process to see both > sshfs mounts timed out when running sshfs to remount the terminal > stopped updating, it didnt disconnect me and an ircd running on the > server remained functional and the server responded to pings, > however the terminal was dead and I couldnt login on ssh for a new > session, a ctrl-alt-del also failed to reboot it and it needed a > power cycle again. > > I have googled researched and read dozens and dozens of nfs bug > reports where most of them seem to be a problem caused by nfs not > disconnecting properly leaving itself in a bad state, the fix is > usually to reboot. I am having to reboot weekly more often then my > windows desktop pc, everyone else having no problems with the nfs > on their linux servers having no problems and its hardly inspiring > that the stable freebsd is not stable. All these problems on > google didnt get fixed no dev attention etc. > > So far I have not got my local bsd box up and running yet due to no > keyboard still need parts for it. I've updated the sshfs and libs port, you may want to update and see if that helps. -- Anish Mistry Hi yes my sshfs and the libs got updated but didnt fix the crash however I did find this link. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1362611+0+archive/2006/freebsd-stable/20060702.freebsd-stable It does make sense if thats the problem since the entire server even locally stops working properly, and it always follows a unexpected nfs/sshfs disconnection ie. network timeout. I am now running 6.2-RC that has the new file and currently at 1 day 11hrs uptime. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Missing pkg-descr
On Wed, 2006-12-13 at 12:27 -0600, Wayne M. Barnes wrote: > Dear FreeBSD, > > Did something happen to the location for the "pkg-descr" so > that ports can't find it? The following happens to me a lot, > for many packages: > > ===> Installing for gmake-3.81_1 > ===> Generating temporary packing list > ** Missing pkg-descr for gmake-3.81_1. > *** Error code 1 > > Stop in /usr/ports/devel/gmake. > *** Error code 1 > > Stop in /usr/ports/x11-toolkits/open-motif. > *** Error code 1 > > A workaround is to add this package with pkg_add -rv, but this > is tiresome, since I must do it many times to finish a complicated > port (this time the port is java/jdk15). > > This happened on a new install of > FreeBSD poweredge.etaq.com 6.2-RC1 FreeBSD 6.2-RC1 #0: Thu Nov 16 05:12:08 > UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 > %ll /usr/ports/devel/gmake/pkg-descr -rw-r--r-- 1 root wheel 215 May 18 2000 /usr/ports/devel/gmake/pkg-descr If the file doesn't exist, is there anything unusual re the maintenance of the ports tree on that system? Perhaps old files were pruned, etc.? Refreshing the ports tree ought to fix it. Wayne P.S. This probably ought to have gone to ports@ or [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: pf killing NFS
> I pulled the "scrub in all" line and replaced it with a "scrub in on > bge0". I don't really care about scrubbing on the internal network. All > works as expected now. I dont really care about scrubbing my intrenal nbetwork either - but I do care about NAT working on the outside, which requires fragment reassembly before the packets go out - hence I scrub to reassemble any fragmented packets comming into the machine. I dont know if this is actually necessary or not, but I thought it best to be on the safe side! -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adaptec 2100, asr driver
Charles Sprickman wrote: On Wed, 13 Dec 2006, Jim Pingle wrote: Willem Jan Withagen wrote: So the 1000$ question: is there any chance of getting at least the state of the RAID and its disk out into the open? It shure would give me a much better feeling, knowing that at least serious trouble would be detected by me. Instead of getting this call from a NOC. It works fine here. I use this on systems with 2100s, and with 2010s. cd /usr/ports/sysutils/asr-utils; make install clean Make sure it installs compat4x, it should as it is listed as a dependency. Add this to /etc/rc.conf: compat4x_enable="YES" add "options ASR_COMPAT" to your kernel and rebuild the kernel I have quite a few machines with the Adaptec cards, and while I hate them and the management tools, I don't have much choice but to use them until we retire the hardware. Does anyone have any info on whether adaptec is planning on updating these tools to work with FreeBSD 6+? Or have they basically abandoned support for FreeBSD? Knowing that info would help me plan our 4.11 to 6.x migration. Well what I hated about it, is that I could not monitor the state of the individual disks. But Jim's remarks proved me wrong. There's probably enough stuff in the driver to not run it on amd64, but in my case it is a legacy system, not old enough to toss. I too came from 4.x on this system, not really careing for the tools while at 5.x. But once it started to beep we needed some action. I see very few obstacles to go for it. --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adaptec 2100, asr driver
Charles Sprickman wrote: On Wed, 13 Dec 2006, Jim Pingle wrote: Willem Jan Withagen wrote: So the 1000$ question: is there any chance of getting at least the state of the RAID and its disk out into the open? It shure would give me a much better feeling, knowing that at least serious trouble would be detected by me. Instead of getting this call from a NOC. It works fine here. I use this on systems with 2100s, and with 2010s. cd /usr/ports/sysutils/asr-utils; make install clean Make sure it installs compat4x, it should as it is listed as a dependency. Add this to /etc/rc.conf: compat4x_enable="YES" add "options ASR_COMPAT" to your kernel and rebuild the kernel I have quite a few machines with the Adaptec cards, and while I hate them and the management tools, I don't have much choice but to use them until we retire the hardware. Does anyone have any info on whether adaptec is planning on updating these tools to work with FreeBSD 6+? Or have they basically abandoned support for FreeBSD? Knowing that info would help me plan our 4.11 to 6.x migration. Thanks, Charles Adaptec abandoned work on asr for FreeBSD about 5 years ago, and abandoned all development on ASR cards and tools on all OSes about 4 years ago, with the exception of maintenance commitments for certain customers. They wrote the ASR technology assets off of their books at that time, making it a firm, deliberate, and permanent business decision. On the plus side, wheels are in motion to develop native, updated management tools for FreeBSD for the cards that are serviced by the AAC driver. First in line is a simple status app. If you are interested in more complex apps, please contact me privately. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ath_hal
Why do recent kernels display the banner: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) on boot when ath hardware is not present? I'd rather have my dmesgs not mention phantom hardware, especially in the GENERIC kernels. signature.asc Description: OpenPGP digital signature
Re: pf killing NFS
On Wed, 13 Dec 2006, Pete French wrote: I'm running a 6.2-RC1 box (cvsup'd today) that has two broadcom nics. One is an internal network (nfs) and the other is external. ... Doing something like "ls /usr/ports" will just hang until interrupted. Using tcp for nfs makes it workable, but very slow. Oddly enough I hit precisely this problem last night - with a cvsup from a few days ago. I have tried adding the 'no-df' flag to the scrub rules, but this did not help much. What I ended up doing was this: I pulled the "scrub in all" line and replaced it with a "scrub in on bge0". I don't really care about scrubbing on the internal network. All works as expected now. Glad to have the bad checksum error explained, that had me thinking I'd be visiting the co-lo to track down a flakey cable. :) Charles scrub in on bge0 proto tcp fragment reassemble random-id so that I am not scrubbing UDP traffic. this works fine. -pete. ___ 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-RC1 em(4) issue - freezes during CD boot
On 12/12/06, Chris Buechler <[EMAIL PROTECTED]> wrote: Jack Vogel wrote: > UH, can't do anything if you don't give any information, saying its a > 'box' > and it has an 'em' is useless. We have installed RC1 on a number of > systems without problem. Yes, I understand that. I was after what info would be useful. You gave me a few ideas, thanks. As for ACPI, the boot menu option recently changed to "enable ACPI", so I'm assuming it must be disabled by default now. I tried with ACPI on 6.2-RC1 and got the same result. I was able to narrow this down to something that has changed since 6.2-BETA3. The BETA3 CD boots, installs, and works fine. The RC1 CD won't boot, as I described in my first message. With the em card taken out, the 6.2-RC1 CD boots and installs just fine, so it's definitely the em card. Hardware: Dual AMD Athlon MP 2800+, Tyan Tiger MPX motherboard, 2 GB reg ECC RAM, Adaptec 2110S PCI-X SCSI RAID, onboard xl(4) NIC, Intel PRO/1000 MT PCI desktop adapter (ugh, I know it's not well suited for the box, but this is a personal server and a cheap card that's adequate for my needs). Drives: 3 x 18 GB SCSI in RAID 5, 1 x 73 GB SCSI on RAID controller but a stand alone drive, and a 500 GB IDE drive on the onboard IDE controller. I need the PCI ID of that NIC, just to be sure that I can't reproduce this, but I doubt it, pciconf -l You can install without the card, reconfig the kernel so em isnt static in it, rebuild and install that kernel... THEN put the NIC back in and you should be able to boot. interesting question is what will happen when you load the em driver afterwords :) But that way you can do the pciconf with the thing plugged in but not hanging the system. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adaptec 2100, asr driver
On Wed, 13 Dec 2006, Jim Pingle wrote: Willem Jan Withagen wrote: So the 1000$ question: is there any chance of getting at least the state of the RAID and its disk out into the open? It shure would give me a much better feeling, knowing that at least serious trouble would be detected by me. Instead of getting this call from a NOC. It works fine here. I use this on systems with 2100s, and with 2010s. cd /usr/ports/sysutils/asr-utils; make install clean Make sure it installs compat4x, it should as it is listed as a dependency. Add this to /etc/rc.conf: compat4x_enable="YES" add "options ASR_COMPAT" to your kernel and rebuild the kernel I have quite a few machines with the Adaptec cards, and while I hate them and the management tools, I don't have much choice but to use them until we retire the hardware. Does anyone have any info on whether adaptec is planning on updating these tools to work with FreeBSD 6+? Or have they basically abandoned support for FreeBSD? Knowing that info would help me plan our 4.11 to 6.x migration. Thanks, Charles Reboot. That's it. You can use "raidutil -A off" to silence the alarm once it is active. As well as checking the drives with "raidutil -L all". You can get more/less detail, just check the command line options. Jim ___ 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: Adaptec 2100, asr driver
Bruce Burden wrote: On Wed, Dec 13, 2006 at 12:13:11PM -0500, Jim Pingle wrote: Willem Jan Withagen wrote: So the 1000$ question: is there any chance of getting at least the state of the RAID and its disk out into the open? It works fine here. I use this on systems with 2100s, and with 2010s. cd /usr/ports/sysutils/asr-utils; make install clean I have a 3210S, along with asr-utils. The asr-utils will live in /usr/local/dpt, and dprmgr provides a nice GUI to monitor and configure the raid. I already suspected something like that when I saw /dev/dpt17... However the $1000 answer came while I was posting my message: options ASR_COMPAT with thanx to Jim Pingle --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge Ierr rate increase from 5.3R -> 6.1R
On 13 Dec 2006, at 09:18, Gleb Smirnoff wrote: D> > Greg Eden wrote: D> >> Hello D> >> D> >> I recently updated two production servers from 5.3 to 6.1 via D> >> cvsup and D> >> buildworld. Since the upgrade I've seen an increase in the number of D> >> Input packet errors reported on the bge cards in on both boxes. In 5.3-RELEASE the bge(4) driver did not read the error count from the chip at all. So errors were not accounted. Many thanks for clearing up the mystery best wishes greg. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Adaptec 2100, asr driver
On Wed, Dec 13, 2006 at 12:13:11PM -0500, Jim Pingle wrote: > Willem Jan Withagen wrote: > > So the 1000$ question: is there any chance of getting at least the state > > of the RAID and its disk out into the open? > > It works fine here. I use this on systems with 2100s, and with 2010s. > > cd /usr/ports/sysutils/asr-utils; make install clean > I have a 3210S, along with asr-utils. The asr-utils will live in /usr/local/dpt, and dprmgr provides a nice GUI to monitor and configure the raid. I have had some problems reported with disk going bad, but I suspect it was more a power issue (I have 5 73GBs in a Super Micro enclosure). Bruce -- "I like bad!" Bruce BurdenAustin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Missing pkg-descr
Dear FreeBSD, Did something happen to the location for the "pkg-descr" so that ports can't find it? The following happens to me a lot, for many packages: ===> Installing for gmake-3.81_1 ===> Generating temporary packing list ** Missing pkg-descr for gmake-3.81_1. *** Error code 1 Stop in /usr/ports/devel/gmake. *** Error code 1 Stop in /usr/ports/x11-toolkits/open-motif. *** Error code 1 A workaround is to add this package with pkg_add -rv, but this is tiresome, since I must do it many times to finish a complicated port (this time the port is java/jdk15). This happened on a new install of FreeBSD poweredge.etaq.com 6.2-RC1 FreeBSD 6.2-RC1 #0: Thu Nov 16 05:12:08 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386 -- Wayne M. Barnes, Ph.D., President lab at: DNA Polymerase Technology, Inc. The Inventery 11 Princeton Avenue 1508 S. Grand Blvd University City, MO 63130 St. Louis, MO 63104 fax (314)754-9556 Phone: 314.680.0575 email: [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: kqueue LOR
On Tuesday 12 December 2006 21:48, Bruce Evans wrote:
> > Memory barriers just specify ordering, they don't ensure a cache flush so
> > another CPU reads up to date values. You can use memory barriers in
> > conjunction with atomic operations on a variable to ensure that you can
> > safely read other variables (which is what locks do). For example, in
this
>
> I thought that the acquire/release variants of atomic ops guarantee
> this. They seem to be documented to do this, while mutexes don't seem
> to be documented to do this. The MI (?) implementation of mutexes
> depends on atomic_cmpset_{acq,rel}_ptr() doing this.
The acq/rel just specify ordering. As Attilio mentioned, we assume that the
atomic_cmpset() that sets the contested flag will fail while racing with
another CPU (even if the CPU can't see the new value, as long as it fails and
keeps spinning mutexes will still work). The 'rel' barrier on CPU A when
releasing a lock forces all the other writes to be posted (and eventually
become "visible") to other CPUs before the write that releases the lock.
The 'acq' barrier on CPU B when acquiring the lock forces the CPU to not
reorder any reads before it acquires the lock, so this makes you not read any
data until you have the lock. Thus, once CPU B has waited long enough
to "see" the write from A to release the lock, we know that 1) it can
also "see" all the other writes from that CPU that the lock protected, and 2)
B hasn't tried to read any of them yet so it shouldn't have any stale values
in registers. None of this requires the OS to do a cache flush. (If you
have an SMP system where the cache can still hold stale values after another
CPU updates values in memory where it is "visible" to the CPU acquiring the
lock, then _acq might need to flush the cache, but that would be a property
of that architecture. However, even that would not require cache flushes so
long as the stale values were evicted from the cache such that they honor the
memory barrier and you don't see the new value of the lock until you see the
new values of the earlier data.)
--
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: Adaptec 2100, asr driver
Willem Jan Withagen wrote: > So the 1000$ question: is there any chance of getting at least the state > of the RAID and its disk out into the open? It shure would give me a > much better feeling, knowing that at least serious trouble would be > detected by me. Instead of getting this call from a NOC. It works fine here. I use this on systems with 2100s, and with 2010s. cd /usr/ports/sysutils/asr-utils; make install clean Make sure it installs compat4x, it should as it is listed as a dependency. Add this to /etc/rc.conf: compat4x_enable="YES" add "options ASR_COMPAT" to your kernel and rebuild the kernel Reboot. That's it. You can use "raidutil -A off" to silence the alarm once it is active. As well as checking the drives with "raidutil -L all". You can get more/less detail, just check the command line options. Jim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Adaptec 2100, asr driver
Hi, I have a customer with a server with an Adaptec 2100 SCSI card and 2 73Gb seagates, running 6.1. Now one of the disks has been acting up and disconnected from the Raid-1. Customer got a call from the NOC that a server was beeping quite loud. So I rebuild the RAID and stress tested it a little, and thus far the disks have not disconnected or caused other trouble. I am however reluctant to ship the box back into the data center, because I can not get the ASR tools to work with the card. Reading this list, this is not really uncommon. So the 1000$ question: is there any chance of getting at least the state of the RAID and its disk out into the open? It shure would give me a much better feeling, knowing that at least serious trouble would be detected by me. Instead of getting this call from a NOC. OR was this driver maintained by the manufacturer and he is no longer supporting it? Thanx, --WjW ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kqueue LOR
On Wed, Dec 13, 2006 at 04:12:57AM +, Tor Egge wrote:
> > Hmm, may be, since vnode must be interlocked by ffs_sync() after
> > MNTK_SUSPENDED set, and before MNTK_SUSPEND, mount interlock is not
> > needed in ufs_itimes.
> >
> > Tor ?
> If neither IN_CHANGE nor IN_UPDATE is set then it might be unsafe
> to set IN_MODIFIED in ufs_itimes() since the file system might be
> suspended or in the process of being suspended with the vnode sync
> loop in ffs_sync() having iterated past the vnode.
This was exactly the reason for IN_LAZYACCESS flag introduction. It is
set when fs is suspending or suspended, and no IN_CHANGE or IN_UPDATE
flags are set.
> I don't think the mount interlock is needed to check for MNTK_SUSPEND
> being set in ufs_itimes() as long as the vnode interlock is held. If
> a stale value is read without MNTK_SUSPEND set then the vnode sync
> loop in ffs_sync() cannot have iterated past the vnode, thus it should
> still be safe to set IN_MODIFIED. All writes by the CPU performing
> the vnode sync loop before it released the vnode interlock for the
> same vnode should be visible to the CPU in ufs_itimes() after it has
> obtained the vnode interlock.
I think that you statement is valid for both MNTK_SUSPEND and
MNTK_SUSPENDED flags. In other words, aquision of mount interlock could
be safely removed from the ufs_itimes(), as was suggested by [EMAIL PROTECTED]
Index: ufs/ufs/ufs_vnops.c
===
RCS file: /usr/local/arch/ncvs/src/sys/ufs/ufs/ufs_vnops.c,v
retrieving revision 1.283
diff -u -r1.283 ufs_vnops.c
--- ufs/ufs/ufs_vnops.c 6 Nov 2006 13:42:09 - 1.283
+++ ufs/ufs/ufs_vnops.c 13 Dec 2006 14:10:31 -
@@ -133,19 +133,15 @@
{
struct inode *ip;
struct timespec ts;
- int mnt_locked;
ip = VTOI(vp);
- mnt_locked = 0;
- if ((vp->v_mount->mnt_flag & MNT_RDONLY) != 0) {
- VI_LOCK(vp);
+ VI_LOCK(vp);
+ if ((vp->v_mount->mnt_flag & MNT_RDONLY) != 0)
goto out;
+ if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) == 0) {
+ VI_UNLOCK(vp);
+ return;
}
- MNT_ILOCK(vp->v_mount); /* For reading of mnt_kern_flags. */
- mnt_locked = 1;
- VI_LOCK(vp);
- if ((ip->i_flag & (IN_ACCESS | IN_CHANGE | IN_UPDATE)) == 0)
- goto out_unl;
if ((vp->v_type == VBLK || vp->v_type == VCHR) && !DOINGSOFTDEP(vp))
ip->i_flag |= IN_LAZYMOD;
@@ -172,10 +168,7 @@
out:
ip->i_flag &= ~(IN_ACCESS | IN_CHANGE | IN_UPDATE);
- out_unl:
VI_UNLOCK(vp);
- if (mnt_locked)
- MNT_IUNLOCK(vp->v_mount);
}
/*
[ It seems that MNTK_SUSPENDED flag implies MNTK_SUSPEND. ]
pgpMGzCo3rusc.pgp
Description: PGP signature
Re: pf killing NFS
> You are misunderstanding. The problem is simply that the bpf device sees=20 > bad checksums as it sees the packet before the hardware has calculated=20 > it. On the receiver the checksum will be correct. Ah, gotcha. That makes perfect sense now. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf killing NFS
On Wednesday 13 December 2006 12:05, Pete French wrote: > > As Luke already pointed out, "no-df" on the scrub rule should help. > > As=20 for the "bad cksum!" - this is a symptom of checksumming done > > in=20 hardware. ifconfig bge1 -rxcsum -txcsum should get rid of > > them. > > I am a bit concerned by this - we use a lot of bge interfaces, and I > have hardware checksumming enabled on all of them. Are they known to > produce bad checksums ? You are misunderstanding. The problem is simply that the bpf device sees bad checksums as it sees the packet before the hardware has calculated it. On the receiver the checksum will be correct. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgp78oYfArtpS.pgp Description: PGP signature
Re: Setup Virtual Server Port on HP Proliant Server ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, December 13, 2006 06:31:44 -0400 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > I hate feeling panic'd, but I am ... > > Figured to press space as it was booting, and got the: > > boot: > > prompt ... typing 'boot -s' tells me 'No boot' ... > > typing 'load /boot/kernel/kernel' give me a dump and BTX halted ... > > help? Well, this was the most painful (and panic'd) morning I've had in a while ... got a tech to put a CD in to the drive for me, booted up, went into fixit mode, removed the loader.conf file and am not back where I started from before mucking with loader.conf (ie. VSP works for login, break still doesn't work) ... I know what I did wrong with loader.conf though ... boot blocks needed to be rebuilt for COM2 vs COM1 .. is there some way I can do that from loader.conf without having to rebuild the kernel, or does the kernel have to be rebuilt? And, also ... is that why I can't break to DDB, that I don't have comconsole setup through the com port, only the getty? Thanks ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFf96J4QvfyHIvDvMRAv78AKDbKv9rH3EPj1Oq8xJCp25t36o+FwCeLc6h SPoELF6VVseXz/GVWgJrb2Y= =uHDt -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf killing NFS
> As Luke already pointed out, "no-df" on the scrub rule should help. As=20 > for the "bad cksum!" - this is a symptom of checksumming done in=20 > hardware. ifconfig bge1 -rxcsum -txcsum should get rid of them. I am a bit concerned by this - we use a lot of bge interfaces, and I have hardware checksumming enabled on all of them. Are they known to produce bad checksums ? -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf killing NFS
> I'm running a 6.2-RC1 box (cvsup'd today) that has two broadcom nics. One > is an internal network (nfs) and the other is external. ... > Doing something like "ls /usr/ports" will just hang until interrupted. > Using tcp for nfs makes it workable, but very slow. Oddly enough I hit precisely this problem last night - with a cvsup from a few days ago. I have tried adding the 'no-df' flag to the scrub rules, but this did not help much. What I ended up doing was this: scrub in on bge0 proto tcp fragment reassemble random-id so that I am not scrubbing UDP traffic. this works fine. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Setup Virtual Server Port on HP Proliant Server ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, December 13, 2006 06:24:40 -0400 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > 'k, I'm at a loss here ... no console, no comconsole ... how do I get in and > remove /boot/loader.conf on a remote server? :( > > Is there some key I can hit so that it doesn't load /boot/loader.conf, since > I no longer even get the option menu to go to single user mode ... I hate feeling panic'd, but I am ... Figured to press space as it was booting, and got the: boot: prompt ... typing 'boot -s' tells me 'No boot' ... typing 'load /boot/kernel/kernel' give me a dump and BTX halted ... help? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFf9aQ4QvfyHIvDvMRAvLvAJ4gGW3ngOrEDskQiXXUQtXE1ohElQCfVreT U1NKS2P2HahV6ik+e5tVI2w= =EXGi -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Setup Virtual Server Port on HP Proliant Server ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Wednesday, December 13, 2006 06:13:22 -0400 "Marc G. Fournier" <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > > - --On Wednesday, December 13, 2006 05:36:13 -0400 "Marc G. Fournier" > <[EMAIL PROTECTED]> wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> >> 'k, I've drop'd -stable off of this ... >> >> Did some searching, found the HP Lights-Out VSP Configuration guide ... I >> think everything is setup right in the BIOS ... VSP is on COM2 (default), >> EMS points to COM2 ... run VSP through iLO/web the message: >> >> Virtual Server Port active: IO=0x02F8 INT=3 >> >> so, COM2 ... >> >> But, in /dev, I have no device ... because I need sio build into my kernel, >> right? >> >> 'k ... going to do that next ... > > Getting closer ... still missing something though ... > > Have a getty on ttyd1, and a Login: prompt ... but I still can't seem to send > a break ... > > According to the VSP config guide, Ctrl-B should do it ... > > Do I have to setup the comconsole stuff in /etc/loader.conf as well, for the > break to work? > > Damn, now I screwed up the server ... no remcons, and nothing on the vsp ... > all I have left is: > > Loading /boot/defaults/loader.conf > > after adding: > > hint.acpi.0.disabled=1 > boot_multicons="YES" > boot_serial="YES" > comconsole_speed="115200" > console="comconsole,vidconsole" > > to /boot/loader.conf ... > > So, that was the wrong move ... :( 'k, I'm at a loss here ... no console, no comconsole ... how do I get in and remove /boot/loader.conf on a remote server? :( Is there some key I can hit so that it doesn't load /boot/loader.conf, since I no longer even get the option menu to go to single user mode ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFf9To4QvfyHIvDvMRAhhgAKDseeaBOYRcVcbiCkP8fSEW/Uhn0gCfd2Zm zi4QqN2wlsFzd6t0TNPDG6A= =fIuB -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bge Ierr rate increase from 5.3R -> 6.1R
D> > Greg Eden wrote: D> >> Hello D> >> D> >> I recently updated two production servers from 5.3 to 6.1 via D> >> cvsup and D> >> buildworld. Since the upgrade I've seen an increase in the number of D> >> Input packet errors reported on the bge cards in on both boxes. In 5.3-RELEASE the bge(4) driver did not read the error count from the chip at all. So errors were not accounted. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf killing NFS
On Wednesday 13 December 2006 07:10, Charles Sprickman wrote: > Hi all, > > I'm running a 6.2-RC1 box (cvsup'd today) that has two broadcom nics. > One is an internal network (nfs) and the other is external. > > PF has this rule for all traffic on the private net: > > [EMAIL PROTECTED] /home/jails]# pfctl -sr|grep bge1 > pass in quick on bge1 inet from 192.168.1.0/24 to any > pass out quick on bge1 inet from any to 192.168.1.0/24 > > No state since these are "quick" and symmetrical. > > Doing something like "ls /usr/ports" will just hang until interrupted. > Using tcp for nfs makes it workable, but very slow. > > If I disable pf (pfctl -d), both types of mounts work, and speed is > excellent. I also just found that if I remove the "scrub in all" > statement and change it to "scrub in on bge0", things are fine. > > Any idea what's going on? The tcpdump output confuses me (see "bad > cksum!"), so I'm posting some snippets here. As Luke already pointed out, "no-df" on the scrub rule should help. As for the "bad cksum!" - this is a symptom of checksumming done in hardware. ifconfig bge1 -rxcsum -txcsum should get rid of them. -- /"\ Best regards, | [EMAIL PROTECTED] \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | [EMAIL PROTECTED] / \ ASCII Ribbon Campaign | Against HTML Mail and News pgppB7vvCmPvM.pgp Description: PGP signature
Mounting smbfs as non-root
I am trying to mount a SMB filesystem as an ordinary user (because
I don't want to give root to this particular person). Whilst
running mount_smbfs as root works, attempting the same command
as non-root consistently returns
mount_smbfs: can not setup kernel iconv table (ISO8859-1:tolower): syserr =
Operation not permitted
I've looked at a ktrace and the source code and the offending code is
sysctlbyname("kern.iconv.add", ...)
I've looked through iconv_sysctl_add() and can't see any way for the
code to return EPERM.
My reading of all the code also suggests that once the relevant iconv
tables are loaded, then iconv_sysctl_add() should return EEXIST
(via iconv_register_cspair()). But even if the relevant translation
table is loaded (by mounting a SMB filesystem as root), I still get
the above error when trying to use mount_smbfs as a user. I've even
written some code to let me look at the kern.iconv MIB tree which
confirms the above but doesn't get any me any closer to a solution.
This is the same on two 6.2-PRERELEASE systems and I get the same
behaviour on an oldish 7-current system. Does anyone have any
suggestions on what is going wrong?
--
Peter Jeremy
pgpyQbzzxJbSw.pgp
Description: PGP signature
Re: g_vfs_done() failures on 6.2-RC1
On Wed, Dec 13, 2006 at 07:09:15PM +1100, Jan Mikkelsen wrote: > Scott Long wrote: > >Jan Mikkelsen wrote: > > > >>- Daichi Goto's unionfs-p16 has been applied. > >>- The Areca driver is 1.20.00.12 from the Areca website. > >>- sym(4) patch (see PR/89550), but no sym controller present. > >>- SMP + FAST_IPSEC + SUIDDIR + device crypto. > >> > >>So: I've seen this problem on a few machines under heavy I/O load, with > >>ataraid and with arcmsr. I've seen others report similar problems, but > >>I've seen no resolution. Does anyone have any idea what the problem is? > >>Has anyone else seen similar problems? Where to from here? > >> > >>Thanks, > >> > > > >You mention that you are using a driver from the Areca website. Have > >you tried using the stock driver that comes with FreeBSD? I don't know > >if it will be better or not, but I was planning on doing a refresh of > >the stock driver, and I'd hate to introduce instability that wasn't there > >before. > > I haven't run it recently. I can roll back to the stock driver and see > whether I see it again. However, I can't always reproduce the problem, so > I probably can't prove the absence of the problem. > > I mentioned that I have seen similar problems on machines with ataraid, > like this: > > DOH! ata_alloc_composite failed! (x5) > FAILURE - out of memory in ata_raid_init_request (x6) > g_vfs_done():ar0s3f[WRITE(offset=113324673024, length=2048)]error = 5 > g_vfs_done():ar0s3f[WRITE(offset=113325062144, length=2048)]error = 5 > g_vfs_done():ar0s3f[WRITE(offset=113325127680, length=2048)]error = 5 > g_vfs_done():ar0s3f[WRITE(offset=113325242368, length=2048)]error = 5 > g_vfs_done():ar0s3f[WRITE(offset=113325256704, length=2048)]error = 5 > g_vfs_done():ar0s3f[WRITE(offset=113325275136, length=2048)]error = 5 > > However, looking at this again, I'm not sure that the problem is identical > anymore because the offset seems to be within the partition rather than > just plain wrong (assuming the units of the offset message are bytes). > These messages are from an HP DL145G1 with two SATA drives and ataraid. > > The workload that caused these messages is very similar: Heavy I/O during > multiple concurrent removes of deep trees on a filesystem with softupdates, > system needs a reboot to get back on track. Yes, it looks like a different problem: a) It's a different driver (ataraid vs areca). The g_vfs_done message is a generic error, it means "the driver I was writing to returned EIO in response to this attempted write". The reasons why the error occurred will depend on the driver and hardware. b) As you say, the error messages are sensible in the ataraid case but not in the areca case. c) There is a previous error message which causes the g_vfs_done errors as secondary effects. Your bug here is whatever causes the "DOH!" in ataraid, so that's what you should follow up (separately). Kris pgp6Lv9w51WQd.pgp Description: PGP signature
Re: g_vfs_done() failures on 6.2-RC1
Scott Long wrote: Jan Mikkelsen wrote: - Daichi Goto's unionfs-p16 has been applied. - The Areca driver is 1.20.00.12 from the Areca website. - sym(4) patch (see PR/89550), but no sym controller present. - SMP + FAST_IPSEC + SUIDDIR + device crypto. So: I've seen this problem on a few machines under heavy I/O load, with ataraid and with arcmsr. I've seen others report similar problems, but I've seen no resolution. Does anyone have any idea what the problem is? Has anyone else seen similar problems? Where to from here? Thanks, You mention that you are using a driver from the Areca website. Have you tried using the stock driver that comes with FreeBSD? I don't know if it will be better or not, but I was planning on doing a refresh of the stock driver, and I'd hate to introduce instability that wasn't there before. I haven't run it recently. I can roll back to the stock driver and see whether I see it again. However, I can't always reproduce the problem, so I probably can't prove the absence of the problem. I mentioned that I have seen similar problems on machines with ataraid, like this: DOH! ata_alloc_composite failed! (x5) FAILURE - out of memory in ata_raid_init_request (x6) g_vfs_done():ar0s3f[WRITE(offset=113324673024, length=2048)]error = 5 g_vfs_done():ar0s3f[WRITE(offset=113325062144, length=2048)]error = 5 g_vfs_done():ar0s3f[WRITE(offset=113325127680, length=2048)]error = 5 g_vfs_done():ar0s3f[WRITE(offset=113325242368, length=2048)]error = 5 g_vfs_done():ar0s3f[WRITE(offset=113325256704, length=2048)]error = 5 g_vfs_done():ar0s3f[WRITE(offset=113325275136, length=2048)]error = 5 However, looking at this again, I'm not sure that the problem is identical anymore because the offset seems to be within the partition rather than just plain wrong (assuming the units of the offset message are bytes). These messages are from an HP DL145G1 with two SATA drives and ataraid. The workload that caused these messages is very similar: Heavy I/O during multiple concurrent removes of deep trees on a filesystem with softupdates, system needs a reboot to get back on track. Thanks, Jan. PS: Any news on importing the sym(4) patch? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
