Call for testing VMware open-vm-tools update
VMware has been contributing to making FreeBSD a first class citizen for their open source vmware tools. As a continuing part of this contribution there's a new version of open-vm-tools in the works. The INO64 work in FreeBSD HEAD broke building open-vm-tools for HEAD/i386, and there was a kernel panic that affected HEAD/amd64. That has been addressed and vmware has started QA for the tools for FreeBSD 11.1-R and 10.3-R amd64 and i386. I've given this update a fair amount of testing and it gets a "works on my machine" certification from me. The new version is available as a port at https://people.freebsd.org/~jpaetzel/open-vm-tools.tar.gz . Feel free to give it a spin and please report any issues by filing a bug at https://bugs.freebsd.org/ If you tag the bug you create as ports emulators/open-vm-tools it will get auto-assigned to me. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Apparent fxp regression in FreeBSD 8.4-RC3
At this point fxp hardware is over a decade old. I'm loath to introduce delays at the end of the runway for this issue. Keep in mind that delays to 8.4 are pushed directly on to delays for 9.2, which won't be started until 8.4 is completed, and is desperately needed. (9.1 doesn't have drivers for common shipping hardware for example). Factors like these as well as the age of fxp hardware drive my decision to complete 8.4 and push this fix in to EN territory. Thanks, Josh Paetzel FreeBSD - The Power to Serve On May 23, 2013, at 10:11 PM, Jeremy Chadwick j...@koitsu.org wrote: On Fri, May 24, 2013 at 12:56:20AM -0400, Glen Barber wrote: On Thu, May 23, 2013 at 09:40:35PM -0700, Jeremy Chadwick wrote: [...] So if someone wants to take a stab at this, they'll need to do so and make me an ISO. Sorry that I can't make things easier. :-( This definitely needs to get fixed before 8.4-RELEASE. *sigh* At this point, it is highly unlikely this will be fixed before 8.4-RELEASE. We are _far_ too deep into the release cycle. In fact, we are effectively done with the release, and waiting on release notes to be completed. I think this will likely be included in errata notes for the release. I urge you to meet with others in Release Engineering and discuss this fully. This is major enough that, once fixed, it warrants an immediate binary update (to the kernel + if_fxp.ko) pushed out via freebsd-update. fxp(4) is a commonly-used driver; it isn't something rare/uncommon. Also remember at this stage we don't know if it's a specific PHY model or specific NIC model (or series) which triggers it. For all we know it could affect everything that fxp(4) drives. Please don't forget that FreeBSD has a very well-established history of having rock-solid Intel NIC support. Sure, mistakes happen, we're human, bugs get introduced, but this does not bode well -- meaning I would expect Slashdot et al to pick up on this. It is very unfortunate that this waited so long to be reported, as much time has passed since 8.4-BETA1... This is what happens when people socially proliferate the belief that RELEASE is rock solid/stable, don't run stable/X -- the number of people who test what changes between RELEASE builds is vastly smaller comparatively. I've only been saying this for the past 15 years, so it's even more unfortunate that people keep believing it. :/ -- | Jeremy Chadwick j...@koitsu.org | | UNIX Systems Administratorhttp://jdc.koitsu.org/ | | Mountain View, CA, US| | Making life hard for others since 1977. PGP 4BD6C0CB | ___ 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: LSI 9240-4i 4K alignment
On 08/20/2012 00:19, Don Lewis wrote: On 19 Aug, Josh Paetzel wrote: On 08/19/2012 14:04, Steven Hartland wrote: HBA's are the way to go if your using ZFS to manage the disks, you only need RAID if your using a FS which doesn't manage the disk side well such as UFS. Its often quite common for RAID controllers to actually be slower vs RAID controllers as the RAID stack can get in the way. Any idea of what kind of performance penalty I might see by using the RAID firmware in JBOD mode vs flashing the IT firmware? I don't have any current numbers, on ZFS v14 14 RAID controllers were actually a bit faster, but that's all changed dramatically. On our high end stuff we can get HBAs to go over 25% faster than high end RAID controllers, like the 9260/9280, but we don't test with RAID controllers anymore at all, so I don't have up to the minute info. ZFS does block checksums, and so do LSI mfi cards, even when in JBOD mode, you also can't bypass the cache on the card without a huge performance hit, so you end up with 256MB or whatever in between your disks and the OS. In addition because the 9240 is based on the 2008 which lacks hardware assist for RAID5/6 those two modes are done in software, so you take another hit there. Advantages: ZFS doesn't work with hot spares as of this moment on FreeBSD, but LSI controllers do, so if your strategy involves hot spares the RAID card is the better choice. LSI controllers can be set to auto-replace, ZFS can't. Enclosure management works better on RAID controllers than through FreeBSD in many cases. Just to clear up, The 9240 is a sas2008 based card with the megaraid software on top of it. In it's default config from LSI the FreeBSD mfi will recognize it in later versions of FreeBSD (The upcoming 9.1 for sure) Older versions of mfi will not recognize it. The card can be flashed with IT firmware and then becomes a 9211 HBA, but it's a bit more expensive than a 9211 is so that doesn't make sense to do in many cases. The price difference was pretty minor when I looked. Confusingly enough, the 9211 HBA also has some RAID capabilities. For me, the biggest advantage of the 9211 would be that it would have allowed me to use shorter cables. On the dmesg posted the firmware on the card is phase 11. This *must* be in lockstep with the driver version or the card may not play nicely. FreeBSD 8.3 and 9.0 have v13 of the driver, the upcoming 9.1 will have v14. Note that v14 fixes a *ton* of stability bugs, including issues where bad drives would hang the controller or prevent systems from booting. Where do those version numbers come from? The mfi driver in 9.0-RELEASE claims to be version 3.00 and the the driver in 9.1 claims to be version 4.23. I was talking about mps, not mfi. The dmesg I was responding to showed an mps. This is what shows up in dmesg on my machine: mfi0: Drake Skinny port 0xce00-0xceff mem 0xfcefc000-0xfcef,0xfce8-0xf ceb irq 18 at device 0.0 on pci1 mfi0: Using MSI mfi0: Megaraid SAS driver Ver 4.23 mfi0: 333 (398082533s/0x0020/info) - Shutdown command received from host mfi0: 334 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0073 /1000/9240/1000) mfi0: 335 (boot + 3s/0x0020/info) - Firmware version 2.70.04-0862 mfi0: 336 (boot + 5s/0x0020/info) - Board Revision 04A mfi0: 337 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0073 /1000/9240/1000) mfi0: 338 (boot + 3s/0x0020/info) - Firmware version 2.70.04-0862 mfi0: 339 (boot + 5s/0x0020/info) - Board Revision 04A mfi0: 340 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0073 /1000/9240/1000) mfi0: 341 (boot + 3s/0x0020/info) - Firmware version 2.70.04-0862 mfi0: 342 (boot + 5s/0x0020/info) - Board Revision 04A mfi0: 343 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0073 /1000/9240/1000) mfi0: 344 (boot + 3s/0x0020/info) - Firmware version 2.70.04-0862 mfi0: 345 (boot + 5s/0x0020/info) - Board Revision 04A mfi0: 346 (398759025s/0x0020/info) - Time established as 08/20/12 6:23:45; (25 seconds since power on) mfi0: 347 (398759051s/0x0020/info) - Time established as 08/20/12 6:24:11; (51 seconds since power on) mfi0: 348 (398759078s/0x0020/WARN) - Patrol Read can't be started, as PDs are ei ther not ONLINE, or are in a VD with an active process, or are in an excluded VD % mfiutil show firmware mfi0 Firmware Package Version: 20.5.1-0003 mfi0 Firmware Images: Name VersionDate Time Status BIOS 4.14.00 active PCLI 03.02-001:#%8 Feb 09 2010 13:09:06 active BCON 4.0-22-e_10-RelMar 11 2010 12:38:08 active NVDT 3.04.03-0002 Apr 05 2010 18:50:27 active APP 2.70.04-0862 May 05 2010 18:12:07 active BTBL 2.01.00.00-0019May 14 2009 15:52:08 active The only firmware file on LSI's web site for the 9240-8i is version
Re: LSI 9240-4i 4K alignment
On 08/19/2012 14:04, Steven Hartland wrote: - Original Message - From: Don Lewis truck...@freebsd.org To: kill...@multiplay.co.uk Cc: gkontos.m...@gmail.com; freebsd-stable@FreeBSD.org; freebsd-hardw...@freebsd.org Sent: Sunday, August 19, 2012 6:37 PM Subject: Re: LSI 9240-4i 4K alignment On 16 Aug, Steven Hartland wrote: - Original Message - From: George Kontostanos gkontos.m...@gmail.com You are right, the chip specs say: LSISAS2108 RAID-on-Chip The drives are identified as mfisyspd0, mfisyspd1, etc. The following might be interesting to you:- http://forums.servethehome.com/showthread.php?599-LSI-RAID-Controller-and-HBA-Complete-Listing-Plus-OEM-Models Which states:- LSI MegaRAID SAS 9240-4i 1x4 port internal SAS vertical, no cache, no BBU, RAID 0, 1, 10 and 5, can be crossflashed to LSI9211 IT/IR This is insteresting as this is the card we're using but in the 8 port version under mps :) I wish I would have known this earlier. I just put together a ZFS server using LSI MegaRAID SAS 9240-8i cards. The cabling probably would have been cleaner with the 9211-8i, but I went with the 9240 because the vendor that I purchased the cards from listed that 9240 as being PCI-Express 2.0, but didn't say that about the 9211. I also got the impression that the 9240 recognized JBOD drives with the off-the-shelf firmware, whereas the 9211 did not. Even LSI's own site is a bit confusing. They list the 9211 in the HBA section, but its specs don't mention JBOD, whereas the 9240 is listed in the RAID section and its specs do list JBOD. If the only physical difference between the cards is the connector position, it seems odd that they don't offer products with all the combinations of firmware and connector position. I haven't configured the ZFS pool yet, but I didn't have any trouble installing FreeBSD 9.1-BETA on the GPT partitioned boot drive, which shows up as an mfi device. I'm planning on getting the ZFS pool up and running in the next few days. HBA's are the way to go if your using ZFS to manage the disks, you only need RAID if your using a FS which doesn't manage the disk side well such as UFS. Its often quite common for RAID controllers to actually be slower vs RAID controllers as the RAID stack can get in the way. JBOD is generally what HBA's do by default which may be the reason why LSI's site doesn't mention it. Regards Steve Just to clear up, The 9240 is a sas2008 based card with the megaraid software on top of it. In it's default config from LSI the FreeBSD mfi will recognize it in later versions of FreeBSD (The upcoming 9.1 for sure) Older versions of mfi will not recognize it. The card can be flashed with IT firmware and then becomes a 9211 HBA, but it's a bit more expensive than a 9211 is so that doesn't make sense to do in many cases. On the dmesg posted the firmware on the card is phase 11. This *must* be in lockstep with the driver version or the card may not play nicely. FreeBSD 8.3 and 9.0 have v13 of the driver, the upcoming 9.1 will have v14. Note that v14 fixes a *ton* of stability bugs, including issues where bad drives would hang the controller or prevent systems from booting. Thanks, Josh Paetzel ___ 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: nmbclusters: how do we want to fix this for 8.3 ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2012 13:51, Jack Vogel wrote: On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo ri...@iet.unipi.it mailto:ri...@iet.unipi.it wrote: On Wed, Feb 22, 2012 at 09:09:46PM +, Ben Hutchings wrote: On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: ... I have hit this problem recently, too. Maybe the issue mostly/only exists on 32-bit systems. No, we kept hitting mbuf pool limits on 64-bit systems when we started working on FreeBSD support. ok never mind then, the mechanism would be the same, though the limits (especially VM_LIMIT) would be different. Here is a possible approach: 1. nmbclusters consume the kernel virtual address space so there must be some upper limit, say VM_LIMIT = 256000 (translates to 512MB of address space) 2. also you don't want the clusters to take up too much of the available memory. This one would only trigger for minimal-memory systems, or virtual machines, but still... MEM_LIMIT = (physical_ram / 2) / 2048 3. one may try to set a suitably large, desirable number of buffers TARGET_CLUSTERS = 128000 4. and finally we could use the current default as the absolute minimum MIN_CLUSTERS = 1024 + maxusers*64 Then at boot the system could say nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) nmbclusters = max(nmbclusters, MIN_CLUSTERS) In turn, i believe interfaces should do their part and by default never try to allocate more than a fraction of the total number of buffers, Well what fraction should that be? It surely depends on how many interfaces are in the system and how many queues the other interfaces have. if necessary reducing the number of active queues. So now I have too few queues on my interface even after I increase the limit. There ought to be a standard way to configure numbers of queues and default queue lengths. Jack raised the problem that there is a poorly chosen default for nmbclusters, causing one interface to consume all the buffers. If the user explicitly overrides the value then the number of cluster should be what the user asks (memory permitting). The next step is on devices: if there are no overrides, the default for a driver is to be lean. I would say that topping the request between 1/4 and 1/8 of the total buffers is surely better than the current situation. Of course if there is an explicit override, then use it whatever happens to the others. cheers luigi Hmmm, well, I could make the default use only 1 queue or something like that, was thinking more of what actual users of the hardware would want. After the installed kernel is booted and the admin would do whatever post install modifications they wish it could be changed, along with nmbclusters. This was why i sought opinions, of the algorithm itself, but also anyone using ixgbe and igb in heavy use, what would you find most convenient? Jack The default setting is a thorn in our (with my ixsystems servers for freebsd hat on) side. A system with a quad port igb card and two onboard igb NICs won't boot stable/8 or 8.x-R to multiuser. Ditto for a dual port chelsio or ixgbe alongside dual onboard igb interfaces. My vote would be having systems over some minimum threshold of system ram to come up with a higher default for nmbclusters. You don't see too many 10gbe NICs in systems with 2GB of RAM - -- Thanks, Josh Paetzel FreeBSD -- The power to serve -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRmIGAAoJEKFq1/n1feG229gIAIciDDKnc/K6/dgBA2YFGuuV V9cYD6+Zm4bVT9nvFhxJCUj+3CTGQFvNwi2sQx6pVMUWQC7Cpb323CShc8BBNjV3 vCzTmvqVshO+LWhx6J8lq4rqTU+PIKajF3GnwIWt4xmZ6WhrjCUySORYSAINQjKr iXJg/HBA7z/tsPUqOvzU0esZ4moUECapoldEOe0EF2jidARuM4q6MD1+QLMs+JSO JUS5yMPV022NVYS79NsUfvJ1cuwd6/I7CPvsJsW0E+zMMF2BjKZesU89zyFDST80 0WptoEqR9cuyApwu0OfDDzKyL7Z6G9yaAr0zkCAHATxkK0KArMJP/j2eT5uzZkE= =b44v -END PGP SIGNATURE- ___ 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: known problems with 8.x and HP DL16 G5 server?
On Feb 11, 2012, at 4:55 AM, Jan Mikkelsen j...@transactionware.com wrote: On 11/02/2012, at 7:30 PM, Julian Elischer wrote: turns out that the HP machine has an HP branded (and with different firmware) raid controller that is not quite the same as the standard one. FreeBSD can't handle it and dies. Josh Paetzel may remember the exact type.. I forget.. I have some memory of HP DL160 servers with an embedded ciss(4) controller taking a long time to boot. I recall a delay of multiple minutes. I don't remember what I did to work around it. Does it really stop, or is it just being slow? Regards, Jan. It really does stop. It was left overnight once. It has an old mpt (rebranded lsi 1068) with HP firmware on it. The controller takes way too long to probe but eventually it passes that and then hangs where Julian describes. If you poke around on the web, there's posts where this machine hangs on boot on 6.2, 7.0 and 8.0. Removing the HBA allows it to boot normally. My next troubleshooting step would be replacing the HBA with one with stock LSI firmware. Thanks, Josh Paetzel___ 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
NFS regression on recent STABLE
I've been involved with a project at work doing some fun things with NFS. Recently due to changes in a available hardware we did a complete refresh of the system. New HBAs, new storage boxes, and due to some internal software confusion we updated the OS on the head from 8.1-R with zpool 15 backported to STABLE. Our primary client that we were using against this setup was a ESXi 4.1 machine. In a nutshell, it didn't work. Long description is, ZFS would deadlock and any operation on the pool would hang. The ESXi instance would mark the NFS mount as unavailable. I initially thought this could be due to any number of factors, we have new HBAs in the mix, new storage boxes, a new version of zpool, and one test case. Meanwhile, back at the ranch, I have a somewhat similar setup at home. FreeBSD 8.1 NFS server, ESXi 4.1 box mounting an NFS exported ZFS filesystem from the FreeBSD box as a datastore. Last night I pulled that box up to STABLE, rebooted it, and a minute after it rebooted the ESXi box marked the NFS datastore as unavailable. I checked the FreeBSD machine and sure enough it hung doing an ls on the zpool. I ran a few tests, and as soon as the ESXi box mounts the NFS export it hangs the ZFS filesystem. If I don't mount it up, the NFS server does fine. Thinking it might be a ZFS problem I moved the mount to a UFS filesystem. While this doesn't cause the box to hang on filesystem operations, the mount goes unavailable. The only other client I have on my network is a FreeBSD 8.1 box, and that has no issues All of this is with the standard NFS server, I haven't yet tested with the experimental server. -- Thanks, Josh Paetzel signature.asc Description: This is a digitally signed message part.
Re: NFS regression on recent STABLE
On Tuesday, November 23, 2010 08:33:52 am Josh Paetzel wrote: I've been involved with a project at work doing some fun things with NFS. Recently due to changes in a available hardware we did a complete refresh of the system. New HBAs, new storage boxes, and due to some internal software confusion we updated the OS on the head from 8.1-R with zpool 15 backported to STABLE. Our primary client that we were using against this setup was a ESXi 4.1 machine. In a nutshell, it didn't work. Long description is, ZFS would deadlock and any operation on the pool would hang. The ESXi instance would mark the NFS mount as unavailable. I initially thought this could be due to any number of factors, we have new HBAs in the mix, new storage boxes, a new version of zpool, and one test case. Meanwhile, back at the ranch, I have a somewhat similar setup at home. FreeBSD 8.1 NFS server, ESXi 4.1 box mounting an NFS exported ZFS filesystem from the FreeBSD box as a datastore. Last night I pulled that box up to STABLE, rebooted it, and a minute after it rebooted the ESXi box marked the NFS datastore as unavailable. I checked the FreeBSD machine and sure enough it hung doing an ls on the zpool. I ran a few tests, and as soon as the ESXi box mounts the NFS export it hangs the ZFS filesystem. If I don't mount it up, the NFS server does fine. Thinking it might be a ZFS problem I moved the mount to a UFS filesystem. While this doesn't cause the box to hang on filesystem operations, the mount goes unavailable. The only other client I have on my network is a FreeBSD 8.1 box, and that has no issues All of this is with the standard NFS server, I haven't yet tested with the experimental server. Thanks to kib for helping resolve this. In a nutshell, at one point there was a problem in STABLE, it was fixed, and my local cvsup mirror fell out of sync and while I thought I was seeing a problem from a system updated last night, I was getting an old rev. Updating the system to a mirror that isn't broken fixed the problem. -- Thanks, Josh Paetzel signature.asc Description: This is a digitally signed message part.
Re: Recent MFC to 7 causes crash on VMware ESXi
On 02/05/10 07:27, John Baldwin wrote: On Thursday 04 February 2010 10:00:55 pm Tom McLaughlin wrote: Hi all, a recent MFC to 7-STABLE has started to cause issues for my VMs on VMware ESXi 3.5u4. After loading the mpt driver for the LSI disk controller the VM just shuts off. The workaround is to change the disk controller to the BusLogic type. Still, it used to work up until last week. The change was made around January 26th and based on the commits that day I'm guessing it's either r203047 or r203073 I have the same issue with both amd64 and i386 VMs. This affects HEAD and 8-STABLE as well and first affected HEAD over the summer. (I just worked around it and went about my business at the time. :-/) I've attached a dmesg from a kernel before the problem and one from after it started. What if you set 'hw.clfush_disable=1' from the loader? For what it's worth, I have two machines running ESXi 4.0 and haven't encountered this problem. It's possible this issue affects 3.5 only. -- Thanks, Josh Paetzel FreeBSD -- The power to serve ___ 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: em(4) on FreeBSD is sometimes annoying
On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: OK, I just got access to a machine, am going to install and see if I can repro this this afternoon. Jack For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 and neither install has this problem. I can cold boot it with the NIC unplugged, plug in a cable, I get a link light and ifconfig em0 goes to active, dhclient em0 gets an IP successfully. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Lenovo Thinkpad t61p and FreeBSD?
On Sunday 08 June 2008 02:03:33 pm Alexandre Sunny Kovalenko wrote: On Wed, 2008-06-04 at 07:45 -0500, Josh Paetzel wrote: On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: On Tue, Jun 03, 2008 at 11:13:27AM -0400, [EMAIL PROTECTED] wrote: Quoting [EMAIL PROTECTED]: Quoting Jeremy Chadwick [EMAIL PROTECTED]: Based on my experiences with my workplace-provided T60p, it's safe to say I'll never recommend a Lenovo product. The temperatures of these laptops are absolutely insane, supported by an incredibly loud fan. I'm not interested in a product that can have a GPU reaching temperatures of almost 70C **while idling**. I purchased a T60p about two months ago and I haven't had any of these happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch after a few hours idling. Does your fan run all the time that loud? I'm wondering if there were changes made at the factory to fix this type of problem if it was wide spread. Regards, Nick LaRoche That was a T61p not a T60p It really doesn't matter in this case; T60p, T60p (widescreen), T61p, X60p, etc... They all behave the same way when it comes to temperatures: incredibly high, sometimes to the point of the system shutting off (for some). My T60p is really unusable for anything cpu intensive under FreeBSD. Even with the ibm acpi addons loaded and the fan set to it's highest setting it only turns at 3700rpm, which isn't enough to keep it from shutting down due to heat. (eg over 100C) I'm interested in whatever cooling solutions people have... You can read through this thread: http://www.freebsd.org/cgi/getmsg.cgi?fetch=141019+0 +/usr/local/www/db/text/2008/freebsd-acpi/20080217.freebsd-acpi which mentions at least two ways to approach it -- the right one is from the referenced message forward. HTH, So in doing some more research I finally got together the nerve to disassemble my laptop. After cleaning a massive amount of thermal paste off the cpu and heatsink it's operating around 60C after multiple make -j4 buildworlds, where it used to shut down due to going over 100C. It seems I'm not the first person to discover this was the root cause of their heat and noise problems with their Lenovo T60/61 laptop. I've also been able to turn over control of the fan back to the BIOS as opposed to running it full out all the time. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Lenovo Thinkpad t61p and FreeBSD?
On Wednesday 04 June 2008 07:25:13 am Jeremy Chadwick wrote: On Tue, Jun 03, 2008 at 11:13:27AM -0400, [EMAIL PROTECTED] wrote: Quoting [EMAIL PROTECTED]: Quoting Jeremy Chadwick [EMAIL PROTECTED]: Based on my experiences with my workplace-provided T60p, it's safe to say I'll never recommend a Lenovo product. The temperatures of these laptops are absolutely insane, supported by an incredibly loud fan. I'm not interested in a product that can have a GPU reaching temperatures of almost 70C **while idling**. I purchased a T60p about two months ago and I haven't had any of these happen (yet?) running Ubuntu 7.10. The machine only gets slightly warm to the touch after a few hours idling. Does your fan run all the time that loud? I'm wondering if there were changes made at the factory to fix this type of problem if it was wide spread. Regards, Nick LaRoche That was a T61p not a T60p It really doesn't matter in this case; T60p, T60p (widescreen), T61p, X60p, etc... They all behave the same way when it comes to temperatures: incredibly high, sometimes to the point of the system shutting off (for some). My T60p is really unusable for anything cpu intensive under FreeBSD. Even with the ibm acpi addons loaded and the fan set to it's highest setting it only turns at 3700rpm, which isn't enough to keep it from shutting down due to heat. (eg over 100C) I'm interested in whatever cooling solutions people have... -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: Source upgrade from 5.5 to 6.X not safe?
On Friday 02 November 2007 05:29:03 am Clint Olsen wrote:
On Nov 02, LI Xin wrote:
So we get:
- 5.5-STABLE works well on your box
- 6.2-RELEASE stock GENERIC works fine
- 6.3-PRERELEASE failed for some reason.
So far as I am aware I have no clue why this could happen. Could you
check if you have any special configuration in your /etc/make.conf,
especially special CFLAGS? I usually simply remove my /usr/src /usr/obj
and build a new world without make.conf to make sure.
No special configs in my system:
X11BASE=${LOCALBASE}
# added by use.perl 2007-08-24 03:20:32
PERL_VER=5.8.8
PERL_VERSION=5.8.8
Unless something in here could be construed as dangerous?
-Clint
Supported source upgrades across major version numbers are the last of the old
release to the first of the newerso in your case 5.5 - 6.0 - 6.3
Other upgrade paths *may* work, or they may not.
--
Thanks,
Josh Paetzel
PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
signature.asc
Description: This is a digitally signed message part.
Re: problems with Hitachi 1TB SATA drives
On Tuesday 24 July 2007, Daniel O'Connor wrote: On Tue, 24 Jul 2007, Jeremy Chadwick wrote: On Mon, Jul 23, 2007 at 07:40:21PM -0700, Bill Swingle wrote: Doh, I knew I forgot something in my original email. Here's the full dmesg: http://dub.net/rum.dub.net.dmesg Actually you did include this in your original Email. I think Daniel overlooked it. :-) Oops, maybe it was an attachment I forgot to read. As you say later - it would be good to know what mode the chipset is in. Might be worth trying AHCI mode if you have it (although maybe ICH5 is too old for that?) I don't have any experience with the Hitachi 1TB SATA drives, but I know an outfit that was trying out the Seagate 1TB drives and had 8 out of 12 fail their burn-in (a 3 day torture test) My luck with consumer SATA drives has been incredibly dismal, with ~40 of them in service I see multiple failures a year, including drives being DOA and dying after a few weeks of service. I wouldn't be at all surprised if one or both of the drives was bad right out of the box. It could be something else of course, but don't discount the fact that they could be bad from your troubleshooting just because they are new. -- Thanks, Josh Paetzel pgpqtvh04aNlq.pgp Description: PGP signature
Re: problems with Hitachi 1TB SATA drives
On Tuesday 24 July 2007, Jeremy Chadwick wrote: * SCSI is outrageously expensive even in 2007. I have yet to see any shred of justification for why SCSI costs so much *even today*. It costs only a smidgen less than it did 15 years ago. * SCSI is on its way out. Seagate recently announced that they'll no longer be supporting SCSI products, possibly by the end of next year: Seagate has announced that by next year they will no longer be supporting SCSI product and will be moving customers to the SATA interface. http://www.horizontechnology.com/news/market/market_perspective_sto rage_04-11-2007.php I'm willing to bet others will follow suit. It's more than just an interface. SCSI drives are manufactured with completely different components than IDE/SATA drives. The platters have different materials on them, the heads are different, the actuators are different. The higher spindle speeds present different engineering challanges, if you know anything about physics you'll realize the difference between spinning something at 7200rpm and 15,000rpm is not linear in terms of the forces involved. You're really paying for two things when you buy SCSI/SAS. reliability under 100% duty cycle seek times As far as that article goes, I wonder if they are including SAS in the SATA catagory or the SCSI catagory. It's perfectly reasonable to phase out U320 SCSII can't see SAS going away any time soon. -- Thanks, Josh Paetzel pgpEiD1JSN0K4.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
On Thursday 19 July 2007, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jeremy Chadwick [EMAIL PROTECTED] writes: : If someone wants to work on this and needs devices/toys (thumb : drives, external enclosures + hard disks), let me know, I will be : more than happy to buy them the hardware needed. Willing to fund the work on it too? This is a volunteer project, and you have to motivate people to work on this. Tirades in mailing lists has proven to be ineffective in the past. I've looked at the issue, and generically, if a device goes away, it is *HARD* to not panic. The same thing happens if you eject a CF card in a PC Card adapter in a PC Card slot. The best one can do without massive buffer cache work is what firewire does: it has one attachment to handle all umass devices. When the device goes away, it pauses all operations to that device. If the device comes back, it resumes the I/O . If the device never comes back, then the I/O never finishes. Warner Just curious, but what, if any, is the performance hit with this strategy? I could care less about performance on a usb stick, but if we are talking about changes that are going to affect all filesystems regardless of storage device implimentation then I'm sort of interested. eg: I wouldn't be happy trading filesystem performance for avoiding a panic that is trivial to avoid in the first place. -- Thanks, Josh Paetzel pgpmLTsui8umW.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007, Momchil Ivanov wrote: Hi, I am running FreeBSD 6.2-STABLE #11: Sat Jul 14 16:27:12 CEST 2007 and accidently unplugged the USB hub to which my external hdd together with a mouse were connected and this caused my machine to freeze for some seconds and then reboot. At that moment the hdd was mounted and I was playing music out of it. After that I tried to reproduce it :) so just plugged only the hdd directly, mounted it and started playing music files from it. When I unplugged the USB cable the same thing happened: short freeze, and then reboot. Is this expected behaviour? And is there some way to avoid the freeze and reboot? Thanks. Yes, it's expected behavior. The workaround is to not unplug mounted devices. (There's nothing special about USB here, if you unplugged an IDE drive you'd get the same behavior) -- Thanks, Josh Paetzel pgpUBWpa2fyAG.pgp Description: PGP signature
Re: removing external usb hdd without unmounting causes reboot?
On Wednesday 18 July 2007, Mark Linimon wrote: On Wed, Jul 18, 2007 at 10:05:59AM -0700, Jeremy Chadwick wrote: Bottom line here is that the kernel panics when removing a USB device that has filesystems mounted. s/USB // I also have a hard time believing that the reason it hasn't been fixed is because there isn't an easy fix. I'm under the impression it hasn't been fixed because either no one cares enough to fix it (using the workaround as a scapegoat excuse), or because the majority of people do not use USB-based storage devices. The reason is not the USB stack; the reason (IIRC) is that the FreeBSD VM was written with the default assumption that Devices Never Go Away. A large rewrite, I'm told, will be needed to fix this, and the code is convoluted and tricky. No one finds the situation acceptable; introducing the scapegoat word isn't going to win you any support. The problem is not a weekend's worth of work to fix, nor does it have anything to do with avoidance by one particular maintainer, which you apparently had encountered before. mcl Panicing really is the right thing to do with the current architecture. Not panicing when a mounted filesystem disappears runs the risk of corrupting other mounted filesystems. Mark is entirely correct, FreeBSD faces an architecture problem here in that the vm and filesystems we have today were not designed in an era when they could just disappear from a running system. The BSD way isn't to apply a quick and dirty little hack to fix the 'problem', it's to design the system properly. And this is assuming a quick and dirty hack even exists. The other problem you're running in to with UFS anyways is that there is no chance to 'unmount' the filesystem when you disconnect the drive. By the time anything has a chance to realize it's gone it's too late. Whether the disk is in the middle of a write, still has buffers to be written out, or is perfectly clean and needs to just be marked as such by the time the OS realizes any of that needs to be done the drive is no longer physically connected to the computer. What might need to happen is a redesign of the vm subsystem so that it can safely deal with mounted filesystems going away, and designing a filesystem that doesn't need to be unmounted specifically for removeable devices. Doesn't sound trivial to me. Or You can just not remove devices with mounted filesystems from your computer. -- Thanks, Josh Paetzel pgpBhbiMYM6HX.pgp Description: PGP signature
Re: is read-write nullfs safe?
On Tuesday 19 June 2007, Rong-en Fan wrote: I'm running 6.2-RELEASE, and I am wondering if using nullfs w/ rw is safe in a production environment? My impression is that ro nullfs is ok, but not rw. Is this still the case? Regards, Rong-En Fan I've been using r/w nullfs in production for ages without issue...sure you're not confusing nullfs with unionfs? -- Thanks, Josh Paetzel pgpy8sRjFZ1KN.pgp Description: PGP signature
Re: updating xorg-libraries 7.2 to 7.2.1
Shaun Branden wrote: I just updated my system from xorg-libraries 7.2 to 7.2.1 [EMAIL PROTECTED]:xorg-libraries$ portversion -v|grep xorg-libraries-7.2needs updating (port has 7.2_1) and had a little trouble with portupgrade === Cleaning for xorg-libraries-7.2_1 Read /usr/ports/UPDATING for the procedure to upgrade or install xorg 7.2. *** Error code 1 until I used export XORG_UPGRADE=yes from /usr/ports/UPDATING. Do I have to do this everytime I run portupgrade? UPDATING says: It is necessary to set the XORG_UPGRADE environment variable while updating from xorg 6.9 to 7.2. Once the upgrade is complete this is no longer be required. xorg 7.2 was installed on this system from scratch, ie no ports to start with. uname -a FreeBSD sagan.cai 6.2-STABLE FreeBSD 6.2-STABLE #0: Fri May 25 20:45:33 CST 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAGAN i386 thanks shaun -- Shaun Branden: Alchemist and Bit Bender PGP and contact details in the headers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] For right now if you want portupgrade to do anything with xorg you need to export XORG_UPGRADE -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1-RELEASE source update fails during compilation
Jason Vance wrote: I'm unable to buildworld on a brand new installation of freebsd 6.1. Almost everytime my build fails on the genattrtab.c section of cc_tools. I've tried multiple harddrives, and downloaded the source code many times. A couple of times the system has rebooted itself, once during cvsup of the source code, and again during a build. What else should I be looking for to diagnose this problem? My System: FreeBSD 6.1-RELEASE 733MHZ Intel P3 Asus pv3-4x latest bios 1006.004 Sound Blaster Live Voodoo 3 16mb GFX Card HDDs: I've tried 3 different drives, the first few tries were with 2 drives gmirror'd and then without the gmirror ( RAID 1 ) Memtest checks out ok ( Ran 5 hours 150 loops ) Here is the last few lines of everytime I've tried to compile the source. Failures likes these are almost always hardware related. If it was a software problem it would die at the same place every time. You could be suffering from overheating, bad ram (regardless of what memtest tells you) power fluctuations due to a faulty PSU, or any other number of esoteric problems. FreeBSD has this knack of not playing nicely with partially broken hardware. :) Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What is a good choice of sata-ii raid controller for freebsd?
On Friday 09 February 2007 09:15, Artem Kuchin wrote: Alexander Sabourenkov wrote: Artem Kuchin wrote: hi! I am the original poster of this thread. I have read many interesting reply during these two days. However, as i said in the original message due to certification issues i am pretty limited to INTEL controllers and i have not seen a single relevant reply about them. This is interesting. Nobody uses Intel controllers on FreeBSD or they just suck that much? If you have enough SATA ports and no need for fancy RAID levels, then my advice is to use gmirror. Hardware RAID1 buys you nothing in perfomance and reliability for a prolonged headache with drivers, bios insanity and monitoring+control tools. Hm... two points here. I, somehow, do not really believe that software raid (gmirror for example) is as reliable as hardware. I, deeply inside, believe that i might screw things very badly under some heavy load and bad timing conditions. Can't explain it. it is religious i guess, but i can be very wrong about this. However, two perfomance point: Under gmirror OS must issue two commands to write to disks and some commands to check/set mark that mirrored data is intact. Under hardware RAID OS issue sonly one command to write and no checking command, since raid controller handles this async. So, software OS raid must be slower than controller based raid anyway. Am i right here? Any benchmark data on this? As for reliability of gmirror. I just need to know how it works to see for myself that if power turned off in some racing condition gmirror will know that disk are out of sync. If it is done than gmirror must check sync of disks every read, and that mean two command for reading too, which must slow down things. Is it true? -- Artem What hardware RAID buys you over gmirror is that you can boot from it. If a drive in the mirror fails the device name available to the OS is still the same. The FreeBSD loader does not do gmirror, it boots off the raw device, and then gmirror is loaded. If the drive you are booting off of fails you have to have the BIOS set to boot from the other drive in the mirror, and then you run into 'what is the root device set to in loader.conf' issues. From a raw speed perspective on an unloaded CPU a 3.0ghz processor is probably just as fast or faster than the embedded processor on a RAID card running at a few hundred mhz. Sure, once you start talking about CPUs at full load there are advantages to off-loading stuff to a dedicated processor. -- Thanks, Josh Paetzel ___ 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
On Thursday 11 January 2007 11:51, Jack Vogel wrote: On 1/11/07, Bruce A. Mah [EMAIL PROTECTED] wrote: If memory serves me right, Jack Vogel wrote: On 1/10/07, Colin Percival [EMAIL PROTECTED] wrote: Scott T. Hildreth wrote: Does anyone know if the Release is still going to happen today? The release is not going to happen today, but will be very soon. My guess is that builds and mirroring will happen over the weekend and the release announcement will go out on Monday or Tuesday depending upon your time zone. Colin Percival You guys ROCK :) Hope this means I get a new current snapshot too? The January CURRENT snapshots have been uploaded to ftp-master. kensmith@ hasn't announced these yet, I think because he's waiting for them to make their way out to the various FTP mirror sites. Yes, our validation team sent me email this morning saying it was available :) Jack csup'd to RELENG_6_2 late last night intending to get a box from 6.1-R to 6.2-RC2 and ended up with 6.2-RELEASE. I was *so* bummed out. ;) From /usr/src/UPDATING 20070114: FreeBSD 6.2-RELEASE. I know this is all just part of the release process, but it's still somewhat amusing since it's the 12th here. ;) -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PE 1950 bce NICs revisited
On Wednesday 29 November 2006 11:33, Josh Paetzel wrote: On Wednesday 29 November 2006 10:43, Scott Long wrote: Josh Paetzel wrote: I've been using 6.1-R on a PE1950 for some time now. The stock bce driver doesn't work at all. I dug up a driver off the web (0.9.6) that worked fine with my workload (basically all TCP) but in talking to Scott I discovered that UDP traffic was a problem for this driver. Some time ago I upgraded to the driver in -STABLE. This driver also appears to work fine, but about once a day I get the following: Nov 29 01:16:47 server2 kernel: bce1: /usr/src/sys/dev/bce/if_bce.c(5000): Watch dog timeout occurred, resetting! Nov 29 01:16:47 server2 kernel: bce1: link state changed to DOWN Nov 29 01:16:48 server2 kernel: bce1: link state changed to UP Pretty minor complaint, as it doesn't really affect the operation of the box, but I suppose it's a sign that there's still some work to be done. $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6 2006/10/24 As I write this I see there has been some further work on the driver, so I think I'll upgrade it and see what happens. It's possible that rev 1.2.2.6 will fix what you're seeing. If not, then it might be the general issue with the watchdog framework being unreliable that we addressed with the em driver. If so, then it's mostly harmless. Scott The string I pasted is what I was using. Rebuilt using: /repoman/r/ncvs/src/sys/dev/bce/if_bce.c,v 1.2.2.6.2.1 this morning. I'll give it a few days and see how it's working. I think either way it's harmless. It happens about once a day, and strangely enough it's almost always in periods of very low load. Well, since the upgrade the NIC hasn't reset, so I'd say we have a winner. Thanks for all the work on this thing. :) -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Dell PE 1950 bce NICs revisited
I've been using 6.1-R on a PE1950 for some time now. The stock bce driver doesn't work at all. I dug up a driver off the web (0.9.6) that worked fine with my workload (basically all TCP) but in talking to Scott I discovered that UDP traffic was a problem for this driver. Some time ago I upgraded to the driver in -STABLE. This driver also appears to work fine, but about once a day I get the following: Nov 29 01:16:47 server2 kernel: bce1: /usr/src/sys/dev/bce/if_bce.c(5000): Watch dog timeout occurred, resetting! Nov 29 01:16:47 server2 kernel: bce1: link state changed to DOWN Nov 29 01:16:48 server2 kernel: bce1: link state changed to UP Pretty minor complaint, as it doesn't really affect the operation of the box, but I suppose it's a sign that there's still some work to be done. $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6 2006/10/24 As I write this I see there has been some further work on the driver, so I think I'll upgrade it and see what happens. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell PE 1950 bce NICs revisited
On Wednesday 29 November 2006 10:43, Scott Long wrote: Josh Paetzel wrote: I've been using 6.1-R on a PE1950 for some time now. The stock bce driver doesn't work at all. I dug up a driver off the web (0.9.6) that worked fine with my workload (basically all TCP) but in talking to Scott I discovered that UDP traffic was a problem for this driver. Some time ago I upgraded to the driver in -STABLE. This driver also appears to work fine, but about once a day I get the following: Nov 29 01:16:47 server2 kernel: bce1: /usr/src/sys/dev/bce/if_bce.c(5000): Watch dog timeout occurred, resetting! Nov 29 01:16:47 server2 kernel: bce1: link state changed to DOWN Nov 29 01:16:48 server2 kernel: bce1: link state changed to UP Pretty minor complaint, as it doesn't really affect the operation of the box, but I suppose it's a sign that there's still some work to be done. $FreeBSD: src/sys/dev/bce/if_bce.c,v 1.2.2.6 2006/10/24 As I write this I see there has been some further work on the driver, so I think I'll upgrade it and see what happens. It's possible that rev 1.2.2.6 will fix what you're seeing. If not, then it might be the general issue with the watchdog framework being unreliable that we addressed with the em driver. If so, then it's mostly harmless. Scott The string I pasted is what I was using. Rebuilt using: /repoman/r/ncvs/src/sys/dev/bce/if_bce.c,v 1.2.2.6.2.1 this morning. I'll give it a few days and see how it's working. I think either way it's harmless. It happens about once a day, and strangely enough it's almost always in periods of very low load. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still have BCE driver issues (dell pe 1950) and NFS
On Tuesday 07 November 2006 03:30, Fredrik Widlund wrote: Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott I know I've brought this up before, but I have a PE1950 with a pair of bce nics that get pounded on 24/7. I've been using 6.1-R with the 0.9.6 version of the bce driver for a couple of months now. The driver is available here: http://yogurt.org/FreeBSD/if_bce.c I've emailed the author of the driver and I've at least mentioned it to Scott once but I really can't understand why we don't just import this driver into the tree. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Still have BCE driver issues (dell pe 1950) and NFS
On Tuesday 07 November 2006 10:10, Scott Long wrote: Josh Paetzel wrote: On Tuesday 07 November 2006 03:30, Fredrik Widlund wrote: Hi, Will a fix/this fix be part of the 6.2 Release? We will be relying heavily on fbsd6.2 and pe1950 and are worried about the BCE stability? Kind regards, Fredrik Widlund Scott Long wrote: Olivier Mueller wrote: Le 7 nov. 06 à 01:15, Scott Long a écrit : Olivier Mueller wrote: NFS Server: dell poweredge 1950, with the 1.2.2.6 version of if_bce.c: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.6 mem - Start a directory listing on it: immediate (network) crash of the NFS server. (reproduced 3 times) Do the following, then retry your test: ifconfig bce0 -txcsum Oh, this way it looks much better, thanks. Directory listing was fine, and copying files during 2-3 minutes over NFS worked as well. More tests will follow tomorrow. Next step? :-) Should I put that command somewhere in my init scripts, or even directly in rc.conf, or wait for a new if_bce0.c version? I am available for any other PE1950-related tests if this may help. Regards, Olivier Change /sys/dev/bce/if_bcereg.h so that BCE_IF_HWASSIST is defined to 0. Then recompile. Scott I know I've brought this up before, but I have a PE1950 with a pair of bce nics that get pounded on 24/7. I've been using 6.1-R with the 0.9.6 version of the bce driver for a couple of months now. The driver is available here: http://yogurt.org/FreeBSD/if_bce.c I've emailed the author of the driver and I've at least mentioned it to Scott once but I really can't understand why we don't just import this driver into the tree. What you just posted is exactly what committed to CVS for 7-CURRENT and 6-STABLE, and what was proven to break down under moderate to heavy UDP traffic. I don't doubt that your servers have a load that doesn't trigger the problem, but if you're curious I can send you a couple of very simple test cases that will cause your driver to panic and your network interface to wedge. Scott My bad. Thanks for clearing this up. (In my case pretty much all of the traffic is TCP which I guess would explain why it's working for me) -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: When will the new BCE driver in HEAD be incorporated into RELENG_6?
On Wednesday 25 October 2006 19:24, Scott Long wrote: Sam Baskinger wrote: Bill Moran wrote: [snip] The driver from HEAD (if_bce.c 1.17) is looking much better - thanks Scott! We couldn't trigger this bug using UDP NFS mounts. Neither could we trigger it with multiple simultaneous TCP connections. I'm seeing similar improvement. I've been testing the new version since I came in this morning (About 2.5 hours so far), with no failures. [snip] Adding to the excitement, our band of attack squirrels haven't been able to bring down our 2950 yet with this one. We are using the if_bce.c from the HEAD w/ a small chunk about vlans commented out (for any wondering). We're trying outbound UDP_STREAM tests w/ netperf of big and small payloads to a machine on the same 100Mb switch. Nothing fancy, but what we could once crash in seconds now hangs tough till the end of the test. Sam Excellent. RELENG_6 was updated with the changes a few days ago. Scott I tried putting 6.1-R on a PE1950 some time ago and the bce NIC wouldn't work at all. The driver version striing was 0.9.5. I found a newer version 0.9.6 on the web and that has been working just fine for me under pretty heavy loads. Is this new driver you're talking about different than the newer version I found on the web? -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: partioning failed
On Sunday 22 October 2006 13:10, Freek Nossin wrote: Hello, I've run into some problems while I was trying to install freebsd 6.1 (i386). When I've finished partitioning and the installer wants to write the partition data to disk, it fails to do so. I used the typical settings, ie one slice on the disc, with a default partitioning scheme (except that I merged the /tmp with /var). The installer reports: unable to find device node for /dev/ad0s1b. I tried to use another hard disk, which resulted in the same error. On VTY1 I got the following messages: ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=63 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=63 ad0: FAILURE - READ_DMA status=51ready, dsc, error error=84ICRC, aborted LBA=63 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=0 ad0: FAILURE - READ_DMA status=51ready, dsc, error error=84ICRC, abortedLBA=0 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64 ad0: FAILURE - READ_DMA status=51ready, dsc, error error=84ICRC, aborted LBA=64 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=63 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=63 ad0: FAILURE - READ_DMA status=51ready, dsc, error error=84ICRC, aborted LBA=63 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=63 ad0: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=63 ad0: FAILURE - READ_DMA status=51ready, dsc, error error=84ICRC, aborted LBA=63 System information: Athlon XP 1700+ / 786 MB Asus A7V266 (bios v1.11) Maxtor 60 GB Has anyone any suggestions? Thanks, Freek I'd try a different cable for the drive. If that doesn't fix it the controller on the motherboard is probably bad. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell 1950 does not properly respond to reboot and shutdown -p
On Wednesday 04 October 2006 12:42, Guy Helmer wrote: Bill Moran wrote: In response to Guy Helmer [EMAIL PROTECTED]: Bill Moran wrote: A reboot causes the OS to halt, but the hardware just sits there on the shutdown screen. A shutdown -p does the same. Other ACPIish stuff seems to work as advertised. (i.e. hitting the power button cleanly shuts down the OS) I'm posting this to stable@, but the same behaviour occurs with FreeBSD 6.1-RELEASE as well. Does setting hw.acpi.handle_reboot to 1 via sysctl help? If set, this variable will use ACPI to perform the reboot action via the reset register instead of using the keyboard controller or a triple fault to reboot. I manually changed that setting and the behaviour did not change. Does the setting need set before the kernel boots? The value of that parameter is checked at runtime so you should be able to set it while the system is running. Do you get an ACPI reset failed message on the console? Guy For what it's worth I have 6.1-R on a 1950 and reboot works just fine. Haven't tried the shutdown -p command. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: snd_emu10k1 driver
On Wednesday 27 September 2006 11:55, Bill Blue wrote: Hi, Is this driver known to be 100% working? I'm running stable 6.2 p6 right now and have this device driver installed (device sound and device snd_emu10k1 compiled into the kernel) for use with a Creative Live! card. Audio outputs work correctly, and the various players will produce audio as expected via the PCM control. Line input works as well. 'mixer' works as does KDE's kmix (they track each other). I've also installed the driver via kldload at boot, but it makes no difference. I'm unable to successfully record audio from the line input of this Creative Live! card. Either using the generic /dev/dsp as the recording source, or individual devices /dev/dsp0.0 and up, dspW0.0 and up, or dspr0.4/5. There's just no audio there. For the recording software I've used Krec, ffmpeg, darkice and streamTranscoder (the latter two feeding an icecast server). 'mixer' has its recording device (=rec) set to line in, and I'm feeding audio to line in (analog) and spdif in (digital). There's no problem monitoring the 'line in' buss on the outputs, but there's no audio on the record output device. dmesg shows the driver being installed, and cat /dev/sndstat shows it is active on pcm0. If I cat /dev/sndstat with a higher verbosity (set with sysctrl) it shows that the record devices should be dsp0.4 and dsp0.5, line and mic in respectively. The man page for snd_emu10k1 says the recording devices should be dspr0.4 and dspr0.5 but only if they're driving a codec directly -- I'm not sure what that means exactly. There's no sound daemons like esound or artsd running during these tests. The ports being tested as an input device seem to open correctly and show up as read devices in fstat. I've also tried the snd_emu10kx driver to no avail. Has anyone had experience using the Live! sound card and these drivers? And if so, is recording correctly supported? I have other sound cards available, but none of them seem to have driver support in FreeBSD. One is a Delta (Midiman) 410 with an ICE1712 chip, and the other is a Turtle Beach TB400 (not a Santa Cruz) with Vortex AU8830A2 chip. Both cards have analog and digital ins and outs. Anyone with insight on any of this? --Bill I thought I'd try this out since I have a SB Live! 5.1, use the snd_emu10k1 driver and don't run artsd or esound but when I start krec the record button is greyed out! Using ffmpeg and the /dev/dsp device I was able to record just fine from the mic port on the card. I'm running 6.1-R-p6 -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [AMD64-SMP] I can't get my cpus working at 100%
On Thursday 24 August 2006 13:09, Laurent C wrote: Hello all, I can't get my athlon x2 processor working at 100% on cpu-intensive apps. I've made some tests with john --test and transcode, wich are both multithreaded apps. For example if I launch transcode it takes between 50% and 55% cpu (on top), and if I launch a second transcode session on another file, the total cpu used on top is 100%, without lower the speed of the first transcode session. The same behavior occurs with john. A single john --test give me some speed results, and the same command with a transcode or second john --test give me the same speed results but now with 100% cpu used. I made a portupgrade -auf just after building and installing my SMP kernel and World, to be sure all is up-to-date. So it's seems it's not a top output problem, but a real underuse of the computing power. %uname -a FreeBSD wks02.chez.oim 6.1-STABLE FreeBSD 6.1-STABLE #0: Thu Aug 17 18:47:31 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/WKS02_SMP amd64 Does anyone could explain me what's happening with my system ? An application that is not written to take advantage of a multi-cpu system is unable to max out more than one CPU at a time. top isn't really SMP 'aware' so in a dual CPU system something that is using 50% of the CPU is in reality maxing one CPU. This is a bit over-simplified because the process will bounce between the two CPUs but it will never execute on more than one at a time. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVIDIA 6600GT Freeze
On Thursday 20 July 2006 06:51, Nealie wrote: I have a problem with my system freezing when using an NVIDIA video card using the nvidia-driver port. All seems to work fine for a while but then the system freezes and won't even reply to a ping. This can happen regardless of whether I use openGL or not. Everything works fine using the nv driver, so it doesn't seem to be a hardware problem. My setup is as follows: uname: FreeBSD server.home 6.1-STABLE FreeBSD 6.1-STABLE #0: Wed Jul 19 11:19:16 CEST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SERVER i386 AGP NVIDIA 6600GT installed on an MSI K8T Neo-F V2.09 motherboard (VIA K8T800 Pro chipset) with an AMD Athlon 64 3500+ CPU. The NVIDIA driver is installed as per the instructions, with agp and dri removed from the kernel in order to use the NVIDIA agp interface, even though the sysctl settings suggest otherwise. If anyone has any ideas about this problem I'd be very grateful. This probably isn't very helpful but I have nearly the exact same setup and it works fine. The only differences I see is that I'm running 6.1-RELEASE and my motherboard is an asus based on the K8T800 chipset. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.3-STABLE makes terrible router/gateway?
On Thursday 23 December 2004 18:24, Marc G. Fournier wrote: Due to limitations in the standard 'linksys/dlink/netgear' routers, as far as firewalls are concerned, last night I setup one of my 5.3-STABLE boxes as being the gateway ... unless I've set something up wrong, 'blows chunks' is what comes to mind :( The machine: CPU: Intel(R) Pentium(R) 4 CPU 2.00GHz (1995.01-MHz 686-class CPU) real memory = 536805376 (511 MB) avail memory = 519823360 (495 MB) Two controllers: fxp0: Intel 82550 Pro/100 Ethernet port 0xd000-0xd03f mem 0xfa00-0xfa01,0xfa021000-0xfa021fff irq 19 at device 9.0 on pci2 miibus0: MII bus on fxp0 fxp0: Ethernet address: 00:02:b3:ee:da:3e de0: Digital 21140A Fast Ethernet port 0xd100-0xd17f mem 0xfa02-0xfa02007f irq 20 at device 11.0 on pci2 de0: [GIANT-LOCKED] de0: SMC 9332BDT 21140A [10-100Mb/s] pass 2.0 de0: enabling 10baseT port de0: Ethernet address: 00:00:c0:b9:e1:f9 Firewall rules are bare minimal: # ipfw list 00050 divert 8668 ip from any to any via de0 01000 allow ip from any to any 65535 deny ip from any to any And natd is running with: -redirect_port tcp 192.168.1.4:22 22 -n de0 I run interactive sessions to my remote/colo servers ... and I can *see* the difference between the Linksys and the FreeBSD box, as far as being able to get work done is concerned ... My only thought is that its the de controller itself ... when I tried to compile it into the kernel, vs using it as a module, it caused the server itself to crash just before it did the PRNG stuff (just after mounting root) ... loading it as a module works fine though ... is there a problem with the de driver itself, or 5.x, that needs to be looked into? thanks ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 Is it possible that there is a 10/100 or duplex mismatch on the NICs? I use a 200mhz Ppro w/ the fxp0 and sis0 drivers to nat/firewall a 3mbps connection so I would think your hardware is sufficient to do the job. -- Thanks, Josh Paetzel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Multiple Network Cards
On Wednesday 01 December 2004 11:50, Joan Picanyol wrote: * munn [EMAIL PROTECTED] [20041201 12:10]: I want to add a second network card to a FreeBSD 4.10p4 box. The first card has an address 192.168.123.99 (xl0). The second card has the address 192.168.123.98 (fpx0). When I reboot the machine and do an ifconfig -a, I see fpx0 with the address 192.168.123.98 but xl0 now has options=1(RXCSUM) where the ip address 192.168.123.99 would normally be. What am I doing wrong? Nothing? xl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=9RXCSUM,VLAN_MTU inet 192.168.124.9 netmask 0xff00 broadcast 192.168.124.255 ether 00:e0:81:27:cb:3b media: Ethernet autoselect (100baseTX full-duplex) status: active Or do you actually have a problem? qvb Maybe this is (or should be) a FAQ: I don't think you can put two NICs on the same subnet with FreeBSD. Please correct me if I'm wrong, especially if you can post a inconfig backing you up. ::D -- Thanks, Josh Paetzel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildworld problem woithout the -j4
On Sat, Sep 07, 2002 at 05:45:48PM -0400, Gene Bomgardner wrote: OK. The problem becomes clearer without the threads. I see what caused buildworld to terminate but I'm not sure what to do about it. Make stops on an error when it tries to delete a directory using rm. Output (last several lines) follows: Again, any help is appreciated. === gnu/usr.bin/sort rm -f sort sort.o error.o version.o long-options.o getopt.o getopt1.o xstrtod.o sort.1.gz sort.1.cat.gz rm -f .depend /usr/src/gnu/usr.bin/sort/GPATH /usr/src/gnu/usr.bin/sort/GRTAGS /usr/src/gnu/usr.bin/sort/GSYMS /usr/src/gnu/usr.bin/sort/GTAGS === gnu/usr.bin/tar rm -f tar buffer.o create.o diffarch.o extract.o getdate.o getoldopt.o getopt.o getopt1.o gnu.o list.o mangle.o names.o port.o prepend_args.o rtapelib.o tar.o update.o version.o tar.1.gz tar.1.cat.gz getdate.c rm: tar: is a directory *** Error code 1 Stop in /usr/src/gnu/usr.bin/tar. *** Error code 1 Stop in /usr/src/gnu/usr.bin/tar. *** Error code 1 Stop in /usr/src/gnu/usr.bin. *** Error code 1 Stop in /usr/src/gnu. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 God's Blessings, Gene make -j4 buildworld usually bombs on my SMP boxes. Have you tried rm -rf /usr/obj and restarting the build? Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Chipset SiS735 / NIC SiS 900 - PR kern/30836
On Wed, Jan 09, 2002 at 10:47:28PM -0500, Dan Langille wrote: Hi folks, It appears I am not the first to buy a K7S5A motherboard (an SiS 735 chipset) with integrated NIC. I can't get my NIC to work either. Bill: I'm ready to help with this. If you so wish, I can give you a login on the box. cheers. -- Dan Langille The FreeBSD Diary - http://freebsddiary.org/ - practical examples I can do the same as well. I've got the same motherboard, and can't get the NIC to work. Device probe and attach 6 is what I get. It picks everything up, but gives the MAC address as 00:00:00:00:00 Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Reproducable system hangs in -STABLE
On Tue, Jan 08, 2002 at 12:58:58PM -0800, Doug White wrote: On Mon, 7 Jan 2002, Josh Paetzel wrote: While running two copies of dnetc, running xmms will hang my system with a hard lock up. I think I've seen this appear before for non-priority problems too though ... hm ... This is the classic priority inversion problem. How are you starting your dnetc's? They are starting at boot time from the script that the port installs into /usr/local/etc/rc.d Make sure you are NOT nice(1)ing dnetc OR xmms. nice -20 or idprio'ing dnetc will cause an instant lockup. I'm not nicing the processes manually at all. The script gives dnetc a nice value of 20. What happens if you run only one dnetc? Hmm, evidentally you didn't see or don't remember my original post. I can only reproduce this lockup ONE way. I need to have 2 dnetc's running, and one xmms. I can't reproduce it using setiathome instead of dnetc, or mpg123 instead of xmms. I guess I'm pretty lucky, as I don't NEED two dnetc's running, so the workaround is simple and painless. I was just hoping to get some light shed on the situation. Josh Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
My first 4.5-PRERELEASE Issue
I cvsupped last night to 4.5-PRERELEASE uname -a FreeBSD twincat.vladsempire.net 4.5-PRERELEASE FreeBSD 4.5-PRERELEASE #1: Thu Dec 20 22:44:31 GMT 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TWINCAT i386 I'm running a dual p3-600b/133 on a Tyan Tiger 133 with a half a gig of pc133 ram, a geforce2 gts ddr, and a linksys LNE100TX network card. My modem is a USR/3Com 56k external. Ever since I made world/kernel I've been getting small hangs in my internet connection. These messages have started appearing in my logs as well: sio0: 1 more silo overflow (total 1257) sio0: 1 more silo overflow (total 1258) sio0: 1 more silo overflow (total 1259) sio0: 1 more silo overflow (total 1260) I seem to get an overflow every 30 seconds or so. It hasn't really hampered my ability to download anything. I pulled down a 30 meg file overnight that averaged 5K/sec. I watched a download today, and I get my typical 5.5K/sec, then it will stop receiving for a second or two, then fire back up again. I'd attach a dmesg, but it's been totally overwritten by these silo overflows, and I'm not at a point where I can reboot. I'll probably send a pr with more info, but I thought I'd get this out there right away. Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: X and non-X graphics in 4.4-STABLE: system hangs.
On Sun, Dec 02, 2001 at 12:28:16AM +0700, Eugene Grosbein wrote: On Sat, Dec 01, 2001 at 11:30:21PM +0700, Eugene Grosbein wrote: I have found a method to hang recent 4.4-STABLE and this is 100% reproducable with my hardware. There is also much simplier way to demonstrate this: 1. Build kernel with options VESA and options SC_PIXEL_MODE. 2. boot and login at vty0 (no need to login as root) 3. vidcontrol VESA_800x600 4. swutdown -r +2 # to make shure that kernel will be dead too 4. startx 5. make shure that X started and switch to vty0 6. switch back to X and system hangs forever, it will not reboot. Anybody with XFree 4.1.0 and S3 Trio 3D can confirm this? This becames really annoying. I'm using a S3 Virge/DX 86C375 as a secondary adapter in X. Lately about half the time when I start X from the console it completely hangs my system. I am not using VESA console modes. I'm running -STABLE from a couple of days ago, but I was experiencing this before that. Also using XFree 4.1.0_6 Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: decl.c error in stable buildworld
On Thursday 19 July 2001 00:09, Armando Cerna wrote: Hello, I am sending you this email to report an error I got when doing a make buildworld after a cvsup 2 hours ago from cvsup9.freebsd.org. The error is as follows /usr/src/usr.bin/xlint/lint1/decl.c:1784: union has no member named `_v_quad' *** Error code 1 Thanks for all the great work Armando I think those guys might've gotten you a little worked up about this. I cvsupped right after you said you had this error and make buildwrold completed fine on my box. Friar_Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: decl.c error in stable buildworld
On Thursday 19 July 2001 02:07, Josh Paetzel wrote: On Thursday 19 July 2001 00:09, Armando Cerna wrote: Hello, I am sending you this email to report an error I got when doing a make buildworld after a cvsup 2 hours ago from cvsup9.freebsd.org. The error is as follows /usr/src/usr.bin/xlint/lint1/decl.c:1784: union has no member named `_v_quad' *** Error code 1 Thanks for all the great work Armando I think those guys might've gotten you a little worked up about this. I cvsupped right after you said you had this error and make buildwrold completed fine on my box. Friar_Josh Well, I hate to eat crow here, but I was looking at the wrong xterm when I said that. It turns out that make buildworld died in the exact same way. 4.3-STABLE from about midnight 7-18-01. Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Regarding New FreeBSD BenchMark From Sysadmin Mag (left out a fiew tuning options)
On Friday 13 July 2001 21:26, Juha Saarinen wrote: ::camcontrol modepage da0 -m 0x08 -e -P 3 su-2.05# camcontrol modepage da0 -m 0x08 -e -P 3 camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist su-2.05# camcontrol devlist IBM DDYS-T36950N S93Eat scbus0 target 0 lun 0 (da0) IBM DDYS-T36950N S93Eat scbus0 target 1 lun 0 (da1) # camcontrol inquiry da0 -S camcontrol: cam_lookup_pass: CAMGETPASSTHRU ioctl failed cam_lookup_pass: No such file or directory cam_lookup_pass: either the pass driver isn't in your kernel cam_lookup_pass: or da0 doesn't exist Am I missing some funky kernel option here? -- Juha Well, look at what it says. You either don't have the funky pass driver in your kernel, or you don't have any SCSI drives. Josh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
