From ivoras at freebsd.org Mon Nov 3 03:43:53 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Mon Nov 3 03:44:00 2008 Subject: Benchmark tools: was Areca vs ZFS In-Reply-To: References: Message-ID: grarpamp wrote: > Don't randomio, blogbench [and bonnie] pretty much do a subset of > what iozone does? > > iozone.org: > Read, write, re-read, re-write, read backwards, read strided, > fread, fwrite, random read/write, pread/pwrite variants Very probably yes. Though in my experience iozone is much harder to configure / run right. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081103/7d846738/signature.pgp From fbsd at dannysplace.net Mon Nov 3 22:12:40 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Mon Nov 3 22:12:47 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> Message-ID: <490FE7CD.6020806@dannysplace.net> Ivan Voras wrote: > Danny Carroll wrote: > >> Any thoughts on this setup as well as advice on what options to give to >> bonnie++ (or suggestions on another disk testing package) are very welcome. > > I'd suggest two more tests, because bonnie++ won't tell you the > performance of random IO and file system overhead: > > 1) randomIO: http://arctic.org/~dean/randomio/ > 2) blogbench: http://www.pureftpd.org/project/blogbench > > Be sure to select appropriate parameters for both (and the same > parameters in every test so they can be compared) and study how they are > used so you don't, for example, benchmark your system drive instead of > the array :) ! (try not to put the system on the array - use the array > only for benchmarks). > > For example, use blogbench "-c 30 -i 20 -r 40 -W 5 -w 5" to simulate a > read-mostly environment. > Apologies if this comes twice. Thanks for the info. I'll put together a few tests together with the test scenarios already discussed. On another note, slightly OT, I've been tuning the system a little bit and I already have had some gains. Apart from the ZFS tuning already mentioned, I have also done a few other things. - Forced 1000baseTX mode on the Nic - Experimented with jumbo frames and device polling. - Tuned a few network IO parameters. These really have no relevance to the tests I want to do (Areca Vs. ZFS) but it was interesting to me to note the following: - Device polling resulted in a performance degradation. It's possible that I did not correctly tune the device polling sysctl parameters well, so I will revisit this. - Tuning sysctl params gave the best results I've been able to double my Samba throughput. - Jumbo Frames had no noticeable effect. - I have seen sustained 130Mb reads from ZFS: capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- bigarray 1.29T 3.25T 1.10K 0 140M 0 bigarray 1.29T 3.25T 1.00K 0 128M 0 bigarray 1.29T 3.25T 945 0 118M 0 bigarray 1.29T 3.25T 1.05K 0 135M 0 bigarray 1.29T 3.25T 1.01K 0 129M 0 bigarray 1.29T 3.25T 994 0 124M 0 ad4 ad6 ad8 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0.00 0 0.00 65.90 375 24.10 63.74 387 24.08 0 0 19 2 78 0.00 0 0.00 66.36 357 23.16 63.93 370 23.11 0 0 23 2 75 16.00 0 0.00 64.84 387 24.51 63.79 389 24.20 0 0 23 2 75 16.00 2 0.03 68.09 407 27.04 64.98 409 25.98 0 0 28 2 70 Notes: ad4 is the system drive, and not part of ZFS. I forgot to add the options for the rest of the array drives (5 in total) These figures are not measured along the same time frame. I'm curious if the ~130M figure shown above is bandwidth from the array or a total of all the drives. In other words, does it include reading the parity information? I think it does not since if I look at iostat figures and add up all of the drives it is greater than that reported by zfs by a factor of 5/4 (100M in Zfs iostat = 5 x 25Mb in standard iostat). If so then that is probably the most I will see coming off the drives during a network transfer given that 130Mb/s should already be over the limit of Gigabit ethernet. Lastly, The windows client which performed these tests was measuring local bandwidth at about 30-50Mb/s. I believe this figure to be incorrect (given how much I transferred in X seconds...) Edit: Scratch that, I can't do math. It was indeed transferring at about 50M/sec. I wonder why the IOstat measurements showed more IO than 50M/sec...? -D From danny at dannysplace.net Mon Nov 3 22:19:04 2008 From: danny at dannysplace.net (Danny Carroll) Date: Mon Nov 3 22:19:12 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> Message-ID: <490FE404.2000308@dannysplace.net> Ivan Voras wrote: > Danny Carroll wrote: > I'd suggest two more tests, because bonnie++ won't tell you the > performance of random IO and file system overhead: > > 1) randomIO: http://arctic.org/~dean/randomio/ > 2) blogbench: http://www.pureftpd.org/project/blogbench > > Be sure to select appropriate parameters for both (and the same > parameters in every test so they can be compared) and study how they are > used so you don't, for example, benchmark your system drive instead of > the array :) ! (try not to put the system on the array - use the array > only for benchmarks). > > For example, use blogbench "-c 30 -i 20 -r 40 -W 5 -w 5" to simulate a > read-mostly environment. Thanks for the info. I'll put together a few tests together with the test scenarios already discussed. On another note, slightly OT, I've been tuning the system a little bit and I already have had some gains. Apart from the ZFS tuning already mentioned, I have also done a few other things. - Forced 1000baseTX mode on the Nic - Experimented with jumbo frames and device polling. - Tuned a few network IO parameters. These really have no relevance to the tests I want to do (Areca Vs. ZFS) but it was interesting to me to note the following: - Device polling resulted in a performance degradation. It's possible that I did not correctly tune the device polling sysctl parameters well, so I will revisit this. - Tuning sysctl params gave the best results I've been able to double my Samba throughput. - Jumbo Frames had no noticeable effect. - I have seen sustained 130Mb reads from ZFS: capacity operations bandwidth pool used avail read write read write ---------- ----- ----- ----- ----- ----- ----- bigarray 1.29T 3.25T 1.10K 0 140M 0 bigarray 1.29T 3.25T 1.00K 0 128M 0 bigarray 1.29T 3.25T 945 0 118M 0 bigarray 1.29T 3.25T 1.05K 0 135M 0 bigarray 1.29T 3.25T 1.01K 0 129M 0 bigarray 1.29T 3.25T 994 0 124M 0 ad4 ad6 ad8 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0.00 0 0.00 65.90 375 24.10 63.74 387 24.08 0 0 19 2 78 0.00 0 0.00 66.36 357 23.16 63.93 370 23.11 0 0 23 2 75 16.00 0 0.00 64.84 387 24.51 63.79 389 24.20 0 0 23 2 75 16.00 2 0.03 68.09 407 27.04 64.98 409 25.98 0 0 28 2 70 Notes: ad4 is the system drive, and not part of ZFS. I forgot to add the options for the rest of the array drives (5 in total) These figures are not measured along the same time frame. I'm curious if the ~130M figure shown above is bandwidth from the array or a total of all the drives. In other words, does it include reading the parity information? I think it does not since if I look at iostat figures and add up all of the drives it is greater than that reported by zfs by a factor of 5/4 (100M in Zfs iostat = 5 x 25Mb in standard iostat). If so then that is probably the most I will see coming off the drives during a network transfer given that 130Mb/s should already be over the limit of Gigabit ethernet. Lastly, The windows client which performed these tests was measuring local bandwidth at about 30-50Mb/s. I believe this figure to be incorrect (given how much I transferred in X seconds...) -D From olihc17 at yahoo.com Mon Nov 3 23:32:02 2008 From: olihc17 at yahoo.com (chilo) Date: Tue Nov 4 04:22:24 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit Message-ID: <967012.89519.qm@web53803.mail.re2.yahoo.com> Hi guys I'm new when it comes to using Freebsd but can you recommend me a motherboard(s) that will support Freebsd 7.0? It will have at least RAID 1 configuration with full driver support. I'm planning to install Freebsd to a clone PC so that I can continue my progress/self training. Thank you very much. From koitsu at FreeBSD.org Tue Nov 4 04:26:24 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Nov 4 04:26:31 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit In-Reply-To: <967012.89519.qm@web53803.mail.re2.yahoo.com> References: <967012.89519.qm@web53803.mail.re2.yahoo.com> Message-ID: <20081104122622.GA47582@icarus.home.lan> On Mon, Nov 03, 2008 at 11:05:19PM -0800, chilo wrote: > Hi guys I'm new when it comes to using Freebsd but can you recommend > me a motherboard(s) that will support Freebsd 7.0? It will have at > least RAID 1 configuration with full driver support. I'm planning to > install Freebsd to a clone PC so that I can continue my progress/self > training. Thank you very much. Most consumer motherboards will work. However, with regards to "RAID 1 configuration", what are you planning on using for RAID 1? A RAID controller, or something like gmirror(8) which is software/OS-based RAID in FreeBSD? (Most people will strongly recommend using software/OS-based RAID, for a lot of good reasons.) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From deischen at freebsd.org Tue Nov 4 06:53:46 2008 From: deischen at freebsd.org (Daniel Eischen) Date: Tue Nov 4 06:53:53 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit In-Reply-To: <20081104122622.GA47582@icarus.home.lan> References: <967012.89519.qm@web53803.mail.re2.yahoo.com> <20081104122622.GA47582@icarus.home.lan> Message-ID: On Tue, 4 Nov 2008, Jeremy Chadwick wrote: > On Mon, Nov 03, 2008 at 11:05:19PM -0800, chilo wrote: >> Hi guys I'm new when it comes to using Freebsd but can you recommend >> me a motherboard(s) that will support Freebsd 7.0? It will have at >> least RAID 1 configuration with full driver support. I'm planning to >> install Freebsd to a clone PC so that I can continue my progress/self >> training. Thank you very much. > > Most consumer motherboards will work. > > However, with regards to "RAID 1 configuration", what are you planning > on using for RAID 1? A RAID controller, or something like gmirror(8) > which is software/OS-based RAID in FreeBSD? (Most people will strongly > recommend using software/OS-based RAID, for a lot of good reasons.) I'm in the market for a decent motherboard also. Been monitoring slickdeals lately - newegg seems to have specials every now and then on the ASUS P5Q Pro. The reviews I've read seem pretty positive on this board. Anyone with any experience with this board? -- DE From koitsu at FreeBSD.org Tue Nov 4 07:03:53 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Nov 4 07:03:59 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit In-Reply-To: References: <967012.89519.qm@web53803.mail.re2.yahoo.com> <20081104122622.GA47582@icarus.home.lan> Message-ID: <20081104150351.GA50595@icarus.home.lan> On Tue, Nov 04, 2008 at 09:29:15AM -0500, Daniel Eischen wrote: > On Tue, 4 Nov 2008, Jeremy Chadwick wrote: > >> On Mon, Nov 03, 2008 at 11:05:19PM -0800, chilo wrote: >>> Hi guys I'm new when it comes to using Freebsd but can you recommend >>> me a motherboard(s) that will support Freebsd 7.0? It will have at >>> least RAID 1 configuration with full driver support. I'm planning to >>> install Freebsd to a clone PC so that I can continue my progress/self >>> training. Thank you very much. >> >> Most consumer motherboards will work. >> >> However, with regards to "RAID 1 configuration", what are you planning >> on using for RAID 1? A RAID controller, or something like gmirror(8) >> which is software/OS-based RAID in FreeBSD? (Most people will strongly >> recommend using software/OS-based RAID, for a lot of good reasons.) > > I'm in the market for a decent motherboard also. Been monitoring > slickdeals lately - newegg seems to have specials every now and > then on the ASUS P5Q Pro. The reviews I've read seem pretty > positive on this board. Anyone with any experience with this > board? Yes, there are some of us in the FreeBSD community who have experience with the P5Q series. The first issue you'll run into is lack of Ethernet support on FreeBSD. I've worked with Yong-Hyeon PYUN on this, sending him a new P5Q SE motherboard, and he was able to develop a driver for it (it is in no way optimised for speed, but it does work). The driver is not part of the FreeBSD source code yet. See my "Networking" section here: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues If you want the driver, Yong-Hyeon can provide it. I've CC'd him here. The second issue you'll run into, at least on the P5Q SE, is a 10-15 second delay when enabling AHCI mode in the BIOS (for the Intel ICH). Machine will POST, then sit there for 10-15 seconds with a blinking cursor before booting any disk (and after that, works fine). Switch back to Enhanced mode and the problem disappears. I find this very odd, as no other ICH-based AHCI system I have behaves this way; very likely a BIOS bug/problem. Note: despite owning a P5Q SE board, I do not use it for FreeBSD (I run Windows on my desktops, and FreeBSD on my servers). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From patpro at patpro.net Tue Nov 4 07:25:42 2008 From: patpro at patpro.net (Patrick Proniewski) Date: Tue Nov 4 07:25:48 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit In-Reply-To: References: <967012.89519.qm@web53803.mail.re2.yahoo.com> <20081104122622.GA47582@icarus.home.lan> Message-ID: <340A39B4-BD0F-4FD0-AE7D-46A82A701B4B@patpro.net> On 4 nov. 08, at 15:29, Daniel Eischen wrote: > I'm in the market for a decent motherboard also. Been monitoring > slickdeals lately - newegg seems to have specials every now and > then on the ASUS P5Q Pro. The reviews I've read seem pretty > positive on this board. Anyone with any experience with this > board? I don't know about onboard RAID 1, or about ASUS specifically, but I do know that TYAN and SuperMicro make very nice motherboards with great FreeBSD support. I own a 2 years old TYAN Tiger i7520SD sporting 2 Intel Xeon LV 1.66 GHz (sossaman), and an 3 years old SuperMicro P4SCI sporting 1 Intel Pentium 4. Both are running 24/7/365 since I bought them. regards, patpro From lolo at troll.free.org Tue Nov 4 07:35:00 2008 From: lolo at troll.free.org (Laurent Frigault) Date: Tue Nov 4 07:35:08 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit In-Reply-To: References: <967012.89519.qm@web53803.mail.re2.yahoo.com> <20081104122622.GA47582@icarus.home.lan> Message-ID: <20081104150157.GA3332@troll.free.org> On Tue, Nov 04, 2008 at 09:29:15AM -0500, Daniel Eischen wrote: > I'm in the market for a decent motherboard also. Been monitoring > slickdeals lately - newegg seems to have specials every now and > then on the ASUS P5Q Pro. The reviews I've read seem pretty > positive on this board. Anyone with any experience with this > board? Same for me with the ASUS P5Q-E (does not seems to be very different from P5Q Pro) Is there any web site with dmesg output of know working (or not) hardware/motherboards/... ? Regards -- Laurent Frigault | Free.org From nick at van-laarhoven.org Tue Nov 4 14:25:37 2008 From: nick at van-laarhoven.org (Nick Hibma) Date: Tue Nov 4 14:25:44 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <1225836292.3428.37.camel@localhost> References: <200810092344.10388.nick@van-laarhoven.org> <1225836292.3428.37.camel@localhost> Message-ID: <200811042325.26574.nick@van-laarhoven.org> > Now (5-days old current), everything looks fine, chat finishes, but ppp > failed to handshake (same ppp config works before with ubsa): > > Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: PPP Started (background > mode). Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: bundle: Establish > Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Send: ATDT#777^M Are you sure this phone number is correct? I'd have to check the 3GPP spec, but something like ATDT*99***1# is more like the Huawei expects. The general format is *****#. If you have set multiple PDP contexts through AT+CGDCONT you can select the one you need by replacing the '1' in the line above with the appropriate number. The 'Unexpected * in phase *' I've not seen before and would indicate that a valid packet is received but one that is not appropriate at that point. You might want to add some more logging options to see what is going on. > It looks like that characters are delivered not reliable way through ucom > port: Same on U0.2 port: Weird. Should not happen. > - after disconnecting ppp from port card is not reset, so no more any > chat if start ppp again (you just need skip chat phase). - How to reset > card before start ? We've had this problem with an EDGE card from Option, and we basically power down the port and power up again the card to get it back. Patches have been sent to Warner to get committed. > - Disconnecting card crashes kernel, it is possible to catch that crash > with DDB, but dump can't be written. Modem is on cardbus device. > (probbaly will be fixed by new usb stack ?) kldunload usb first. The USB stack crashes if the device disappears. This takes some effort as you will have to unload all related modules. If you have ums_load="YES" in your /boot/loader.conf without usb_load="YES", then you are in luck as you should be able to unload ums and usb will unload as well. Once these are unloaded you should be able to unload the PCMCIA card without problems. Works with Option cards this way. Nick From vova at fbsd.ru Tue Nov 4 14:26:57 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Tue Nov 4 14:27:08 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200810092344.10388.nick@van-laarhoven.org> References: <200810092344.10388.nick@van-laarhoven.org> Message-ID: <1225836292.3428.37.camel@localhost> On Thu, 2008-10-09 at 23:44 +0200, Nick Hibma wrote: > Just now I have committed a driver for Option and Huawei cards previously > supported by the ubsa driver. More information is in the commit message. > > I am looking for people who would be able to provide more information after > testing with the 3G cards branded by: > > OEM: > Merlin > Huawei > Option > Sierra > Novatel > Qualcomm > > Rebranded: > Dell > Vodafone > > Note: The driver can be copied across to FreeBSD 7-STABLE if you copy the > sys/modules/u3g directory and sys/dev/usb/u3g.c and sys/dev/usb/usbdevs > files from HEAD and _move_ the ID from ubsa to u3g. > > More information can be found on > > http://people.freebsd.org/~n_hibma/u3g.html Ehh, I have Huawei card, and it works ok before with ubsa driver: Controller /dev/usb5: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), NEC(0x0000), rev 1.00 port 1 addr 2: full speed, power 500 mA, config 1, Huawei Mobile(0x1001), Huawei Technologies(0x12d1), rev 0.00 ucom0: on uhub5 ucom0: configured 3 serial ports (U0.%d) Now (5-days old current), everything looks fine, chat finishes, but ppp failed to handshake (same ppp config works before with ubsa): Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: PPP Started (background mode). Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: bundle: Establish Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: deflink: closed -> opening Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: deflink: Connected! Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: deflink: opening -> dial Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Phone: #777 Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: deflink: Dial attempt 1 of 1 Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Send: AT^M Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Expect(15): OK Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Received: ^M Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Received: OK^M Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Send: ATE1Q0^M Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Expect(15): OK Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Received: Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Received: OK^M Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Send: ATDT#777^M Nov 5 00:57:37 vbook ppp[4644]: tun0: Chat: Expect(40): CONNECT Nov 5 00:57:37 vbook ppp[4644]: tun0: Chat: Received: ^M Nov 5 00:57:37 vbook ppp[4644]: tun0: Chat: Received: CONNECT^M Nov 5 00:57:37 vbook ppp[4644]: tun0: Phase: deflink: dial -> carrier Nov 5 00:57:38 vbook ppp[4644]: tun0: Phase: deflink: /dev/ttyU0.0 doesn't support CD Nov 5 00:57:38 vbook ppp[4644]: tun0: Phase: deflink: carrier -> login Nov 5 00:57:38 vbook ppp[4644]: tun0: Phase: deflink: login -> lcp Nov 5 00:57:38 vbook ppp[4644]: tun0: LCP: FSM: Using "deflink" as a transport Nov 5 00:57:38 vbook ppp[4644]: tun0: LCP: deflink: State change Initial --> Closed Nov 5 00:57:38 vbook ppp[4644]: tun0: LCP: deflink: State change Closed --> Stopped Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: deflink: LayerStart Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: deflink: SendConfigReq(1) state = Stopped Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: MRU[4] 1500 Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: MAGICNUM[6] 0xb88169a8 Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Nov 5 00:57:39 vbook ppp[4644]: tun0: LCP: deflink: State change Stopped --> Req-Sent Nov 5 00:57:40 vbook ppp[4644]: tun0: LCP: deflink: RecvConfigAck(1) state = Req-Sent Nov 5 00:57:40 vbook ppp[4644]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 5 00:57:40 vbook ppp[4644]: tun0: LCP: MRU[4] 1500 Nov 5 00:57:40 vbook ppp[4644]: tun0: LCP: MAGICNUM[6] 0xb88169a8 Nov 5 00:57:40 vbook ppp[4644]: tun0: LCP: QUALPROTO[8] proto c025, interval 10000ms Nov 5 00:57:40 vbook ppp[4644]: tun0: LCP: deflink: State change Req-Sent --> Ack-Rcvd Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: deflink: RecvConfigReq(3) state = Ack-Rcvd Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: MAGICNUM[6] 0x2e7ad2d8 Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: deflink: SendConfigAck(3) state = Ack-Rcvd Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: ACCMAP[6] 0x00000000 Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: AUTHPROTO[5] 0xc223 (CHAP 0x05) Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: MAGICNUM[6] 0x2e7ad2d8 Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: deflink: State change Ack-Rcvd --> Opened Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: deflink: LayerUp Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: deflink: SendIdent(0) state = Opened Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: MAGICNUM b88169a8 Nov 5 00:57:42 vbook ppp[4644]: tun0: LCP: TEXT user-ppp 3.4.2 (built COMPILATIONDATE) Nov 5 00:57:42 vbook ppp[4644]: tun0: Phase: bundle: Authenticate Nov 5 00:57:42 vbook ppp[4644]: tun0: Phase: deflink: his = CHAP 0x05, mine = none Nov 5 00:57:52 vbook ppp[4644]: tun0: Phase: Chap Input: CHALLENGE (16 bytes from pdsn-m22-7cm2) Nov 5 00:57:52 vbook ppp[4644]: tun0: Phase: Chap Output: RESPONSE (mobile) Nov 5 00:57:53 vbook ppp[4644]: tun0: LCP: deflink: RecvEchoRequest(1) state = Opened Nov 5 00:57:53 vbook ppp[4644]: tun0: LCP: deflink: SendEchoReply(1) state = Opened Nov 5 00:57:53 vbook ppp[4644]: tun0: CCP: deflink: Error: Unexpected CCP in phase Authenticate (ignored) Nov 5 00:58:03 vbook last message repeated 3 times Nov 5 00:58:07 vbook ppp[4644]: tun0: IPCP: deflink: Error: Unexpected IPCP in phase Authenticate (ignored) Nov 5 00:58:07 vbook ppp[4644]: tun0: CCP: deflink: Error: Unexpected CCP in phase Authenticate (ignored) Nov 5 00:58:11 vbook ppp[4644]: tun0: CCP: deflink: Error: Unexpected CCP in phase Authenticate (ignored) Nov 5 00:58:42 vbook ppp[4644]: tun0: Phase: deflink: HDLC errors -> FCS: 26, ADDR: 0, COMD: 0, PROTO: 0 Nov 5 00:58:52 vbook ppp[4644]: tun0: Phase: deflink: ** Too many LQR packets lost ** Nov 5 00:58:52 vbook ppp[4644]: tun0: LCP: deflink: LayerDown Nov 5 00:58:52 vbook ppp[4644]: tun0: LCP: deflink: State change Opened --> Starting Nov 5 00:58:52 vbook ppp[4644]: tun0: LCP: deflink: LayerFinish Nov 5 00:58:52 vbook ppp[4644]: tun0: LCP: deflink: State change Starting --> Initial Nov 5 00:58:52 vbook ppp[4644]: tun0: Phase: deflink: Disconnected! It looks like that characters are delivered not reliable way through ucom port: Same on U0.2 port: Below output, just after entring AT\n three times: # cu -l /dev/cuaU0.2 can't open log file /var/log/aculog. Connected ^RSSILVL: 20 8 OK It OK I ^RSSILVL: 20 8em0X?6T OK I -------------------- Any hints will be very appriciated. > Thanks, > > Nick P.S. I have also two other problems with same card, (they was with ubsa also): - after disconnecting ppp from port card is not reset, so no more any chat if start ppp again (you just need skip chat phase). - How to reset card before start ? - Disconnecting card crashes kernel, it is possible to catch that crash with DDB, but dump can't be written. Modem is on cardbus device. (probbaly will be fixed by new usb stack ?) -- Vladimir B. Grebenschikov vova@fbsd.ru From olihc17 at yahoo.com Tue Nov 4 16:17:07 2008 From: olihc17 at yahoo.com (chilo) Date: Tue Nov 4 16:52:37 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit Message-ID: <513215.77035.qm@web53801.mail.re2.yahoo.com> Has anyone used an Intel board with raid compatibility? If I can't push hardware I guess I'm off to using software raid. many thanks. ________________________________ From: Jeremy Chadwick To: Daniel Eischen Cc: chilo ; freebsd-hardware@freebsd.org; pyunyh@gmail.com Sent: Tuesday, November 4, 2008 11:03:51 PM Subject: Re: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit On Tue, Nov 04, 2008 at 09:29:15AM -0500, Daniel Eischen wrote: > On Tue, 4 Nov 2008, Jeremy Chadwick wrote: > >> On Mon, Nov 03, 2008 at 11:05:19PM -0800, chilo wrote: >>> Hi guys I'm new when it comes to using Freebsd but can you recommend >>> me a motherboard(s) that will support Freebsd 7.0? It will have at >>> least RAID 1 configuration with full driver support. I'm planning to >>> install Freebsd to a clone PC so that I can continue my progress/self >>> training. Thank you very much. >> >> Most consumer motherboards will work. >> >> However, with regards to "RAID 1 configuration", what are you planning >> on using for RAID 1? A RAID controller, or something like gmirror(8) >> which is software/OS-based RAID in FreeBSD? (Most people will strongly >> recommend using software/OS-based RAID, for a lot of good reasons.) > > I'm in the market for a decent motherboard also. Been monitoring > slickdeals lately - newegg seems to have specials every now and > then on the ASUS P5Q Pro. The reviews I've read seem pretty > positive on this board. Anyone with any experience with this > board? Yes, there are some of us in the FreeBSD community who have experience with the P5Q series. The first issue you'll run into is lack of Ethernet support on FreeBSD. I've worked with Yong-Hyeon PYUN on this, sending him a new P5Q SE motherboard, and he was able to develop a driver for it (it is in no way optimised for speed, but it does work). The driver is not part of the FreeBSD source code yet. See my "Networking" section here: http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues If you want the driver, Yong-Hyeon can provide it. I've CC'd him here. The second issue you'll run into, at least on the P5Q SE, is a 10-15 second delay when enabling AHCI mode in the BIOS (for the Intel ICH). Machine will POST, then sit there for 10-15 seconds with a blinking cursor before booting any disk (and after that, works fine). Switch back to Enhanced mode and the problem disappears. I find this very odd, as no other ICH-based AHCI system I have behaves this way; very likely a BIOS bug/problem. Note: despite owning a P5Q SE board, I do not use it for FreeBSD (I run Windows on my desktops, and FreeBSD on my servers). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Tue Nov 4 17:10:35 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Tue Nov 4 17:10:41 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit In-Reply-To: <513215.77035.qm@web53801.mail.re2.yahoo.com> References: <513215.77035.qm@web53801.mail.re2.yahoo.com> Message-ID: <20081105011021.GA62277@icarus.home.lan> On Tue, Nov 04, 2008 at 04:17:06PM -0800, chilo wrote: > Has anyone used an Intel board with raid compatibility? If I can't push hardware I guess I'm off to using software raid. many thanks. What is "RAID compatibility"? I have a feeling you're talking about BIOS-based Intel MatrixRAID, in which case, **do not use it**. There are bugs in the ata(4) layer which will bite you badly, including data loss even in RAID-1 situations. http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Stick with OS-based software RAID. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From olihc17 at yahoo.com Tue Nov 4 17:42:43 2008 From: olihc17 at yahoo.com (chilo) Date: Tue Nov 4 20:04:15 2008 Subject: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit Message-ID: <270648.30039.qm@web53808.mail.re2.yahoo.com> yep im talking about that raid. ok jeremy i'll go with the software raid thank you very much. ________________________________ From: Jeremy Chadwick To: chilo Cc: freebsd-hardware@freebsd.org Sent: Wednesday, November 5, 2008 9:10:21 AM Subject: Re: Motherboard Recommendation for Freebsd 7.0 32-bit or 64-bit On Tue, Nov 04, 2008 at 04:17:06PM -0800, chilo wrote: > Has anyone used an Intel board with raid compatibility? If I can't push hardware I guess I'm off to using software raid. many thanks. What is "RAID compatibility"? I have a feeling you're talking about BIOS-based Intel MatrixRAID, in which case, **do not use it**. There are bugs in the ata(4) layer which will bite you badly, including data loss even in RAID-1 situations. http://wiki.freebsd.org/JeremyChadwick/ATA_issues_and_troubleshooting Stick with OS-based software RAID. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From vova at fbsd.ru Wed Nov 5 00:58:18 2008 From: vova at fbsd.ru (Vladimir Grebenschikov) Date: Wed Nov 5 00:58:31 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811042325.26574.nick@van-laarhoven.org> References: <200810092344.10388.nick@van-laarhoven.org> <1225836292.3428.37.camel@localhost> <200811042325.26574.nick@van-laarhoven.org> Message-ID: <1225875486.1713.37.camel@localhost> On Tue, 2008-11-04 at 23:25 +0100, Nick Hibma wrote: > > Now (5-days old current), everything looks fine, chat finishes, but ppp > > failed to handshake (same ppp config works before with ubsa): > > > > Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: PPP Started (background > > mode). Nov 5 00:57:35 vbook ppp[4644]: tun0: Phase: bundle: Establish > > Nov 5 00:57:35 vbook ppp[4644]: tun0: Chat: Send: ATDT#777^M > > Are you sure this phone number is correct? I'd have to check the 3GPP spec, > but something like > > ATDT*99***1# > > is more like the Huawei expects. The general format is > *****#. If you have set multiple PDP contexts > through AT+CGDCONT you can select the one you need by replacing the '1' in > the line above with the appropriate number. Actually it is not exactly 3G modem - it is Huawei EC500 for CDMA2000 network (hybrid 2.5G / 3G - Skylink operator in Russia) ATDT#777 is usual dial for that operator. > The 'Unexpected * in phase *' I've not seen before and would indicate that a > valid packet is received but one that is not appropriate at that point. You > might want to add some more logging options to see what is going on. > > > It looks like that characters are delivered not reliable way through ucom > > port: Same on U0.2 port: > > Weird. Should not happen. What I can do to help track the problem ? > > - after disconnecting ppp from port card is not reset, so no more any > > chat if start ppp again (you just need skip chat phase). - How to reset > > card before start ? > > We've had this problem with an EDGE card from Option, and we basically power > down the port and power up again the card to get it back. Patches have been > sent to Warner to get committed. Nice, are these patches attached to some PR ? > > - Disconnecting card crashes kernel, it is possible to catch that crash > > with DDB, but dump can't be written. Modem is on cardbus device. > > (probbaly will be fixed by new usb stack ?) > > kldunload usb first. The USB stack crashes if the device disappears. This > takes some effort as you will have to unload all related modules. If you > have ums_load="YES" in your /boot/loader.conf without usb_load="YES", then > you are in luck as you should be able to unload ums and usb will unload as > well. > > Once these are unloaded you should be able to unload the PCMCIA card without > problems. Works with Option cards this way. Uhh, really need to try new USB stack (I will try). > Nick -- Vladimir B. Grebenschikov vova@fbsd.ru From ivoras at freebsd.org Wed Nov 5 02:58:53 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Nov 5 02:59:00 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <490FE404.2000308@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <490FE404.2000308@dannysplace.net> Message-ID: Danny Carroll wrote: > - I have seen sustained 130Mb reads from ZFS: > capacity operations bandwidth > pool used avail read write read write > ---------- ----- ----- ----- ----- ----- ----- > bigarray 1.29T 3.25T 1.10K 0 140M 0 > bigarray 1.29T 3.25T 1.00K 0 128M 0 > bigarray 1.29T 3.25T 945 0 118M 0 > bigarray 1.29T 3.25T 1.05K 0 135M 0 > bigarray 1.29T 3.25T 1.01K 0 129M 0 > bigarray 1.29T 3.25T 994 0 124M 0 > > ad4 ad6 ad8 cpu > KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id > 0.00 0 0.00 65.90 375 24.10 63.74 387 24.08 0 0 19 2 78 > 0.00 0 0.00 66.36 357 23.16 63.93 370 23.11 0 0 23 2 75 > 16.00 0 0.00 64.84 387 24.51 63.79 389 24.20 0 0 23 2 75 > 16.00 2 0.03 68.09 407 27.04 64.98 409 25.98 0 0 28 2 70 > I'm curious if the ~130M figure shown above is bandwidth from the array > or a total of all the drives. In other words, does it include reading > the parity information? I think it does not since if I look at iostat > figures and add up all of the drives it is greater than that reported by > zfs by a factor of 5/4 (100M in Zfs iostat = 5 x 25Mb in standard iostat). The numbers make sense - you have 5 drives in RAID-Z and 4/5ths of total bandwidth is the "real" bandwidth. On the other hand, 25 MB/s is very slow for modern drives (assuming you're doing sequential read/write tests). Are you having hardware problems? > Lastly, The windows client which performed these tests was measuring > local bandwidth at about 30-50Mb/s. I believe this figure to be > incorrect (given how much I transferred in X seconds...) Using Samba? Search the lists for Samba performance advice - the default configuration isn't nearly optimal. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081105/3a9ad504/signature.pgp From nick at van-laarhoven.org Wed Nov 5 08:06:16 2008 From: nick at van-laarhoven.org (Nick Hibma) Date: Wed Nov 5 08:06:24 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811051548.mA5Fmsot040177@lava.sentex.ca> References: <200810092344.10388.nick@van-laarhoven.org> <200811051548.mA5Fmsot040177@lava.sentex.ca> Message-ID: <200811051706.00850.nick@van-laarhoven.org> > At 04:44 PM 10/9/2008, Nick Hibma wrote: > >Just now I have committed a driver for Option and Huawei cards > > previously supported by the ubsa driver. More information is in the > > commit message. > > > >I am looking for people who would be able to provide more information > > after testing with the 3G cards branded by: > > Hi, > I gave it a try on the Sierra USB card and it seems to work > really well on RELENG_7! There is however also a mini-pci express > version of the Sierra card, the MC8775. Do you have plans to add > support for it ? I am not sure how the unit is even supposed to show > up as I dont see it in the dmesg, but I do see that it shows some > sort of umass device > > # usbdevs > addr 1: OHCI root hub, AMD > addr 2: USB MMC Storage, Sierra Wireless > addr 1: EHCI root hub, AMD If you could run usbdevs -v and then jot down the IDs you can add those to the top of u3g.c. You'll have to add a quirk like for other sierra devices that show up as mass storage and need to be kicked into modem mode. It pretends to be a mass storage device (with drivers on it) and after installation switches to modem mode. Or that's my guess. Nick > dmesg snippet > ... > isa_probe_children: probing PnP devices > umass0: addr 2> on uhub0 > umass0:0:0:-1: Attached to scbus0 > Device configuration finished. > procfs registered > Timecounter "TSC" frequency 498053687 Hz quality 800 > Timecounters tick every 1.000 msec > crypto: > vlan: initialized, using hash tables with chaining > IPsec: Initialized Security Association Processing. > pflog0: bpf attached > lo0: bpf attached > ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire > ad0: setting PIO4 on CS5536 chip > ad0: 1953MB at ata0-master PIO4 > ad0: 4001760 sectors [3970C/16H/63S] 4 sectors/interrupt 1 depth queue > GEOM: new disk ad0 > pass0 at umass-sim0 bus 0 target 0 lun 0 > pass0: Removable CD-ROM SCSI-0 device > pass0: 1.000MB/s transfers > Trying to mount root from ufs:/dev/ad0s1a > start_init: trying /sbin/init > bridge0: bpf attached > bridge0: Ethernet address: 3a:72:35:a3:25:ce > tun0: bpf attached > > Not sure why it shows up as a passthrough device ? > > ---Mike From mike at sentex.net Wed Nov 5 08:19:48 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Nov 5 08:19:55 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200810092344.10388.nick@van-laarhoven.org> References: <200810092344.10388.nick@van-laarhoven.org> Message-ID: <200811051548.mA5Fmsot040177@lava.sentex.ca> At 04:44 PM 10/9/2008, Nick Hibma wrote: >Just now I have committed a driver for Option and Huawei cards previously >supported by the ubsa driver. More information is in the commit message. > >I am looking for people who would be able to provide more information after >testing with the 3G cards branded by: Hi, I gave it a try on the Sierra USB card and it seems to work really well on RELENG_7! There is however also a mini-pci express version of the Sierra card, the MC8775. Do you have plans to add support for it ? I am not sure how the unit is even supposed to show up as I dont see it in the dmesg, but I do see that it shows some sort of umass device # usbdevs addr 1: OHCI root hub, AMD addr 2: USB MMC Storage, Sierra Wireless addr 1: EHCI root hub, AMD dmesg snippet ... isa_probe_children: probing PnP devices umass0: on uhub0 umass0:0:0:-1: Attached to scbus0 Device configuration finished. procfs registered Timecounter "TSC" frequency 498053687 Hz quality 800 Timecounters tick every 1.000 msec crypto: vlan: initialized, using hash tables with chaining IPsec: Initialized Security Association Processing. pflog0: bpf attached lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire ad0: setting PIO4 on CS5536 chip ad0: 1953MB at ata0-master PIO4 ad0: 4001760 sectors [3970C/16H/63S] 4 sectors/interrupt 1 depth queue GEOM: new disk ad0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable CD-ROM SCSI-0 device pass0: 1.000MB/s transfers Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init bridge0: bpf attached bridge0: Ethernet address: 3a:72:35:a3:25:ce tun0: bpf attached Not sure why it shows up as a passthrough device ? ---Mike >OEM: > Merlin > Huawei > Option > Sierra > Novatel > Qualcomm > >Rebranded: > Dell > Vodafone > >Note: The driver can be copied across to FreeBSD 7-STABLE if you copy the >sys/modules/u3g directory and sys/dev/usb/u3g.c and sys/dev/usb/usbdevs >files from HEAD and _move_ the ID from ubsa to u3g. > >More information can be found on > > http://people.freebsd.org/~n_hibma/u3g.html > >Thanks, > >Nick >---------- Forwarded Message ---------- >Subject: svn commit: r183735 - in head: share/man/man4 sys/conf sys/dev/usb >sys/i386/conf sys/modules sys/modules/u3g >Date: Thu October 9 2008 >From: Nick Hibma >To: src-committers@freebsd.org, svn-src-all@freebsd.org, >svn-src-head@freebsd.org > >Author: n_hibma >Date: Thu Oct 9 21:25:01 2008 >New Revision: 183735 >URL: http://svn.freebsd.org/changeset/base/183735 > >Log: > Say hello to the u3g driver, implementing support for 3G modems. > > This was located in the ubsa driver, but should be moved into a separate > driver: > > - 3G modems provide multiple serial ports to allow AT commands while the >PPP > connection is up. > - 3G modems do not provide baud rate or other serial port settings. > - Huawei cards need specific initialisation. > - ubsa is for Belkin adapters, an Linuxy choice for another device like >3G. > > Speeds achieved here with a weak signal at best is ~40kb/s (UMTS). No >spooky > STALLED messages as well. > > Next: Move over all entries for Sierra and Novatel cards once I have found > testers, and implemented serial port enumeration for Sierra (or rather >have > Andrea Guzzo do it). They list all endpoints in 1 iface instead of 4 >ifaces. > > Submitted by: aguzzo@anywi.com > MFC after: 3 weeks > >Added: > head/share/man/man4/u3g.4 (contents, props changed) > head/sys/dev/usb/u3g.c (contents, props changed) > head/sys/modules/u3g/ > head/sys/modules/u3g/Makefile (contents, props changed) >Modified: > head/share/man/man4/Makefile > head/sys/conf/NOTES > head/sys/conf/files > head/sys/dev/usb/ubsa.c > head/sys/dev/usb/usbdevs > head/sys/i386/conf/GENERIC > head/sys/modules/Makefile > >Modified: head/share/man/man4/Makefile >============================================================================== >--- head/share/man/man4/Makefile Thu Oct 9 20:51:25 >2008 (r183734) >+++ head/share/man/man4/Makefile Thu Oct 9 21:25:01 >2008 (r183735) >@@ -384,6 +384,7 @@ MAN= aac.4 \ > twe.4 \ > tx.4 \ > txp.4 \ >+ u3g.4 \ > uark.4 \ > uart.4 \ > ubsa.4 \ > >Added: head/share/man/man4/u3g.4 >============================================================================== >--- /dev/null 00:00:00 1970 (empty, because file is newly added) >+++ head/share/man/man4/u3g.4 Thu Oct 9 21:25:01 2008 (r183735) >@@ -0,0 +1,100 @@ >+.\" >+.\" Copyright (c) 2008 AnyWi Technologies >+.\" All rights reserved. >+.\" >+.\" This code is derived from uark.c >+.\" >+.\" Permission to use, copy, modify, and distribute this software for any >+.\" purpose with or without fee is hereby granted, provided that the above >+.\" copyright notice and this permission notice appear in all copies. >+.\" >+.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL >WARRANTIES >+.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >+.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR >+.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >+.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN >+.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >+.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >+.\" >+.\" $FreeBSD$ >+.\" >+.Dd October 7, 2008 >+.Dt U3G 4 >+.Os >+.Sh NAME >+.Nm u3g >+.Nd USB support for 3G datacards >+.Sh SYNOPSIS >+To compile this driver into the kernel, >+place the following lines in your >+kernel configuration file: >+.Bd -ragged -offset indent >+.Cd "device u3g" >+.Cd "device ucom" >+.Ed >+.Pp >+Alternatively, to load the driver as a >+module at boot time, place the following line in >+.Xr loader.conf 5 : >+.Bd -literal -offset indent >+u3g_load="YES" >+.Ed >+.Sh DESCRIPTION >+The >+.Nm >+driver provides support for the multiple USB-to-serial interfaces exposed >by >+many 3G usb/pccard modems. >+.Pp >+The device is accessed through the >+.Xr ucom 4 >+driver which makes it behave like a >+.Xr tty 4 . >+.Sh HARDWARE >+The >+.Nm >+driver supports the following adapters: >+.Pp >+.Bl -bullet -compact >+.It >+Option Globetrotter 3G Fusion (only 3G part, not WLAN) >+.It >+Option Globetrotter 3G Fusion Quad (only 3G part, not WLAN) >+.It >+Option Globetrotter 3G Quad >+.It >+Option Globetrotter 3G >+.It >+Vodafone Mobile Connect Card 3G >+.It >+Huawei E220 (E270?) >+.It >+Huawei Mobile >+.El >+.Pp >+The supported 3G cards provide the necessary modem port for ppp, >+pppd, or mpd connections as well as extra ports (depending on the specific >+device) to provide other functions (diagnostic port, SIM toolkit port) >+.Sh SEE ALSO >+.Xr tty 4 , >+.Xr ucom 4 , >+.Xr usb 4 , >+.Xr ubsa 4 >+.Sh HISTORY >+The >+.Nm >+driver >+appeared in >+.Fx 7.0 . >+The >+.Xr ubsa 4 >+manual page was modified for >+.Nm >+by >+.An Andrea Guzzo Aq aguzzo@anywi.com >+in September 2008. >+.Sh AUTHORS >+The >+.Nm >+driver was written by >+.An Andrea Guzzo Aq aguzzo@anywi.com . >+Hardware for testing provided by AnyWi Technologies, Leiden, NL. > >Modified: head/sys/conf/NOTES >============================================================================== >--- head/sys/conf/NOTES Thu Oct 9 20:51:25 2008 (r183734) >+++ head/sys/conf/NOTES Thu Oct 9 21:25:01 2008 (r183735) >@@ -2416,6 +2416,8 @@ device uscanner > # > # USB serial support > device ucom >+# USB support for 3G modem cards by Option, Huawei and Sierra >+device u3g > # USB support for Technologies ARK3116 based serial adapters > device uark > # USB support for Belkin F5U103 and compatible serial adapters >@@ -2441,7 +2443,6 @@ device aue > > # ASIX Electronics AX88172 USB 2.0 ethernet driver. Used in the > # LinkSys USB200M and various other adapters. >- > device axe > > # > >Modified: head/sys/conf/files >============================================================================== >--- head/sys/conf/files Thu Oct 9 20:51:25 2008 (r183734) >+++ head/sys/conf/files Thu Oct 9 21:25:01 2008 (r183735) >@@ -1327,6 +1327,7 @@ dev/usb/ohci_pci.c optional ohci pci > dev/usb/sl811hs.c optional slhci > dev/usb/slhci_pccard.c optional slhci pccard > dev/usb/uark.c optional uark >+dev/usb/u3g.c optional u3g > dev/usb/ubsa.c optional ubsa > dev/usb/ubser.c optional ubser > dev/usb/ucom.c optional ucom > >Added: head/sys/dev/usb/u3g.c >============================================================================== >--- /dev/null 00:00:00 1970 (empty, because file is newly added) >+++ head/sys/dev/usb/u3g.c Thu Oct 9 21:25:01 2008 (r183735) >@@ -0,0 +1,330 @@ >+/* >+ * Copyright (c) 2008 AnyWi Technologies >+ * Author: Andrea Guzzo >+ * * based on uark.c 1.1 2006/08/14 08:30:22 jsg * >+ * * parts from ubsa.c 183348 2008-09-25 12:00:56Z phk * >+ * >+ * Permission to use, copy, modify, and distribute this software for any >+ * purpose with or without fee is hereby granted, provided that the above >+ * copyright notice and this permission notice appear in all copies. >+ * >+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES >+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF >+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR >+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES >+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN >+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF >+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. >+ * >+ * $FreeBSD$ >+ */ >+ >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+#include >+ >+#include >+#include >+#include >+ >+#include >+ >+#include "usbdevs.h" >+ >+#ifdef U3G_DEBUG >+#define DPRINTFN(n, x) do { if (u3gdebug > (n)) printf x; } while (0) >+int u3gtebug = 0; >+#else >+#define DPRINTFN(n, x) >+#endif >+#define DPRINTF(x) DPRINTFN(0, x) >+ >+#define U3GBUFSZ 1024 >+#define U3G_MAXPORTS 4 >+ >+struct u3g_softc { >+ struct ucom_softc sc_ucom[U3G_MAXPORTS];; >+ device_t sc_dev; >+ usbd_device_handle sc_udev; >+ u_char sc_msr; >+ u_char sc_lsr; >+ u_char numports; >+ >+ usbd_interface_handle sc_intr_iface; /* interrupt interface */ >+#ifdef U3G_DEBUG >+ int sc_intr_number; /* interrupt number */ >+ usbd_pipe_handle sc_intr_pipe; /* interrupt pipe */ >+ u_char *sc_intr_buf; /* interrupt buffer */ >+#endif >+ int sc_isize; >+}; >+ >+struct ucom_callback u3g_callback = { >+ NULL, >+ NULL, >+ NULL, >+ NULL, >+ NULL, >+ NULL, >+ NULL, >+ NULL, >+}; >+ >+static const struct usb_devno u3g_devs[] = { >+ /* OEM: Option */ >+ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3G }, >+ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD }, >+ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GPLUS }, >+ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GTMAX36 }, >+ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_VODAFONEMC3G }, >+ /* OEM: Huawei */ >+ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE }, >+ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E220 }, >+ >+ { 0, 0 } >+}; >+ >+#ifdef U3G_DEBUG >+static void >+u3g_intr(usbd_xfer_handle xfer, usbd_private_handle priv, usbd_status >status) >+{ >+ struct u3g_softc *sc = (struct u3g_softc *)priv; >+ device_printf(sc->sc_dev, "INTERRUPT CALLBACK\n"); >+} >+#endif >+ >+static int >+u3g_huawei_reinit(usbd_device_handle dev) >+{ >+ /* The Huawei device presents itself as a umass device with Windows >+ * drivers on it. After installation of the driver, it reinits into a >+ * 3G serial device. >+ */ >+ usb_device_request_t req; >+ usb_config_descriptor_t *cdesc; >+ >+ /* Get the config descriptor */ >+ cdesc = usbd_get_config_descriptor(dev); >+ if (cdesc == NULL) >+ return (UMATCH_NONE); >+ >+ /* One iface means umass mode, more than 1 (4 usually) means >3G mode */ >+ if (cdesc->bNumInterface > 1) >+ return (UMATCH_VENDOR_PRODUCT); >+ >+ req.bmRequestType = UT_WRITE_DEVICE; >+ req.bRequest = UR_SET_FEATURE; >+ USETW(req.wValue, UF_DEVICE_REMOTE_WAKEUP); >+ USETW(req.wIndex, UHF_PORT_SUSPEND); >+ USETW(req.wLength, 0); >+ >+ (void) usbd_do_request(dev, &req, 0); >+ >+ return UMATCH_NONE; /* mismatch; it will be gone and reappear */ >+} >+ >+static int >+u3g_match(device_t self) >+{ >+ struct usb_attach_arg *uaa = device_get_ivars(self); >+ >+ if (uaa->iface != NULL) >+ return (UMATCH_NONE); >+ >+ if (uaa->vendor == USB_VENDOR_HUAWEI) >+ return u3g_huawei_reinit(uaa->device); >+ >+ if (usb_lookup(u3g_devs, uaa->vendor, uaa->product)) >+ return UMATCH_VENDOR_PRODUCT; >+ >+ return UMATCH_NONE; >+} >+ >+static int >+u3g_attach(device_t self) >+{ >+ struct u3g_softc *sc = device_get_softc(self); >+ struct usb_attach_arg *uaa = device_get_ivars(self); >+ usbd_device_handle dev = uaa->device; >+ usbd_interface_handle iface; >+ usb_interface_descriptor_t *id; >+ usb_endpoint_descriptor_t *ed; >+ usbd_status error; >+ int i, n; >+ usb_config_descriptor_t *cdesc; >+ struct ucom_softc *ucom = NULL; >+ char devnamefmt[32]; >+ >+ sc->sc_dev = self; >+#ifdef DEBUG >+ sc->sc_intr_number = -1; >+ sc->sc_intr_pipe = NULL; >+#endif >+ /* Move the device into the configured state. */ >+ error = usbd_set_config_index(dev, 1, 1); >+ if (error) { >+ device_printf(self, "failed to set configuration: %s\n", >+ usbd_errstr(error)); >+ goto bad; >+ } >+ >+ /* get the config descriptor */ >+ cdesc = usbd_get_config_descriptor(dev); >+ >+ if (cdesc == NULL) { >+ device_printf(self, "failed to get configuration >descriptor\n"); >+ goto bad; >+ } >+ >+ sc->sc_udev = dev; >+ sc->numports = (cdesc->bNumInterface <= >U3G_MAXPORTS)?cdesc->bNumInterface:U3G_MAXPORTS; >+ for ( i = 0; i < sc->numports; i++ ) { >+ ucom = &sc->sc_ucom[i]; >+ >+ ucom->sc_dev = self; >+ ucom->sc_udev = dev; >+ error = usbd_device2interface_handle(dev, i, &iface); >+ if (error) { >+ device_printf(ucom->sc_dev, >+ "failed to get interface, err=%s\n", >+ usbd_errstr(error)); >+ ucom->sc_dying = 1; >+ goto bad; >+ } >+ id = usbd_get_interface_descriptor(iface); >+ ucom->sc_iface = iface; >+ >+ ucom->sc_bulkin_no = ucom->sc_bulkout_no = -1; >+ for (n = 0; n < id->bNumEndpoints; n++) { >+ ed = usbd_interface2endpoint_descriptor(iface, n); >+ if (ed == NULL) { >+ device_printf(ucom->sc_dev, >+ "could not read endpoint >descriptor\n"); >+ goto bad; >+ } >+ if (UE_GET_DIR(ed->bEndpointAddress) == UE_DIR_IN && >+ UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) >+ ucom->sc_bulkin_no = ed->bEndpointAddress; >+ else if (UE_GET_DIR(ed->bEndpointAddress) == >UE_DIR_OUT && >+ UE_GET_XFERTYPE(ed->bmAttributes) == UE_BULK) >+ ucom->sc_bulkout_no = ed->bEndpointAddress; >+ } >+ if (ucom->sc_bulkin_no == -1 || ucom->sc_bulkout_no == -1) { >+ device_printf(ucom->sc_dev, "missing endpoint\n"); >+ goto bad; >+ } >+ ucom->sc_parent = sc; >+ ucom->sc_ibufsize = U3GBUFSZ; >+ ucom->sc_obufsize = U3GBUFSZ; >+ ucom->sc_ibufsizepad = U3GBUFSZ; >+ ucom->sc_opkthdrlen = 0; >+ >+ ucom->sc_callback = &u3g_callback; >+ >+ sprintf(devnamefmt,"U%d.%%d", device_get_unit(self)); >+ DPRINTF(("u3g: in=0x%x out=0x%x, devname=%s\n", >+ ucom->sc_bulkin_no, ucom->sc_bulkout_no, devnamefmt)); >+#if __FreeBSD_version < 800000 >+ ucom_attach_tty(ucom, TS_CALLOUT, devnamefmt, i); >+#else >+ ucom_attach_tty(ucom, devnamefmt, i); >+#endif >+ } >+#ifdef U3G_DEBUG >+ if (sc->sc_intr_number != -1 && sc->sc_intr_pipe == NULL) { >+ sc->sc_intr_buf = malloc(sc->sc_isize, M_USBDEV, M_WAITOK); >+ error = usbd_open_pipe_intr(sc->sc_intr_iface, >+ sc->sc_intr_number, >+ USBD_SHORT_XFER_OK, >+ &sc->sc_intr_pipe, >+ sc, >+ sc->sc_intr_buf, >+ sc->sc_isize, >+ u3g_intr, >+ 100); >+ if (error) { >+ device_printf(self, >+ "cannot open interrupt pipe (addr %d)\n", >+ sc->sc_intr_number); >+ goto bad; >+ } >+ } >+#endif >+ device_printf(self, "configured %d serial ports (/dev/cuaU%d.X)", >+ sc->numports, device_get_unit(self)); >+ >+ return 0; >+ >+bad: >+ DPRINTF(("u3g_attach: ATTACH ERROR\n")); >+ ucom->sc_dying = 1; >+ return ENXIO; >+} >+ >+static int >+u3g_detach(device_t self) >+{ >+ struct u3g_softc *sc = device_get_softc(self); >+ int rv = 0; >+ int i; >+ >+ DPRINTF(("u3g_detach: sc=%p\n", sc)); >+ >+ for (i = 0; i < sc->numports; i++) { >+ if(sc->sc_ucom[i].sc_udev) { >+ sc->sc_ucom[i].sc_dying = 1; >+ rv = ucom_detach(&sc->sc_ucom[i]); >+ if(rv != 0) { >+ device_printf(self, "Can't deallocat >port %d", i); >+ return rv; >+ } >+ } >+ } >+ >+#ifdef U3G_DEBUG >+ if (sc->sc_intr_pipe != NULL) { >+ int err = usbd_abort_pipe(sc->sc_intr_pipe); >+ if (err) >+ device_printf(self, >+ "abort interrupt pipe failed: %s\n", >+ usbd_errstr(err)); >+ err = usbd_close_pipe(sc->sc_intr_pipe); >+ if (err) >+ device_printf(self, >+ "close interrupt pipe failed: %s\n", >+ usbd_errstr(err)); >+ free(sc->sc_intr_buf, M_USBDEV); >+ sc->sc_intr_pipe = NULL; >+ } >+#endif >+ >+ return 0; >+} >+ >+static device_method_t u3g_methods[] = { >+ /* Device interface */ >+ DEVMETHOD(device_probe, u3g_match), >+ DEVMETHOD(device_attach, u3g_attach), >+ DEVMETHOD(device_detach, u3g_detach), >+ >+ { 0, 0 } >+}; >+ >+static driver_t u3g_driver = { >+ "ucom", >+ u3g_methods, >+ sizeof (struct u3g_softc) >+}; >+ >+DRIVER_MODULE(u3g, uhub, u3g_driver, ucom_devclass, usbd_driver_load, 0); >+MODULE_DEPEND(u3g, usb, 1, 1, 1); >+MODULE_DEPEND(u3g, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); > >Modified: head/sys/dev/usb/ubsa.c >============================================================================== >--- head/sys/dev/usb/ubsa.c Thu Oct 9 20:51:25 2008 (r183734) >+++ head/sys/dev/usb/ubsa.c Thu Oct 9 21:25:01 2008 (r183735) >@@ -161,8 +161,6 @@ SYSCTL_INT(_hw_usb_ubsa, OID_AUTO, debug > struct ubsa_softc { > struct ucom_softc sc_ucom; > >- int sc_huawei; >- > int sc_iface_number; /* > interface number */ > > usbd_interface_handle sc_intr_iface; /* interrupt interface */ >@@ -228,24 +226,11 @@ static const struct ubsa_product { > { USB_VENDOR_GOHUBS, USB_PRODUCT_GOHUBS_GOCOM232 }, > /* Peracom */ > { USB_VENDOR_PERACOM, USB_PRODUCT_PERACOM_SERIAL1 }, >- /* Dell version of the Novatel 740 */ >- { USB_VENDOR_DELL, USB_PRODUCT_DELL_U740 }, >- /* Option Vodafone MC3G */ >- { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_VODAFONEMC3G }, >- /* Option GlobeTrotter 3G */ >- { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3G }, >- /* Option GlobeTrotter 3G QUAD */ >- { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD }, >- /* Option GlobeTrotter 3G+ */ >- { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GPLUS }, >- /* Option GlobeTrotter Max 3.6 */ >- { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GTMAX36 }, >- /* Huawei Mobile */ >- { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE }, >- { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_E270 }, >+ /* Merlin */ > { USB_VENDOR_MERLIN, USB_PRODUCT_MERLIN_V620 }, > /* Qualcomm, Inc. ZTE CDMA */ > { USB_VENDOR_QUALCOMMINC, USB_PRODUCT_QUALCOMMINC_CDMA_MSM }, >+ /* Novatel */ > { USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_CDMA_MODEM }, > /* Novatel Wireless Merlin ES620 */ > { USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_ES620 }, >@@ -256,6 +241,8 @@ static const struct ubsa_product { > /* Novatel Wireless Merlin U740 */ > { USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_U740 }, > { USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_U740_2 }, >+ /* Dell version of the Novatel 740 */ >+ { USB_VENDOR_DELL, USB_PRODUCT_DELL_U740 }, > /* Novatel Wireless Merlin U950D */ > { USB_VENDOR_NOVATEL, USB_PRODUCT_NOVATEL_U950D }, > /* Novatel Wireless Merlin V620 */ >@@ -341,52 +328,6 @@ MODULE_DEPEND(ubsa, usb, 1, 1, 1); > MODULE_DEPEND(ubsa, ucom, UCOM_MINVER, UCOM_PREFVER, UCOM_MAXVER); > MODULE_VERSION(ubsa, UBSA_MODVER); > >-/* >- * Huawei Exxx radio devices have a built in flash disk which is their >- * default power up configuration. This allows the device to carry its >- * own installation software. >- * >- * Instead of following the USB spec, and create multiple configuration >- * descriptors for this, the devices expects the driver to send >- * UF_DEVICE_REMOTE_WAKEUP to endpoint 2 to reset the device, so it >- * reprobes, now with the radio exposed. >- */ >- >-static usbd_status >-ubsa_huawei(device_t self, struct usb_attach_arg *uaa) { >- usb_device_request_t req; usbd_device_handle dev; >- usb_config_descriptor_t *cdesc; >- >- if (self == NULL) >- return (UMATCH_NONE); >- if (uaa == NULL) >- return (UMATCH_NONE); >- dev = uaa->device; >- if (dev == NULL) >- return (UMATCH_NONE); >- /* get the config descriptor */ >- cdesc = usbd_get_config_descriptor(dev); >- if (cdesc == NULL) >- return (UMATCH_NONE); >- >- if (cdesc->bNumInterface > 1) >- return (0); >- >- /* Bend it like Beckham */ >- device_printf(self, "Kicking Huawei device into radio mode\n"); >- memset(&req, 0, sizeof req); >- req.bmRequestType = UT_WRITE_DEVICE; >- req.bRequest = UR_SET_FEATURE; >- USETW(req.wValue, UF_DEVICE_REMOTE_WAKEUP); >- USETW(req.wIndex, 2); >- USETW(req.wLength, 0); >- >- /* We get error return, but it works */ >- (void)usbd_do_request(dev, &req, 0); >- return (UMATCH_NONE); >-} >- >- > static int > ubsa_match(device_t self) > { >@@ -399,9 +340,6 @@ ubsa_match(device_t self) > for (i = 0; ubsa_products[i].vendor != 0; i++) { > if (ubsa_products[i].vendor == uaa->vendor && > ubsa_products[i].product == uaa->product) { >- if (uaa->vendor == USB_VENDOR_HUAWEI && >- ubsa_huawei(self, uaa)) >- break; > return (UMATCH_VENDOR_PRODUCT); > } > } >@@ -424,9 +362,6 @@ ubsa_attach(device_t self) > dev = uaa->device; > ucom = &sc->sc_ucom; > >- if (uaa->vendor == USB_VENDOR_HUAWEI) >- sc->sc_huawei = 1; >- > /* > * initialize rts, dtr variables to something > * different from boolean 0, 1 >@@ -575,8 +510,6 @@ ubsa_request(struct ubsa_softc *sc, u_in > usbd_status err; > > /* The huawei Exxx devices support none of these tricks */ >- if (sc->sc_huawei) >- return (0); > req.bmRequestType = UT_WRITE_VENDOR_DEVICE; > req.bRequest = request; > USETW(req.wValue, value); > >Modified: head/sys/dev/usb/usbdevs >============================================================================== >--- head/sys/dev/usb/usbdevs Thu Oct 9 20:51:25 2008 (r183734) >+++ head/sys/dev/usb/usbdevs Thu Oct 9 21:25:01 2008 (r183735) >@@ -1434,7 +1434,7 @@ product HTC SMARTPHONE 0x0a51 SmartPhon > > /* HUAWEI products */ > product HUAWEI MOBILE 0x1001 Huawei Mobile >-product HUAWEI E270 0x1003 Huawei HSPA modem >+product HUAWEI E220 0x1003 Huawei HSDPA modem > > /* HUAWEI 3com products */ > product HUAWEI3COM WUB320G 0x0009 Aolynk WUB320g > >Modified: head/sys/i386/conf/GENERIC >============================================================================== >--- head/sys/i386/conf/GENERIC Thu Oct 9 20:51:25 2008 (r183734) >+++ head/sys/i386/conf/GENERIC Thu Oct 9 21:25:01 2008 (r183735) >@@ -304,6 +304,7 @@ device urio # Diamond >Rio 500 MP3 play > device uscanner # Scanners > # USB Serial devices > device ucom # Generic com ttys >+device u3g # USB-based 3G modems (Option, Huawei, Sierra) > device uark # Technologies ARK3116 based serial adapters > device ubsa # Belkin F5U103 and compatible > serial adapters > device uftdi # For FTDI usb serial adapters > >Modified: head/sys/modules/Makefile >============================================================================== >--- head/sys/modules/Makefile Thu Oct 9 20:51:25 2008 (r183734) >+++ head/sys/modules/Makefile Thu Oct 9 21:25:01 2008 (r183735) >@@ -269,6 +269,7 @@ SUBDIR= ${_3dfx} \ > twe \ > tx \ > txp \ >+ u3g \ > uark \ > uart \ > ubsa \ > >Added: head/sys/modules/u3g/Makefile >============================================================================== >--- /dev/null 00:00:00 1970 (empty, because file is newly added) >+++ head/sys/modules/u3g/Makefile Thu Oct 9 21:25:01 >2008 (r183735) >@@ -0,0 +1,8 @@ >+# $FreeBSD$ >+ >+.PATH: ${.CURDIR}/../../dev/usb >+ >+KMOD= u3g >+SRCS= u3g.c ucomvar.h opt_usb.h device_if.h bus_if.h usbdevs.h >+ >+.include >_______________________________________________ >svn-src-all@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/svn-src-all >To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" > >------------------------------------------------------- >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From mike at sentex.net Wed Nov 5 08:38:42 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Nov 5 08:38:54 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811051706.00850.nick@van-laarhoven.org> References: <200810092344.10388.nick@van-laarhoven.org> <200811051548.mA5Fmsot040177@lava.sentex.ca> <200811051706.00850.nick@van-laarhoven.org> Message-ID: <200811051638.mA5Gcdtj040411@lava.sentex.ca> At 11:06 AM 11/5/2008, Nick Hibma wrote: > > At 04:44 PM 10/9/2008, Nick Hibma wrote: > > >Just now I have committed a driver for Option and Huawei cards > > > previously supported by the ubsa driver. More information is in the > > > commit message. > > > > > >I am looking for people who would be able to provide more information > > > after testing with the 3G cards branded by: > > > > Hi, > > I gave it a try on the Sierra USB card and it seems to work > > really well on RELENG_7! There is however also a mini-pci express > > version of the Sierra card, the MC8775. Do you have plans to add > > support for it ? I am not sure how the unit is even supposed to show > > up as I dont see it in the dmesg, but I do see that it shows some > > sort of umass device > > > > # usbdevs > > addr 1: OHCI root hub, AMD > > addr 2: USB MMC Storage, Sierra Wireless > > addr 1: EHCI root hub, AMD > >If you could run usbdevs -v and then jot down the IDs you can add those to >the top of u3g.c. You'll have to add a quirk like for other sierra devices >that show up as mass storage and need to be kicked into modem mode. > >It pretends to be a mass storage device (with drivers on it) and after >installation switches to modem mode. > >Or that's my guess. # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), AMD(0x0000), rev 1.00 port 1 powered port 2 addr 2: full speed, power 100 mA, config 1, USB MMC Storage(0x0fff), Sierra Wireless(0x1199), rev 0.00 port 3 powered port 4 powered Controller /dev/usb1: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), AMD(0x0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered It looks like its already there in the drivers. Is it possible the mini-pci express card is conflicting with the USB of the Alix board ? ---Mike >Nick > > > dmesg snippet > > ... > > isa_probe_children: probing PnP devices > > umass0: > addr 2> on uhub0 > > umass0:0:0:-1: Attached to scbus0 > > Device configuration finished. > > procfs registered > > Timecounter "TSC" frequency 498053687 Hz quality 800 > > Timecounters tick every 1.000 msec > > crypto: > > vlan: initialized, using hash tables with chaining > > IPsec: Initialized Security Association Processing. > > pflog0: bpf attached > > lo0: bpf attached > > ata0-master: pio=PIO4 wdma=WDMA2 udma=UNSUPPORTED cable=40 wire > > ad0: setting PIO4 on CS5536 chip > > ad0: 1953MB at ata0-master PIO4 > > ad0: 4001760 sectors [3970C/16H/63S] 4 sectors/interrupt 1 depth queue > > GEOM: new disk ad0 > > pass0 at umass-sim0 bus 0 target 0 lun 0 > > pass0: Removable CD-ROM SCSI-0 device > > pass0: 1.000MB/s transfers > > Trying to mount root from ufs:/dev/ad0s1a > > start_init: trying /sbin/init > > bridge0: bpf attached > > bridge0: Ethernet address: 3a:72:35:a3:25:ce > > tun0: bpf attached > > > > Not sure why it shows up as a passthrough device ? > > > > ---Mike From nick at van-laarhoven.org Wed Nov 5 10:05:17 2008 From: nick at van-laarhoven.org (Nick Hibma) Date: Wed Nov 5 10:05:29 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811051638.mA5Gcdtj040411@lava.sentex.ca> References: <200810092344.10388.nick@van-laarhoven.org> <200811051706.00850.nick@van-laarhoven.org> <200811051638.mA5Gcdtj040411@lava.sentex.ca> Message-ID: <200811051905.05294.nick@van-laarhoven.org> > >If you could run usbdevs -v and then jot down the IDs you can add those > > to the top of u3g.c. You'll have to add a quirk like for other sierra > > devices that show up as mass storage and need to be kicked into modem > > mode. > > > >It pretends to be a mass storage device (with drivers on it) and after > >installation switches to modem mode. > > > >Or that's my guess. > > # usbdevs -v > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, OHCI root hub(0x0000), > AMD(0x0000), rev 1.00 > port 1 powered > port 2 addr 2: full speed, power 100 mA, config 1, USB MMC > Storage(0x0fff), Sierra Wireless(0x1199), rev 0.00 > port 3 powered > port 4 powered > Controller /dev/usb1: > addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), > AMD(0x0000), rev 1.00 > port 1 powered > port 2 powered > port 3 powered > port 4 powered > > It looks like its already there in the drivers. Is it possible the > mini-pci express card is conflicting with the USB of the Alix board ? Well, it should change to modem mode, so perhaps the sierra_init function is not correct yet. I'll have to check that out. nick From danny at dannysplace.net Wed Nov 5 22:09:43 2008 From: danny at dannysplace.net (Danny Carroll) Date: Wed Nov 5 22:09:50 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> <490FE404.2000308@dannysplace.net> Message-ID: <49128A27.2080405@dannysplace.net> Ivan Voras wrote: > Danny Carroll wrote: > >> - I have seen sustained 130Mb reads from ZFS: >> capacity operations bandwidth >> pool used avail read write read write >> ---------- ----- ----- ----- ----- ----- ----- >> bigarray 1.29T 3.25T 1.10K 0 140M 0 >> bigarray 1.29T 3.25T 1.00K 0 128M 0 >> bigarray 1.29T 3.25T 945 0 118M 0 >> bigarray 1.29T 3.25T 1.05K 0 135M 0 >> bigarray 1.29T 3.25T 1.01K 0 129M 0 >> bigarray 1.29T 3.25T 994 0 124M 0 >> >> ad4 ad6 ad8 cpu >> KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id >> 0.00 0 0.00 65.90 375 24.10 63.74 387 24.08 0 0 19 2 78 >> 0.00 0 0.00 66.36 357 23.16 63.93 370 23.11 0 0 23 2 75 >> 16.00 0 0.00 64.84 387 24.51 63.79 389 24.20 0 0 23 2 75 >> 16.00 2 0.03 68.09 407 27.04 64.98 409 25.98 0 0 28 2 70 > >> I'm curious if the ~130M figure shown above is bandwidth from the array >> or a total of all the drives. In other words, does it include reading >> the parity information? I think it does not since if I look at iostat >> figures and add up all of the drives it is greater than that reported by >> zfs by a factor of 5/4 (100M in Zfs iostat = 5 x 25Mb in standard iostat). > > The numbers make sense - you have 5 drives in RAID-Z and 4/5ths of total > bandwidth is the "real" bandwidth. On the other hand, 25 MB/s is very > slow for modern drives (assuming you're doing sequential read/write > tests). Are you having hardware problems? No, just the IO from disk to net is slow... >> Lastly, The windows client which performed these tests was measuring >> local bandwidth at about 30-50Mb/s. I believe this figure to be >> incorrect (given how much I transferred in X seconds...) > > Using Samba? Search the lists for Samba performance advice - the default > configuration isn't nearly optimal. In my second post I mentioned that the IO windows was reporting was right. I was getting about 50Mb/sec but ZFS was reporting about 130M/s. I timed this by copying 20Gb and timing it with my watch. Just as a rough guide. I am curious about this inconsistency. If anyone has any ideas??? -D From tethys.ocean at gmail.com Thu Nov 6 02:14:46 2008 From: tethys.ocean at gmail.com (tethys ocean) Date: Thu Nov 6 02:14:53 2008 Subject: Broadcom Netxtreme Ethernet Boot Agent v10.7.5 Message-ID: <235b80000811060148o115e2696r3045c7e6db4a14b2@mail.gmail.com> Hi all I am installed FreeBSD 7.0 to DELL Poweredge T100 but freebsd cant set its NIC in dmesg print is *pci4 at device 0.0 (no diriver attached)* FreeBSD cant recognize this ethernet card in below since its card is *Broadcom Netxtreme Ethernet Boot Agent v10.7.5* -- Share now a pigeon's flight Bluebound along the ancient skies, Its women forever hair and mammal, A Mediterranean town may arise If you rip apart a pigeon's heart. From peterjeremy at optushome.com.au Thu Nov 6 02:48:53 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Nov 6 02:48:59 2008 Subject: Broadcom Netxtreme Ethernet Boot Agent v10.7.5 In-Reply-To: <235b80000811060148o115e2696r3045c7e6db4a14b2@mail.gmail.com> References: <235b80000811060148o115e2696r3045c7e6db4a14b2@mail.gmail.com> Message-ID: <20081106104849.GE51239@server.vk2pj.dyndns.org> On 2008-Nov-06 11:48:36 +0200, tethys ocean wrote: >I am installed FreeBSD 7.0 to DELL Poweredge T100 but freebsd cant set its >NIC in dmesg print is *pci4 at device 0.0 (no diriver >attached)* Can you provide the relevant lines from 'pciconf -lv' please. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081106/f20d80ea/attachment.pgp From tethys.ocean at gmail.com Thu Nov 6 08:44:36 2008 From: tethys.ocean at gmail.com (tethys ocean) Date: Thu Nov 6 08:44:42 2008 Subject: Broadcom Netxtreme Ethernet Boot Agent v10.7.5 In-Reply-To: <20081106104849.GE51239@server.vk2pj.dyndns.org> References: <235b80000811060148o115e2696r3045c7e6db4a14b2@mail.gmail.com> <20081106104849.GE51239@server.vk2pj.dyndns.org> Message-ID: <235b80000811060844p68b6b09rfbb82e31532dcd6b@mail.gmail.com> none0@pci0:4:0:0 class=0x020000 card=0x028b1028 chip=0x165a14e4 rev=0x00 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtrere BMC5722 Gigabit Ethernet PCIe' class = network subclass = ethernet On Thu, Nov 6, 2008 at 12:48 PM, Peter Jeremy wrote: > On 2008-Nov-06 11:48:36 +0200, tethys ocean > wrote: > >I am installed FreeBSD 7.0 to DELL Poweredge T100 but freebsd cant set > its > >NIC in dmesg print is *pci4 at device 0.0 (no diriver > >attached)* > > Can you provide the relevant lines from 'pciconf -lv' please. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > -- Share now a pigeon's flight Bluebound along the ancient skies, Its women forever hair and mammal, A Mediterranean town may arise If you rip apart a pigeon's heart. From peterjeremy at optushome.com.au Thu Nov 6 10:26:57 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Thu Nov 6 10:27:05 2008 Subject: Broadcom Netxtreme Ethernet Boot Agent v10.7.5 In-Reply-To: <235b80000811060844p68b6b09rfbb82e31532dcd6b@mail.gmail.com> References: <235b80000811060148o115e2696r3045c7e6db4a14b2@mail.gmail.com> <20081106104849.GE51239@server.vk2pj.dyndns.org> <235b80000811060844p68b6b09rfbb82e31532dcd6b@mail.gmail.com> Message-ID: <20081106182653.GF51239@server.vk2pj.dyndns.org> On 2008-Nov-06 18:44:34 +0200, tethys ocean wrote: >none0@pci0:4:0:0 class=0x020000 card=0x028b1028 chip=0x165a14e4 rev=0x00 >hdr=0x00 >vendor = 'Broadcom Corporation' >device = 'NetXtrere BMC5722 Gigabit Ethernet PCIe' >class = network >subclass = ethernet Support for this chip was added somewhat after 7.0 was released. Can you please try one of the FreeBSD 7.1 pre-release snapshots. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081106/8ec259a9/attachment.pgp From mike at sentex.net Thu Nov 6 14:03:47 2008 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 6 14:03:54 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811051548.mA5Fmsot040177@lava.sentex.ca> References: <200810092344.10388.nick@van-laarhoven.org> <200811051548.mA5Fmsot040177@lava.sentex.ca> Message-ID: <200811062203.mA6M3ij3048835@lava.sentex.ca> At 10:48 AM 11/5/2008, Mike Tancsa wrote: >At 04:44 PM 10/9/2008, Nick Hibma wrote: >>Just now I have committed a driver for Option and Huawei cards previously >>supported by the ubsa driver. More information is in the commit message. >> >>I am looking for people who would be able to provide more information after >>testing with the 3G cards branded by: > >Hi, > I gave it a try on the Sierra USB card and it seems to work > really well on RELENG_7! There is however also a mini-pci express > version of the Sierra card, the MC8775. For the archives, I was able to get the card working with the latest version of the driver from the SVN tree! (http://people.freebsd.org/~n_hibma/u3g.html) For the hardware, I used http://www.pcengines.ch/alix6b2.htm with RELENG_7 and nanobsd. The board has dual SIM slots, but there are no drivers to switch between the two, so just the top one works. When I bought the mini-pciexpress card (or PCI Express Mini Card), it was listed as a MC8775, where as ati3 shows a Sierra MC8781. I bought it on ebay from the US and it works fine using my Roger's blackbery SIM here in Ontario, Canada. # cat /var/run/dmesg.boot Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.1-PRERELEASE #0: Thu Nov 6 12:05:41 EST 2008 mdtancsa@nanobsd2.sentex.ca:/usr/obj/nanobsd.alix/usr/src/sys/nano5501 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 Features=0x88a93d AMD Features=0xc0400000 real memory = 268435456 (256 MB) avail memory = 253202432 (241 MB) pnpbios: Bad PnP BIOS data checksum K6-family MTRR support enabled (2 registers) cryptosoft0: on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 ... u3gstub0: at uhub0 port 2 (addr 2) disconnected u3gstub0: detached .... ucom0: on uhub0 ucom0: configured 3 serial ports (U0.%d) # cu -l /dev/cuaU0.2 Connected ati Manufacturer: Sierra Wireless, Inc. Model: MC8781 Revision: F1_0_0_4CAP C:/WS/FW/F1_0_0_4CAP/MSM7200R3/SRC/AMSS 2007/09/25 18:39:23 IMEI: 356685011922513 IMEI SV: 4 FSN: D350568535811 3GPP Release 6 +GCAP: +CGSM,+DS,+ES at!GSTATUS? !GSTATUS: Current Time: 3455 Temperature: 30 Bootup Time: 3201 Mode: ONLINE System mode: WCDMA PS state: Not attached WCDMA band: WCDMA800 GSM band: Unknown WCDMA channel: 1037 GSM channel: 65535 GMM (PS) state:DEREGISTERED NO IMSI MM (CS) state: IDLE NO IMSI WCDMA L1 State:L1M_PCH_SLEEP RRC State: DISCONNECTED RX level (dBm):-87 OK at^SYSINFO ^SYSINFO: 1,0,1,5,255 From todorov at paladin.bulgarpress.com Thu Nov 6 14:27:57 2008 From: todorov at paladin.bulgarpress.com (Todorov) Date: Thu Nov 6 14:28:10 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811062203.mA6M3ij3048835@lava.sentex.ca> References: <200810092344.10388.nick@van-laarhoven.org> <200811051548.mA5Fmsot040177@lava.sentex.ca> <200811062203.mA6M3ij3048835@lava.sentex.ca> Message-ID: <49136B55.8040704@paladin.bulgarpress.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is this source supposed to support PCMCIA Huawei E630 card? I can give a test if so... Regards, Mike Tancsa ??????: | At 10:48 AM 11/5/2008, Mike Tancsa wrote: |> At 04:44 PM 10/9/2008, Nick Hibma wrote: |>> Just now I have committed a driver for Option and Huawei cards |>> previously |>> supported by the ubsa driver. More information is in the commit message. |>> |>> I am looking for people who would be able to provide more information |>> after |>> testing with the 3G cards branded by: |> |> Hi, |> I gave it a try on the Sierra USB card and it seems to work |> really well on RELENG_7! There is however also a mini-pci express |> version of the Sierra card, the MC8775. | | | For the archives, I was able to get the card working with the latest | version of the driver from the SVN tree! | (http://people.freebsd.org/~n_hibma/u3g.html) | | For the hardware, I used | http://www.pcengines.ch/alix6b2.htm | with RELENG_7 and nanobsd. The board has dual SIM slots, but there are | no drivers to switch between the two, so just the top one works. | | When I bought the mini-pciexpress card (or PCI Express Mini Card), it | was listed as a MC8775, where as ati3 shows a Sierra MC8781. I bought | it on ebay from the US and it works fine using my Roger's blackbery SIM | here in Ontario, Canada. | | | # cat /var/run/dmesg.boot | Copyright (c) 1992-2008 The FreeBSD Project. | Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 | The Regents of the University of California. All rights reserved. | FreeBSD is a registered trademark of The FreeBSD Foundation. | FreeBSD 7.1-PRERELEASE #0: Thu Nov 6 12:05:41 EST 2008 | mdtancsa@nanobsd2.sentex.ca:/usr/obj/nanobsd.alix/usr/src/sys/nano5501 | Timecounter "i8254" frequency 1193182 Hz quality 0 | CPU: Geode(TM) Integrated Processor by AMD PCS (498.05-MHz 586-class CPU) | Origin = "AuthenticAMD" Id = 0x5a2 Stepping = 2 | Features=0x88a93d | AMD Features=0xc0400000 | real memory = 268435456 (256 MB) | avail memory = 253202432 (241 MB) | pnpbios: Bad PnP BIOS data checksum | K6-family MTRR support enabled (2 registers) | cryptosoft0: on motherboard | pcib0: pcibus 0 on motherboard | pci0: on pcib0 | ... | u3gstub0: at uhub0 port 2 (addr 2) disconnected | u3gstub0: detached | .... | ucom0: on uhub0 | ucom0: configured 3 serial ports (U0.%d) | | | | # cu -l /dev/cuaU0.2 | Connected | ati | Manufacturer: Sierra Wireless, Inc. | Model: MC8781 | Revision: F1_0_0_4CAP C:/WS/FW/F1_0_0_4CAP/MSM7200R3/SRC/AMSS 2007/09/25 | 18:39:23 | IMEI: 356685011922513 | IMEI SV: 4 | FSN: D350568535811 | 3GPP Release 6 | +GCAP: +CGSM,+DS,+ES | | at!GSTATUS? | !GSTATUS: | Current Time: 3455 Temperature: 30 | Bootup Time: 3201 Mode: ONLINE | System mode: WCDMA PS state: Not attached | WCDMA band: WCDMA800 GSM band: Unknown | WCDMA channel: 1037 GSM channel: 65535 | GMM (PS) state:DEREGISTERED NO IMSI | MM (CS) state: IDLE NO IMSI | | WCDMA L1 State:L1M_PCH_SLEEP RRC State: DISCONNECTED | RX level (dBm):-87 | | | OK | at^SYSINFO | ^SYSINFO: 1,0,1,5,255 | _______________________________________________ | freebsd-hardware@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-hardware | To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkTa1QACgkQibJkIG65HMcAnQCgyeSvhIubmFifIh/SDntGY65M 3fcAmgNG7cL5zrBuCvhizskwQEgGZ35/ =Xg4D -----END PGP SIGNATURE----- From koitsu at FreeBSD.org Thu Nov 6 23:17:54 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Nov 6 23:18:02 2008 Subject: Western Digital hard disks and ATA timeouts Message-ID: <20081107071752.GA5842@icarus.home.lan> A user and myself on a broadband forum were discussing the possibility of diminishing quality of hard disks (particularly 1TB models) in recent days (specifically October). The user continually referenced something called "deep recovery cycle", backed with claims from Newegg reviewers (who often know very little or nothing at all -- grain of salt concept applies), which make Western Digital's desktop hard disks unfit for RAID or server usage. I claimed shenanigans until the user pointed me to the following document on Western Digital's site: http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1397 The feature described apparently causes the hard disk to enter some form of aggressive sector scan/sector remapping loop, which can take up to 2 minutes to complete, during which time, the hard disk is basically unusable. (I imagine ATA commands sent to the disk will simply time out or stall indefinitely, which would result in all sorts of timeout errors). Note that Western Digital's "RAID edition" drives claim to take up to 7 seconds to reallocate sectors, using something they call TLER, which force-limits the amount of time the drive can spend reallocating. TLER cannot be disabled: http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=1478 What baffles me is why Western Digital thinks that 2 minutes of the drive being unusable is acceptable "but only for desktops". Any FreeBSD desktop will start reporting ATA timeouts if the drive wedges for more than 5 seconds -- two minutes would just spew errors and hard-lock the system. What also baffles me is why Western Digital thinks the term "RAID" always means a hardware RAID controller is involved as a buffer between the OS and the disks. Bzzzt, bad assumption on their part. So why do we care? As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and is not adjustable without editing the ATA code yourself and increasing the value. The FreeNAS folks have made patches available to turn the timeout value into a sysctl. Soren and/or others, please increase this timeout value. Five seconds has now been deemed too aggressive a default. And please consider migrating the timeout value into a sysctl. P.S. -- I do not consider any of this reason to avoid Western Digital drives. But I would warn users to be a little more cautious before reporting ATA timeouts when newer (circia 2007 and later) WD drives are in use. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From fbsdlist at src.cx Fri Nov 7 00:34:42 2008 From: fbsdlist at src.cx (Artem Belevich) Date: Fri Nov 7 00:34:48 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: <20081107071752.GA5842@icarus.home.lan> References: <20081107071752.GA5842@icarus.home.lan> Message-ID: > Note that Western Digital's "RAID edition" drives claim to take up to 7 > seconds to reallocate sectors, using something they call TLER, which > force-limits the amount of time the drive can spend reallocating. TLER > cannot be disabled: TLER can be enabled/disabled on recent WD drives (SE16/RE2/GP). SE16/GP come with TLER off, RE2 with TLER on. Google WDTLER utility. It can apparently be obtained from WD by asking them nicely. Or, yet again, google is your friend. Here's one example - http://www.hardforum.com/archive/index.php/t-1191548.html --Artem From koitsu at FreeBSD.org Fri Nov 7 00:36:30 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Nov 7 00:36:42 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: References: <20081107071752.GA5842@icarus.home.lan> Message-ID: <20081107083626.GA1583@icarus.home.lan> On Fri, Nov 07, 2008 at 12:08:01AM -0800, Artem Belevich wrote: > > Note that Western Digital's "RAID edition" drives claim to take up to 7 > > seconds to reallocate sectors, using something they call TLER, which > > force-limits the amount of time the drive can spend reallocating. TLER > > cannot be disabled: > > TLER can be enabled/disabled on recent WD drives (SE16/RE2/GP). SE16/GP > come with TLER off, RE2 with TLER on. Google WDTLER utility. > It can apparently be obtained from WD by asking them nicely. > Or, yet again, google is your friend. Here's one example - > http://www.hardforum.com/archive/index.php/t-1191548.html Thanks for the information. Nice to know one of their FAQ entries is false. Also, note that "SE16/RE2/GP" is not specific enough; I have SE16 drives from 2005, and I highly doubt those have TLER capability due to their age. Also, there's a Wikipedia article on this whole fiasco. http://en.wikipedia.org/wiki/Time-Limited_Error_Recovery It also appears Samsung drives have a similar feature called CCTL, which uses a value of 7 or 8 seconds: http://www.samsung.com/global/business/hdd/learningresource/whitepapers/LearningResource_CCTL.html But regardless of TLER being toggleable, FreeBSD's ATA command timeout of 5 seconds is too aggressive, and should be increased. Likewise, the value should be a sysctl, so those who do want such aggressive values can use it at the community's -- or their own -- behest. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From nick at van-laarhoven.org Fri Nov 7 05:53:19 2008 From: nick at van-laarhoven.org (Nick Hibma) Date: Fri Nov 7 05:53:26 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200811062203.mA6M3ij3048835@lava.sentex.ca> References: <200810092344.10388.nick@van-laarhoven.org> <200811051548.mA5Fmsot040177@lava.sentex.ca> <200811062203.mA6M3ij3048835@lava.sentex.ca> Message-ID: <200811071453.07665.nick@van-laarhoven.org> > For the hardware, I used > http://www.pcengines.ch/alix6b2.htm > with RELENG_7 and nanobsd. The board has dual SIM slots, but there > are no drivers to switch between the two, so just the top one works. If anyone can find information on how to switch SIM slot on the card, I'd be more than happy to include support for it. Would be very useful to have. > at!GSTATUS? > !GSTATUS: > Current Time: 3455 Temperature: 30 > Bootup Time: 3201 Mode: ONLINE > System mode: WCDMA PS state: Not attached > WCDMA band: WCDMA800 GSM band: Unknown > WCDMA channel: 1037 GSM channel: 65535 > GMM (PS) state:DEREGISTERED NO IMSI > MM (CS) state: IDLE NO IMSI > > WCDMA L1 State:L1M_PCH_SLEEP RRC State: DISCONNECTED > RX level (dBm):-87 > > > OK One learns something new every day! > at^SYSINFO > ^SYSINFO: 1,0,1,5,255 Anyone any info on how to decode this? Nick From jhs at berklix.org Fri Nov 7 08:00:09 2008 From: jhs at berklix.org (Julian Stacey) Date: Fri Nov 7 08:00:16 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: Your message "Fri, 07 Nov 2008 00:36:26 PST." <20081107083626.GA1583@icarus.home.lan> Message-ID: <200811071541.mA7FfKEF021236@fire.js.berklix.net> > But regardless of TLER being toggleable, FreeBSD's ATA command timeout > of 5 seconds is too aggressive, and should be increased. Likewise, the > value should be a sysctl, so those who do want such aggressive values Once it migrates from a constant to sysctl variable, could kernel maybe also sniff the drives, & automatically set appropriate value ? (Just an idea ? :-) Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.org From tethys.ocean at gmail.com Fri Nov 7 09:00:17 2008 From: tethys.ocean at gmail.com (tethys ocean) Date: Fri Nov 7 09:00:24 2008 Subject: Broadcom Netxtreme Ethernet Boot Agent v10.7.5 In-Reply-To: <20081106182653.GF51239@server.vk2pj.dyndns.org> References: <235b80000811060148o115e2696r3045c7e6db4a14b2@mail.gmail.com> <20081106104849.GE51239@server.vk2pj.dyndns.org> <235b80000811060844p68b6b09rfbb82e31532dcd6b@mail.gmail.com> <20081106182653.GF51239@server.vk2pj.dyndns.org> Message-ID: <235b80000811070900g6463d56h3ae3e9a5b8cecd0b@mail.gmail.com> Hi Peter, so so thank for your for your spending time and your help.. after installations i ve done update port tree and compiled kernel finally NIC is recognized default being bge0 and now it is running properly. since no problem about NIC my FreeBSD version is anymore 7.1 RELEASE but havent got any NIC problem so so thanks again On Thu, Nov 6, 2008 at 8:26 PM, Peter Jeremy wrote: > On 2008-Nov-06 18:44:34 +0200, tethys ocean > wrote: > >none0@pci0:4:0:0 class=0x020000 card=0x028b1028 chip=0x165a14e4 rev=0x00 > >hdr=0x00 > >vendor = 'Broadcom Corporation' > >device = 'NetXtrere BMC5722 Gigabit Ethernet PCIe' > >class = network > >subclass = ethernet > > Support for this chip was added somewhat after 7.0 was released. > Can you please try one of the FreeBSD 7.1 pre-release snapshots. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > -- Share now a pigeon's flight Bluebound along the ancient skies, Its women forever hair and mammal, A Mediterranean town may arise If you rip apart a pigeon's heart. From peter at wemm.org Fri Nov 7 11:41:29 2008 From: peter at wemm.org (Peter Wemm) Date: Fri Nov 7 11:41:35 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: <20081107071752.GA5842@icarus.home.lan> References: <20081107071752.GA5842@icarus.home.lan> Message-ID: On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick wrote: [..] > As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and > is not adjustable without editing the ATA code yourself and increasing > the value. The FreeNAS folks have made patches available to turn the > timeout value into a sysctl. > > Soren and/or others, please increase this timeout value. Five seconds > has now been deemed too aggressive a default. And please consider > migrating the timeout value into a sysctl. The 5 second timeout has been a problem for quite a while actually. I've had a number of instances where I've had to increase it to 20 or 30 seconds when recovering from marginal drives. The longest "successful" recovery attempt I've seen was 26 seconds, I believe on a Maxtor drive a few years ago. ("successful" == the drive spent 26 seconds but eventually successfully read the sector). Even the IBM death star drives could take much longer than 5 seconds to do a recovery 5 years ago. 5 seconds has never been a good default. I think the timeout should be increased to at least 30 seconds. My windows box has a timeout that goes for several minutes. If there is concern about FreeBSD appearing to hang, I could imagine that a console warning message could be printed after 5 seconds. But just say "drive has not yet responded". But give it more time. In this day and age we're generally not playing games with udma33 vs 66, notched cables, poor CRC support etc. SATA seems to have eliminated all that. Hmm, it might make sense to increase the timeout on SATA connections to 2 or 3 minutes by default. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell From votdev at gmx.de Fri Nov 7 13:02:34 2008 From: votdev at gmx.de (Volker Theile) Date: Fri Nov 7 13:02:47 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: References: <20081107071752.GA5842@icarus.home.lan> Message-ID: <4914A6A1.9050909@gmx.de> I can confirm that. Many FreeNAS users had problems with their HDDs (e.g. with APM, awake disks to access them after they felt to sleep). Increasing timeouts solves the problem in most cases. I think increasing the value BUT allowing the user to set it to a preferred value via sysctrl would be the best solution. I don't understand why adding such an sysctl interface is such an problem for some people. If someone wants to set any other value than the default one HE MUST KNOW what he do and live with the consequences. There are so many other kernel/system variables that can harm the system. Regards Volker Peter Wemm wrote: > On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick wrote: > [..] > >> As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and >> is not adjustable without editing the ATA code yourself and increasing >> the value. The FreeNAS folks have made patches available to turn the >> timeout value into a sysctl. >> >> Soren and/or others, please increase this timeout value. Five seconds >> has now been deemed too aggressive a default. And please consider >> migrating the timeout value into a sysctl. >> > > The 5 second timeout has been a problem for quite a while actually. > I've had a number of instances where I've had to increase it to 20 or > 30 seconds when recovering from marginal drives. The longest > "successful" recovery attempt I've seen was 26 seconds, I believe on a > Maxtor drive a few years ago. ("successful" == the drive spent 26 > seconds but eventually successfully read the sector). Even the IBM > death star drives could take much longer than 5 seconds to do a > recovery 5 years ago. 5 seconds has never been a good default. > > I think the timeout should be increased to at least 30 seconds. My > windows box has a timeout that goes for several minutes. > > If there is concern about FreeBSD appearing to hang, I could imagine > that a console warning message could be printed after 5 seconds. But > just say "drive has not yet responded". But give it more time. > > In this day and age we're generally not playing games with udma33 vs > 66, notched cables, poor CRC support etc. SATA seems to have > eliminated all that. Hmm, it might make sense to increase the timeout > on SATA connections to 2 or 3 minutes by default. > > ------------------------------------------------------------------------ > > > Internal Virus Database is out of date. > Checked by AVG - http://www.avg.com > Version: 8.0.175 / Virus Database: 270.8.5/1764 - Release Date: 03.11.2008 07:46 > > From whizzter at gmail.com Fri Nov 7 13:13:48 2008 From: whizzter at gmail.com (Jonas Lund) Date: Fri Nov 7 13:13:54 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: References: <20081107071752.GA5842@icarus.home.lan> Message-ID: <436c7eda0811071249g33a81c75w85b971ad23a9847d@mail.gmail.com> As i'm writing this i'm trying to rescue the contents of another computers disk. Something about the seek heads or something related to that is physically half-broken so the disk might need up to 10 retries just to read a sector, once read however it's usually no problem. I'm using myrescue (running on 6.2 so i don't know if it's included in the current ports but if anyone wants to run it on freebsd i've done the "gruntwork" for porting) so it's not a really big issue with all the timeouts as it'll try to read that sector again later, but had i had the sysctl i would've been a tad happier right now. As for the defaults being a small value i personally think it's better to throw out some messages/errors early on before the disk reaches a catastrophic state (Atleast on 6.2 the kernel will put out a message for each retry without giving faults, maybe more retries before throwing an error maybe?). By catastrpohic state i'm refering to that oh-so-famous google paper that did say that once a disk has started showing errors it doesn't have long to live, but i do trust that conclusion as i've been "warned" by these messages 2 times but ignored them until the disk went really bad. The main thing i'm trying to get through is that early warning and small problems are helluva lot better than big disasters. Thing of it like the oil meter on your car, it's not like you're gonna go out and drive 100s of km's in the wilderness if you know that the car is in a bad state. (Now if only smart info was reliable!) / Jonas 2008/11/7 Peter Wemm : > On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick wrote: > [..] >> As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and >> is not adjustable without editing the ATA code yourself and increasing >> the value. The FreeNAS folks have made patches available to turn the >> timeout value into a sysctl. >> >> Soren and/or others, please increase this timeout value. Five seconds >> has now been deemed too aggressive a default. And please consider >> migrating the timeout value into a sysctl. > > The 5 second timeout has been a problem for quite a while actually. > I've had a number of instances where I've had to increase it to 20 or > 30 seconds when recovering from marginal drives. The longest > "successful" recovery attempt I've seen was 26 seconds, I believe on a > Maxtor drive a few years ago. ("successful" == the drive spent 26 > seconds but eventually successfully read the sector). Even the IBM > death star drives could take much longer than 5 seconds to do a > recovery 5 years ago. 5 seconds has never been a good default. > > I think the timeout should be increased to at least 30 seconds. My > windows box has a timeout that goes for several minutes. > > If there is concern about FreeBSD appearing to hang, I could imagine > that a console warning message could be printed after 5 seconds. But > just say "drive has not yet responded". But give it more time. > > In this day and age we're generally not playing games with udma33 vs > 66, notched cables, poor CRC support etc. SATA seems to have > eliminated all that. Hmm, it might make sense to increase the timeout > on SATA connections to 2 or 3 minutes by default. > -- > Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV > "All of this is for nothing if we don't go to the stars" - JMS/B5 > "If Java had true garbage collection, most programs would delete > themselves upon execution." -- Robert Sewell > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > From sos at FreeBSD.ORG Fri Nov 7 13:28:22 2008 From: sos at FreeBSD.ORG (=?ISO-8859-1?Q?S=F8ren_Schmidt?=) Date: Fri Nov 7 13:28:29 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: References: <20081107071752.GA5842@icarus.home.lan> Message-ID: <77C223A7-C5FC-45DE-BF1A-3BC7982FA582@FreeBSD.ORG> On 7Nov, 2008, at 20:12 , Peter Wemm wrote: > On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick > wrote: > [..] >> As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, >> and >> is not adjustable without editing the ATA code yourself and >> increasing >> the value. The FreeNAS folks have made patches available to turn the >> timeout value into a sysctl. >> >> Soren and/or others, please increase this timeout value. Five >> seconds >> has now been deemed too aggressive a default. And please consider >> migrating the timeout value into a sysctl. > > The 5 second timeout has been a problem for quite a while actually. > I've had a number of instances where I've had to increase it to 20 or > 30 seconds when recovering from marginal drives. The longest > "successful" recovery attempt I've seen was 26 seconds, I believe on a > Maxtor drive a few years ago. ("successful" == the drive spent 26 > seconds but eventually successfully read the sector). Even the IBM > death star drives could take much longer than 5 seconds to do a > recovery 5 years ago. 5 seconds has never been a good default. > > I think the timeout should be increased to at least 30 seconds. My > windows box has a timeout that goes for several minutes. > > If there is concern about FreeBSD appearing to hang, I could imagine > that a console warning message could be printed after 5 seconds. But > just say "drive has not yet responded". But give it more time. > > In this day and age we're generally not playing games with udma33 vs > 66, notched cables, poor CRC support etc. SATA seems to have > eliminated all that. Hmm, it might make sense to increase the timeout > on SATA connections to 2 or 3 minutes by default. Actually I do have a patch around that logs the timeout on the console after the normal timeout (5secs), then just goes on to wait for double the timeout and log again etc etc, final timeout was IIRC 60 secs but could be anything. -S?ren From stb at lassitu.de Sat Nov 8 07:56:27 2008 From: stb at lassitu.de (Stefan Bethke) Date: Sat Nov 8 07:56:40 2008 Subject: Request for testers: Option 3G cards, also Sierra, Huawei and Novatel In-Reply-To: <200810092344.10388.nick@van-laarhoven.org> References: <200810092344.10388.nick@van-laarhoven.org> Message-ID: <65A46633-F826-4848-B459-9B21DDB4C469@lassitu.de> Am 09.10.2008 um 23:44 schrieb Nick Hibma: > Just now I have committed a driver for Option and Huawei cards > previously > supported by the ubsa driver. More information is in the commit > message. I've got an O2 Germany branded Huawai U169 here that offers the main serial port as it's first function, so it is working with the old driver already. The new driver (as in -current as of yesterday) seems to work fine for the PPP connection and using cuaU0.2 to query the status while the connection is active. Machine is a VMware image hosted on a Mac Pro. at+cgmi huawei OK at+cgmm E169G OK at+cgmr 11.314.07.00.00 dmesg is a bit garbled: u3gstub0: <\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? \M^?\M^?\M^?\M^? HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 3> on uhub0 u3gstub0: at uhub0 port 1 (addr 3) disconnected u3gstub0: detached ucom0: <\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? \M^?\M^?\M^?\M^? HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 3> on uhub0 ucom0: configured 3 serial ports (U0.%d) umass0: <\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^?\M^? \M^?\M^?\M^?\M^? HUAWEI Mobile, class 0/0, rev 1.10/0.00, addr 3> on uhub0 cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 1.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount the ISO9660 image fails with: root@freebsd-current:/etc/ppp# mount -t iso9660 /dev/cd0 /mnt mount: /dev/cd0 : Operation not supported by device usbdevs sees this: Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 3: full speed, power 500 mA, config 1, HUAWEI Mobile(0x1001), ???????????????????(0x12d1), rev 0.00 HTH, Stefan -- Stefan Bethke Fon +49 170 346 0140 From joe at zircon.seattle.wa.us Sun Nov 9 15:49:36 2008 From: joe at zircon.seattle.wa.us (Joe Kelsey) Date: Sun Nov 9 16:05:28 2008 Subject: Western Digital hard disks and ATA timeouts In-Reply-To: <77C223A7-C5FC-45DE-BF1A-3BC7982FA582@FreeBSD.ORG> References: <20081107071752.GA5842@icarus.home.lan> <77C223A7-C5FC-45DE-BF1A-3BC7982FA582@FreeBSD.ORG> Message-ID: <49177244.9060802@zircon.seattle.wa.us> S?ren Schmidt wrote: > On 7Nov, 2008, at 20:12 , Peter Wemm wrote: > >> On Thu, Nov 6, 2008 at 11:17 PM, Jeremy Chadwick >> wrote: >> [..] >>> As stated, FreeBSD's ATA command timeout is hard-set to 5 seconds, and >>> is not adjustable without editing the ATA code yourself and increasing >>> the value. The FreeNAS folks have made patches available to turn the >>> timeout value into a sysctl. >>> >>> Soren and/or others, please increase this timeout value. Five seconds >>> has now been deemed too aggressive a default. And please consider >>> migrating the timeout value into a sysctl. >> >> The 5 second timeout has been a problem for quite a while actually. >> I've had a number of instances where I've had to increase it to 20 or >> 30 seconds when recovering from marginal drives. The longest >> "successful" recovery attempt I've seen was 26 seconds, I believe on a >> Maxtor drive a few years ago. ("successful" == the drive spent 26 >> seconds but eventually successfully read the sector). Even the IBM >> death star drives could take much longer than 5 seconds to do a >> recovery 5 years ago. 5 seconds has never been a good default. >> >> I think the timeout should be increased to at least 30 seconds. My >> windows box has a timeout that goes for several minutes. >> >> If there is concern about FreeBSD appearing to hang, I could imagine >> that a console warning message could be printed after 5 seconds. But >> just say "drive has not yet responded". But give it more time. >> >> In this day and age we're generally not playing games with udma33 vs >> 66, notched cables, poor CRC support etc. SATA seems to have >> eliminated all that. Hmm, it might make sense to increase the timeout >> on SATA connections to 2 or 3 minutes by default. > > Actually I do have a patch around that logs the timeout on the console > after the normal timeout (5secs), then just goes on to wait for double > the timeout and log again etc etc, final timeout was IIRC 60 secs but > could be anything. I have a disk which I am finally getting rid of that produces READ_DMA and WRITE_DMA errors at a pretty high rate. I did enable the extra ATA error reporting and it doesn't seem to indicate any sort of actual errors, just extra long itmeouts. At one time, I did change the system to extend the timeout, but I did not see any real improvement at 30 seconds. I suspect that an even more extended timeout would be necessary to solve the problem. I am removing the disk this week. Does anyone want a disk that produces DMA timeouts at a regular rate? Would it help actually solve this problem? Please let me know if you want such a beast and I will ship it to you. /Joe From roberth.sjonoy at gmail.com Tue Nov 11 08:02:26 2008 From: roberth.sjonoy at gmail.com (=?ISO-8859-1?Q?Roberth_Sjon=F8y?=) Date: Tue Nov 11 08:02:34 2008 Subject: cmi 8788 support? Message-ID: Hello, I see that FreeBSD 7.1-BETA2 supports creatives X-FI soundcards, but I'm wondering where the support for the widely used cmi8788 chipset is? Regards, Roberth Sjon?y From ltning at mac.com Wed Nov 12 02:29:19 2008 From: ltning at mac.com (=?ISO-8859-1?Q?Eirik_=D8verby?=) Date: Wed Nov 12 02:29:26 2008 Subject: FreeBSD-AMD64 on Xeon MP - SOLVED In-Reply-To: <6D397584-2B6B-4F1A-B5C4-2A7B77AE52EB@anduin.net> References: <6D397584-2B6B-4F1A-B5C4-2A7B77AE52EB@anduin.net> Message-ID: Hi all, the issue below has been solved by a new BIOS for the server in question. I recently received a beta BIOS from Supermicro, after having reported the issue and done a bit of troubleshooting with them. The tip that helped the most was the boot-linux-first trick. Anyone who wants the BIOS may mail me privately; otherwise it'll likely be released by Supermicro in the not-too-distant future. /Eirik On Oct 20, 2008, at 08:22, Eirik ?verby wrote: > Hi, > >> > Hi all, >> > >> > I try to run FreeBSD-7-AMD64 on a Quad Xeon (Xeon MP 7320) and >> 32GB RAM. >> > The Board is a X7QC3 by supermicro and the installation is done on >> > another system, updated and plugged to this system. So I have a >> drive >> > with 7-STABLE compiled today. >> > >> > The last line I see from dmesg is vga0- then the system freezes. >> > >> > Anyone using a similar configuration or knows what could be >> wrong? I >> > still have some days left to play with it, before this box gets >> shipped >> > to the customer. >> >> This looks very, very similar to what I had once, on similar hardware >> (4x Xeon 7xxx, SuperMicro). I didn't find a solution and didn't >> bother >> since the box isn't intended for FreeBSD. I did find (by accident) a >> curious workaround: I booted Linux (I used Ubuntu 8.04 amd64 LiveCD - >> just to boot it, without installing), then rebooted and booted >> FreeBSD - >> worked every time, but it's obviously not a long-term solution. If >> you >> can also verify that this "solves" the problem, then someone might >> work >> with you to produce a patch. > > I just received four such servers, all intended for FreeBSD.... And > I'm seeing exactly the same problem. I'm going to try booting Linux > and then back into FreeBSD, but it's obviously not a solution. > Anyone who might want to work on this can have a box like this to > work on via remote KVM (including remote boot media capability) any > time. > > I'm going to go poke the supplier and Supermicro for some updated > firmware. > Any progress on your end? > > Some additional info: Safe mode boot gets a bit further, to the > point where it tries to mount/read from /dev/md0, but then hangs hard. > > /Eirik > From ivoras at freebsd.org Wed Nov 12 03:23:31 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Nov 12 03:23:37 2008 Subject: FreeBSD-AMD64 on Xeon MP - SOLVED In-Reply-To: References: <6D397584-2B6B-4F1A-B5C4-2A7B77AE52EB@anduin.net> Message-ID: <9bbcef730811120251w320e9d0cv972424ab02dc444e@mail.gmail.com> 2008/11/12 Eirik ?verby : > Hi all, > > the issue below has been solved by a new BIOS for the server in question. I > recently received a beta BIOS from Supermicro, after having reported the > issue and done a bit of troubleshooting with them. The tip that helped the > most was the boot-linux-first trick. > > Anyone who wants the BIOS may mail me privately; otherwise it'll likely be > released by Supermicro in the not-too-distant future. Hi, I'd like the update since it's likely I'll get another of those machines soon. From danny at dannysplace.net Wed Nov 12 21:46:34 2008 From: danny at dannysplace.net (Danny Carroll) Date: Wed Nov 12 21:46:40 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <490A8FAD.8060009@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> Message-ID: <491BBF38.9010908@dannysplace.net> Danny Carroll wrote: > Jeremy Chadwick wrote: >> I'd like to see the performance difference between these scenarios: >> >> - Memory cache enabled on Areca, write caching enabled on disks >> - Memory cache enabled on Areca, write caching disabled on disks >> - Memory cache disabled on Areca, write caching enabled on disks >> - Memory cache disabled on Areca, write caching disabled on disks >> The initial results for a ICH9 vs Areca in JBod mode can be found here: http://www.dannysplace.net/ZFS-JBODTests.html Summary: 5 Disk ZFS RaidZ array with atime turned off. ICH9 - block reads avg 400MByte/Sec ICH9 - block writes avg 150MByte/Sec ArecaJBOD - block reads avg 300MByte/Sec ArecaJBOD - block writes avg 160MByte/Sec The Areca seems to be in all except char and block writes. Block reads are 75% as fast as the ICH9 and rewrites are about 85% as fast. There seems to be little difference between enabling and disabling the disk cache on the Areca. This leads me to two conclusions: 1. Disabling the write cache does nothing on Seagate drives. 2. IO to the drives is so slow that a write cache is irrelevant. These are just some quick tests that I started with, mainly to compare the areca bus versus the ich9 bus. If someone has any tuning suggestions, then now is the time to make them before I migrate the ICH9 drives to the Areca bus. -D p.s. My OS details are: FreeBSD 7.1-PRERELEASE #3: Tue Nov 4 13:58:49 EST 2008 localhost# cat /etc/sysctl.conf kern.maxvnodes=400000 net.key.preferred_oldsa=0 net.key.blockacq_count=0 kern.ipc.maxsockbuf=400000 net.inet.ip.fastforwarding=1 net.inet.tcp.rfc1323=1 kern.ipc.maxsockbuf=16777216 net.local.stream.sendspace=82320 net.local.stream.recvspace=82320 net.inet.tcp.local_slowstart_flightsize=10 net.inet.tcp.nolocaltimewait=1 net.inet.tcp.delayed_ack=1 net.inet.tcp.delacktime=100 net.inet.tcp.mssdflt=1460 net.inet.tcp.sendspace=78840 net.inet.tcp.recvspace=78840 net.inet.tcp.slowstart_flightsize=54 net.inet.tcp.inflight.enable=1 net.inet.tcp.inflight.min=6144 net.inet.tcp.hostcache.expire=3900 localhost# cat /boot/loader.conf hw.em.rxd=4096 hw.em.txd=4096 vm.kmem_size="1536M" vm.kmem_size_max="1536M" smb_load="YES" smbus_load="YES" ichsmb_load="YES" From limguowei at gmail.com Wed Nov 12 22:35:57 2008 From: limguowei at gmail.com (weinter.lim) Date: Wed Nov 12 22:36:09 2008 Subject: Problems With BroadCom NetXtreme Ethernet and Atheros AR5B91 Message-ID: <20475350.post@talk.nabble.com> I am using FreeBSD 7.1 BETA 2 on my New Acer Aspire 4530 During Boot Dmesg did not detect my Ethernet BroadCom NetXtreme pciconf -lv none5@pci0:8:0:0 Class=0X020000 card=0X014a1025 chip=0X168414e4 rev=0X10 hdr=0X00 vendor = 'Broadcom Corporation' class = network subclass = ethernet My Atheros Wireless also failed to detect none6@pci0:11:0:0 Class=0X028000 card=0X03031a32 chip=0X002a168c rev=0X01 hdr=0X00 vendor = 'Atheros Communication Inc' class = network Thanks -- View this message in context: http://www.nabble.com/Problems-With-BroadCom-NetXtreme-Ethernet-and-Atheros-AR5B91-tp20475350p20475350.html Sent from the freebsd-hardware mailing list archive at Nabble.com. From limguowei at gmail.com Wed Nov 12 22:35:57 2008 From: limguowei at gmail.com (weinter.lim) Date: Wed Nov 12 22:36:10 2008 Subject: Problems With BroadCom NetXtreme Ethernet and Atheros AR5B91 Message-ID: <20475350.post@talk.nabble.com> I am using FreeBSD 7.1 BETA 2 on my New Acer Aspire 4530 The motherboard belong to Nvidia NForce9 series with the integrated GPU 9100M G During Boot Dmesg did not detect my Ethernet BroadCom NetXtreme pciconf -lv none5@pci0:8:0:0 Class=0X020000 card=0X014a1025 chip=0X168414e4 rev=0X10 hdr=0X00 vendor = 'Broadcom Corporation' class = network subclass = ethernet My Atheros Wireless also failed to detect none6@pci0:11:0:0 Class=0X028000 card=0X03031a32 chip=0X002a168c rev=0X01 hdr=0X00 vendor = 'Atheros Communication Inc' class = network Thanks -- View this message in context: http://www.nabble.com/Problems-With-BroadCom-NetXtreme-Ethernet-and-Atheros-AR5B91-tp20475350p20475350.html Sent from the freebsd-hardware mailing list archive at Nabble.com. From won.derick at yahoo.com Wed Nov 12 23:08:19 2008 From: won.derick at yahoo.com (Won De Erick) Date: Wed Nov 12 23:08:32 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage Message-ID: <704830.24415.qm@web45815.mail.sp1.yahoo.com> Hello, I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: 13 root 1 171 ki31 0K 16K CPU13 d 265:35 100.00% idle: cpu13 18 root 1 171 ki31 0K 16K CPU8 8 265:34 100.00% idle: cpu8 22 root 1 171 ki31 0K 16K CPU4 4 265:34 100.00% idle: cpu4 12 root 1 171 ki31 0K 16K CPU14 e 265:34 100.00% idle: cpu14 23 root 1 171 ki31 0K 16K CPU3 3 265:30 100.00% idle: cpu3 24 root 1 171 ki31 0K 16K CPU2 2 265:21 100.00% idle: cpu2 11 root 1 171 ki31 0K 16K CPU15 f 265:04 100.00% idle: cpu15 14 root 1 171 ki31 0K 16K CPU12 c 264:42 100.00% idle: cpu12 25 root 1 171 ki31 0K 16K CPU1 1 264:29 100.00% idle: cpu1 17 root 1 171 ki31 0K 16K CPU9 9 263:29 100.00% idle: cpu9 21 root 1 171 ki31 0K 16K CPU5 5 261:47 100.00% idle: cpu5 20 root 1 171 ki31 0K 16K CPU6 6 260:56 100.00% idle: cpu6 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 19 root 1 171 ki31 0K 16K CPU7 7 244:22 85.79% idle: cpu7 26 root 1 171 ki31 0K 16K RUN 0 216:13 54.79% idle: cpu0 27 root 1 -32 - 0K 16K *Giant 0 49:02 48.19% swi4: clock sio 45 root 1 -64 - 0K 16K WAIT 7 21:14 21.29% irq17: uhci0 16 root 1 171 ki31 0K 16K RUN a 146:07 11.08% idle: cpu10 47 root 1 -64 - 0K 16K WAIT 6 4:39 2.88% irq16: ciss0 15 root 1 171 ki31 0K 16K RUN b 141:43 1.17% idle: cpu11 30 root 1 -16 - 0K 16K - f 0:33 0.00% yarrow 61 root 1 20 - 0K 16K syncer e 0:08 0.00% syncer irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. I read about the MSI interrupt handling for FreeBSD, and I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, which means a total of four IRQs, and eventually four cores (or 4 CPU) for the transactions. With this way, the IDLE processors would be utilized. Other ways how I can maximize the use of the IDLE CPUs? Thanks, Won From koitsu at FreeBSD.org Wed Nov 12 23:26:11 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 12 23:26:18 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <704830.24415.qm@web45815.mail.sp1.yahoo.com> References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> Message-ID: <20081113072610.GA13698@icarus.home.lan> On Wed, Nov 12, 2008 at 10:55:06PM -0800, Won De Erick wrote: > Hello, Nobody can read the pasted output you've sent. Your Email client is hard-wrapping long lines. Please re-send the data with this feature disabled. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From freebsd at sopwith.solgatos.com Wed Nov 12 23:30:30 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Wed Nov 12 23:30:41 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: Your message of "Thu, 13 Nov 2008 15:46:32 +1000." <491BBF38.9010908@dannysplace.net> Message-ID: <200811130657.GAA26763@sopwith.solgatos.com> >> For the array(s) >> 9 x ST31000340AS 1tb disks >> 1 x ST31000333AS 1tb disk (trying to swap this for a ST31000340AS) > There seems to be little difference between enabling and disabling the > disk cache on the Areca. This leads me to two conclusions: > 1. Disabling the write cache does nothing on Seagate drives. > 2. IO to the drives is so slow that a write cache is irrelevant. I have a couple of the ST31000340AS 1TB disks as well as older lower capacity Seagates, and turning the write cache on/off makes a MASSIVE (roughly 10:1) difference in write speed. Jeremy reports "about 13%" with Seagate ST3120026AS: http://lists.freebsd.org/pipermail/freebsd-hardware/2008-October/005450.html Perhaps there is something about the Areca or the testing? Is the write cache really getting turned on/off? You're getting about 2-3x the speed I'd expect if the write cache were off, so maybe it is still on but there is a bottleneck elsewhere? Have you tried a simple test with /dev/zero and dd to a raw drive to eliminate the effects of the filesystem? From won.derick at yahoo.com Wed Nov 12 23:38:17 2008 From: won.derick at yahoo.com (Won De Erick) Date: Wed Nov 12 23:38:24 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <20081113072610.GA13698@icarus.home.lan> Message-ID: <576266.41435.qm@web45812.mail.sp1.yahoo.com> resending my previous email. ---------------------------------------------------------------------------------------------------------------------- Hello, I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: 13 root 1 171 ki31 0K 16K CPU13 d 265:35 100.00% idle: cpu13 18 root 1 171 ki31 0K 16K CPU8 8 265:34 100.00% idle: cpu8 22 root 1 171 ki31 0K 16K CPU4 4 265:34 100.00% idle: cpu4 12 root 1 171 ki31 0K 16K CPU14 e 265:34 100.00% idle: cpu14 23 root 1 171 ki31 0K 16K CPU3 3 265:30 100.00% idle: cpu3 24 root 1 171 ki31 0K 16K CPU2 2 265:21 100.00% idle: cpu2 11 root 1 171 ki31 0K 16K CPU15 f 265:04 100.00% idle: cpu15 14 root 1 171 ki31 0K 16K CPU12 c 264:42 100.00% idle: cpu12 25 root 1 171 ki31 0K 16K CPU1 1 264:29 100.00% idle: cpu1 17 root 1 171 ki31 0K 16K CPU9 9 263:29 100.00% idle: cpu9 21 root 1 171 ki31 0K 16K CPU5 5 261:47 100.00% idle: cpu5 20 root 1 171 ki31 0K 16K CPU6 6 260:56 100.00% idle: cpu6 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 19 root 1 171 ki31 0K 16K CPU7 7 244:22 85.79% idle: cpu7 26 root 1 171 ki31 0K 16K RUN 0 216:13 54.79% idle: cpu0 27 root 1 -32 - 0K 16K *Giant 0 49:02 48.19% swi4: clock sio 45 root 1 -64 - 0K 16K WAIT 7 21:14 21.29% irq17: uhci0 16 root 1 171 ki31 0K 16K RUN a 146:07 11.08% idle: cpu10 47 root 1 -64 - 0K 16K WAIT 6 4:39 2.88% irq16: ciss0 15 root 1 171 ki31 0K 16K RUN b 141:43 1.17% idle: cpu11 30 root 1 -16 - 0K 16K - f 0:33 0.00% yarrow 61 root 1 20 - 0K 16K syncer e 0:08 0.00% syncer irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. I read about the MSI interrupt handling for FreeBSD, and I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, which means a total of four IRQs, and eventually four cores (or 4 CPU) for the transactions. With this way, the IDLE processors would be utilized. Other ways how I can maximize the use of the IDLE CPUs? Thanks, Won --------------------------------------------------------------------------------------------------------------------------- ________________________________ From: Jeremy Chadwick To: Won De Erick Cc: freebsd-hardware@freebsd.org Sent: Thursday, November 13, 2008 3:26:10 PM Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage On Wed, Nov 12, 2008 at 10:55:06PM -0800, Won De Erick wrote: > Hello, Nobody can read the pasted output you've sent. Your Email client is hard-wrapping long lines. Please re-send the data with this feature disabled. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" From koitsu at FreeBSD.org Wed Nov 12 23:43:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 12 23:43:14 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <200811130657.GAA26763@sopwith.solgatos.com> References: <491BBF38.9010908@dannysplace.net> <200811130657.GAA26763@sopwith.solgatos.com> Message-ID: <20081113074301.GA13938@icarus.home.lan> On Wed, Nov 12, 2008 at 10:57:58PM +0000, Dieter wrote: > >> For the array(s) > >> 9 x ST31000340AS 1tb disks > >> 1 x ST31000333AS 1tb disk (trying to swap this for a ST31000340AS) > > > There seems to be little difference between enabling and disabling the > > disk cache on the Areca. This leads me to two conclusions: > > 1. Disabling the write cache does nothing on Seagate drives. > > 2. IO to the drives is so slow that a write cache is irrelevant. > > I have a couple of the ST31000340AS 1TB disks as well as older lower capacity > Seagates, and turning the write cache on/off makes a MASSIVE (roughly 10:1) > difference in write speed. > > Jeremy reports "about 13%" with Seagate ST3120026AS: > http://lists.freebsd.org/pipermail/freebsd-hardware/2008-October/005450.html > > Perhaps there is something about the Areca or the testing? Is the write cache > really getting turned on/off? The Areca controller he has can do caching of its own (it has 256MBytes of cache). Meaning, if you disable write cache on the disks (but not the Areca controller itself), all of the caching being done is purely controller-based. The actual disk writes between the controller and the disk will, of course, be "slow" -- but between the OS and the controller, things should appear fast. Let me outline the 4 test scenarios (I thought I did this in my original mail to Danny, but I believe I also said "don't get caught up in excessive granularity because it'll just confuse people now" -- case in point): - Areca cache disabled, disk write cache enabled - Areca cache disabled, disk write cache disabled - Areca cache enabled, disk write cache enabled - Areca cache enabled, disk write cache disabled [**] As I understand it, Danny performed the tests with the [**] configuration. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Wed Nov 12 23:46:04 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 12 23:46:11 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <576266.41435.qm@web45812.mail.sp1.yahoo.com> References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <20081113072610.GA13698@icarus.home.lan> <576266.41435.qm@web45812.mail.sp1.yahoo.com> Message-ID: <20081113074602.GB13938@icarus.home.lan> On Wed, Nov 12, 2008 at 11:38:15PM -0800, Won De Erick wrote: > I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: > > 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 > 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 > > irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. There was a ***major*** bce(4) cleanup that just happened. Your 7.0 box will not have these changes. Please upgrade your box to RELENG_7 (a.k.a. 7.1-PRERELEASE), csup'd recently (today preferably), and try your tests again: http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046482.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From koitsu at FreeBSD.org Thu Nov 13 00:19:38 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Nov 13 00:19:46 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <366483.43588.qm@web45807.mail.sp1.yahoo.com> References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <20081113072610.GA13698@icarus.home.lan> <576266.41435.qm@web45812.mail.sp1.yahoo.com> <20081113074602.GB13938@icarus.home.lan> <366483.43588.qm@web45807.mail.sp1.yahoo.com> Message-ID: <20081113081936.GA14779@icarus.home.lan> On Thu, Nov 13, 2008 at 12:07:37AM -0800, Won De Erick wrote: > Noted on this, I will update you through this thread. > > However is there any possibility of the following: > > > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > for the transactions. With this way, the IDLE processors would be utilized. > > What I mean here is, for the two interfaces: > > one IRQ for bce0 Rx > one IRQ for bce0 Tx > one IRQ for bce1 Rx > one IRQ for bce1 Tx I can't even begin to imagine how this would be possible on any NIC. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From won.derick at yahoo.com Thu Nov 13 00:21:25 2008 From: won.derick at yahoo.com (Won De Erick) Date: Thu Nov 13 00:21:31 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <20081113072610.GA13698@icarus.home.lan> <576266.41435.qm@web45812.mail.sp1.yahoo.com> <20081113074602.GB13938@icarus.home.lan> Message-ID: <366483.43588.qm@web45807.mail.sp1.yahoo.com> Noted on this, I will update you through this thread. However is there any possibility of the following: > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > for the transactions. With this way, the IDLE processors would be utilized. What I mean here is, for the two interfaces: one IRQ for bce0 Rx one IRQ for bce0 Tx one IRQ for bce1 Rx one IRQ for bce1 Tx Thanks, Won ________________________________ From: Jeremy Chadwick To: Won De Erick Cc: freebsd-hardware@freebsd.org Sent: Thursday, November 13, 2008 3:46:02 PM Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage On Wed, Nov 12, 2008 at 11:38:15PM -0800, Won De Erick wrote: > I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: > > 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 > 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 > > irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. There was a ***major*** bce(4) cleanup that just happened. Your 7.0 box will not have these changes. Please upgrade your box to RELENG_7 (a.k.a. 7.1-PRERELEASE), csup'd recently (today preferably), and try your tests again: http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046482.html -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | _______________________________________________ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" From wjw at digiware.nl Thu Nov 13 00:53:27 2008 From: wjw at digiware.nl (Willem Jan Withagen) Date: Thu Nov 13 00:53:34 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <491BBF38.9010908@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> Message-ID: <491BE632.1020801@IMAP> Danny Carroll wrote: > Danny Carroll wrote: >> Jeremy Chadwick wrote: >>> I'd like to see the performance difference between these scenarios: >>> >>> - Memory cache enabled on Areca, write caching enabled on disks >>> - Memory cache enabled on Areca, write caching disabled on disks >>> - Memory cache disabled on Areca, write caching enabled on disks >>> - Memory cache disabled on Areca, write caching disabled on disks >>> > > > The initial results for a ICH9 vs Areca in JBod mode can be found here: > http://www.dannysplace.net/ZFS-JBODTests.html Just as a polite question, since I'm very much in favor doing benchmarking and do appreciate these kinds of test. You might want to add an introductory page to your results describing how you setup the test: Details of the hardware Details of the disk setup possible version and options with bonnie The script you used.... This would allow others to redo your experiment and try to figure out why their numbers are different. --WjW From won.derick at yahoo.com Thu Nov 13 01:34:02 2008 From: won.derick at yahoo.com (Won De Erick) Date: Thu Nov 13 01:34:08 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <20081113072610.GA13698@icarus.home.lan> <576266.41435.qm@web45812.mail.sp1.yahoo.com> <20081113074602.GB13938@icarus.home.lan> <366483.43588.qm@web45807.mail.sp1.yahoo.com> <20081113081936.GA14779@icarus.home.lan> Message-ID: <527634.76455.qm@web45804.mail.sp1.yahoo.com> Jeremy Chadwick wrote: >> On Thu, Nov 13, 2008 at 12:07:37AM -0800, Won De Erick wrote: >> Noted on this, I will update you through this thread. >> >> However is there any possibility of the following: >> >> > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, >> > which means a total of four IRQs, and eventually four cores (or 4 CPUs) >> > for the transactions. With this way, the IDLE processors would be utilized. >> >> What I mean here is, for the two interfaces: >> >> one IRQ for bce0 Rx >> one IRQ for bce0 Tx >> one IRQ for bce1 Rx >> one IRQ for bce1 Tx > I can't even begin to imagine how this would be possible on any NIC. Yeah, but I can't also imagine how beneficial this idea when implemented. From koitsu at FreeBSD.org Thu Nov 13 01:37:09 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Nov 13 01:37:16 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <527634.76455.qm@web45804.mail.sp1.yahoo.com> References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <20081113072610.GA13698@icarus.home.lan> <576266.41435.qm@web45812.mail.sp1.yahoo.com> <20081113074602.GB13938@icarus.home.lan> <366483.43588.qm@web45807.mail.sp1.yahoo.com> <20081113081936.GA14779@icarus.home.lan> <527634.76455.qm@web45804.mail.sp1.yahoo.com> Message-ID: <20081113093707.GA16322@icarus.home.lan> On Thu, Nov 13, 2008 at 01:34:01AM -0800, Won De Erick wrote: > Jeremy Chadwick wrote: > > >> On Thu, Nov 13, 2008 at 12:07:37AM -0800, Won De Erick wrote: > >> Noted on this, I will update you through this thread. > >> > >> However is there any possibility of the following: > >> > >> > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > >> > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > >> > for the transactions. With this way, the IDLE processors would be utilized. > >> > >> What I mean here is, for the two interfaces: > >> > >> one IRQ for bce0 Rx > >> one IRQ for bce0 Tx > >> one IRQ for bce1 Rx > >> one IRQ for bce1 Tx > > > I can't even begin to imagine how this would be possible on any NIC. > > Yeah, but I can't also imagine how beneficial this idea when implemented. Right -- me either. What you just said begs the question. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From rmaglasang at infoweapons.com Thu Nov 13 02:21:58 2008 From: rmaglasang at infoweapons.com (Ronnel P. Maglasang) Date: Thu Nov 13 02:22:14 2008 Subject: assigning interrupts Message-ID: <491BFB68.7050405@infoweapons.com> Hi All, Is there a way to explicitly assign an interrupt of a device? I'm running on 6.3 and the two NICs share the same interrupt. Obviously this will affect the performance if the NICs are exposed to heavy network traffic. # vmstat -i interrupt total rate irq11: em0 vr0+ 1081099 77 Total 16958562 1222 Looking at the driver's code, I have the initial though that this is the place where I can modify. -- adapter->res_interrupt = bus_alloc_resource_any(dev, SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); -- I've tried changing RF_SHAREABLE to RF_ALLOCATED or other values but still could not get the desired result and worst the device fail to initialize. Is this possible in 6.3? Thanks, Ronnel From koitsu at FreeBSD.org Thu Nov 13 02:40:56 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Thu Nov 13 02:41:03 2008 Subject: assigning interrupts In-Reply-To: <491BFB68.7050405@infoweapons.com> References: <491BFB68.7050405@infoweapons.com> Message-ID: <20081113104054.GA17501@icarus.home.lan> On Thu, Nov 13, 2008 at 06:03:20PM +0800, Ronnel P. Maglasang wrote: > Hi All, > > Is there a way to explicitly assign an interrupt > of a device? I'm running on 6.3 and the two NICs > share the same interrupt. Obviously this will affect > the performance if the NICs are exposed to heavy network > traffic. > > # vmstat -i > interrupt total rate > > irq11: em0 vr0+ 1081099 77 > > Total 16958562 1222 > > > Looking at the driver's code, I have the initial though > that this is the place where I can modify. This is the responsibility of the BIOS or ACPI configuration. There is no way to do this via OS software, as far as I know. Try looking at the motherboard manual for what PCI levels (A/B/C/D) share IRQs with what slot, then move cards around. Otherwise, consider purchasing a motherboard that has an APIC (this is not a typo) increasing the IRQ count to 256. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From rea-fbsd at codelabs.ru Thu Nov 13 02:43:43 2008 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Nov 13 02:43:53 2008 Subject: assigning interrupts In-Reply-To: <491BFB68.7050405@infoweapons.com> References: <491BFB68.7050405@infoweapons.com> Message-ID: Thu, Nov 13, 2008 at 06:03:20PM +0800, Ronnel P. Maglasang wrote: > Is there a way to explicitly assign an interrupt > of a device? What about BIOS? What about physically reshuffling the cards if they aren't on-board ones? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081113/ab3fd770/attachment.pgp From fbsd at dannysplace.net Thu Nov 13 03:09:33 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Thu Nov 13 03:09:40 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <491BE632.1020801@IMAP> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491BE632.1020801@IMAP> Message-ID: <491C0B00.4030408@dannysplace.net> Good idea. Actually, what I will do eventually is *also* post the results to the mailing list. It will probably be around long after my own server is gone. -D Willem Jan Withagen wrote: > Danny Carroll wrote: >> Danny Carroll wrote: >>> Jeremy Chadwick wrote: >>>> I'd like to see the performance difference between these scenarios: >>>> >>>> - Memory cache enabled on Areca, write caching enabled on disks >>>> - Memory cache enabled on Areca, write caching disabled on disks >>>> - Memory cache disabled on Areca, write caching enabled on disks >>>> - Memory cache disabled on Areca, write caching disabled on disks >>>> >> >> >> The initial results for a ICH9 vs Areca in JBod mode can be found here: >> http://www.dannysplace.net/ZFS-JBODTests.html > > Just as a polite question, since I'm very much in favor doing > benchmarking and do appreciate these kinds of test. > > You might want to add an introductory page to your results describing > how you setup the test: > Details of the hardware > Details of the disk setup > possible version and options with bonnie > The script you used.... > > This would allow others to redo your experiment and try to figure out > why their numbers are different. > > --WjW > > From danny at dannysplace.net Thu Nov 13 05:58:57 2008 From: danny at dannysplace.net (Danny Carroll) Date: Thu Nov 13 05:59:10 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <20081113074301.GA13938@icarus.home.lan> References: <491BBF38.9010908@dannysplace.net> <200811130657.GAA26763@sopwith.solgatos.com> <20081113074301.GA13938@icarus.home.lan> Message-ID: <491C32BF.7020805@dannysplace.net> Jeremy Chadwick wrote: > On Wed, Nov 12, 2008 at 10:57:58PM +0000, Dieter wrote: > The Areca controller he has can do caching of its own (it has 256MBytes > of cache). Meaning, if you disable write cache on the disks (but not > the Areca controller itself), all of the caching being done is purely > controller-based. The actual disk writes between the controller and the > disk will, of course, be "slow" -- but between the OS and the > controller, things should appear fast. It is entirely possible. I do not know however if the Areca cache works just for Raid or also in JBOD mode. The card can be configured via a web interface (it has it's own nic), via the CLI, or via the BIOS. The only setting I do see is: Disk Write Cache Mode. This is what I have tested. It might have been the Areca cache I turned off, or it might have been the disk caches that I turned off. I hope it is the former, otherwise what is the purpose of having a battery backup unit? If the disks cache the write, then you will probably lose data anyway. I think, once I turn on Raid mode, there will be an option to turn on/off caching in the raid part of the config. The manual shows me that there is an option there, but it only indicates that you can change the cache mode from WriteBack to WriteThrough. But for now, since it's in JBOD mode I cannot access that. > Let me outline the 4 test scenarios (I thought I did this in my original > mail to Danny, but I believe I also said "don't get caught up in > excessive granularity because it'll just confuse people now" -- case in > point): > > - Areca cache disabled, disk write cache enabled > - Areca cache disabled, disk write cache disabled > - Areca cache enabled, disk write cache enabled > - Areca cache enabled, disk write cache disabled [**] > > As I understand it, Danny performed the tests with the [**] > configuration. > The tests should have names: Test 1: Areca cache disabled, disk write cache enabled Test 2: Areca cache disabled, disk write cache disabled Test 3: Areca cache enabled, disk write cache enabled Test 4: Areca cache enabled, disk write cache disabled You did outline these, I thought I was performaing test 2 because I am assuming that when you turn on JBOD mode, you do not get caching on the controller. Once I am sure there is not something glaringly wrong with the FreeBSD side of things I'll run as many of these tests as I can. For now, I think it is only tests 1 and 2. So, my thoughts remain, why was the read performance the same, and the write performance actually marginally better, after I turned off the cache? I did a reboot after I turned off the cache but I did not power cycle the drives. Perhaps that is the answer? Or perhaps simply the Areca controller cannot turn off the cache on the ST31000340AS drives. Or perhaps the cache is ALWAYS enabled and cannot be turned off on the controller. That mean I was doing test 4 as Jeremy suggested. That seems a likely possibility as well. In fact, thinking about it now, it makes the most sense to me. -D From ndenev at gmail.com Thu Nov 13 07:29:31 2008 From: ndenev at gmail.com (Nikolay Denev) Date: Thu Nov 13 07:29:37 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <491C32BF.7020805@dannysplace.net> References: <491BBF38.9010908@dannysplace.net> <200811130657.GAA26763@sopwith.solgatos.com> <20081113074301.GA13938@icarus.home.lan> <491C32BF.7020805@dannysplace.net> Message-ID: <04B6F041-3052-4650-BE62-817E2B28D034@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13 Nov, 2008, at 15:59 , Danny Carroll wrote: [snip] > > It is entirely possible. I do not know however if the Areca cache > works > just for Raid or also in JBOD mode. > I think some RAID controllers do not use the cache when you export the disks as pass-thru/jbod, but on some controllers you can workaround this by making every disk a RAID0(stripe) array with only one disk. Dunno if that would work on the areca... [snip] - -- Regards, Nikolay Denev -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (Darwin) iEYEARECAAYFAkkcQlsACgkQHNAJ/fLbfrkTkgCgo2NupY2Qe3TglJpoIIwne4uH VRwAnRl9p44NFxyWf9zhjrZOOImtiBAs =4Djt -----END PGP SIGNATURE----- From scottl at samsco.org Thu Nov 13 09:15:19 2008 From: scottl at samsco.org (Scott Long) Date: Thu Nov 13 09:15:29 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <491BBF38.9010908@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> Message-ID: <491C5AA7.1030004@samsco.org> Danny Carroll wrote: > Danny Carroll wrote: >> Jeremy Chadwick wrote: >>> I'd like to see the performance difference between these scenarios: >>> >>> - Memory cache enabled on Areca, write caching enabled on disks >>> - Memory cache enabled on Areca, write caching disabled on disks >>> - Memory cache disabled on Areca, write caching enabled on disks >>> - Memory cache disabled on Areca, write caching disabled on disks >>> > > > The initial results for a ICH9 vs Areca in JBod mode can be found here: > http://www.dannysplace.net/ZFS-JBODTests.html > > Summary: > 5 Disk ZFS RaidZ array with atime turned off. > ICH9 - block reads avg 400MByte/Sec > ICH9 - block writes avg 150MByte/Sec > ArecaJBOD - block reads avg 300MByte/Sec > ArecaJBOD - block writes avg 160MByte/Sec > > > The Areca seems to be in all except char and block writes. Block reads > are 75% as fast as the ICH9 and rewrites are about 85% as fast. > > There seems to be little difference between enabling and disabling the > disk cache on the Areca. This leads me to two conclusions: > 1. Disabling the write cache does nothing on Seagate drives. > 2. IO to the drives is so slow that a write cache is irrelevant. > > These are just some quick tests that I started with, mainly to compare > the areca bus versus the ich9 bus. If someone has any tuning > suggestions, then now is the time to make them before I migrate the ICH9 > drives to the Areca bus. The Areca controller likely doesn't buffer/cache for disks in JBOD mode, as others in this thread have stated. Without buffering, simple disk controllers will almost always be faster than accelerated raid controllers because the accelerated controllers add more latency between the host and the disk. A simple controller will directly funnel data from the host to the disk as soon as it receives a command. An accelerated controller, however, has a CPU and a mini-OS on it that has to schedule the work coming from the host and handle its own tasks and interrupts. This adds latency that quickly adds up under benchmarks. Your numbers clearly demonstrate this. Scott From jhb at freebsd.org Thu Nov 13 11:46:55 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 13 11:47:07 2008 Subject: Problems With BroadCom NetXtreme Ethernet and Atheros AR5B91 In-Reply-To: <20475350.post@talk.nabble.com> References: <20475350.post@talk.nabble.com> Message-ID: <200811131436.57422.jhb@freebsd.org> On Thursday 13 November 2008 01:18:03 am weinter.lim wrote: > > I am using FreeBSD 7.1 BETA 2 on my New Acer Aspire 4530 > During Boot Dmesg did not detect my Ethernet BroadCom NetXtreme > pciconf -lv > > none5@pci0:8:0:0 Class=0X020000 card=0X014a1025 chip=0X168414e4 rev=0X10 > hdr=0X00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet The Linux tg3 driver claims this is a BCM5764. Can you try this patch and include any messages (especially any phy messages) from a verbose boot? Alternatively, you could boot w/o bge in the kernel, turn on bootverbose (debug.bootverbose sysctl) and kldload a patched bge.ko and capture the dmesg output. Index: if_bge.c =================================================================== RCS file: /usr/cvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.215 diff -u -r1.215 if_bge.c --- if_bge.c 27 Oct 2008 22:10:01 -0000 1.215 +++ if_bge.c 13 Nov 2008 19:33:15 -0000 @@ -184,6 +184,7 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5754M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5764 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780S }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5781 }, Index: if_bgereg.h =================================================================== RCS file: /usr/cvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.81 diff -u -r1.81 if_bgereg.h --- if_bgereg.h 14 Oct 2008 20:28:42 -0000 1.81 +++ if_bgereg.h 13 Nov 2008 19:33:02 -0000 @@ -2094,6 +2094,7 @@ #define BCOM_DEVICEID_BCM5754M 0x1672 #define BCOM_DEVICEID_BCM5755 0x167B #define BCOM_DEVICEID_BCM5755M 0x1673 +#define BCOM_DEVICEID_BCM5764 0x1684 #define BCOM_DEVICEID_BCM5780 0x166A #define BCOM_DEVICEID_BCM5780S 0x166B #define BCOM_DEVICEID_BCM5781 0x16DD > > My Atheros Wireless also failed to detect > > none6@pci0:11:0:0 Class=0X028000 card=0X03031a32 chip=0X002a168c rev=0X01 > hdr=0X00 > vendor = 'Atheros Communication Inc' > class = network No idea on this one. You could ask Sam perhaps. -- John Baldwin From jhb at freebsd.org Thu Nov 13 11:47:01 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 13 11:47:08 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <20081113081936.GA14779@icarus.home.lan> References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <366483.43588.qm@web45807.mail.sp1.yahoo.com> <20081113081936.GA14779@icarus.home.lan> Message-ID: <200811131438.25904.jhb@freebsd.org> On Thursday 13 November 2008 03:19:36 am Jeremy Chadwick wrote: > On Thu, Nov 13, 2008 at 12:07:37AM -0800, Won De Erick wrote: > > Noted on this, I will update you through this thread. > > > > However is there any possibility of the following: > > > > > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > > for the transactions. With this way, the IDLE processors would be utilized. > > > > What I mean here is, for the two interfaces: > > > > one IRQ for bce0 Rx > > one IRQ for bce0 Tx > > one IRQ for bce1 Rx > > one IRQ for bce1 Tx > > I can't even begin to imagine how this would be possible on any NIC. igb(4) does it. It is quite possible and one of the purposes of MSI. However, the current bce(4) hardware does not support this. It only allows for a single message and thus a single IRQ per-device. -- John Baldwin From jhb at freebsd.org Thu Nov 13 11:47:07 2008 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 13 11:47:19 2008 Subject: assigning interrupts In-Reply-To: <491BFB68.7050405@infoweapons.com> References: <491BFB68.7050405@infoweapons.com> Message-ID: <200811131441.16427.jhb@freebsd.org> On Thursday 13 November 2008 05:03:20 am Ronnel P. Maglasang wrote: > Hi All, > > Is there a way to explicitly assign an interrupt > of a device? I'm running on 6.3 and the two NICs > share the same interrupt. Obviously this will affect > the performance if the NICs are exposed to heavy network > traffic. > > # vmstat -i > interrupt total rate > > irq11: em0 vr0+ 1081099 77 > > Total 16958562 1222 > > > Looking at the driver's code, I have the initial though > that this is the place where I can modify. > > -- > adapter->res_interrupt = bus_alloc_resource_any(dev, > SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); > -- > > I've tried changing RF_SHAREABLE to RF_ALLOCATED or other > values but still could not get the desired result and worst > the device fail to initialize. Is this possible in 6.3? You can not easily assign them, no. In many cases the interrupt pins from the devices may be hardwired to a single input pin on an interrupt controller. In that case there is nothing you can do. You can read more about the gory details here: http://people.freebsd.org/~jhb/papers/bsdcan/2007/ -- John Baldwin From fbsd at dannysplace.net Thu Nov 13 12:46:47 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Thu Nov 13 12:46:53 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <04B6F041-3052-4650-BE62-817E2B28D034@gmail.com> References: <491BBF38.9010908@dannysplace.net> <200811130657.GAA26763@sopwith.solgatos.com> <20081113074301.GA13938@icarus.home.lan> <491C32BF.7020805@dannysplace.net> <04B6F041-3052-4650-BE62-817E2B28D034@gmail.com> Message-ID: <491C9224.4050407@dannysplace.net> Nikolay Denev wrote: > I think some RAID controllers do not use the cache when you export the > disks as pass-thru/jbod, I assumed this is the case but now I am not so sure. > but on some controllers you can workaround this by making > every disk a RAID0(stripe) array with only one disk. > Dunno if that would work on the areca... You can probably do that with this as controller as well. However if I look at the manual I do not see an option to disable the cache for Raid sets. Only to change it from Write-back to Write-Through. I guess write-through is *almost* as if the cache is disabled. -D From fbsd at dannysplace.net Thu Nov 13 12:59:43 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Thu Nov 13 12:59:49 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <491C5AA7.1030004@samsco.org> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> Message-ID: <491C9535.3030504@dannysplace.net> Scott Long wrote: > The Areca controller likely doesn't buffer/cache for disks in JBOD mode, > as others in this thread have stated. Without buffering, simple disk > controllers will almost always be faster than accelerated raid > controllers because the accelerated controllers add more latency between > the host and the disk. A simple controller will directly funnel data > from the host to the disk as soon as it receives a command. An > accelerated controller, however, has a CPU and a mini-OS on it that has > to schedule the work coming from the host and handle its own tasks and > interrupts. This adds latency that quickly adds up under benchmarks. > Your numbers clearly demonstrate this. That's nice to know. I'm not sure it tells us why the Non-Cached writes were about 8% faster though. The other thing about the "NoWriteCache" test I performed that I neglected to mention yesterday is that I actually panic'd the box (running out of memory). This was the first time I have had that happen with ZFS even though in previous testing (with cache enabled) I punished the box for a lot longer. Perhaps the ZFS caching took over where the disk caching left off? Could that explain why I did not see a negative difference in the numbers between Cache enabled and Cache disabled? One of the questions I wanted to answer for myself was just this: "Does a battery-backed cache on an Areca card protect me when I am in JBOD mode." If the Areca does not buffer/cache in JBOD mode then that means the answer is no. -D From limguowei at gmail.com Thu Nov 13 22:17:50 2008 From: limguowei at gmail.com (weinter.lim) Date: Thu Nov 13 22:17:57 2008 Subject: Problems With BroadCom NetXtreme Ethernet and Atheros AR5B91 In-Reply-To: <200811131436.57422.jhb@freebsd.org> References: <20475350.post@talk.nabble.com> <200811131436.57422.jhb@freebsd.org> Message-ID: <20495276.post@talk.nabble.com> John Baldwin wrote: > > On Thursday 13 November 2008 01:18:03 am weinter.lim wrote: >> >> I am using FreeBSD 7.1 BETA 2 on my New Acer Aspire 4530 >> During Boot Dmesg did not detect my Ethernet BroadCom NetXtreme >> pciconf -lv >> >> none5@pci0:8:0:0 Class=0X020000 card=0X014a1025 chip=0X168414e4 rev=0X10 >> hdr=0X00 >> vendor = 'Broadcom Corporation' >> class = network >> subclass = ethernet > > The Linux tg3 driver claims this is a BCM5764. Can you try this patch and > include any messages (especially any phy messages) from a verbose boot? > Alternatively, you could boot w/o bge in the kernel, turn on bootverbose > (debug.bootverbose sysctl) and kldload a patched bge.ko and capture the > dmesg > output. > > Index: if_bge.c > =================================================================== > RCS file: /usr/cvs/src/sys/dev/bge/if_bge.c,v > retrieving revision 1.215 > diff -u -r1.215 if_bge.c > --- if_bge.c 27 Oct 2008 22:10:01 -0000 1.215 > +++ if_bge.c 13 Nov 2008 19:33:15 -0000 > @@ -184,6 +184,7 @@ > { BCOM_VENDORID, BCOM_DEVICEID_BCM5754M }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5755 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5755M }, > + { BCOM_VENDORID, BCOM_DEVICEID_BCM5764 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5780 }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5780S }, > { BCOM_VENDORID, BCOM_DEVICEID_BCM5781 }, > Index: if_bgereg.h > =================================================================== > RCS file: /usr/cvs/src/sys/dev/bge/if_bgereg.h,v > retrieving revision 1.81 > diff -u -r1.81 if_bgereg.h > --- if_bgereg.h 14 Oct 2008 20:28:42 -0000 1.81 > +++ if_bgereg.h 13 Nov 2008 19:33:02 -0000 > @@ -2094,6 +2094,7 @@ > #define BCOM_DEVICEID_BCM5754M 0x1672 > #define BCOM_DEVICEID_BCM5755 0x167B > #define BCOM_DEVICEID_BCM5755M 0x1673 > +#define BCOM_DEVICEID_BCM5764 0x1684 > #define BCOM_DEVICEID_BCM5780 0x166A > #define BCOM_DEVICEID_BCM5780S 0x166B > #define BCOM_DEVICEID_BCM5781 0x16DD > >> >> My Atheros Wireless also failed to detect >> >> none6@pci0:11:0:0 Class=0X028000 card=0X03031a32 chip=0X002a168c rev=0X01 >> hdr=0X00 >> vendor = 'Atheros Communication Inc' >> class = network > > No idea on this one. You could ask Sam perhaps. > > -- > John Baldwin > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to > "freebsd-hardware-unsubscribe@freebsd.org" > > Hi I just found another issue that is rather worrying When i tried compiling my kernel the temperature run up to 90 degs On my previous laptop Acer Aspire 4520G using the TL-60 Processor it went up to a maximium of 70 deg Now on my new RM-72 Turion It went up to 90 deg I am afraid that even if the heat didn't burn up my processor it will burn up my other components as well8-O I am really worried -- View this message in context: http://www.nabble.com/Problems-With-BroadCom-NetXtreme-Ethernet-and-Atheros-AR5B91-tp20475350p20495276.html Sent from the freebsd-hardware mailing list archive at Nabble.com. From rmaglasang at infoweapons.com Fri Nov 14 00:26:46 2008 From: rmaglasang at infoweapons.com (Ronnel P. Maglasang) Date: Fri Nov 14 00:27:07 2008 Subject: assigning interrupts In-Reply-To: <200811131441.16427.jhb@freebsd.org> References: <491BFB68.7050405@infoweapons.com> <200811131441.16427.jhb@freebsd.org> Message-ID: <491D356A.70607@infoweapons.com> John Baldwin wrote: > On Thursday 13 November 2008 05:03:20 am Ronnel P. Maglasang wrote: > >> Hi All, >> >> Is there a way to explicitly assign an interrupt >> of a device? I'm running on 6.3 and the two NICs >> share the same interrupt. Obviously this will affect >> the performance if the NICs are exposed to heavy network >> traffic. >> >> # vmstat -i >> interrupt total rate >> >> irq11: em0 vr0+ 1081099 77 >> >> Total 16958562 1222 >> >> >> Looking at the driver's code, I have the initial though >> that this is the place where I can modify. >> >> -- >> adapter->res_interrupt = bus_alloc_resource_any(dev, >> SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); >> -- >> >> I've tried changing RF_SHAREABLE to RF_ALLOCATED or other >> values but still could not get the desired result and worst >> the device fail to initialize. Is this possible in 6.3? >> > > You can not easily assign them, no. In many cases the interrupt pins from the > devices may be hardwired to a single input pin on an interrupt controller. > In that case there is nothing you can do. You can read more about the gory > details here: > > http://people.freebsd.org/~jhb/papers/bsdcan/2007/ > > What was changed in 7.x in terms of assigning interrupts? I have another box running on 7.0 (2 NICs). I noticed there are no devices sharing interrupts. But if 6.x is installed on the same box (previous installation), the two NICs will share the same interrupt. I'm now looking at the drivers. I assume this is not NIC-firmware related. From won.derick at yahoo.com Fri Nov 14 00:48:50 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 00:48:57 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <366483.43588.qm@web45807.mail.sp1.yahoo.com> <20081113081936.GA14779@icarus.home.lan> <200811131438.25904.jhb@freebsd.org> Message-ID: <829178.39837.qm@web45811.mail.sp1.yahoo.com> > ----- Original Message ---- > From: John Baldwin > To: freebsd-hardware@freebsd.org > Cc: Jeremy Chadwick ; Won De Erick > Sent: Friday, November 14, 2008 3:38:25 AM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > On Thursday 13 November 2008 03:19:36 am Jeremy Chadwick wrote: > > On Thu, Nov 13, 2008 at 12:07:37AM -0800, Won De Erick wrote: > > > Noted on this, I will update you through this thread. > > > > > > However is there any possibility of the following: > > > > > > > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > > > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > > > for the transactions. With this way, the IDLE processors would be utilized. > > > > > > What I mean here is, for the two interfaces: > > > > > > one IRQ for bce0 Rx > > > one IRQ for bce0 Tx > > > one IRQ for bce1 Rx > > > one IRQ for bce1 Tx > > > > I can't even begin to imagine how this would be possible on any NIC. > igb(4) does it. It is quite possible and one of the purposes of MSI. > However, the current bce(4) hardware does not support this. It only allows > for a single message and thus a single IRQ per-device. based from the man pages, igb driver supports Intel NICs w/ controllers starting from Intel NIC controller 82574. One Intel NIC (controller: 82576, see http://www.intel.com/Assets/PDF/prodbrief/320116.pdf) says it supports MSIX which minimizes the overhead of interrupts and allows load balancing of interrupt handling between multiple cores/CPUs. I should want a little more explanation how this feature being handled by MSIX. Thanks a lot. > -- > John Baldwin From won.derick at yahoo.com Fri Nov 14 03:30:11 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 03:30:18 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage Message-ID: <305614.76266.qm@web45809.mail.sp1.yahoo.com> > ----- Original Message ---- > From: Won De Erick > To: Jeremy Chadwick > Cc: freebsd-hardware@freebsd.org > Sent: Thursday, November 13, 2008 4:07:37 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Noted on this, I will update you through this thread. With FreeBSD 7.1 Beta2, here is the result: 52 root 1 -68 - 0K 16K CPU11 b 38:43 95.36% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 25:50 85.16% irq31: bce0 There's a slight difference w/ the previous result though, but I observed that overall CPU utilization didn't change. ### Complete result: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21 root 1 171 ki31 0K 16K CPU5 5 91:29 100.00% idle: cpu5 14 root 1 171 ki31 0K 16K CPU12 c 91:29 100.00% idle: cpu12 22 root 1 171 ki31 0K 16K CPU4 4 91:29 100.00% idle: cpu4 17 root 1 171 ki31 0K 16K CPU9 9 91:28 100.00% idle: cpu9 12 root 1 171 ki31 0K 16K CPU14 e 91:27 100.00% idle: cpu14 23 root 1 171 ki31 0K 16K CPU3 3 90:58 100.00% idle: cpu3 25 root 1 171 ki31 0K 16K CPU1 1 86:41 100.00% idle: cpu1 19 root 1 171 ki31 0K 16K CPU7 7 84:00 100.00% idle: cpu7 24 root 1 171 ki31 0K 16K CPU2 2 83:53 100.00% idle: cpu2 18 root 1 171 ki31 0K 16K CPU8 8 79:01 100.00% idle: cpu8 26 root 1 171 ki31 0K 16K RUN 0 74:18 100.00% idle: cpu0 11 root 1 171 ki31 0K 16K CPU15 0 0:00 100.00% idle: cpu15 13 root 1 171 ki31 0K 16K CPU13 0 0:00 100.00% idle: cpu13 20 root 1 171 ki31 0K 16K CPU6 6 90:18 99.27% idle: cpu6 52 root 1 -68 - 0K 16K CPU11 b 38:43 95.36% irq32: bce1 51 root 1 -68 - 0K 16K CPU10 a 25:50 85.16% irq31: bce0 16 root 1 171 ki31 0K 16K RUN a 65:39 15.97% idle: cpu10 28 root 1 -32 - 0K 16K WAIT 8 12:28 5.18% swi4: clock sio 15 root 1 171 ki31 0K 16K RUN b 52:46 3.76% idle: cpu11 45 root 1 -64 - 0K 16K WAIT 7 7:29 1.17% irq17: uhci0 47 root 1 -64 - 0K 16K WAIT 6 1:11 0.10% irq16: ciss0 Is there some ways how the intensive [network] load can be distributed among the IDLE processors? Another thing, I observed that in the above test, the net.isr is enabled by default. When I tried disabling this, # sysctl net.isr.direct=0 net.isr.direct: 1 -> 0 the result: 52 root 1 -68 - 0K 16K WAIT b 64:00 42.97% irq32: bce1 51 root 1 -68 - 0K 16K WAIT a 38:22 12.26% irq31: bce0 The CPU utilizations considerably dropped! What was changed in the fbsd7.1? How useful this net.isr is? Is this needed in an environment with heavy network traffic? Can someone explain? > However is there any possibility of the following: > > > I don't know if there's a way to split the interrupt request for each bce's Rx and Tx, > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > for the transactions. With this way, the IDLE processors would be utilized. > > What I mean here is, for the two interfaces: > > one IRQ for bce0 Rx > one IRQ for bce0 Tx > one IRQ for bce1 Rx > one IRQ for bce1 Tx > > > Thanks, > > Won > > > > ________________________________ > From: Jeremy Chadwick > To: Won De Erick > Cc: freebsd-hardware@freebsd.org > Sent: Thursday, November 13, 2008 3:46:02 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > On Wed, Nov 12, 2008 at 11:38:15PM -0800, Won De Erick wrote: > > I am conducting a CPU utilization testing with my box(HP DL 585 running FreeBSD 7.0), and come up with the results below: > > > > 52 root 1 -68 - 0K 16K CPU11 b 123:53 100.00% irq32: bce1 > > 51 root 1 -68 - 0K 16K CPU10 a 119:28 89.06% irq31: bce0 > > > > irq31 and irq32 are consuming high CPU usage, which i think the cause of hard reset. > > There was a ***major*** bce(4) cleanup that just happened. Your 7.0 box > will not have these changes. Please upgrade your box to RELENG_7 > (a.k.a. 7.1-PRERELEASE), csup'd recently (today preferably), and try > your tests again: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-November/046482.html > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > From ivoras at freebsd.org Fri Nov 14 03:48:58 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Nov 14 03:49:04 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <305614.76266.qm@web45809.mail.sp1.yahoo.com> References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> Message-ID: Won De Erick wrote: > Another thing, I observed that in the above test, the net.isr is enabled by default. When I tried disabling this, > > # sysctl net.isr.direct=0 > net.isr.direct: 1 -> 0 > > the result: > > 52 root 1 -68 - 0K 16K WAIT b 64:00 42.97% irq32: bce1 > 51 root 1 -68 - 0K 16K WAIT a 38:22 12.26% irq31: bce0 > > The CPU utilizations considerably dropped! You will probably find a "swi" process that has picked up the difference (when isr.direct is disabled, some of network protocol processing is offloaded to a swi thread). This might help spread the load across CPU but in my testing it didn't help real-world throughput. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081114/7fc43a3a/signature.pgp From won.derick at yahoo.com Fri Nov 14 04:46:40 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 04:46:46 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> Message-ID: <555333.76711.qm@web45806.mail.sp1.yahoo.com> > ----- Original Message ---- > From: Ivan Voras > To: freebsd-hardware@freebsd.org > Cc: freebsd-net@freebsd.org > Sent: Friday, November 14, 2008 7:49:13 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Won De Erick wrote: > > > Another thing, I observed that in the above test, the net.isr is enabled by default. When I tried disabling this, > > > > # sysctl net.isr.direct=0 > > net.isr.direct: 1 -> 0 > > > > the result: > > > > 52 root 1 -68 - 0K 16K WAIT b 64:00 42.97% irq32: bce1 > > 51 root 1 -68 - 0K 16K WAIT a 38:22 12.26% irq31: bce0 > > > > The CPU utilizations considerably dropped! > > You will probably find a "swi" process that has picked up the difference > (when isr.direct is disabled, some of network protocol processing is > offloaded to a swi thread). This might help spread the load across CPU > but in my testing it didn't help real-world throughput. > You are right. I noticed the following when net.isr is diabled, lowering the idle time of cpu0. 27 root 1 -44 - 0K 16K WAIT 0 52:20 76.37% swi1: net 26 root 1 171 ki31 0K 16K CPU0 0 111:58 64.36% idle: cpu0 Another thing, Packet drops on Intel NIC ( Intel? PRO/1000 PT Dual Port Server Adapter w/ control processor 82571GB) did not occur when the net.isr was disabled, while the overall CPU utilization remains considerably low. Note: The following result was obtained during a transition from a disabled to enabled net.isr. Hence the first part packets errs bytes packets errs bytes colls drops 10844 0 15603850 7940 0 582934 0 0 11659 0 16800328 8503 0 630330 0 0 11778 0 17033560 8998 0 677934 0 0 12149 0 17592134 9504 0 728094 0 0 12551 0 18223550 9974 0 774164 0 0 13127 0 19093604 10413 0 811858 0 0 13712 0 20010140 10924 0 848014 0 0 14499 0 21153538 11407 0 878252 0 0 14818 0 21740270 11979 0 915374 0 0 15831 0 23136446 12376 0 950636 0 0 15912 0 23365454 12852 0 997242 0 0 16257 0 23848866 13282 0 1041878 0 0 16384 0 24084782 13666 0 1079790 0 0 16670 0 24508980 14078 0 1106886 0 0 17845 0 26255548 14486 0 1134700 0 0 18097 0 26705634 15064 0 1163308 0 0 18470 0 27283000 15365 0 1198828 0 0 18139 0 26842676 15596 0 1225540 0 0 18792 0 27799564 16000 0 1264568 0 0 17854 178 26454106 16521 0 1298714 0 0 16741 1542 24820298 16770 0 1343328 0 0 input (em0) output packets errs bytes packets errs bytes colls drops 15288 1667 22683486 17231 0 1422690 0 0 15539 1718 23250372 17282 0 1495058 0 0 14379 545 21541954 17364 0 1508696 0 0 14312 1733 21546776 17276 0 1503372 0 0 14269 1744 21498908 17516 0 1508294 0 0 14444 1729 21766812 17175 0 1482130 0 0 15023 1724 22643198 16987 0 1432048 0 0 15279 1703 23036294 16909 0 1395094 0 0 15325 1701 23118536 16938 0 1380268 0 0 15572 1684 23494362 16909 0 1344214 0 0 15798 1699 23845972 16857 0 1303200 0 0 16195 1683 24497790 17059 0 1291586 0 0 16431 1674 24851278 16826 0 1245320 0 0 16683 1643 25231910 16675 0 1204450 0 0 16728 1647 25302534 16672 0 1178930 0 0 16826 1649 25455662 16662 0 1178140 0 0 16760 1653 25352830 16480 0 1161086 0 0 17002 1634 25720672 16423 0 1143508 0 0 16943 1643 25629892 16642 0 1160858 0 0 16995 1644 25708823 16539 0 1153782 0 0 17026 1643 25758462 16606 0 1153342 0 0 However, network throughput didn't change in the two scenarios above. Is there anything that I can test to improve my network throughput. Thanks, Won From ivoras at freebsd.org Fri Nov 14 04:54:52 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Nov 14 04:54:58 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <555333.76711.qm@web45806.mail.sp1.yahoo.com> References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> <555333.76711.qm@web45806.mail.sp1.yahoo.com> Message-ID: Won De Erick wrote: > 17002 1634 25720672 16423 0 1143508 0 0 > 16943 1643 25629892 16642 0 1160858 0 0 > 16995 1644 25708823 16539 0 1153782 0 0 > 17026 1643 25758462 16606 0 1153342 0 0 What do you use for generating the traffic? > However, network throughput didn't change in the two scenarios above. > Is there anything that I can test to improve my network throughput. I'm not sure but you could maybe try disabling all but one of your CPUs and see if anything changes. It looks like you have at least 16 CPUs. On my machine, with 8 CPUs (2xquad core) I get roughly 150,000 PPS before I hit a similar single-CPU-bound network processing bottleneck (also with Intel? PRO/1000 PT/Server) - which is too low for my needs so I'm searching for a solution. In my case I don't see transmission errors. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-hardware/attachments/20081114/fc82f3ef/signature.pgp From won.derick at yahoo.com Fri Nov 14 05:14:14 2008 From: won.derick at yahoo.com (Won De Erick) Date: Fri Nov 14 06:10:26 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage References: <305614.76266.qm@web45809.mail.sp1.yahoo.com> <555333.76711.qm@web45806.mail.sp1.yahoo.com> Message-ID: <674901.2796.qm@web45801.mail.sp1.yahoo.com> > From: Ivan Voras > To: freebsd-hardware@freebsd..org > Cc: freebsd-net@freebsd.org > Sent: Friday, November 14, 2008 8:55:13 PM > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > Won De Erick wrote: > > > 17002 1634 25720672 16423 0 1143508 0 0 > > 16943 1643 25629892 16642 0 1160858 0 0 > > 16995 1644 25708823 16539 0 1153782 0 0 > > 17026 1643 25758462 16606 0 1153342 0 0 > > What do you use for generating the traffic? > I used w-get in bombarding tcp traffic w/ thousand of sessions. > > However, network throughput didn't change in the two scenarios above. > > Is there anything that I can test to improve my network throughput. > > I'm not sure but you could maybe try disabling all but one of your CPUs > and see if anything changes. It looks like you have at least 16 CPUs. On > my machine, with 8 CPUs (2xquad core) I get roughly 150,000 PPS before I > hit a similar single-CPU-bound network processing bottleneck (also with > Intel? PRO/1000 PT/Server) - which is too low for my needs so I'm > searching for a solution. In my case I don't see transmission errors. will try this. From limguowei at gmail.com Fri Nov 14 08:13:49 2008 From: limguowei at gmail.com (weinter.lim) Date: Fri Nov 14 08:13:55 2008 Subject: Problems With BroadCom NetXtreme Ethernet and Atheros AR5B91 In-Reply-To: <200811131436.57422.jhb@freebsd.org> References: <20475350.post@talk.nabble.com> <200811131436.57422.jhb@freebsd.org> Message-ID: <20503489.post@talk.nabble.com> On Thursday 13 November 2008 01:18:03 am weinter.lim wrote: > > I am using FreeBSD 7.1 BETA 2 on my New Acer Aspire 4530 > During Boot Dmesg did not detect my Ethernet BroadCom NetXtreme > pciconf -lv > > none5@pci0:8:0:0 Class=0X020000 card=0X014a1025 chip=0X168414e4 rev=0X10 > hdr=0X00 > vendor = 'Broadcom Corporation' > class = network > subclass = ethernet The Linux tg3 driver claims this is a BCM5764. Can you try this patch and include any messages (especially any phy messages) from a verbose boot? Alternatively, you could boot w/o bge in the kernel, turn on bootverbose (debug.bootverbose sysctl) and kldload a patched bge.ko and capture the dmesg output. Index: if_bge.c =================================================================== RCS file: /usr/cvs/src/sys/dev/bge/if_bge.c,v retrieving revision 1.215 diff -u -r1.215 if_bge.c --- if_bge.c 27 Oct 2008 22:10:01 -0000 1.215 +++ if_bge.c 13 Nov 2008 19:33:15 -0000 @@ -184,6 +184,7 @@ { BCOM_VENDORID, BCOM_DEVICEID_BCM5754M }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5755M }, + { BCOM_VENDORID, BCOM_DEVICEID_BCM5764 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780 }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5780S }, { BCOM_VENDORID, BCOM_DEVICEID_BCM5781 }, Index: if_bgereg.h =================================================================== RCS file: /usr/cvs/src/sys/dev/bge/if_bgereg.h,v retrieving revision 1.81 diff -u -r1.81 if_bgereg.h --- if_bgereg.h 14 Oct 2008 20:28:42 -0000 1.81 +++ if_bgereg.h 13 Nov 2008 19:33:02 -0000 @@ -2094,6 +2094,7 @@ #define BCOM_DEVICEID_BCM5754M 0x1672 #define BCOM_DEVICEID_BCM5755 0x167B #define BCOM_DEVICEID_BCM5755M 0x1673 +#define BCOM_DEVICEID_BCM5764 0x1684 #define BCOM_DEVICEID_BCM5780 0x166A #define BCOM_DEVICEID_BCM5780S 0x166B #define BCOM_DEVICEID_BCM5781 0x16DD Hi, I patched the files as advise the Ethernet was detected but upon configuring the network no data was transmitted (the activity light did not lit up) and the system hung Thanks -- View this message in context: http://www.nabble.com/Problems-With-BroadCom-NetXtreme-Ethernet-and-Atheros-AR5B91-tp20475350p20503489.html Sent from the freebsd-hardware mailing list archive at Nabble.com. From jhb at freebsd.org Sat Nov 15 10:01:37 2008 From: jhb at freebsd.org (John Baldwin) Date: Sat Nov 15 10:01:43 2008 Subject: assigning interrupts In-Reply-To: <491D356A.70607@infoweapons.com> References: <491BFB68.7050405@infoweapons.com> <200811131441.16427.jhb@freebsd.org> <491D356A.70607@infoweapons.com> Message-ID: <200811151123.41183.jhb@freebsd.org> On Friday 14 November 2008 03:23:06 am Ronnel P. Maglasang wrote: > John Baldwin wrote: > > On Thursday 13 November 2008 05:03:20 am Ronnel P. Maglasang wrote: > > > >> Hi All, > >> > >> Is there a way to explicitly assign an interrupt > >> of a device? I'm running on 6.3 and the two NICs > >> share the same interrupt. Obviously this will affect > >> the performance if the NICs are exposed to heavy network > >> traffic. > >> > >> # vmstat -i > >> interrupt total rate > >> > >> irq11: em0 vr0+ 1081099 77 > >> > >> Total 16958562 1222 > >> > >> > >> Looking at the driver's code, I have the initial though > >> that this is the place where I can modify. > >> > >> -- > >> adapter->res_interrupt = bus_alloc_resource_any(dev, > >> SYS_RES_IRQ, &rid, RF_SHAREABLE | RF_ACTIVE); > >> -- > >> > >> I've tried changing RF_SHAREABLE to RF_ALLOCATED or other > >> values but still could not get the desired result and worst > >> the device fail to initialize. Is this possible in 6.3? > >> > > > > You can not easily assign them, no. In many cases the interrupt pins from the > > devices may be hardwired to a single input pin on an interrupt controller. > > In that case there is nothing you can do. You can read more about the gory > > details here: > > > > http://people.freebsd.org/~jhb/papers/bsdcan/2007/ > > > > > What was changed in 7.x in terms of assigning interrupts? I have another > box running on 7.0 (2 NICs). I noticed there are no devices sharing > interrupts. But if 6.x is installed on the same box (previous installation), > the two NICs will share the same interrupt. I'm now looking at the drivers. > I assume this is not NIC-firmware related. MSI. Newer 6.x (6.4, possibly 6.3; if not by default on 6.3 then it can be enabled on 6.3 via 'hw.pci.enable_msi=1' tunable) will do it as well. -- John Baldwin From jhb at freebsd.org Sat Nov 15 10:01:45 2008 From: jhb at freebsd.org (John Baldwin) Date: Sat Nov 15 10:01:54 2008 Subject: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage In-Reply-To: <829178.39837.qm@web45811.mail.sp1.yahoo.com> References: <704830.24415.qm@web45815.mail.sp1.yahoo.com> <200811131438.25904.jhb@freebsd.org> <829178.39837.qm@web45811.mail.sp1.yahoo.com> Message-ID: <200811151125.44733.jhb@freebsd.org> On Friday 14 November 2008 03:48:48 am Won De Erick wrote: > > > ----- Original Message ---- > > From: John Baldwin > > To: freebsd-hardware@freebsd.org > > Cc: Jeremy Chadwick ; Won De Erick > > Sent: Friday, November 14, 2008 3:38:25 AM > > Subject: Re: IRQ31 and IRQ32 on HPDL585 running FreeBSD 7.0 are consuming HIGH CPU usage > > > > On Thursday 13 November 2008 03:19:36 am Jeremy Chadwick wrote: > > > On Thu, Nov 13, 2008 at 12:07:37AM -0800, Won De Erick wrote: > > > > Noted on this, I will update you through this thread. > > > > > > > > However is there any possibility of the following: > > > > > > > > > I don't know if there's a way to split the interrupt request for each > bce's Rx and Tx, > > > > > which means a total of four IRQs, and eventually four cores (or 4 CPUs) > > > > > for the transactions. With this way, the IDLE processors would be > utilized. > > > > > > > > What I mean here is, for the two interfaces: > > > > > > > > one IRQ for bce0 Rx > > > > one IRQ for bce0 Tx > > > > one IRQ for bce1 Rx > > > > one IRQ for bce1 Tx > > > > > > I can't even begin to imagine how this would be possible on any NIC. > > > igb(4) does it. It is quite possible and one of the purposes of MSI. > > However, the current bce(4) hardware does not support this. It only allows > > for a single message and thus a single IRQ per-device. > > based from the man pages, igb driver supports Intel NICs w/ controllers starting from Intel NIC controller 82574. > > One Intel NIC (controller: 82576, see http://www.intel.com/Assets/PDF/prodbrief/320116.pdf) says it supports MSIX which minimizes the overhead of interrupts and allows load balancing of interrupt handling between multiple cores/CPUs. > > I should want a little more explanation how this feature being handled by MSIX. Thanks a lot. MSI/MSI-X is just an alternate facility PCI devices can use to assert interrupts rather than the legacy INTx lines. MSI/MSI-X support things like multiple messages per-device (rather than INTx where each function can only use a single intpin). As far as how a given PCI device makes use of MSI, that is up to that device's design and the driver. You would need to talk to the igb(4) maintainer to find out more details on how igb(4) uses MSI/MSI-X. -- John Baldwin From sebosik at demax.sk Sat Nov 15 12:48:49 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Sat Nov 15 12:48:57 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors Message-ID: <491F31B5.90403@demax.sk> Hi all OS: Freebsd 7-STABLE from CVS of today Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native mode, but not AHCI), LG SATA DVD-RW GH20NS15 Problem: if I run freebsd without LG DVD connected to any SATA port onboard everything works allright. When I connect SATA DVD to board, then freebsd refuses to boot with messages similar to those: acd0: FAILURE-READ_BIG timed out unknown: FAILURE-READ_BIG timed out cddone: goit error 0x5 back Messages are repeating forever. Anybody knows where should be a bug? Temporary I`ve disconnected LG SATA burner from system board. Thanks for any idea. Best regards -- Jan Sebosik, Slovakia sebosik@demax.sk From ltning at anduin.net Sun Nov 16 12:27:19 2008 From: ltning at anduin.net (=?ISO-8859-1?Q?Eirik_=D8verby?=) Date: Sun Nov 16 12:27:26 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <491C9535.3030504@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> Message-ID: On Nov 13, 2008, at 21:59, Danny Carroll wrote: > Scott Long wrote: >> The Areca controller likely doesn't buffer/cache for disks in JBOD >> mode, >> as others in this thread have stated. Without buffering, simple disk >> controllers will almost always be faster than accelerated raid >> controllers because the accelerated controllers add more latency >> between >> the host and the disk. A simple controller will directly funnel data >> from the host to the disk as soon as it receives a command. An >> accelerated controller, however, has a CPU and a mini-OS on it that >> has >> to schedule the work coming from the host and handle its own tasks >> and >> interrupts. This adds latency that quickly adds up under benchmarks. >> Your numbers clearly demonstrate this. > > That's nice to know. I'm not sure it tells us why the Non-Cached > writes > were about 8% faster though. The other thing about the "NoWriteCache" > test I performed that I neglected to mention yesterday is that I > actually panic'd the box (running out of memory). This was the first > time I have had that happen with ZFS even though in previous testing > (with cache enabled) I punished the box for a lot longer. > > Perhaps the ZFS caching took over where the disk caching left off? > Could that explain why I did not see a negative difference in the > numbers between Cache enabled and Cache disabled? > > One of the questions I wanted to answer for myself was just this: > "Does > a battery-backed cache on an Areca card protect me when I am in JBOD > mode." If the Areca does not buffer/cache in JBOD mode then that > means > the answer is no. I have noticed that my 3ware controllers, after updating firmware recently, have removed the JBOD option entirely, classifying it as something you wouldn't want to do with that kind of hardware anyway. I believed then, and even more so now, they are correct. Use the RAID-0 disk trick to be able to utilize the controller cache. And regarding write-back vs write-through; I believe write-through is equvivalent to disabling controller write cache, however it WILL cache the writes in order to respond to future reads of the data being written. I would guess, but I don't know, that this also goes for disk- level caches too, though, so it probably doesn't matter. /Eirik From fbsd at dannysplace.net Sun Nov 16 19:15:51 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Sun Nov 16 19:16:04 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> Message-ID: <4920E1DD.7000101@dannysplace.net> Eirik ?verby wrote: > I have noticed that my 3ware controllers, after updating firmware > recently, have removed the JBOD option entirely, classifying it as > something you wouldn't want to do with that kind of hardware anyway. I > believed then, and even more so now, they are correct. It kinda depends. If there were a good 8 or 16+ port SATA card out there that *simply* did SATA with no bells and whistles, then there would be no point buying a Raid adaptor when you want to use things like ZFS. But there are no such cards available. > Use the RAID-0 disk trick to be able to utilize the controller cache. > And regarding write-back vs write-through; I believe write-through is > equvivalent to disabling controller write cache, however it WILL cache > the writes in order to respond to future reads of the data being > written. I would guess, but I don't know, that this also goes for > disk-level caches too, though, so it probably doesn't matter. It is interesting to me that the default setting on the Areca card was to have the disk caches turned on. I think that is strange because by default you have a situation that can lead to data loss even if you have a battery backup unit. -D From matt at corp.spry.com Sun Nov 16 22:35:28 2008 From: matt at corp.spry.com (Matt Simerson) Date: Sun Nov 16 22:35:34 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <4920E1DD.7000101@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> Message-ID: On Nov 16, 2008, at 7:15 PM, Danny Carroll wrote: > Eirik ?verby wrote: >> I have noticed that my 3ware controllers, after updating firmware >> recently, have removed the JBOD option entirely, classifying it as >> something you wouldn't want to do with that kind of hardware >> anyway. I >> believed then, and even more so now, they are correct. > > It kinda depends. If there were a good 8 or 16+ port SATA card out > there that *simply* did SATA with no bells and whistles, then there > would be no point buying a Raid adaptor when you want to use things > like > ZFS. > > But there are no such cards available. Allow me to introduce you to Marvell. The sell the SATA controller used in the Sun thumper (X4500). I've used that same SATA controller under OpenSolaris and FreeBSD. Unfortunately, that controller doesn't use multi-lane cables. When you pack in 3 controllers and 24 disks, it's a cabling disaster. http://freebsd.monkey.org/freebsd-fs/200808/msg00027.html >> Use the RAID-0 disk trick to be able to utilize the controller cache. >> And regarding write-back vs write-through; I believe write-through is >> equvivalent to disabling controller write cache, however it WILL >> cache >> the writes in order to respond to future reads of the data being >> written. I would guess, but I don't know, that this also goes for >> disk-level caches too, though, so it probably doesn't matter. > > It is interesting to me that the default setting on the Areca card was > to have the disk caches turned on. I think that is strange because by > default you have a situation that can lead to data loss even if you > have > a battery backup unit. The Areca cards do NOT have the cache enabled by default. I ordered the optional battery and RAM upgrade for my collection of 1231ML cards. Even with the BBWC, the cache is not enabled by default. I had to go out of my way to enable it, on every single controller. Matt From koitsu at FreeBSD.org Sun Nov 16 23:08:22 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Sun Nov 16 23:08:32 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> Message-ID: <20081117070818.GA22231@icarus.home.lan> On Sun, Nov 16, 2008 at 10:06:42PM -0800, Matt Simerson wrote: > > On Nov 16, 2008, at 7:15 PM, Danny Carroll wrote: > >> Eirik ?verby wrote: >>> I have noticed that my 3ware controllers, after updating firmware >>> recently, have removed the JBOD option entirely, classifying it as >>> something you wouldn't want to do with that kind of hardware anyway. >>> I >>> believed then, and even more so now, they are correct. >> >> It kinda depends. If there were a good 8 or 16+ port SATA card out >> there that *simply* did SATA with no bells and whistles, then there >> would be no point buying a Raid adaptor when you want to use things >> like >> ZFS. >> >> But there are no such cards available. > > Allow me to introduce you to Marvell. The sell the SATA controller used > in the Sun thumper (X4500). I've used that same SATA controller under > OpenSolaris and FreeBSD. Unfortunately, that controller doesn't use > multi-lane cables. When you pack in 3 controllers and 24 disks, it's a > cabling disaster. > > http://freebsd.monkey.org/freebsd-fs/200808/msg00027.html I participated in that thread. http://freebsd.monkey.org/freebsd-fs/200808/msg00028.html The questions I had never got answered. The most important one being: have you actually performed a hard failure or forced disk swap with both the Areca and Marvell controllers? And how does FreeBSD behave when you do this? I've a feeling it works fine on the Areca (since CAM/da(4) are used), but if the Marvell card uses ata(4) (and I'm guessing it does) I'm concerned. Why? For sake of comparison: Promise controllers are considered one of the most well-supported controllers under FreeBSD, mainly due to Soren having access to their documentation; yet, when I attempted to do an actual disk upgrade, the Promise controller did nothing but cause me grief, forcing me to yank the entire card from my system. http://wiki.freebsd.org/JeremyChadwick/ZFS_disk_upgrade_gone_bad Users should read this story and the follow-up. And in my situation, the disk wasn't even bad/failed. What was supposed to be a simple procedure (and it was with Intel AHCI, as you'll read) turned into a complete nightmare. Take my story and apply it to a production datacentre -- but with an 8 or 16-port card and a shelf of disks. What're you going to tell your boss when this stuff fails like how I documented? "Yeah so I need US$600 to replace the card" "Why? We don't have that kind of budget. Is the card bad? Can we RMA it?" "No, the card isn't bad" "Then what is the problem?" "Well you see......" So when I see someone say "Yeah, try the , it works great", my first response is "Just how well have you actually tested failure or upgrade scenarios?" Most don't, and instead just *assume* come fail-time, that everything will "just work" -- and they find out the horrible truth when it's already too late. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From danny at dannysplace.net Mon Nov 17 03:42:53 2008 From: danny at dannysplace.net (Danny Carroll) Date: Mon Nov 17 03:43:04 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> Message-ID: <492158D2.5020506@dannysplace.net> Matt Simerson wrote: > Allow me to introduce you to Marvell. The sell the SATA controller used > in the Sun thumper (X4500). I've used that same SATA controller under > OpenSolaris and FreeBSD. Unfortunately, that controller doesn't use > multi-lane cables. When you pack in 3 controllers and 24 disks, it's a > cabling disaster. > > http://freebsd.monkey.org/freebsd-fs/200808/msg00027.html Interesting. Wish I had seen it before. To be honest I did consider this board but I was really in favour of PCIe over PCIX. That might have been a mistake :-) > The Areca cards do NOT have the cache enabled by default. I ordered the > optional battery and RAM upgrade for my collection of 1231ML cards. Even > with the BBWC, the cache is not enabled by default. I had to go out of > my way to enable it, on every single controller. Are you talking about the Areca cache or the disks own caches? On my board it was enabled. But maybe mine was the exception. -D From morganw at chemikals.org Mon Nov 17 03:44:50 2008 From: morganw at chemikals.org (Wes Morgan) Date: Mon Nov 17 03:44:57 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> Message-ID: On Sun, 16 Nov 2008, Matt Simerson wrote: > > On Nov 16, 2008, at 7:15 PM, Danny Carroll wrote: > >> Eirik ?verby wrote: >>> I have noticed that my 3ware controllers, after updating firmware >>> recently, have removed the JBOD option entirely, classifying it as >>> something you wouldn't want to do with that kind of hardware anyway. I >>> believed then, and even more so now, they are correct. >> >> It kinda depends. If there were a good 8 or 16+ port SATA card out >> there that *simply* did SATA with no bells and whistles, then there >> would be no point buying a Raid adaptor when you want to use things like >> ZFS. >> >> But there are no such cards available. > > Allow me to introduce you to Marvell. The sell the SATA controller used in > the Sun thumper (X4500). I've used that same SATA controller under > OpenSolaris and FreeBSD. Unfortunately, that controller doesn't use > multi-lane cables. When you pack in 3 controllers and 24 disks, it's a > cabling disaster. > > http://freebsd.monkey.org/freebsd-fs/200808/msg00027.html > >>> Use the RAID-0 disk trick to be able to utilize the controller cache. >>> And regarding write-back vs write-through; I believe write-through is >>> equvivalent to disabling controller write cache, however it WILL cache >>> the writes in order to respond to future reads of the data being >>> written. I would guess, but I don't know, that this also goes for >>> disk-level caches too, though, so it probably doesn't matter. >> >> It is interesting to me that the default setting on the Areca card was >> to have the disk caches turned on. I think that is strange because by >> default you have a situation that can lead to data loss even if you have >> a battery backup unit. > > The Areca cards do NOT have the cache enabled by default. I ordered the > optional battery and RAM upgrade for my collection of 1231ML cards. Even with > the BBWC, the cache is not enabled by default. I had to go out of my way to > enable it, on every single controller. Are you using these areca cards successfully with large arrays? I found a 1680i card for a decent price and installed it this weekend, but since then I'm seeing the raidz2 pool that it's running hang so frequently that I can't even trust using it. The hangs occur in both 7-stable and 8-current with the new ZFS patch. Same exact settings that have been rock solid for me before now don't want to work at all. The drives are just set as JBOD -- the controller actually defaulted to this, so I didn't have to make any real changes in the BIOS. Any tips on your setup? Did you have any similar problems? From matt at corp.spry.com Mon Nov 17 13:05:00 2008 From: matt at corp.spry.com (Matt Simerson) Date: Mon Nov 17 13:05:12 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: <492158D2.5020506@dannysplace.net> References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> <492158D2.5020506@dannysplace.net> Message-ID: On Nov 17, 2008, at 3:43 AM, Danny Carroll wrote: > Matt Simerson wrote: >> Allow me to introduce you to Marvell. The sell the SATA controller >> used >> in the Sun thumper (X4500). I've used that same SATA controller under >> OpenSolaris and FreeBSD. Unfortunately, that controller doesn't use >> multi-lane cables. When you pack in 3 controllers and 24 disks, >> it's a >> cabling disaster. >> >> http://freebsd.monkey.org/freebsd-fs/200808/msg00027.html > > Interesting. Wish I had seen it before. To be honest I did consider > this board but I was really in favour of PCIe over PCIX. That might > have been a mistake :-) > >> The Areca cards do NOT have the cache enabled by default. I ordered >> the >> optional battery and RAM upgrade for my collection of 1231ML cards. >> Even >> with the BBWC, the cache is not enabled by default. I had to go out >> of >> my way to enable it, on every single controller. > > Are you talking about the Areca cache or the disks own caches? Disk caching is a completely different animal, and one which I didn't mention. I'm spoke only about the write cache on the controller. Mine all arrived off by default, which is a VERY reasonable default configuration. Page 97 of the manual says about it: >>> 3.7.5.12 Disk Write Cache Mode >>> User can set the "Disk Write Cache Mode" to Auto, Enabled, or >>> Disabled. Enabled increases speed, Disabled increases reliability. > On my board it was enabled. But maybe mine was the exception. Perhaps it's model specific, or your vendor configured it that way. Or you got a return that someone else monkeyed with. I'm not going to speak for Areca but it seems quite odd that Areca would ship them with the cache enabled. I've used many hundreds of RAID controllers over the years and without exception, every single one with a write cache had it disabled by default. Matt From matt at corp.spry.com Mon Nov 17 14:07:54 2008 From: matt at corp.spry.com (Matt Simerson) Date: Mon Nov 17 14:08:01 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> Message-ID: <8B620677-C2CA-4408-A0B1-AACC23FD0FF1@corp.spry.com> On Nov 17, 2008, at 3:26 AM, Wes Morgan wrote: >>> The Areca cards do NOT have the cache enabled by default. I >>> ordered the optional battery and RAM upgrade for my collection of >>> 1231ML cards. Even with the BBWC, the cache is not enabled by >>> default. I had to go out of my way to enable it, on every single >>> controller. > > Are you using these areca cards successfully with large arrays? Yes, if you consider 24 x 1TB large. > I found a 1680i card for a decent price and installed it this > weekend, but since then I'm seeing the raidz2 pool that it's running > hang so frequently that I can't even trust using it. The hangs occur > in both 7-stable and 8-current with the new ZFS patch. Same exact > settings that have been rock solid for me before now don't want to > work at all. The drives are just set as JBOD -- the controller > actually defaulted to this, so I didn't have to make any real > changes in the BIOS. > > Any tips on your setup? Did you have any similar problems? I talked to a storage vendor of ours that has sold several SuperMicro systems like ours where the client was using OpenSolaris and having similar stability issues to what we see on FreeBSD. It seems to be a lack of maturity in ZFS that underlies these problems. It appears that running ZFS on FreeBSD will either thrill or horrify. When I tested with modest I/O requirements, it worked great and I was tickled. But when I build these new systems as backup servers, I was generating immensely more disk I/O. I started with 7.0 release and saw crashes hourly. With tuning, I was only crashing once or twice a day (always memory related). With 16GB of RAM. I ran for a month with one server on JBOD with RAIDZ2 and another with RAIDZ across two RAID 5 arrays. Then I lost a disk and consequently the array on the JBOD server. Since RAID 5 had proved to run so much faster, I ditched the Marvell cards, installed a pair of 1231MLs and reformatted it with RAID 5. Both 24 disk systems have been ZFS RAIDZ across two RAID 5 hardware arrays for months since. If I build another system tomorrow, that's exactly how I'd do it. After upgrading to 8-HEAD and applying The Great ZFS Patch, I am content with only having to reboot the systems once every 7-12 days. I have another system with only 8 disks and 4GB of RAM with ZFS running on a single RAID 5 array. Under the same workload as the 24 disk systems, it was crashing at least once a day. This was existing hardware, so we were confident it wasn't hardware issues. I finally resolved it by wiping the disks clean, creating a GPT partition on the array and using UFS. The system hasn't crashed once since and is far more responsive under heavy load than my ZFS systems. Of course, all of this might get a fair bit better soon: http://svn.freebsd.org/viewvc/base?view=revision&revision=185029 Matt From danny at dannysplace.net Mon Nov 17 15:46:17 2008 From: danny at dannysplace.net (Danny Carroll) Date: Mon Nov 17 15:46:32 2008 Subject: Areca vs. ZFS performance testing. In-Reply-To: References: <490A782F.9060406@dannysplace.net> <20081031033208.GA21220@icarus.home.lan> <490A849C.7030009@dannysplace.net> <20081031043412.GA22289@icarus.home.lan> <490A8FAD.8060009@dannysplace.net> <491BBF38.9010908@dannysplace.net> <491C5AA7.1030004@samsco.org> <491C9535.3030504@dannysplace.net> <4920E1DD.7000101@dannysplace.net> <492158D2.5020506@dannysplace.net> Message-ID: <49220238.2040507@dannysplace.net> Matt Simerson wrote: > Disk caching is a completely different animal, and one which I didn't > mention. I'm spoke only about the write cache on the controller. Mine > all arrived off by default, which is a VERY reasonable default > configuration. Page 97 of the manual says about it: Ahhh, no I was talking about the disk cache setting. That is the one that is set to on by default (at least for me). I find it strange that this is the case. IMHO it makes the idea of a Battery backed cache redundant. > Perhaps it's model specific, or your vendor configured it that way. Or > you got a return that someone else monkeyed with. I'm not going to speak > for Areca but it seems quite odd that Areca would ship them with the > cache enabled. I've used many hundreds of RAID controllers over the > years and without exception, every single one with a write cache had it > disabled by default. I guess I had a return model. It's not really a big deal. -D From sebosik at demax.sk Wed Nov 19 02:08:37 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 02:08:43 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <491F31B5.90403@demax.sk> References: <491F31B5.90403@demax.sk> Message-ID: <4923E5A2.2060402@demax.sk> Hi again so it seems to be a problem with HPET timer which is onboard and was enabled. If I turned him off, (acd | cd) problems went away. Jan Sebosik napsal(a): > Hi all > > OS: Freebsd 7-STABLE from CVS of today > Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native mode, > but not AHCI), LG SATA DVD-RW GH20NS15 > > Problem: if I run freebsd without LG DVD connected to any SATA port > onboard everything works allright. When I connect SATA DVD to board, > then freebsd refuses to boot with messages similar to those: > > acd0: FAILURE-READ_BIG timed out > unknown: FAILURE-READ_BIG timed out > cddone: goit error 0x5 back > > Messages are repeating forever. > > Anybody knows where should be a bug? > Temporary I`ve disconnected LG SATA burner from system board. > > Thanks for any idea. > > Best regards -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 02:15:32 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 02:15:38 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <4923E5A2.2060402@demax.sk> References: <491F31B5.90403@demax.sk> <4923E5A2.2060402@demax.sk> Message-ID: <20081119101530.GA82861@icarus.home.lan> On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: > Hi again > > so it seems to be a problem with HPET timer which is onboard and was > enabled. If I turned him off, (acd | cd) problems went away. > > > Jan Sebosik napsal(a): >> Hi all >> >> OS: Freebsd 7-STABLE from CVS of today >> Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native mode, >> but not AHCI), LG SATA DVD-RW GH20NS15 >> >> Problem: if I run freebsd without LG DVD connected to any SATA port >> onboard everything works allright. When I connect SATA DVD to board, >> then freebsd refuses to boot with messages similar to those: >> >> acd0: FAILURE-READ_BIG timed out >> unknown: FAILURE-READ_BIG timed out >> cddone: goit error 0x5 back >> >> Messages are repeating forever. >> >> Anybody knows where should be a bug? >> Temporary I`ve disconnected LG SATA burner from system board. >> >> Thanks for any idea. >> >> Best regards Are you ***absolutely 100% certain*** this is true? The time counter selected shouldn't have anything to do with the errors you see. Please thoroughly test this. I'd CC jhb@ to get confirmation of my statement, but I've promised myself I wouldn't bother him until 2009. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 02:19:39 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 02:19:46 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <20081119101530.GA82861@icarus.home.lan> References: <491F31B5.90403@demax.sk> <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> Message-ID: <4923E839.7090001@demax.sk> Hi Yeah, I`ve tested it 2 times (switching it in BIOS). To me it seems bit mysterious, why there is a relationship between HPET setting and acd/cd problems in FreeBSD. Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: >> Hi again >> >> so it seems to be a problem with HPET timer which is onboard and was >> enabled. If I turned him off, (acd | cd) problems went away. >> >> >> Jan Sebosik napsal(a): >>> Hi all >>> >>> OS: Freebsd 7-STABLE from CVS of today >>> Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native mode, >>> but not AHCI), LG SATA DVD-RW GH20NS15 >>> >>> Problem: if I run freebsd without LG DVD connected to any SATA port >>> onboard everything works allright. When I connect SATA DVD to board, >>> then freebsd refuses to boot with messages similar to those: >>> >>> acd0: FAILURE-READ_BIG timed out >>> unknown: FAILURE-READ_BIG timed out >>> cddone: goit error 0x5 back >>> >>> Messages are repeating forever. >>> >>> Anybody knows where should be a bug? >>> Temporary I`ve disconnected LG SATA burner from system board. >>> >>> Thanks for any idea. >>> >>> Best regards > > Are you ***absolutely 100% certain*** this is true? The time counter > selected shouldn't have anything to do with the errors you see. > Please thoroughly test this. > > I'd CC jhb@ to get confirmation of my statement, but I've promised > myself I wouldn't bother him until 2009. :-) > -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 02:25:55 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 02:26:02 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <4923E839.7090001@demax.sk> References: <491F31B5.90403@demax.sk> <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> Message-ID: <20081119102552.GA83022@icarus.home.lan> On Wed, Nov 19, 2008 at 11:19:37AM +0100, Jan Sebosik wrote: > Hi > > Yeah, I`ve tested it 2 times (switching it in BIOS). To me it seems bit > mysterious, why there is a relationship between HPET setting and acd/cd > problems in FreeBSD. > > > Jeremy Chadwick napsal(a): >> On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: >>> Hi again >>> >>> so it seems to be a problem with HPET timer which is onboard and was >>> enabled. If I turned him off, (acd | cd) problems went away. >>> >>> >>> Jan Sebosik napsal(a): >>>> Hi all >>>> >>>> OS: Freebsd 7-STABLE from CVS of today >>>> Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native >>>> mode, but not AHCI), LG SATA DVD-RW GH20NS15 >>>> >>>> Problem: if I run freebsd without LG DVD connected to any SATA port >>>> onboard everything works allright. When I connect SATA DVD to >>>> board, then freebsd refuses to boot with messages similar to >>>> those: >>>> >>>> acd0: FAILURE-READ_BIG timed out >>>> unknown: FAILURE-READ_BIG timed out >>>> cddone: goit error 0x5 back >>>> >>>> Messages are repeating forever. >>>> >>>> Anybody knows where should be a bug? >>>> Temporary I`ve disconnected LG SATA burner from system board. >>>> >>>> Thanks for any idea. >>>> >>>> Best regards >> >> Are you ***absolutely 100% certain*** this is true? The time counter >> selected shouldn't have anything to do with the errors you see. >> Please thoroughly test this. >> >> I'd CC jhb@ to get confirmation of my statement, but I've promised >> myself I wouldn't bother him until 2009. :-) This is very bizarre. The errors being returned from acd0 are that an ATAPI/ATA command (READ_BIG, whatever the code for that is) did not receive a response from the controller or device within 5 seconds (assuming the ata(4) timeout values here; it could be something larger for ATAPI, I don't know). Maybe some a BIOS bug... Can you show us output from the following two commands? sysctl kern.timecounter.choice sysctl kern.timecounter.hardware Soren, do you know how/if the HPET time counter could cause this oddity? All of my systems use ACPI-fast, so I can't test this. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 02:55:36 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 02:55:43 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <20081119102552.GA83022@icarus.home.lan> References: <491F31B5.90403@demax.sk> <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> Message-ID: <4923F0A6.9080304@demax.sk> Allright, I`ve played again with an HPET in BIOS little bit. Results -> HPET disabled: kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast HPET enabled: kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast But now FreeBSD boots also with HPET enabled (really don`t understand what`s going on). When I was trying to mount cd with "mount -t cd9660 /dev/cd0 /mnt/cd0", mount works as expected (atapicd module not loaded). Then I`ve kldload-ed atapicd, "mouunt -t cd9660 /dev/acd0 /mnt/cd0" (acd0, not cd0), but this ended with messages like this: unknown: FAILURE - READ_BIG timeout (retry count 0) Temporary I`ve disabled HPET in BIOS (Linux got problems too-> he created gigabytes of log messages in /var/log/messages :D). Best regards, Jan Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 11:19:37AM +0100, Jan Sebosik wrote: >> Hi >> >> Yeah, I`ve tested it 2 times (switching it in BIOS). To me it seems bit >> mysterious, why there is a relationship between HPET setting and acd/cd >> problems in FreeBSD. >> >> >> Jeremy Chadwick napsal(a): >>> On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: >>>> Hi again >>>> >>>> so it seems to be a problem with HPET timer which is onboard and was >>>> enabled. If I turned him off, (acd | cd) problems went away. >>>> >>>> >>>> Jan Sebosik napsal(a): >>>>> Hi all >>>>> >>>>> OS: Freebsd 7-STABLE from CVS of today >>>>> Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in native >>>>> mode, but not AHCI), LG SATA DVD-RW GH20NS15 >>>>> >>>>> Problem: if I run freebsd without LG DVD connected to any SATA port >>>>> onboard everything works allright. When I connect SATA DVD to >>>>> board, then freebsd refuses to boot with messages similar to >>>>> those: >>>>> >>>>> acd0: FAILURE-READ_BIG timed out >>>>> unknown: FAILURE-READ_BIG timed out >>>>> cddone: goit error 0x5 back >>>>> >>>>> Messages are repeating forever. >>>>> >>>>> Anybody knows where should be a bug? >>>>> Temporary I`ve disconnected LG SATA burner from system board. >>>>> >>>>> Thanks for any idea. >>>>> >>>>> Best regards >>> Are you ***absolutely 100% certain*** this is true? The time counter >>> selected shouldn't have anything to do with the errors you see. >>> Please thoroughly test this. >>> >>> I'd CC jhb@ to get confirmation of my statement, but I've promised >>> myself I wouldn't bother him until 2009. :-) > > This is very bizarre. The errors being returned from acd0 are that an > ATAPI/ATA command (READ_BIG, whatever the code for that is) did not > receive a response from the controller or device within 5 seconds > (assuming the ata(4) timeout values here; it could be something larger > for ATAPI, I don't know). Maybe some a BIOS bug... > > Can you show us output from the following two commands? > > sysctl kern.timecounter.choice > sysctl kern.timecounter.hardware > > Soren, do you know how/if the HPET time counter could cause this oddity? > All of my systems use ACPI-fast, so I can't test this. > -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 03:21:04 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 03:21:30 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <4923F0A6.9080304@demax.sk> References: <491F31B5.90403@demax.sk> <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> Message-ID: <20081119112102.GA84963@icarus.home.lan> On Wed, Nov 19, 2008 at 11:55:34AM +0100, Jan Sebosik wrote: > Allright, I`ve played again with an HPET in BIOS little bit. > > Results -> > > HPET disabled: > > kern.timecounter.choice: TSC(-100) ACPI-fast(1000) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > > HPET enabled: > > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) > dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > > > But now FreeBSD boots also with HPET enabled (really don`t understand > what`s going on). > > When I was trying to mount cd with "mount -t cd9660 /dev/cd0 /mnt/cd0", > mount works as expected (atapicd module not loaded). > > Then I`ve kldload-ed atapicd, "mouunt -t cd9660 /dev/acd0 /mnt/cd0" > (acd0, not cd0), but this ended with messages like this: > unknown: FAILURE - READ_BIG timeout (retry count 0) > > Temporary I`ve disabled HPET in BIOS (Linux got problems too-> he > created gigabytes of log messages in /var/log/messages :D). > > Best regards, Jan > > Jeremy Chadwick napsal(a): >> On Wed, Nov 19, 2008 at 11:19:37AM +0100, Jan Sebosik wrote: >>> Hi >>> >>> Yeah, I`ve tested it 2 times (switching it in BIOS). To me it seems >>> bit mysterious, why there is a relationship between HPET setting and >>> acd/cd problems in FreeBSD. >>> >>> >>> Jeremy Chadwick napsal(a): >>>> On Wed, Nov 19, 2008 at 11:08:34AM +0100, Jan Sebosik wrote: >>>>> Hi again >>>>> >>>>> so it seems to be a problem with HPET timer which is onboard and >>>>> was enabled. If I turned him off, (acd | cd) problems went away. >>>>> >>>>> >>>>> Jan Sebosik napsal(a): >>>>>> Hi all >>>>>> >>>>>> OS: Freebsd 7-STABLE from CVS of today >>>>>> Problematic HW: Intel DQ45CB (Q45 chipset, ICH10, SATA in >>>>>> native mode, but not AHCI), LG SATA DVD-RW GH20NS15 >>>>>> >>>>>> Problem: if I run freebsd without LG DVD connected to any SATA >>>>>> port onboard everything works allright. When I connect SATA >>>>>> DVD to board, then freebsd refuses to boot with messages >>>>>> similar to those: >>>>>> >>>>>> acd0: FAILURE-READ_BIG timed out >>>>>> unknown: FAILURE-READ_BIG timed out >>>>>> cddone: goit error 0x5 back >>>>>> >>>>>> Messages are repeating forever. >>>>>> >>>>>> Anybody knows where should be a bug? >>>>>> Temporary I`ve disconnected LG SATA burner from system board. >>>>>> >>>>>> Thanks for any idea. >>>>>> >>>>>> Best regards >>>> Are you ***absolutely 100% certain*** this is true? The time counter >>>> selected shouldn't have anything to do with the errors you see. >>>> Please thoroughly test this. >>>> >>>> I'd CC jhb@ to get confirmation of my statement, but I've promised >>>> myself I wouldn't bother him until 2009. :-) >> >> This is very bizarre. The errors being returned from acd0 are that an >> ATAPI/ATA command (READ_BIG, whatever the code for that is) did not >> receive a response from the controller or device within 5 seconds >> (assuming the ata(4) timeout values here; it could be something larger >> for ATAPI, I don't know). Maybe some a BIOS bug... >> >> Can you show us output from the following two commands? >> >> sysctl kern.timecounter.choice >> sysctl kern.timecounter.hardware >> >> Soren, do you know how/if the HPET time counter could cause this oddity? >> All of my systems use ACPI-fast, so I can't test this. What this proves is that disabling HPET in the BIOS makes absolutely no change to FreeBSD as far as the timecounter goes. It's still using ACPI-fast no matter if HPET is disabled or not. Disabling HPET does show up in FreeBSD (as you can tell), but the ATA/ATAPI stuff *should not* have some direct tie-in to HPET. I'm left believing you've found a BIOS bug. Please bring this up with your motherboard or system vendor. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 03:41:03 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 03:41:09 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <4923FA30.5000303@modulus.org> References: <491F31B5.90403@demax.sk> <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> Message-ID: <4923FB4D.7090505@demax.sk> Andrew Snow napsal(a): > > Hi > > I have a P45 chipset but haven't noticed those problems. I use AHCI > mode because it enabled hotswap SATA. > > But do you also get error messages on the console about timecount going > backwards for some processes? I can't make it go away, even if I force > HPET as a counter > > - Andrew Hi obviously no, I don`t get any messages about time going backwards. I`ve also tryied AHCI mode, but after some mailing with Intel technical support they claimed to downgrade to native SATA mode (non-AHCI operation). -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 03:53:15 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 03:53:22 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <4923FB4D.7090505@demax.sk> References: <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> Message-ID: <20081119115311.GA85626@icarus.home.lan> On Wed, Nov 19, 2008 at 12:41:01PM +0100, Jan Sebosik wrote: > Andrew Snow napsal(a): >> >> Hi >> >> I have a P45 chipset but haven't noticed those problems. I use AHCI >> mode because it enabled hotswap SATA. >> >> But do you also get error messages on the console about timecount going >> backwards for some processes? I can't make it go away, even if I force >> HPET as a counter >> >> - Andrew > > Hi > > obviously no, I don`t get any messages about time going backwards. > > I`ve also tryied AHCI mode, but after some mailing with Intel technical > support they claimed to downgrade to native SATA mode (non-AHCI > operation). Andrew: "Time going backwards" is known to happen on certain systems which use features like Intel SpeedStep. I can reproduce the problem on all sorts of server hardware. It's documented in my Wiki under "Kernel": http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues Power-save modes such as C1E might also cause it, but I've enabled this on systems without any repercussions. Just EIST appears to behave oddly, on RELENG_7. (I've tried EIST on CURRENT, and it seems to behave better. I remember reading about major improvements jhb@ completed there which might explain CURRENT working) Jan: (Quoting you from your misplaced mail to -stable) > I thought also about bios bug... it`s pretty new piece of HW with modern > chipset (Q45). I believe that the next release of BIOS comes soon. The chipset has nothing to do with it. I can show you two identical systems, chipset-wise, and show you BIOS bugs. The system manufacturer is who maintains the BIOS, not the chipset manufacturer. > But what about those atapicd problems? Is it related to SATA interface > of DVD/CD drive? Maybe also the LG drive has buggy FW :). Now I'm confused. Didn't we just determine that your acd0 problems disappear if you disable HPET in the BIOS (which makes no sense, but it works, and is probably a BIOS bug)? If so, then what's that got to do with SATA interfaces or LG optical drives? Please help me understand. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 04:16:35 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 04:16:42 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <20081119115311.GA85626@icarus.home.lan> References: <4923E5A2.2060402@demax.sk> <20081119101530.GA82861@icarus.home.lan> <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> Message-ID: <492403A1.60209@demax.sk> Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 12:41:01PM +0100, Jan Sebosik wrote: >> Andrew Snow napsal(a): >>> Hi >>> >>> I have a P45 chipset but haven't noticed those problems. I use AHCI >>> mode because it enabled hotswap SATA. >>> >>> But do you also get error messages on the console about timecount going >>> backwards for some processes? I can't make it go away, even if I force >>> HPET as a counter >>> >>> - Andrew >> Hi >> >> obviously no, I don`t get any messages about time going backwards. >> >> I`ve also tryied AHCI mode, but after some mailing with Intel technical >> support they claimed to downgrade to native SATA mode (non-AHCI >> operation). > > Andrew: > > "Time going backwards" is known to happen on certain systems which use > features like Intel SpeedStep. I can reproduce the problem on all sorts > of server hardware. It's documented in my Wiki under "Kernel": > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > Power-save modes such as C1E might also cause it, but I've enabled this > on systems without any repercussions. Just EIST appears to behave > oddly, on RELENG_7. (I've tried EIST on CURRENT, and it seems to behave > better. I remember reading about major improvements jhb@ completed > there which might explain CURRENT working) > > Jan: > > (Quoting you from your misplaced mail to -stable) > >> I thought also about bios bug... it`s pretty new piece of HW with modern >> chipset (Q45). I believe that the next release of BIOS comes soon. > > The chipset has nothing to do with it. I can show you two identical > systems, chipset-wise, and show you BIOS bugs. The system manufacturer > is who maintains the BIOS, not the chipset manufacturer. Thanks for explanation. >> But what about those atapicd problems? Is it related to SATA interface >> of DVD/CD drive? Maybe also the LG drive has buggy FW :). > > Now I'm confused. Didn't we just determine that your acd0 problems > disappear if you disable HPET in the BIOS (which makes no sense, but it > works, and is probably a BIOS bug)? If so, then what's that got to do > with SATA interfaces or LG optical drives? Please help me understand. No, atapicd problems are still there regardless of HPET setting. But with HPET enabled, when I kldload atapicd and then try to mount it with command "mount -t cd9660 /dev/acd0 /mnt/cd0", I get neverending "READ_BIG FAILURE" timeouts. -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 04:22:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 04:22:10 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <492403A1.60209@demax.sk> References: <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> Message-ID: <20081119122201.GA86297@icarus.home.lan> On Wed, Nov 19, 2008 at 01:16:33PM +0100, Jan Sebosik wrote: >>> But what about those atapicd problems? Is it related to SATA interface >>> of DVD/CD drive? Maybe also the LG drive has buggy FW :). >> >> Now I'm confused. Didn't we just determine that your acd0 problems >> disappear if you disable HPET in the BIOS (which makes no sense, but it >> works, and is probably a BIOS bug)? If so, then what's that got to do >> with SATA interfaces or LG optical drives? Please help me understand. > > No, atapicd problems are still there regardless of HPET setting. But > with HPET enabled, when I kldload atapicd and then try to mount it with > command "mount -t cd9660 /dev/acd0 /mnt/cd0", I get neverending > "READ_BIG FAILURE" timeouts. What is the atapicd error? I've read through the original mail twice, and I don't see any mention of atapicd errors. Can you provide those? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 04:26:42 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 04:26:48 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <20081119122201.GA86297@icarus.home.lan> References: <4923E839.7090001@demax.sk> <20081119102552.GA83022@icarus.home.lan> <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> Message-ID: <49240600.5000407@demax.sk> Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 01:16:33PM +0100, Jan Sebosik wrote: >>>> But what about those atapicd problems? Is it related to SATA interface >>>> of DVD/CD drive? Maybe also the LG drive has buggy FW :). >>> Now I'm confused. Didn't we just determine that your acd0 problems >>> disappear if you disable HPET in the BIOS (which makes no sense, but it >>> works, and is probably a BIOS bug)? If so, then what's that got to do >>> with SATA interfaces or LG optical drives? Please help me understand. >> No, atapicd problems are still there regardless of HPET setting. But >> with HPET enabled, when I kldload atapicd and then try to mount it with >> command "mount -t cd9660 /dev/acd0 /mnt/cd0", I get neverending >> "READ_BIG FAILURE" timeouts. > > What is the atapicd error? I've read through the original mail twice, > and I don't see any mention of atapicd errors. Can you provide those? > Yes, for sure (I`ve mentioned them in my first mail).. >> acd0: FAILURE - READ_BIG timed out >> unknown: FAILURE - READ_BIG timed out >> cddone: got error 0x5 back also I`ve noticed this message when atapicd got kldload-ed: g_vfs_done(): acd0[READ(offset=32768, length=2048)] error 5 -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 04:41:06 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 04:41:12 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <49240600.5000407@demax.sk> References: <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> Message-ID: <20081119124104.GA86452@icarus.home.lan> On Wed, Nov 19, 2008 at 01:26:40PM +0100, Jan Sebosik wrote: > > > Jeremy Chadwick napsal(a): >> On Wed, Nov 19, 2008 at 01:16:33PM +0100, Jan Sebosik wrote: >>>>> But what about those atapicd problems? Is it related to SATA interface >>>>> of DVD/CD drive? Maybe also the LG drive has buggy FW :). >>>> Now I'm confused. Didn't we just determine that your acd0 problems >>>> disappear if you disable HPET in the BIOS (which makes no sense, but it >>>> works, and is probably a BIOS bug)? If so, then what's that got to do >>>> with SATA interfaces or LG optical drives? Please help me understand. >>> No, atapicd problems are still there regardless of HPET setting. But >>> with HPET enabled, when I kldload atapicd and then try to mount it >>> with command "mount -t cd9660 /dev/acd0 /mnt/cd0", I get neverending >>> "READ_BIG FAILURE" timeouts. >> >> What is the atapicd error? I've read through the original mail twice, >> and I don't see any mention of atapicd errors. Can you provide those? > > Yes, for sure (I`ve mentioned them in my first mail).. > > >> acd0: FAILURE - READ_BIG timed out > >> unknown: FAILURE - READ_BIG timed out > >> cddone: got error 0x5 back Hmm... I'm still confused here. Let me see if I can figure it out. When HPET is enabled and you try to boot a FreeBSD CD, you receive the READ_BIG errors over and over, and it never stops. But if you disable HPET and try to boot a FreeBSD CD, it works. Once the OS is installed (with HPET disabled), if you run "kldload atapicd", you receive the following error: g_vfs_done(): acd0[READ(offset=32768, length=2048)] error 5 And if you try to mount the CD by doing: mount -t cd9660 /dev/acd0 /mnt/cd0 Then you start seeing the READ_BIG errors again, and they never stop. Is this correct? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 04:56:40 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 04:56:47 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <20081119124104.GA86452@icarus.home.lan> References: <4923F0A6.9080304@demax.sk> <20081119112102.GA84963@icarus.home.lan> <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> <20081119124104.GA86452@icarus.home.lan> Message-ID: <49240D05.7010909@demax.sk> Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 01:26:40PM +0100, Jan Sebosik wrote: >> >> Jeremy Chadwick napsal(a): >>> On Wed, Nov 19, 2008 at 01:16:33PM +0100, Jan Sebosik wrote: >>>>>> But what about those atapicd problems? Is it related to SATA interface >>>>>> of DVD/CD drive? Maybe also the LG drive has buggy FW :). >>>>> Now I'm confused. Didn't we just determine that your acd0 problems >>>>> disappear if you disable HPET in the BIOS (which makes no sense, but it >>>>> works, and is probably a BIOS bug)? If so, then what's that got to do >>>>> with SATA interfaces or LG optical drives? Please help me understand. >>>> No, atapicd problems are still there regardless of HPET setting. But >>>> with HPET enabled, when I kldload atapicd and then try to mount it >>>> with command "mount -t cd9660 /dev/acd0 /mnt/cd0", I get neverending >>>> "READ_BIG FAILURE" timeouts. >>> What is the atapicd error? I've read through the original mail twice, >>> and I don't see any mention of atapicd errors. Can you provide those? >> Yes, for sure (I`ve mentioned them in my first mail).. >> >>>> acd0: FAILURE - READ_BIG timed out >>>> unknown: FAILURE - READ_BIG timed out >>>> cddone: got error 0x5 back > > Hmm... I'm still confused here. Let me see if I can figure it out. > > When HPET is enabled and you try to boot a FreeBSD CD, you receive > the READ_BIG errors over and over, and it never stops. > > But if you disable HPET and try to boot a FreeBSD CD, it works. > > Once the OS is installed (with HPET disabled), if you run "kldload > atapicd", you receive the following error: > > g_vfs_done(): acd0[READ(offset=32768, length=2048)] error 5 > > And if you try to mount the CD by doing: > > mount -t cd9660 /dev/acd0 /mnt/cd0 > > Then you start seeing the READ_BIG errors again, and they never > stop. > > Is this correct? > No Jeremy, we don`t understand each other.. sorry for my confusing explanations in my previous postings. I`ve FreeBSD-7 STABLE installed on HDD for a long time, so I don`t need to boot FreeBSD CD /w installer. Last I`ve updated to kernel from 13th November (via csup + make buildkernel/installkernel procedure). Before I`ve not used FreeBSD some time because DRI is not workin` with onboard graphics (Intel GMA4500, but Mr. Noland is doing great job here). But now to the situation/problem: you are almost 100% right, but I`m not booting FreeBSD from CD, but from harddrive (SATA-300 mode). After I kldload atapicd, a see the error you have up there ( g_vfs_done() ), and also I`m unable to mount /dev/acd0 anywhere ending /w READ_BIG neverending errors. Maybe they sometimes ends, but after 10 minutes of waiting I`ve pressed hard-reset button. Maybe I should try -CURRENT sometimes with your proposed ata patches (or are they merged in right now?). Best regards -- Jan Sebosik, Slovakia sebosik@demax.sk From koitsu at FreeBSD.org Wed Nov 19 05:03:47 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 05:03:53 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <49240D05.7010909@demax.sk> References: <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> <20081119124104.GA86452@icarus.home.lan> <49240D05.7010909@demax.sk> Message-ID: <20081119130344.GA87110@icarus.home.lan> On Wed, Nov 19, 2008 at 01:56:37PM +0100, Jan Sebosik wrote: > Jeremy Chadwick napsal(a): >> On Wed, Nov 19, 2008 at 01:26:40PM +0100, Jan Sebosik wrote: >>> >>> Jeremy Chadwick napsal(a): >>>> On Wed, Nov 19, 2008 at 01:16:33PM +0100, Jan Sebosik wrote: >>>>>>> But what about those atapicd problems? Is it related to SATA interface >>>>>>> of DVD/CD drive? Maybe also the LG drive has buggy FW :). >>>>>> Now I'm confused. Didn't we just determine that your acd0 problems >>>>>> disappear if you disable HPET in the BIOS (which makes no sense, but it >>>>>> works, and is probably a BIOS bug)? If so, then what's that got to do >>>>>> with SATA interfaces or LG optical drives? Please help me understand. >>>>> No, atapicd problems are still there regardless of HPET setting. >>>>> But with HPET enabled, when I kldload atapicd and then try to >>>>> mount it with command "mount -t cd9660 /dev/acd0 /mnt/cd0", I >>>>> get neverending "READ_BIG FAILURE" timeouts. >>>> What is the atapicd error? I've read through the original mail twice, >>>> and I don't see any mention of atapicd errors. Can you provide those? >>> Yes, for sure (I`ve mentioned them in my first mail).. >>> >>>>> acd0: FAILURE - READ_BIG timed out >>>>> unknown: FAILURE - READ_BIG timed out >>>>> cddone: got error 0x5 back >> >> Hmm... I'm still confused here. Let me see if I can figure it out. >> >> When HPET is enabled and you try to boot a FreeBSD CD, you receive >> the READ_BIG errors over and over, and it never stops. >> >> But if you disable HPET and try to boot a FreeBSD CD, it works. >> >> Once the OS is installed (with HPET disabled), if you run "kldload >> atapicd", you receive the following error: >> >> g_vfs_done(): acd0[READ(offset=32768, length=2048)] error 5 >> >> And if you try to mount the CD by doing: >> >> mount -t cd9660 /dev/acd0 /mnt/cd0 >> >> Then you start seeing the READ_BIG errors again, and they never >> stop. >> >> Is this correct? >> > > No Jeremy, we don`t understand each other.. sorry for my confusing > explanations in my previous postings. > > I`ve FreeBSD-7 STABLE installed on HDD for a long time, so I don`t need > to boot FreeBSD CD /w installer. Last I`ve updated to kernel from 13th > November (via csup + make buildkernel/installkernel procedure). Before > I`ve not used FreeBSD some time because DRI is not workin` with onboard > graphics (Intel GMA4500, but Mr. Noland is doing great job here). > > But now to the situation/problem: > you are almost 100% right, but I`m not booting FreeBSD from CD, but > from harddrive (SATA-300 mode). After I kldload atapicd, a see the error > you have up there ( g_vfs_done() ), and also I`m unable to mount > /dev/acd0 anywhere ending /w READ_BIG neverending errors. Maybe they > sometimes ends, but after 10 minutes of waiting I`ve pressed hard-reset > button. Okay now I understand. Thank you for taking the time to explain! :-) And when you disable HPET in the BIOS, what happens? > Maybe I should try -CURRENT sometimes with your proposed ata patches (or > are they merged in right now?). Sure, you're free to try CURRENT. The ATA code on CURRENT was modularised, and also a very large patch applied; I can't promise it fixes your CD/DVD drive issues though. I had problems getting CURRENT to see my PCI SATA Promise controller (it wasn't appearing in pciconf -lv, nor dmesg), but I had no problems with CURRENT seeing my ICH7 controller. I also had other problems with CURRENT which caused me to go back to RELENG_7. CURRENT is undergoing lots of changes right now, so I recommend subscribing to -current if you plan on running it. I personally haven't written any ATA patches, except for extending atacontrol to support per-disk write cache enable/disable. I think you might be confusing me with Andrey V. Elsukov, who *has* written lots of ATA stuff. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 06:07:23 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 06:07:29 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <4924106F.4070602@demax.sk> References: <4923F7D5.8030409@demax.sk> <4923F928.8010604@demax.sk> <4923FA30.5000303@modulus.org> <4923FB4D.7090505@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> <20081119124104.GA86452@icarus.home.lan> <49240D05.7010909@demax.sk> <20081119130344.GA87110@icarus.home.lan> <4924106F.4070602@demax.sk> Message-ID: <49241D97.7070800@demax.sk> [snip] > Okay now I understand. Thank you for taking the time to explain! :-) > > And when you disable HPET in the BIOS, what happens? > >> Maybe I should try -CURRENT sometimes with your proposed ata patches >> (or are they merged in right now?). > > Sure, you're free to try CURRENT. The ATA code on CURRENT was > modularised, and also a very large patch applied; I can't promise it > fixes your CD/DVD drive issues though. > > I had problems getting CURRENT to see my PCI SATA Promise controller (it > wasn't appearing in pciconf -lv, nor dmesg), but I had no problems with > CURRENT seeing my ICH7 controller. I also had other problems with > CURRENT which caused me to go back to RELENG_7. CURRENT is undergoing > lots of changes right now, so I recommend subscribing to -current if you > plan on running it. > > I personally haven't written any ATA patches, except for extending > atacontrol to support per-disk write cache enable/disable. I think > you might be confusing me with Andrey V. Elsukov, who *has* written > lots of ATA stuff. Now happens almost nothing (I don`t understand), except the cd/acd problems (READ_BIG errors), but I don`t understand why it is happening.. maybe guys from Intel optimized this board too much for twista OS :). Wishing all the best -- Jan Sebosik, Slovakia sebosik@demax.sk From whizzter at gmail.com Wed Nov 19 06:24:42 2008 From: whizzter at gmail.com (Jonas Lund) Date: Wed Nov 19 06:24:48 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <49241D97.7070800@demax.sk> References: <4923F7D5.8030409@demax.sk> <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> <20081119124104.GA86452@icarus.home.lan> <49240D05.7010909@demax.sk> <20081119130344.GA87110@icarus.home.lan> <4924106F.4070602@demax.sk> <49241D97.7070800@demax.sk> Message-ID: <436c7eda0811190624o4fb3d14cw137ebd3a7718be29@mail.gmail.com> (NOTICE: i'm more of a lowlevel guy close to hardware guy not knowing much of freebsd internals) The fact that FreeBSD is NOT using HPET for timing might be the answer to the "mystery". The HPET hardware might be/get enabled but not handled and firing tons of unexpected interrupts (as you said.. linux produces tons of data into the log, what's the actual content of those logs?). These interrupts in turn might disturb the cd drive in some fashion? Can you bring up some interrupt statistics in freebsd? like a counter of the number of events? Just my 2 cents, Jonas 2008/11/19 Jan Sebosik : > [snip] >> >> Okay now I understand. Thank you for taking the time to explain! :-) >> >> And when you disable HPET in the BIOS, what happens? >> >>> Maybe I should try -CURRENT sometimes with your proposed ata patches (or >>> are they merged in right now?). >> >> Sure, you're free to try CURRENT. The ATA code on CURRENT was >> modularised, and also a very large patch applied; I can't promise it >> fixes your CD/DVD drive issues though. >> >> I had problems getting CURRENT to see my PCI SATA Promise controller (it >> wasn't appearing in pciconf -lv, nor dmesg), but I had no problems with >> CURRENT seeing my ICH7 controller. I also had other problems with >> CURRENT which caused me to go back to RELENG_7. CURRENT is undergoing >> lots of changes right now, so I recommend subscribing to -current if you >> plan on running it. >> >> I personally haven't written any ATA patches, except for extending >> atacontrol to support per-disk write cache enable/disable. I think >> you might be confusing me with Andrey V. Elsukov, who *has* written >> lots of ATA stuff. > > > Now happens almost nothing (I don`t understand), except the cd/acd > problems (READ_BIG errors), but I don`t understand why it is happening.. > maybe guys from Intel optimized this board too much for twista OS :). > > Wishing all the best > -- > Jan Sebosik, Slovakia > sebosik@demax.sk > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > From koitsu at FreeBSD.org Wed Nov 19 06:28:32 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Wed Nov 19 06:28:38 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <436c7eda0811190624o4fb3d14cw137ebd3a7718be29@mail.gmail.com> References: <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> <20081119124104.GA86452@icarus.home.lan> <49240D05.7010909@demax.sk> <20081119130344.GA87110@icarus.home.lan> <4924106F.4070602@demax.sk> <49241D97.7070800@demax.sk> <436c7eda0811190624o4fb3d14cw137ebd3a7718be29@mail.gmail.com> Message-ID: <20081119142829.GA88936@icarus.home.lan> On Wed, Nov 19, 2008 at 03:24:40PM +0100, Jonas Lund wrote: > (NOTICE: i'm more of a lowlevel guy close to hardware guy not knowing > much of freebsd internals) > > The fact that FreeBSD is NOT using HPET for timing might be the answer > to the "mystery". The HPET hardware might be/get enabled but not > handled and firing tons of unexpected interrupts (as you said.. linux > produces tons of data into the log, what's the actual content of those > logs?). > > These interrupts in turn might disturb the cd drive in some fashion? > > Can you bring up some interrupt statistics in freebsd? like a counter > of the number of events? First and foremost, thanks for chiming in, Jonas. The more eyes on this matter the merrier. vmstat -i can provide interrupt rate and count in FreeBSD, e.g.: interrupt total rate irq1: atkbd0 227 0 irq6: fdc0 10 0 irq17: uhci1++ 4479741 10 cpu0: timer 814684046 2000 irq256: em0 17219212 42 cpu1: timer 814683722 2000 Total 1651066958 4053 > 2008/11/19 Jan Sebosik : > > [snip] > >> > >> Okay now I understand. Thank you for taking the time to explain! :-) > >> > >> And when you disable HPET in the BIOS, what happens? > >> > >>> Maybe I should try -CURRENT sometimes with your proposed ata patches (or > >>> are they merged in right now?). > >> > >> Sure, you're free to try CURRENT. The ATA code on CURRENT was > >> modularised, and also a very large patch applied; I can't promise it > >> fixes your CD/DVD drive issues though. > >> > >> I had problems getting CURRENT to see my PCI SATA Promise controller (it > >> wasn't appearing in pciconf -lv, nor dmesg), but I had no problems with > >> CURRENT seeing my ICH7 controller. I also had other problems with > >> CURRENT which caused me to go back to RELENG_7. CURRENT is undergoing > >> lots of changes right now, so I recommend subscribing to -current if you > >> plan on running it. > >> > >> I personally haven't written any ATA patches, except for extending > >> atacontrol to support per-disk write cache enable/disable. I think > >> you might be confusing me with Andrey V. Elsukov, who *has* written > >> lots of ATA stuff. > > > > > > Now happens almost nothing (I don`t understand), except the cd/acd > > problems (READ_BIG errors), but I don`t understand why it is happening.. > > maybe guys from Intel optimized this board too much for twista OS :). > > > > Wishing all the best > > -- > > Jan Sebosik, Slovakia > > sebosik@demax.sk > > _______________________________________________ > > freebsd-hardware@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From sebosik at demax.sk Wed Nov 19 09:01:11 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 09:01:18 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <20081119142829.GA88936@icarus.home.lan> References: <20081119115311.GA85626@icarus.home.lan> <492403A1.60209@demax.sk> <20081119122201.GA86297@icarus.home.lan> <49240600.5000407@demax.sk> <20081119124104.GA86452@icarus.home.lan> <49240D05.7010909@demax.sk> <20081119130344.GA87110@icarus.home.lan> <4924106F.4070602@demax.sk> <49241D97.7070800@demax.sk> <436c7eda0811190624o4fb3d14cw137ebd3a7718be29@mail.gmail.com> <20081119142829.GA88936@icarus.home.lan> Message-ID: <49244655.3010509@demax.sk> Hi so I`ve played with it again, and results are strange. Regardless if HPET is enabled or not.. FreeBSD with atapicd kldloaded won`t mount /dev/acd1 (mounting /dev/cd0 works). When I tryied to mount acd0 it still hangs at READ_BIG TIMEOUT. When I left CD in drive, and rebooted (I wanted to switch HPET), it freezes on cd0 initialization with READ_BIG timeout (I think it`s causing GEOM_LABEL module trying to read CD label). So I think that disabling GEOM_LABEL would help a little. I`ll try on friday with another SATA DVD drive if it`s not a bug inside firmware of LG :) . Best regards, Jan Jeremy Chadwick napsal(a): > On Wed, Nov 19, 2008 at 03:24:40PM +0100, Jonas Lund wrote: >> (NOTICE: i'm more of a lowlevel guy close to hardware guy not knowing >> much of freebsd internals) >> >> The fact that FreeBSD is NOT using HPET for timing might be the answer >> to the "mystery". The HPET hardware might be/get enabled but not >> handled and firing tons of unexpected interrupts (as you said.. linux >> produces tons of data into the log, what's the actual content of those >> logs?). >> >> These interrupts in turn might disturb the cd drive in some fashion? >> >> Can you bring up some interrupt statistics in freebsd? like a counter >> of the number of events? > > First and foremost, thanks for chiming in, Jonas. The more eyes on this > matter the merrier. > > vmstat -i can provide interrupt rate and count in FreeBSD, e.g.: > > interrupt total rate > irq1: atkbd0 227 0 > irq6: fdc0 10 0 > irq17: uhci1++ 4479741 10 > cpu0: timer 814684046 2000 > irq256: em0 17219212 42 > cpu1: timer 814683722 2000 > Total 1651066958 4053 > >> 2008/11/19 Jan Sebosik : >>> [snip] >>>> Okay now I understand. Thank you for taking the time to explain! :-) >>>> >>>> And when you disable HPET in the BIOS, what happens? >>>> >>>>> Maybe I should try -CURRENT sometimes with your proposed ata patches (or >>>>> are they merged in right now?). >>>> Sure, you're free to try CURRENT. The ATA code on CURRENT was >>>> modularised, and also a very large patch applied; I can't promise it >>>> fixes your CD/DVD drive issues though. >>>> >>>> I had problems getting CURRENT to see my PCI SATA Promise controller (it >>>> wasn't appearing in pciconf -lv, nor dmesg), but I had no problems with >>>> CURRENT seeing my ICH7 controller. I also had other problems with >>>> CURRENT which caused me to go back to RELENG_7. CURRENT is undergoing >>>> lots of changes right now, so I recommend subscribing to -current if you >>>> plan on running it. >>>> >>>> I personally haven't written any ATA patches, except for extending >>>> atacontrol to support per-disk write cache enable/disable. I think >>>> you might be confusing me with Andrey V. Elsukov, who *has* written >>>> lots of ATA stuff. >>> >>> Now happens almost nothing (I don`t understand), except the cd/acd >>> problems (READ_BIG errors), but I don`t understand why it is happening.. >>> maybe guys from Intel optimized this board too much for twista OS :). >>> >>> Wishing all the best >>> -- >>> Jan Sebosik, Slovakia >>> sebosik@demax.sk >>> _______________________________________________ >>> freebsd-hardware@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware >>> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-hardware@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hardware >> To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > -- Jan Sebosik, Slovakia sebosik@demax.sk From comp.john at googlemail.com Wed Nov 19 11:24:15 2008 From: comp.john at googlemail.com (John .) Date: Wed Nov 19 11:24:23 2008 Subject: FreeBSD-7.0-RELEASE with AMD Phenom Message-ID: Hi list FreeBSD 7 or 8.0-CURRENT - has anyone been able to get it working on an AMD Phenom machine? I've googled around but not seen any solid success stories yet. I'm looking at these motherboards: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1867 and 8GB RAM and http://www.asrock.com/mb/overview.asp?Model=ALIVENF6G-DVI also considering Asus of similar spec Prime concerns are seeing the full amount of RAM, and whether it can see the SATA controller. thanks -- John From sebosik at demax.sk Wed Nov 19 12:16:51 2008 From: sebosik at demax.sk (Jan Sebosik) Date: Wed Nov 19 12:16:57 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <200811191307.02765.jkim@FreeBSD.org> References: <20081119115311.GA85626@icarus.home.lan> <20081119142829.GA88936@icarus.home.lan> <49244655.3010509@demax.sk> <200811191307.02765.jkim@FreeBSD.org> Message-ID: <49247431.2000800@demax.sk> Jung-uk Kim napsal(a): > On Wednesday 19 November 2008 12:01 pm, Jan Sebosik wrote: >> Hi >> >> so I`ve played with it again, and results are strange. >> >> Regardless if HPET is enabled or not.. FreeBSD with atapicd >> kldloaded won`t mount /dev/acd1 (mounting /dev/cd0 works). When I >> tryied to mount acd0 it still hangs at READ_BIG TIMEOUT. >> >> When I left CD in drive, and rebooted (I wanted to switch HPET), >> it freezes on cd0 initialization with READ_BIG timeout (I think >> it`s causing GEOM_LABEL module trying to read CD label). >> >> So I think that disabling GEOM_LABEL would help a little. >> >> I`ll try on friday with another SATA DVD drive if it`s not a bug >> inside firmware of LG :) . >> >> >> Best regards, Jan >> >> Jeremy Chadwick napsal(a): >>> On Wed, Nov 19, 2008 at 03:24:40PM +0100, Jonas Lund wrote: >>>> (NOTICE: i'm more of a lowlevel guy close to hardware guy not >>>> knowing much of freebsd internals) >>>> >>>> The fact that FreeBSD is NOT using HPET for timing might be the >>>> answer to the "mystery". The HPET hardware might be/get enabled >>>> but not handled and firing tons of unexpected interrupts (as you >>>> said.. linux produces tons of data into the log, what's the >>>> actual content of those logs?). >>>> >>>> These interrupts in turn might disturb the cd drive in some >>>> fashion? >>>> >>>> Can you bring up some interrupt statistics in freebsd? like a >>>> counter of the number of events? >>> First and foremost, thanks for chiming in, Jonas. The more eyes >>> on this matter the merrier. >>> >>> vmstat -i can provide interrupt rate and count in FreeBSD, e.g.: >>> >>> interrupt total rate >>> irq1: atkbd0 227 0 >>> irq6: fdc0 10 0 >>> irq17: uhci1++ 4479741 10 >>> cpu0: timer 814684046 2000 >>> irq256: em0 17219212 42 >>> cpu1: timer 814683722 2000 >>> Total 1651066958 4053 >>> >>>> 2008/11/19 Jan Sebosik : >>>>> [snip] >>>>> >>>>>> Okay now I understand. Thank you for taking the time to >>>>>> explain! :-) >>>>>> >>>>>> And when you disable HPET in the BIOS, what happens? >>>>>> >>>>>>> Maybe I should try -CURRENT sometimes with your proposed ata >>>>>>> patches (or are they merged in right now?). >>>>>> Sure, you're free to try CURRENT. The ATA code on CURRENT was >>>>>> modularised, and also a very large patch applied; I can't >>>>>> promise it fixes your CD/DVD drive issues though. >>>>>> >>>>>> I had problems getting CURRENT to see my PCI SATA Promise >>>>>> controller (it wasn't appearing in pciconf -lv, nor dmesg), >>>>>> but I had no problems with CURRENT seeing my ICH7 controller. >>>>>> I also had other problems with CURRENT which caused me to go >>>>>> back to RELENG_7. CURRENT is undergoing lots of changes right >>>>>> now, so I recommend subscribing to -current if you plan on >>>>>> running it. >>>>>> >>>>>> I personally haven't written any ATA patches, except for >>>>>> extending atacontrol to support per-disk write cache >>>>>> enable/disable. I think you might be confusing me with Andrey >>>>>> V. Elsukov, who *has* written lots of ATA stuff. >>>>> Now happens almost nothing (I don`t understand), except the >>>>> cd/acd problems (READ_BIG errors), but I don`t understand why >>>>> it is happening.. maybe guys from Intel optimized this board >>>>> too much for twista OS :). > > Can you try the attached patch with HPET enabled from BIOS? Sorry, it > will not solve the cd/acd problems but I have a hunch that it may > solve the HPET problem. > > Thanks, > > JK Hi I`ve tried your patch right now, but didn`t notice any change in machine`s behavior. Thanks for your interest and time. Best regards -- Jan Sebosik, Slovakia sebosik@demax.sk From jkim at FreeBSD.org Wed Nov 19 12:40:47 2008 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Wed Nov 19 12:40:54 2008 Subject: Frebsd 7-STABLE, atapicd, atapicam and Intel errors [SOLVED] In-Reply-To: <49247431.2000800@demax.sk> References: <20081119115311.GA85626@icarus.home.lan> <200811191307.02765.jkim@FreeBSD.org> <49247431.2000800@demax.sk> Message-ID: <200811191540.33629.jkim@FreeBSD.org> On Wednesday 19 November 2008 03:16 pm, Jan Sebosik wrote: > Jung-uk Kim napsal(a): > > On Wednesday 19 November 2008 12:01 pm, Jan Sebosik wrote: > >> Hi > >> > >> so I`ve played with it again, and results are strange. > >> > >> Regardless if HPET is enabled or not.. FreeBSD with atapicd > >> kldloaded won`t mount /dev/acd1 (mounting /dev/cd0 works). When > >> I tryied to mount acd0 it still hangs at READ_BIG TIMEOUT. > >> > >> When I left CD in drive, and rebooted (I wanted to switch > >> HPET), it freezes on cd0 initialization with READ_BIG timeout (I > >> think it`s causing GEOM_LABEL module trying to read CD label). > >> > >> So I think that disabling GEOM_LABEL would help a little. > >> > >> I`ll try on friday with another SATA DVD drive if it`s not a bug > >> inside firmware of LG :) . > >> > >> > >> Best regards, Jan > >> > >> Jeremy Chadwick napsal(a): > >>> On Wed, Nov 19, 2008 at 03:24:40PM +0100, Jonas Lund wrote: > >>>> (NOTICE: i'm more of a lowlevel guy close to hardware guy not > >>>> knowing much of freebsd internals) > >>>> > >>>> The fact that FreeBSD is NOT using HPET for timing might be > >>>> the answer to the "mystery". The HPET hardware might be/get > >>>> enabled but not handled and firing tons of unexpected > >>>> interrupts (as you said.. linux produces tons of data into the > >>>> log, what's the actual content of those logs?). > >>>> > >>>> These interrupts in turn might disturb the cd drive in some > >>>> fashion? > >>>> > >>>> Can you bring up some interrupt statistics in freebsd? like a > >>>> counter of the number of events? > >>> > >>> First and foremost, thanks for chiming in, Jonas. The more > >>> eyes on this matter the merrier. > >>> > >>> vmstat -i can provide interrupt rate and count in FreeBSD, > >>> e.g.: > >>> > >>> interrupt total rate > >>> irq1: atkbd0 227 0 > >>> irq6: fdc0 10 0 > >>> irq17: uhci1++ 4479741 10 > >>> cpu0: timer 814684046 2000 > >>> irq256: em0 17219212 42 > >>> cpu1: timer 814683722 2000 > >>> Total 1651066958 4053 > >>> > >>>> 2008/11/19 Jan Sebosik : > >>>>> [snip] > >>>>> > >>>>>> Okay now I understand. Thank you for taking the time to > >>>>>> explain! :-) > >>>>>> > >>>>>> And when you disable HPET in the BIOS, what happens? > >>>>>> > >>>>>>> Maybe I should try -CURRENT sometimes with your proposed > >>>>>>> ata patches (or are they merged in right now?). > >>>>>> > >>>>>> Sure, you're free to try CURRENT. The ATA code on CURRENT > >>>>>> was modularised, and also a very large patch applied; I > >>>>>> can't promise it fixes your CD/DVD drive issues though. > >>>>>> > >>>>>> I had problems getting CURRENT to see my PCI SATA Promise > >>>>>> controller (it wasn't appearing in pciconf -lv, nor dmesg), > >>>>>> but I had no problems with CURRENT seeing my ICH7 > >>>>>> controller. I also had other problems with CURRENT which > >>>>>> caused me to go back to RELENG_7. CURRENT is undergoing > >>>>>> lots of changes right now, so I recommend subscribing to > >>>>>> -current if you plan on running it. > >>>>>> > >>>>>> I personally haven't written any ATA patches, except for > >>>>>> extending atacontrol to support per-disk write cache > >>>>>> enable/disable. I think you might be confusing me with > >>>>>> Andrey V. Elsukov, who *has* written lots of ATA stuff. > >>>>> > >>>>> Now happens almost nothing (I don`t understand), except the > >>>>> cd/acd problems (READ_BIG errors), but I don`t understand why > >>>>> it is happening.. maybe guys from Intel optimized this board > >>>>> too much for twista OS :). > > > > Can you try the attached patch with HPET enabled from BIOS? > > Sorry, it will not solve the cd/acd problems but I have a hunch > > that it may solve the HPET problem. > > > > Thanks, > > > > JK > > Hi > > I`ve tried your patch right now, but didn`t notice any change in > machine`s behavior. Okay. I just went ahead and committed it because that's the right thing to do any way. :-) Thanks for the feedback. Jung-uk Kim From fbsd at dannysplace.net Wed Nov 19 14:36:52 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Wed Nov 19 14:36:59 2008 Subject: FreeBSD-7.0-RELEASE with AMD Phenom In-Reply-To: References: Message-ID: <492494DD.2000604@dannysplace.net> John . wrote: > Hi list > > FreeBSD 7 or 8.0-CURRENT - has anyone been able to get it working on > an AMD Phenom machine? I've googled around but not seen any solid > success stories yet. > > I'm looking at these motherboards: > > http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1867 > and 8GB RAM > > and http://www.asrock.com/mb/overview.asp?Model=ALIVENF6G-DVI > > also considering Asus of similar spec > > Prime concerns are seeing the full amount of RAM, and whether it can > see the SATA controller. I can't advise on anything else but I am sure you will need FreeBSD 8 to see anything above 2G. -D From fbsd at dannysplace.net Wed Nov 19 14:58:18 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Wed Nov 19 14:58:24 2008 Subject: FreeBSD-7.0-RELEASE with AMD Phenom In-Reply-To: <49249762.90503@fragfest.com.au> References: <492494DD.2000604@dannysplace.net> <49249762.90503@fragfest.com.au> Message-ID: <492499DF.5070302@dannysplace.net> Dean Hamstead wrote: > freebsd can do more than 2gigs ram ages ago? > > are you trying amd64 or i386 port? > AMD64. Actaully I re-read the information about the 2gb limit and it had to do with the kmap pool of available memory. I guess that means the rest of the memory is available to userland processes. -D From dean at fragfest.com.au Wed Nov 19 15:18:06 2008 From: dean at fragfest.com.au (Dean Hamstead) Date: Wed Nov 19 15:18:13 2008 Subject: FreeBSD-7.0-RELEASE with AMD Phenom In-Reply-To: <492494DD.2000604@dannysplace.net> References: <492494DD.2000604@dannysplace.net> Message-ID: <49249762.90503@fragfest.com.au> freebsd can do more than 2gigs ram ages ago? are you trying amd64 or i386 port? Dean Danny Carroll wrote: > John . wrote: >> Hi list >> >> FreeBSD 7 or 8.0-CURRENT - has anyone been able to get it working on >> an AMD Phenom machine? I've googled around but not seen any solid >> success stories yet. >> >> I'm looking at these motherboards: >> >> http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1867 >> and 8GB RAM >> >> and http://www.asrock.com/mb/overview.asp?Model=ALIVENF6G-DVI >> >> also considering Asus of similar spec >> >> Prime concerns are seeing the full amount of RAM, and whether it can >> see the SATA controller. > > I can't advise on anything else but I am sure you will need FreeBSD 8 to > see anything above 2G. > > -D > _______________________________________________ > freebsd-hardware@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscribe@freebsd.org" > -- http://fragfest.com.au From bernt at bah.homeip.net Wed Nov 19 21:22:48 2008 From: bernt at bah.homeip.net (Bernt Hansson) Date: Wed Nov 19 21:22:55 2008 Subject: FreeBSD-7.0-RELEASE with AMD Phenom In-Reply-To: References: Message-ID: <4924EC47.2090202@bah.homeip.net> John . said the following on 2008-11-19 19:54: > Hi list > > FreeBSD 7 or 8.0-CURRENT - has anyone been able to get it working on > an AMD Phenom machine? I've googled around but not seen any solid > success stories yet. > > I'm looking at these motherboards: > > http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1867 > and 8GB RAM That card does not support 8Gb, only 4Gb. I got this motherboard and it works fine with AMD64 and 8GB memory. http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2694 From comp.john at googlemail.com Thu Nov 20 03:12:16 2008 From: comp.john at googlemail.com (John .) Date: Thu Nov 20 03:12:23 2008 Subject: FreeBSD-7.0-RELEASE with AMD Phenom In-Reply-To: <4924EC47.2090202@bah.homeip.net> References: <4924EC47.2090202@bah.homeip.net> Message-ID: 2008/11/20 Bernt Hansson : > John . said the following on 2008-11-19 19:54: >> >> Hi list >> >> FreeBSD 7 or 8.0-CURRENT - has anyone been able to get it working on >> an AMD Phenom machine? I've googled around but not seen any solid >> success stories yet. >> >> I'm looking at these motherboards: >> >> >> http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ProductID=1867 >> and 8GB RAM > > That card does not support 8Gb, only 4Gb. > > I got this motherboard and it works fine with AMD64 and 8GB memory. > http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2694 > > > Whoops, sorry wrong link. This is the correct one: http://www.gigabyte.com.tw/Products/Motherboard/Products_Spec.aspx?ClassValue=Motherboard&ProductID=2554&ProductName=GA-MA69G-S3H edit: already bought it, we'll see what happens. Should be here tomorrow ;) -- John From kono at kth.se Thu Nov 20 06:10:03 2008 From: kono at kth.se (Alexander Konovalenko) Date: Thu Nov 20 06:10:10 2008 Subject: 7.1 does not boot on GA-MA770-GS3 (rev. 2.0), but works fine on rev. 1.0? Message-ID: <200811201450.37621@3667> Hi, I have upgraded my hardware from Sempron 3400+ to Phenom X3 8480 on Gigabyte GA-MA770-GS3 (rev. 2.0). FreeBSD 7.1 (amd64) freezes during the boot. Suspecting not appropriate hw configuration for old motherboard I tried to boot from installation CD 7.1 but got the same result... Tried i386 CD but still no luck. However, FreeBSD 6.1 disc booted up successfully. Freezing occurs right after recognition of additional cores and, if verbose output is enabled, initialization of many IOAPIC devices (irqs?). I tried to disable in BIOS as many as possible onboard devices (lan, audio, serial¶llel ports, firewire...), disconnected cd and floppy drives but it did not help. Funny thing is that I have another computer with Phenom X4 on GA-MA770-GS3 (rev. 1.0) and FreeBSD 7.1 amd64 works like a clock there! Note, this is older version of the same board with lower hw revision. That was the main reason why I bought the same MB with a hope that everything will work... Has anybody experienced such problem? HW config: 2Gb RAM: Kingston DDR2 HyperX PC8500 1024MB CL5 running at 800 MHz HDD: Hitachi 250Gb SATA Well, might be that board is faulty, the BIOS update have not been released yet for GA-MA770-GS3 (rev. 2.0). But Windows works ok, though reports few unknown devices... I just checked differences between rev. 1.0 and 2.0: 1) system bus might be a bit faster for 2.0 (not sure) 2) two additional SATA channels 3) two additional USB 2.0 ports This is what I can see there: http://www.gigabyte.com.tw/Products/Motherboard/Products_ComparisonSheet.aspx?ProductID=2874,2722 Any suggestion? regards, Alexander Konovalenko From kono at kth.se Tue Nov 25 16:33:54 2008 From: kono at kth.se (Alexander Konovalenko) Date: Tue Nov 25 16:34:01 2008 Subject: 7.1 does not boot on GA-MA770-GS3 (rev. 2.0), but works fine on rev. 1.0? In-Reply-To: <201BC021-2DAC-453B-B7F7-CC679CC1E764@anduin.net> References: <200811201450.37621@3667> <201BC021-2DAC-453B-B7F7-CC679CC1E764@anduin.net> Message-ID: <200811260132.52689@3667> > On Nov 20, 2008, at 2:50 PM, Alexander Konovalenko wrote: > > Hi, > > > > I have upgraded my hardware from Sempron 3400+ to Phenom X3 8480 on > > Gigabyte > > GA-MA770-GS3 (rev. 2.0). > > > > FreeBSD 7.1 (amd64) freezes during the boot. Suspecting not > > appropriate hw > > configuration for old motherboard I tried to boot from installation > > CD 7.1 > > but got the same result... Tried i386 CD but still no luck. However, > > FreeBSD > > 6.1 disc booted up successfully. > > > > Freezing occurs right after recognition of additional cores and, if > > verbose > > output is enabled, initialization of many IOAPIC devices (irqs?). I > > tried to > > disable in BIOS as many as possible onboard devices (lan, audio, > > serial¶llel ports, firewire...), disconnected cd and floppy > > drives but it > > did not help. > > > > Funny thing is that I have another computer with Phenom X4 on GA- > > MA770-GS3 > > (rev. 1.0) and FreeBSD 7.1 amd64 works like a clock there! Note, > > this is > > older version of the same board with lower hw revision. That was the > > main > > reason why I bought the same MB with a hope that everything will > > work... > > > > Has anybody experienced such problem? > > > > HW config: > > 2Gb RAM: Kingston DDR2 HyperX PC8500 1024MB CL5 running at 800 MHz > > HDD: Hitachi 250Gb SATA > > > > Well, might be that board is faulty, the BIOS update have not been > > released > > yet for GA-MA770-GS3 (rev. 2.0). But Windows works ok, though > > reports few > > unknown devices... > > > > > > I just checked differences between rev. 1.0 and 2.0: > > > > 1) system bus might be a bit faster for 2.0 (not sure) > > 2) two additional SATA channels > > 3) two additional USB 2.0 ports > > > > This is what I can see there: > > http://www.gigabyte.com.tw/Products/Motherboard/Products_ComparisonSheet. > >aspx?ProductID=2874,2722 > > > > Any suggestion? > > > > regards, > > Alexander Konovalenko On Tuesday 25 November 2008, Eirik ?verby wrote: > Hi, > > try booting a linux kernel (from cd) then warm-booting to freebsd cd/ > disk. > > /Eirik thanks Eirik for suggestion, unfortunately I cannot test warm-booting because I have sent this MB back to dealer already. However, some additional info: when FreeBSD 7.1 (either i386 or amd64) hangs on boot and if I wait long enough I get following messages: ... ioapic0: Assigning ISA IRQ 1 to local APIC 0 ioapic0: Assigning ISA IRQ 4 to local APIC 1 ioapic0: Assigning ISA IRQ 9 to local APIC 2 ioapic0: Assigning ISA IRQ 14 to local APIC 0 spin lock 0xffffffff80ac25c0 (sched lock 0) held by 0xffffff0002100370 (tid 100004) too long panic: spin lock held too long cpuid=2 uptime 13 s Cannot dump. No dump device defined Not much helpful to me, but hopefully will help somebody to skip purchasing this mobo... at least until first BIOS update will be released... /Alexander Konovalenko +46-8-5537-8143 (office) +46-7-3752-2116 http://daemon.nanophys.kth.se/~kono Royal Institute of Technology (KTH) Nanostructure Physics Department, Albanova Roslagstullsbacken 21 10691 Stockholm Sweden From sales at gadgets.lmtd.co.uk Wed Nov 26 01:02:05 2008 From: sales at gadgets.lmtd.co.uk (Gadgets LMTD UK) Date: Wed Nov 26 01:02:12 2008 Subject: Get your Blackberry Storm/$350 Message-ID: <200811260839.mAQ8dKKo019862@relay.dotsterhost.com> Get your Blackberry Bold/$300 or Apple iPhone 16GB Apple iPhone 16GB.......$250 per unit Blackberry Bold.............$300 per unit Blackberry Storm.............$350 per unit Video Games Playstation 3 ........$220 Nintendo Wii......... $200 Sony PSP......... ....$140 Xbox 360 Platinum/Premium.... $140 Apple ipod Nano 4gb....$100 Apple ipod Nano 80gb...$250 GSM PHONES Motorola V3i D&G......$250 Nokia N95......... ...$320 Nokia N93......... ...$260 Nokia N93i ...........$280 Nokia N70 ............$160 Nokia N72 ............$175 Nokia N73 ............$250 Nokia N80 ............$200 Nokia N90 ............$200 Nokia N91 ............$200 BUY ANY 5 UNITS AND GET 2 FREE All GSM Phones,Brand New,Tri- Band and Video Games are also Brand new with Complete Accessories plus Int\\\\\\\\\\\\\\\'l Warranty . e-mail us for more enquiry gadgets.lmtd05@gmail.com GADGETS LIMITED (UK) LTD Registered No. 05881519 THE OLD STABLES, ARUNDEL ROAD, POLING, ARUNDEL, WEST SUSSEX, BN18 9QA UNITED KINGDOM From fhard at ccstores.com Wed Nov 26 08:41:56 2008 From: fhard at ccstores.com (Jim Pazarena) Date: Wed Nov 26 08:42:10 2008 Subject: ciss0 driver/routines Message-ID: <492D7814.2010302@ccstores.com> noticed a glaring spelling mistake on a CLI notification, and wasn't sure who (or how) to report it. message as follows: ciss0: *** Parity/consistency initialization complete, logical drive 0 then, ciss0: logical drive 0 c7 completed consistency initialisation ^^^^^^^^^^^^^^^^ s/b initialization is there a better forum to report this? Jim From won.derick at yahoo.com Wed Nov 26 21:48:20 2008 From: won.derick at yahoo.com (Won De Erick) Date: Wed Nov 26 21:48:26 2008 Subject: Is Chelsio NIC model S302-C (1Gbe) supported on FreeBSD? References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <20081126094314.119834gt66jv0g00@webmail.leidinger.net> Message-ID: <688136.62951.qm@web45811.mail.sp1.yahoo.com> Hello, I am reading the man page for cxgb, the integrated Chelsio NIC driver in FreeBSD 7.1. The manual says that it is intented for T3 10G Chelsio NICs. I would like to know if model S302-C (1Gbe) is supported by this. If not, is there any alternative driver? Thanks, Won. From michael at fuckner.net Thu Nov 27 00:03:35 2008 From: michael at fuckner.net (Michael Fuckner) Date: Thu Nov 27 00:03:42 2008 Subject: Is Chelsio NIC model S302-C (1Gbe) supported on FreeBSD? In-Reply-To: <688136.62951.qm@web45811.mail.sp1.yahoo.com> References: <20081125173657.GA50429@freebsd.org> <9bbcef730811251246nf39e825s95a25ae394948e06@mail.gmail.com> <20081126094314.119834gt66jv0g00@webmail.leidinger.net> <688136.62951.qm@web45811.mail.sp1.yahoo.com> Message-ID: <492E5078.6080205@fuckner.net> Won De Erick wrote: Hi, > I am reading the man page for cxgb, the integrated Chelsio NIC driver > in FreeBSD 7.1. The manual says that it is intented for T3 10G Chelsio > NICs. > I would like to know if model S302-C (1Gbe) is supported by this. If > not, is there any alternative driver? I don't know if there's a big difference between S302E and S302E-C, but there seems to be support for Gigabit-Cards with the cxgb-driver grep 302 /usr/src/sys/dev/cxgb/cxgb_main.c {PCI_VENDOR_ID_CHELSIO, 0x0021, 1, "T302E"}, {PCI_VENDOR_ID_CHELSIO, 0x0024, 1, "T302X"}, Regards, Michael! From avg at icyb.net.ua Fri Nov 28 05:39:01 2008 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Nov 28 05:39:08 2008 Subject: dd if=/dev/mem can hang a machine? Message-ID: <492FF203.5060405@icyb.net.ua> I have a new machine with DG33TL mainboard (ICH9/G33). In a course of some hacking I ran dd if=/dev/mem ... to scan all memory, this caused the machine to hang. I tried to reproduce and this is 100% reproducible. I am not used to such behavior. In older days I could scan all the memory without any issues. Could this be related to some modern form of memory-mapped IO? Or to Intel Management Engine (that seems t bite into DRAM)? Or something else? Just wondering. -- Andriy Gapon From fbsd at dannysplace.net Sun Nov 30 05:04:24 2008 From: fbsd at dannysplace.net (Danny Carroll) Date: Sun Nov 30 05:04:31 2008 Subject: ciss0 driver/routines In-Reply-To: <492D7814.2010302@ccstores.com> References: <492D7814.2010302@ccstores.com> Message-ID: <49328F33.8080705@dannysplace.net> Jim Pazarena wrote: > noticed a glaring spelling mistake on a CLI notification, and wasn't > sure who (or how) to report it. > > message as follows: > > ciss0: *** Parity/consistency initialization complete, logical drive 0 > > then, > > ciss0: logical drive 0 c7 completed consistency initialisation > ^^^^^^^^^^^^^^^^ s/b > initialization > Perhaps this driver was written by both an American and a European or Australian.... >From my perspective the first message is the one spelt wrong. -D From gary.jennejohn at freenet.de Sun Nov 30 07:24:43 2008 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sun Nov 30 07:24:55 2008 Subject: dd if=/dev/mem can hang a machine? In-Reply-To: <492FF203.5060405@icyb.net.ua> References: <492FF203.5060405@icyb.net.ua> Message-ID: <20081130162437.1bae4371@ernst.jennejohn.org> On Fri, 28 Nov 2008 15:28:35 +0200 Andriy Gapon wrote: > > I have a new machine with DG33TL mainboard (ICH9/G33). > In a course of some hacking I ran dd if=/dev/mem ... to scan all memory, > this caused the machine to hang. > I tried to reproduce and this is 100% reproducible. > > I am not used to such behavior. In older days I could scan all the > memory without any issues. > > Could this be related to some modern form of memory-mapped IO? Or to > Intel Management Engine (that seems t bite into DRAM)? > Or something else? > > Just wondering. > That's what I would assume. With some hardware just reading a register can be harmful. --- Gary Jennejohn