Re: 8.0 regression: consecutive panics (iwi / wlan)
martinko wrote: Well, the panic points at iwi (see my screenshot pls). And there are other wifi regressions I've already noticed. On 6.x I had 2 issues with iwi: Interface was changing down and up especially when signal was weaker. And there was the dreaded scan stuck. Sometimes the only help was to reboot the machine. On 8.0 I haven't noticed scan stuck and downup happens a lot less. But I guess this is due to newer iwi firmware (3.1 vs 3.0). On the other hand wireless interface is too slow to associate during boot and I'm seeing connection errors from e.g. ntpd. Also the following began appearing in the system log: kernel: iwi0: need multicast update callback And there have been other issues posted to the lists in last weeks. I'd love these to be fixed and I'm willing to help investigate. Regards, Martin PS: I had the same panic today. After reboot I kept losing connection after short time. Restarting AP didn't help. I switched laptop offon and it's running happily since (uptime 10h). Really weird. Sad as it is reported crashes are still happening and I'm getting more worried each day especially since today when the system booted to single due to unexpected soft-updates inconsistencies. (!) :-(( Panics/reboots started right after upgrade to 8.0 and they do not happen when I use wired instead of iwi/wlan connection (both in lagg). M. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
Hi, I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with Corrupted MAC on input message. And Putty SSH tunnel closed with Incorrect MAC received on packet. I need to disable txcsum and rxcsum on the vge network card for solving this problem. Does anyone meet the same regression between 7.2 and 8.0 ? Thanks, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
On Fri, Jan 15, 2010 at 10:32:42AM +0100, Olivier Cochard-Labbé wrote: I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with Corrupted MAC on input message. And Putty SSH tunnel closed with Incorrect MAC received on packet. I need to disable txcsum and rxcsum on the vge network card for solving this problem. Does anyone meet the same regression between 7.2 and 8.0 ? PYUN Yong-Hyeon will respond to this I'm sure, but have you tried the vge(4) code from RELENG_8 (known as 8.0-STABLE)? I've seen some commits to this driver since 8.0-RELEASE: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/ -- | Jeremy Chadwick j...@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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
On Fri, Jan 15, 2010 at 01:40:18AM -0800, Jeremy Chadwick wrote: On Fri, Jan 15, 2010 at 10:32:42AM +0100, Olivier Cochard-Labbé wrote: I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with Corrupted MAC on input message. And Putty SSH tunnel closed with Incorrect MAC received on packet. I need to disable txcsum and rxcsum on the vge network card for solving this problem. Does anyone meet the same regression between 7.2 and 8.0 ? PYUN Yong-Hyeon will respond to this I'm sure, but have you tried the vge(4) code from RELENG_8 (known as 8.0-STABLE)? I've seen some commits to this driver since 8.0-RELEASE: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/ I also want to point out that cvsweb is currently lying with regards to when the files in a tree were last modified -- how/why that's broken is beyond the scope of this thread, but it should probably get fixed. The above URL references all tags/branches. Example: if_vge.c1.723 weeks yongari Yet the latest commit is from 6 days ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/if_vge.c Revision 1.31.2.12: download - view: text, markup, annotated - select for diffs Sat Jan 9 00:29:04 2010 UTC (6 days, 9 hours ago) by yongari Branches: RELENG_7 -- | Jeremy Chadwick j...@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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
On 2010-01-15T01:45:15-0800, Jeremy Chadwick free...@jdc.parodius.com wrote: On Fri, Jan 15, 2010 at 01:40:18AM -0800, Jeremy Chadwick wrote: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/vge/ I also want to point out that cvsweb is currently lying with regards to when the files in a tree were last modified -- how/why that's broken is beyond the scope of this thread, but it should probably get fixed. The above URL references all tags/branches. Might as well use the original Subversion view: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/vge/ -- Kenyon Ralph signature.asc Description: Digital signature
Re: [PATCH] Lockmgr deadlock on STABLE_8
Well, the machine has been running the WITNESS + INVARIANTS kernel for 20 hours now without locking up.This looks like what I saw before - compiling in WITNESS stops it locking up -( Is there any use in my runing a kernel with just INVARIANTS to see if that will lcok ? I know it locks with KDN and DDb on their own, but am not usre how useful that is. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [PATCH] Lockmgr deadlock on STABLE_8
2010/1/15 Pete French petefre...@ticketswitch.com: Well, the machine has been running the WITNESS + INVARIANTS kernel for 20 hours now without locking up.This looks like what I saw before - compiling in WITNESS stops it locking up -( Is there any use in my runing a kernel with just INVARIANTS to see if that will lcok ? I know it locks with KDN and DDb on their own, but am not usre how useful that is. One may never know, try without WITNESS but still the same setup. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: An old gripe: Reading via mmap stinks
Andrew Snow wrote: Hi Mikhail, I assume these tests were done on UFS. Have you tried ZFS? I'm curious to see the results. I suspect it would be noticably worse :) AFAIK ZFS integration with mmap does at least one extra in-memory data copy. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
About nice(1), renice(8) and ULE scheduler
HI all, I've realized that the nice(1) code hasn't been modified for a long time (last code change seems from 4 years ago according the sources). ¿Is the nice(1) behaviour the expected? I mean, ¿Has been the ULE scheduler adapted to nice(1) command or not? nice(1) is a very old command based on old concepts and created in times when SMP didn't exist. So ¿it works correctly when a modern an re-designed scheduler as ULE is used? Maybe I have to read again this paper: http://www.usenix.org/event/bsdcon03/tech/full_papers/roberson/roberson.pdf -- I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain. Bene Gesserit Litany Against Fear. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: USB problems on 8.0-STABLE
On Thursday 14 January 2010 6:40:42 pm Frank wrote: On Thu, 14 Jan 2010, Frank wrote: On Thu, 14 Jan 2010, John Baldwin wrote: What does apctest say when you run it? -- John Baldwin apctest 2010-01-14 18:15:04 apctest 3.14.5 (10 January 2009) freebsd Checking configuration ... Attached to driver: usb sharenet.type = DEFAULT I cannot handle sharenet.type = DEFAULT 2010-01-14 18:15:04 apctest exiting, signal 1 My apologies, I had disabled several things in apcupsd.conf during testing. apctest 2010-01-14 18:37:58 apctest 3.14.5 (10 January 2009) freebsd Checking configuration ... Attached to driver: usb sharenet.type = DISABLE cable.type = USB_CABLE You are using a USB cable type, so I'm entering USB test mode mode.type = USB_UPS Setting up the port ... apctest FATAL ERROR in generic-usb.c at line 636 Cannot find UPS device -- For a link to detailed USB trouble shooting information, please see http://www.apcupsd.com/support.html. apctest error termination completed Try running 'apctest -d 200' -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Fw: 8-STABLE: gmirror segfaulting
I picked the wrong list *sigh* Begin forwarded message: Date: Fri, 15 Jan 2010 16:33:50 +0100 From: Oliver Lehmann lehm...@ans-netz.de To: po...@freebsd.org Cc: m...@freebsd.org, p...@freebsd.org Subject: 8-STABLE: gmirror segfaulting Hi, sorry for the long story following but I think this is important to get the picture ;) I had the following setup: 2 harddisks ada0, ada1 mirrored with gmirror as gm0 1 2.7TB twa-RAID as da0 the da0p1 partition had a gjournal on gm0s1fh the gm0s1f partition had a gjournal on gm0s1fg I tried to label (tunefs -L) da0p1.journal as files and gm0s1f.journal as usr but the label was everytime gone after a reboot for whatever reasons. Later I also felt mad about the massive bad write performance on my RAID-5. Finally I decided to remove the journaling today to get my performance back ;) This is where the problems have started. I was not able to remove the journaling wile the mirror was still intact because it always tried to resolve my previous given usr label which existed on the disks ada0+ada1 below gm0 but never where mapped to the front (gm0s1f.journal) again somehow. That always failed. So I did gmirror remove ada0+ada1 until gm0 was gone and I had back ada0 and ada1 as single disks. I then rebooted into single user again and did gjournal stop for all three journals (breaking gmirror created 2 journals on both RAID-1 hdds of course for ada0s1f and ada1s1f) and then did a gjournal clear. That clear failed on da0p1 (maybe because the gm0s1h journal also devided into ada0s1h and ada1s1h - who knows) so I again rebootet but then having my system waiting forever root mount waiting for: GJOURNAL. I felt a bit pissed off I must admit because at first I thought that I've dumped my system :( Fortunally I had gjournal loaded as kernel module only so I rebooted once more and just loaded the kernel w/o every module. I then was able to make gjournal clear da0p1 while the gjournal module was not loaded. Now the journals on all harddisks where gone. I also did a tunefs -J disable. I now wanted to recreate my gmirror with sysctl kern.geom.debugflags=17 gmirror label -vb round-robin gm0 ada0 This creates a massive printout of debug messages on my console and finally ended up with gmirror: Segmentation fault. Then I'm left with a system responding to every command with Device not configure So all I had left was power-cycling the system. This is repeatable I really want my gmirror back. Any advice? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
--On Friday, January 15, 2010 10:32 AM +0100 Olivier Cochard-Labbé oliv...@cochard.me wrote: Hi, I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with Corrupted MAC on input message. And Putty SSH tunnel closed with Incorrect MAC received on packet. I need to disable txcsum and rxcsum on the vge network card for solving this problem. nfe(4) has complete deadlocks with checksums enabled under high transmit (and possibly receive) loads. It appears to be a regression from 7.2 as well. We think it might have something to do with error recovery, but aren't sure if it's related to *just* nfe(4) or to HW CSums in general. Does anyone meet the same regression between 7.2 and 8.0 ? Thanks, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
On Fri, Jan 15, 2010 at 10:32:42AM +0100, Olivier Cochard-Labb? wrote: Hi, I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with Corrupted MAC on input message. And Putty SSH tunnel closed with Incorrect MAC received on packet. This message comes from scp when it detects it received corrupted frames. This means sender transmitted corrupted frames or the host receiving the frame broke it. I need to disable txcsum and rxcsum on the vge network card for solving this problem. I think there is no vge(4) source changes between 7.2-RELEASE and 8.0-RELEASE so I guess other kernel changes in 8.0-RELEASE might reveal driver bug. Would you try latest vge(4) in stable/8? There were a lot code changes including important bug fixes. Does anyone meet the same regression between 7.2 and 8.0 ? Thanks, Olivier ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Regression with txcsum/rxcsum on vge(4) drivers on 8.0-Release
On Fri, Jan 15, 2010 at 10:05:09AM -0700, Michael Loftis wrote: --On Friday, January 15, 2010 10:32 AM +0100 Olivier Cochard-Labb?? oliv...@cochard.me wrote: Hi, I've just upgraded on of my server from 7.2 to 8.0-Release and meet a problem with the vge(4) drivers: All my SCP transferts didn't works since this upgrade: they close, after a random time, with Corrupted MAC on input message. And Putty SSH tunnel closed with Incorrect MAC received on packet. I need to disable txcsum and rxcsum on the vge network card for solving this problem. nfe(4) has complete deadlocks with checksums enabled under high transmit (and possibly receive) loads. It appears to be a regression from 7.2 as well. We think it might have something to do with error recovery, but aren't sure if it's related to *just* nfe(4) or to HW CSums in general. Please open new thread for this issue. I'm not aware of this and this is the first time I heard for the checksum offloading issue of nfe(4). Include dmesg output for your controller and let me know whether it's really regression from 7.2-RELEASE. If you have reliable way to reproduce the issue, please also let me know. There is no nfe(4) source code differences between 7.2-RELEASE and 8.0-RELEASE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
I just read a different thread about problems with checksums on vge (and nfe in the replies). I'll just chime in here with some more information - I have a couple other message threads going about some weird high packet volumes on my new FreeBSD 8.0-Release NFS server. I thought it might be an issue with the igb driver so I put in a new card using em instead and got the exact same behavior. I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. This is for communications between this client machine (FreeBSD 7.0-Release) and any of the 8.0 machines I have. The packets going to non-8.0 machines (at least so far) appear to be fine. I'll defer to those who know more than I about the networking code, but is there perhaps an issue in general with the checksuming and not specific to one card or driver - is that even possible? That's now 4 different drivers all with various checksum problem reports. I'm going to be working on this all day today (and likely over the weekend) so if I can help by supplying information please let me know what you need. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
Hi-- On Jan 15, 2010, at 11:12 AM, alan bryan wrote: [ ... ] I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. If you run tcpdump on a machine, it normally will receive the traffic being sent from that machine before the checksums are computed, especially if HW checksumming is being used. For reliable detection of these problems, you need to look at the traffic either on a hub or via the monitoring or span port of a smart switch, although simply glancing at the checksum stats from netstat -s on both sides should indicate whether significant error rates are happening. Regards, -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
On Fri, Jan 15, 2010 at 11:12:43AM -0800, alan bryan wrote: I just read a different thread about problems with checksums on vge (and nfe in the replies). I'll just chime in here with some more information - I have a couple other message threads going about some weird high packet volumes on my new FreeBSD 8.0-Release NFS server. I thought it might be an issue with the igb driver so I put in a new card using em instead and got the exact same behavior. I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. This is for communications between this client machine (FreeBSD 7.0-Release) and any of the 8.0 machines I have. The packets going to non-8.0 machines (at least so far) appear to be fine. I'll defer to those who know more than I about the networking code, but is there perhaps an issue in general with the checksuming and not specific to one card or driver - is that even possible? That's now 4 different drivers all with various checksum problem reports. I'm going to be working on this all day today (and likely over the weekend) so if I can help by supplying information please let me know what you need. If you are seeing bad checksum reported by tcpdump/wireshark for TX frames on checksum capable controller, it's normal. bpf(4) just sees TX frames before inserting checksum computed by hardware so tcpdump/wireshark reports invalid checksum. You can safely ignore that. If you want to verify whether sending host generated correct checksum, you should capture the frame on receive side. If tcpdump/ wireshark reports bad checksummed frame on received frames it's real bad checksummed frame. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
--- On Fri, 1/15/10, Chuck Swiger cswi...@mac.com wrote: From: Chuck Swiger cswi...@mac.com Subject: Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0? To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Friday, January 15, 2010, 11:21 AM Hi-- On Jan 15, 2010, at 11:12 AM, alan bryan wrote: [ ... ] I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. If you run tcpdump on a machine, it normally will receive the traffic being sent from that machine before the checksums are computed, especially if HW checksumming is being used. For reliable detection of these problems, you need to look at the traffic either on a hub or via the monitoring or span port of a smart switch, although simply glancing at the checksum stats from netstat -s on both sides should indicate whether significant error rates are happening. Regards, -- -Chuck Ah - thanks for the explanation as I'm new to tcpdump/wireshark. Need to learn more about those tools still. Watching systat -ip 1 gives results like: /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average | IP Input IP Output 4534 total packets received4395 total packets sent 0 - with bad checksums 4395 - generated locally 0 - too short for header 0 - output drops 0 - too short for data42 output fragments generated 0 - with invalid hlen 0 - fragmentation failed 0 - with invalid length0 destinations unreachable 0 - with invalid version 0 packets output via raw IP 0 - jumbograms 84 total fragments received UDP Statistics 0 - fragments dropped 3989 total input packets 0 - fragments timed out0 - too short for header 14 - packets reassembled ok 0 - invalid checksum 0 packets forwarded0 - no checksum 0 - unreachable dests 0 - invalid length 0 - redirects generated0 - no socket for dest port 0 option errors0 - no socket for broadcast 0 unwanted multicasts 0 - socket buffer full 4464 delivered to upper layer 3989 total output packets The total IP packets for this box should normally be in the hundreds per second - it stays constant at this 4K level. And the matching netstat -s: tcp: 47312791 packets sent 28828783 data packets (26317159806 bytes) 206 data packets (633246 bytes) retransmitted 11 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 12364262 ack-only packets (944193 delayed) 0 URG only packets 2518 window probe packets 3212717 window update packets 2903587 control packets 59176152 packets received 34785356 acks (for 26320662084 bytes) 1849829 duplicate acks 0 acks for unsent data 39787782 packets (24426616075 bytes) received in-sequence 601 completely duplicate packets (14975 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 101 out-of-order packets (114828 bytes) 2 packets (0 bytes) of data after window 0 window probes 4411949 window update packets 76 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 905931 connection requests 1098039 connection accepts 0 bad connection attempts 0 listen queue overflows 523 ignored RSTs in the windows 2003969 connections established (including accepts) 2002786 connections closed (including 4056 drops) 1187984 connections updated cached RTT on close 1191288 connections updated cached RTT variance on close 294899 connections updated cached ssthresh on close 0 embryonic connections dropped 34785321 segments updated rtt (of 29019225 attempts) 42636 retransmit timeouts 3512 connections dropped by rexmit timeout 2554 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 23 keepalive timeouts 23 keepalive probes sent 0 connections dropped by keepalive 79387 correct ACK header predictions 16380715 correct data
AHCI and ZFS: root mount error
Hello, After setting ahci_load=YES in /boot/loader.conf, I get a root mount error. ahci seems to attach to disk correctly (I get ada0 messages with no error) Without ahci_load=YES, system boots fine, with ata module attaching to disk. I have a full zfs system, set up following wiki instructions: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition (MBR scheme, ZFS in a FreeBSD slice, together with a swap partition) I'm using a GENERIC kernel, RELENG_8 branch. My /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:zroot nvidia_load=YES snd_hda_load=YES tmpfs_load=YES coretemp_load=YES Regards, Romain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8-STABLE: gmirror segfaulting
Alexander Motin wrote: Interesting story, but I've lost the track. I can't say for sure what crashed gmirror without seeing any messages, but I suppose that after so dirty deconstruction of mirror and journals Hm.. dirty? I used the standard tools ;) you may left some meta-information on devices. Restoring gmirror could make it accessible again. I would try to explicitly clear last few sectors of every disk/partition where something was living with dd to be sure that nothing left there. Right now I've cleaned the whole ada1 disk, recreated the filesystems and dump+restoreing the filesystems from ada0 to ada1. Then I'll switch ada1 andada0 and continue cleaning up the remaining disk. Then I'll gmirror them again. I could try to reproduce the error with my testsystem (have around 10 2GB SCSI disks waiting for such a task) and log every command I typed. But - is someone interested in fixing this? I already opened a PR for glabel not working on top of gjournaled devices but it is open w/o any comment for 2 month. Before I try to find a way of reproducing it I would know that someone would work with the PR I'll create then. I don't like feeding black holes ;) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
recommended miniPCI 802.11a/b/g card for Soekris net5501 running FreeBSD 8-STABLE?
I've been trying to get reliable wireless AP functionality in my Soekris net5501 (http://soekris.com/net5501.htm) box for some time now. In the past I've reported a problem with it (http://www.mail-archive.com/freebsd-stable@freebsd.org/msg105623.html) that causes it to report ath0: stuck beacon; resetting (bmiss count 4). I can minimise this by increasing the count but I still get the problem and the wifi connection is patchy - dropped connections, and low transfer speeds. So, I think the easiest solution is to get a better card. Can somebody please recommend any such miniPCI board. My existing board is a Wistron Neweb CM9 miniPCI wireless card, 802.11abg which is based on the Atheros AR5004 chipset. Some cards that are easy for me to get are the Wistron Neweb DCMA-81, 5006 Super AG Atheros 6G which uses Atheros AR5414, and Senao NMP-8602 PLUS-S / EMP-8602 PLUS-S which uses AR 5006. I can probably source any others that anybody can suggest, too. I'm not after super speed or range, just reliable performance in a net5501 running FreeBSD 8-STABLE and acting as a wireless access point using WPA2. Thanks for any assistance, Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AHCI and ZFS: root mount error
Hi, On Fri, Jan 15, 2010 at 09:13:39PM +0100, Romain Garbage wrote: After setting ahci_load=YES in /boot/loader.conf, I get a root mount error. ahci seems to attach to disk correctly (I get ada0 messages with no error) Without ahci_load=YES, system boots fine, with ata module attaching to disk. I have a full zfs system, set up following wiki instructions: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition (MBR scheme, ZFS in a FreeBSD slice, together with a swap partition) I'm using a GENERIC kernel, RELENG_8 branch. My /boot/loader.conf: zfs_load=YES vfs.root.mountfrom=zfs:zroot nvidia_load=YES snd_hda_load=YES tmpfs_load=YES coretemp_load=YES Check with zpool status if your zpool refers to diskslices like ad0s1. I use gpt have setup the ZFS mirror to refer to gptids: pool: silver state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM silver ONLINE 0 0 0 mirrorONLINE 0 0 0 gptid/9e68d234-f306-11de-a0c4-0002b3b6e838 ONLINE 0 0 0 gptid/a025b88c-f306-11de-a0c4-0002b3b6e838 ONLINE 0 0 0 With that kind of configuration I can switch back and forth between using ATA_CAM or using traditional ATA drivers. Since you're not using GPT I gues you can use geom labels to do more or less the same thing. In short: use labels, nut device names. Saves headaches in many cases. - Olli -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AHCI and ZFS: root mount error
On Sat, 16 Jan 2010 00:29:23 +0100 Oliver Brandmueller o...@e-gitt.net wrote: Check with zpool status if your zpool refers to diskslices like ad0s1. I use gpt have setup the ZFS mirror to refer to gptids: pool: silver state: ONLINE scrub: none requested config: NAMESTATE READ WRITE CKSUM silver ONLINE 0 0 0 mirrorONLINE 0 0 0 gptid/9e68d234-f306-11de-a0c4-0002b3b6e838 ONLINE 0 0 0 gptid/a025b88c-f306-11de-a0c4-0002b3b6e838 ONLINE 0 0 0 With that kind of configuration I can switch back and forth between using ATA_CAM or using traditional ATA drivers. Since you're not using GPT I gues you can use geom labels to do more or less the same thing. In short: use labels, nut device names. Saves headaches in many cases. ZFS actually can find disks without any glabel help. I have one server which I have moved recently to ahci and nothing changes for me. ZFS silently accepted new provider names and continue working as usual. -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0?
--- On Fri, 1/15/10, Pyun YongHyeon pyu...@gmail.com wrote: From: Pyun YongHyeon pyu...@gmail.com Subject: Re: General problems with checksums (txcsum/rxcsum) on FreeBSD 8.0? To: alan bryan alan.br...@yahoo.com Cc: freebsd-stable@freebsd.org Date: Friday, January 15, 2010, 11:32 AM On Fri, Jan 15, 2010 at 11:12:43AM -0800, alan bryan wrote: I just read a different thread about problems with checksums on vge (and nfe in the replies). I'll just chime in here with some more information - I have a couple other message threads going about some weird high packet volumes on my new FreeBSD 8.0-Release NFS server. I thought it might be an issue with the igb driver so I put in a new card using em instead and got the exact same behavior. I'm currently sifting through a tcpdump in wireshark and there are all sorts of messages in there about checksums being incorrect - both TCP and UDP. This is for communications between this client machine (FreeBSD 7.0-Release) and any of the 8.0 machines I have. The packets going to non-8.0 machines (at least so far) appear to be fine. I'll defer to those who know more than I about the networking code, but is there perhaps an issue in general with the checksuming and not specific to one card or driver - is that even possible? That's now 4 different drivers all with various checksum problem reports. I'm going to be working on this all day today (and likely over the weekend) so if I can help by supplying information please let me know what you need. If you are seeing bad checksum reported by tcpdump/wireshark for TX frames on checksum capable controller, it's normal. bpf(4) just sees TX frames before inserting checksum computed by hardware so tcpdump/wireshark reports invalid checksum. You can safely ignore that. If you want to verify whether sending host generated correct checksum, you should capture the frame on receive side. If tcpdump/ wireshark reports bad checksummed frame on received frames it's real bad checksummed frame. Thanks for the help. After looking deeper into this issue today I'm now sure that I'm stuck in some NFS write/fail/retry loop. I'm still not sure if the trigger to get to that state is NFS, ZFS, or networking code. To try to get more information to act on, I'm going to change my client mount options and see what happens. Thanks everyone. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AHCI and ZFS: root mount error
On Fri, 15 Jan 2010 21:13:39 +0100 Romain Garbage romain.garb...@gmail.com wrote: After setting ahci_load=YES in /boot/loader.conf, I get a root mount error. ahci seems to attach to disk correctly (I get ada0 messages with no error) Without ahci_load=YES, system boots fine, with ata module attaching to disk. I have a full zfs system, set up following wiki instructions: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition (MBR scheme, ZFS in a FreeBSD slice, together with a swap partition) I'm using a GENERIC kernel, RELENG_8 branch. I have faced some problems that looks exactly like you say. I haven't investigated thoroughly after some quick-hack-repairs machine runs flawlessly. 1. I have moved to RELENG_8 from RELENG_8_0. I don't think this is it but zfsloader support was what I was looking for. 2. I reinitialised zfs partitions again with a boot code. But this time I used bs=512 dd option. 3. I recreated zpool.cache and replaced it on my pool. Actually I don't know which one helped me, but my bet is for the third step and maybe for second. -- Sphinx of black quartz judge my vow. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AHCI and ZFS: root mount error
2010/1/16, Volodymyr Kostyrko c.kw...@gmail.com: On Fri, 15 Jan 2010 21:13:39 +0100 Romain Garbage romain.garb...@gmail.com wrote: After setting ahci_load=YES in /boot/loader.conf, I get a root mount error. ahci seems to attach to disk correctly (I get ada0 messages with no error) Without ahci_load=YES, system boots fine, with ata module attaching to disk. I have a full zfs system, set up following wiki instructions: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition (MBR scheme, ZFS in a FreeBSD slice, together with a swap partition) I'm using a GENERIC kernel, RELENG_8 branch. I have faced some problems that looks exactly like you say. I haven't investigated thoroughly after some quick-hack-repairs machine runs flawlessly. 1. I have moved to RELENG_8 from RELENG_8_0. I don't think this is it but zfsloader support was what I was looking for. 2. I reinitialised zfs partitions again with a boot code. But this time I used bs=512 dd option. 3. I recreated zpool.cache and replaced it on my pool. Actually I don't know which one helped me, but my bet is for the third step and maybe for second. A weird thing: I just built and installed a new kernel (RELENG_8, source csuped a few hours ago), just adding device ahci to the config file. I get the same error, with driver attaching correctly. Now, adding ahci_load=NO to /boot/loader.conf and booting the new custom kernel, it just boots fine, ahci attaching to the device, and zfs root gets mounted. dmesg | grep ada ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST9250320AS 0303 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 ada1: SAMSUNG HM500JI 2AC101C4 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST9250320AS 0303 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 ada1: SAMSUNG HM500JI 2AC101C4 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) I didn't do anything else, just the line in loader.conf, and the system just works fine. Romain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AHCI and ZFS: root mount error
On Sat, Jan 16, 2010 at 01:48:12AM +0100, Romain Garbage wrote: 2010/1/16, Volodymyr Kostyrko c.kw...@gmail.com: On Fri, 15 Jan 2010 21:13:39 +0100 Romain Garbage romain.garb...@gmail.com wrote: After setting ahci_load=YES in /boot/loader.conf, I get a root mount error. ahci seems to attach to disk correctly (I get ada0 messages with no error) Without ahci_load=YES, system boots fine, with ata module attaching to disk. I have a full zfs system, set up following wiki instructions: http://wiki.freebsd.org/RootOnZFS/ZFSBootPartition (MBR scheme, ZFS in a FreeBSD slice, together with a swap partition) I'm using a GENERIC kernel, RELENG_8 branch. I have faced some problems that looks exactly like you say. I haven't investigated thoroughly after some quick-hack-repairs machine runs flawlessly. 1. I have moved to RELENG_8 from RELENG_8_0. I don't think this is it but zfsloader support was what I was looking for. 2. I reinitialised zfs partitions again with a boot code. But this time I used bs=512 dd option. 3. I recreated zpool.cache and replaced it on my pool. Actually I don't know which one helped me, but my bet is for the third step and maybe for second. A weird thing: I just built and installed a new kernel (RELENG_8, source csuped a few hours ago), just adding device ahci to the config file. I get the same error, with driver attaching correctly. Now, adding ahci_load=NO to /boot/loader.conf and booting the new custom kernel, it just boots fine, ahci attaching to the device, and zfs root gets mounted. dmesg | grep ada ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST9250320AS 0303 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 ada1: SAMSUNG HM500JI 2AC101C4 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ST9250320AS 0303 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes)cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich2 bus 0 scbus2 target 0 lun 0 ada1: SAMSUNG HM500JI 2AC101C4 ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) I didn't do anything else, just the line in loader.conf, and the system just works fine. Can you post your entire kernel configuration file? Thanks. -- | Jeremy Chadwick j...@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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Recent ahci.c commit breaks buildkernel (RELENG_8)
This most recent commit: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/ahci/ahci.c?r1=201588r2=202428 http://www.freebsd.org/cgi/getmsg.cgi?fetch=1059860+0+current/cvs-src-old http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ahci/ahci.c#rev1.1.2.18 Has broken buildkernel. I've verified this on two separate machines: === ahci (all) cc -O2 -pipe -march=nocona -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/SG45H7_RELENG_8_amd64/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/SG45H7_RELENG_8_amd64 -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c cc1: warnings being treated as errors /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_setup_interrupt': /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:574: warning: implicit declaration of function 'bus_describe_intr' /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:574: warning: nested extern declaration of 'bus_describe_intr' *** Error code 1 Stop in /usr/src/sys/modules/ahci. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 bus_describe_intr() doesn't appear to exist in RELENG_8. # grep -r bus_describe_intr /usr/src /usr/src/sys/dev/ahci/ahci.c: bus_describe_intr(dev, ctlr-irqs[i].r_irq, # -- | Jeremy Chadwick j...@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-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: AHCI and ZFS: root mount error
2010/1/16, Jeremy Chadwick free...@jdc.parodius.com: Can you post your entire kernel configuration file? Thanks. Here it its: I just copied the GENERIC conf file, commented out device ataraid and device atadisk, added option ATA_CAM (I forgot to mention all that stuff it in last post), and added device ahci. # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/amd64/conf/GENERIC,v 1.531.2.7 2010/01/12 06:00:56 brooks Exp $ cpu HAMMER ident ATACAMKERNEL # To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env GENERIC.env makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat (sgtty) options COMPAT_IA32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES # POSIX-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #optionsKDTRACE_FRAME # Ensure frames are compiled in #optionsKDTRACE_HOOKS # Kernel DTrace hooks options ATA_CAM # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # Floppy drives device fdc # ATA and ATAPI devices device ata #device atadisk # ATA disk drives
Re: recommended miniPCI 802.11a/b/g card for Soekris net5501 running FreeBSD 8-STABLE?
On Fri, Jan 15, 2010 at 4:50 PM, Graham Menhennitt gra...@menhennitt.com.au wrote: I've been trying to get reliable wireless AP functionality in my Soekris net5501 (http://soekris.com/net5501.htm) box for some time now. In the past I've reported a problem with it (http://www.mail-archive.com/freebsd-stable@freebsd.org/msg105623.html) that causes it to report ath0: stuck beacon; resetting (bmiss count 4). I can minimise this by increasing the count but I still get the problem and the wifi connection is patchy - dropped connections, and low transfer speeds. So, I think the easiest solution is to get a better card. Can somebody please recommend any such miniPCI board. My existing board is a Wistron Neweb CM9 miniPCI wireless card, 802.11abg which is based on the Atheros AR5004 chipset. Some cards that are easy for me to get are the Wistron Neweb DCMA-81, 5006 Super AG Atheros 6G which uses Atheros AR5414, and Senao NMP-8602 PLUS-S / EMP-8602 PLUS-S which uses AR 5006. I can probably source any others that anybody can suggest, too. I'm not after super speed or range, just reliable performance in a net5501 running FreeBSD 8-STABLE and acting as a wireless access point using WPA2. Thanks for any assistance, Graham ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I have two CM9 and two NL-5354MP miniPCI wireless cards on different Soekris net4521s that do are working fine. Except for the multiple hostapd client broadcast traffic problem I posted on http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053757.html they have shown no problems like you describe on 8.0 or 7.2. Perhaps with the slower CPU the problem does not show up for me, but I would be suprised its your card thats the problem. -Russ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Recent ahci.c commit breaks buildkernel (RELENG_8)
Jeremy Chadwick wrote: This most recent commit: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/ahci/ahci.c?r1=201588r2=202428 http://www.freebsd.org/cgi/getmsg.cgi?fetch=1059860+0+current/cvs-src-old http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/ahci/ahci.c#rev1.1.2.18 Has broken buildkernel. I've verified this on two separate machines: bus_describe_intr() doesn't appear to exist in RELENG_8. # grep -r bus_describe_intr /usr/src /usr/src/sys/dev/ahci/ahci.c: bus_describe_intr(dev, ctlr-irqs[i].r_irq, Thanks. Fixed. Sorry. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
