Re: Kernel won't build without 'device bpf'
Buildkernel dies without device bpf in the config file. I think this is due to Sam's commit on 11-14 changing sys/net/bpf.c and bpf.h. Anyone else seeing this? Yup, I'll fix it. Thanks. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Lots of swapping from 'kldload acpi'
* De: David W. Chapman Jr. [EMAIL PROTECTED] [ Data: 2002-11-22 ] [ Subjecte: Re: Lots of swapping from 'kldload acpi' ] On Fri, Nov 22, 2002 at 11:56:29AM -0800, Kris Kennaway wrote: I tried to kldload acpi on a system that has been running for about 3 days, and the kldload process has been sitting there swapping for about an hour now. Breaking into DDB shows that acpi_alloc_wakeup_handler() is trying to contigmalloc(), and this is swapping around presumably trying to find enough space. The kldload process is unkillable from userland because it's working in the kernel. Can something be done to guard against this? From what I was told you can't kldload acpi after boot or that you shouldn't. It might make sense to (once we go to user-space) prevent kldloading anything that calls contigmalloc(). The ubsec module calls contigmalloc (via the bus_dma routines) and quickly aborts when it can't get the memory. Something else must be going on in acpi. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf header bloat ?
(1) When packet headers are copied using m_copy_pkthdr(), different
consumers have different expectations for what the resulting semantics
are for m_tag data -- some want it duplicated, others want it moved.
In practice, it is only ever moved, so consumers that expect
duplication are in for a surprise. We need to re-implement the packet
header copying code so that it can generate a failure (because it
involves allocation), and separate the duplicate and move abstractions
to get clean semantics. I exchanged some e-mail with Sam Leffler on
the topic, and apparently OpenBSD has already made these changes, or
similar ones, and we should do the same for 5.1.
As I explained to you; the handling of mtags mimics what was there for the
aux mbufs. I did this intentionally to avoid changes that might introduce
subtle problems. My intent was to cleanup this stuff after 5.0 releases by
replacing the pkthdr copy macros with separate DUP+MOVE macros ala openbsd.
I did this in my original implemention but discarded it when I did
the -current integration.
(2) m_tag's don't have a notion that the data carried in a tag is
multi-dimmensional and may require special destructor behavior. While
it does centralize copying and free'ing of data, it handles this
purely with bcopy, malloc, and free, which is not appropriate for use
with MAC labels, since they may contain a variety of per-policy data
that may require special handling (reference count management, etc).
I tried putting tag-specific release/free/... code in the m_tag
central routines, and it looks like that would work, although it
eventually would lead to a lot of junk in the m_tag code. We might
want to consider m_tag entry free/copy pointers of some sort, but I'm
not sure if we want to go there. Adding the MAC stuff to the
m_tag_{free,copy,...} calls won't break the ABI, whereas adding free
and copy pointers to the tags themselves would.
I don't believe it's necessary to overload the basic mtag structure but
instead introduce a specific cookie that enables a more general mechanism
that would be suitable for your needs.
(3) Not all code generating packets properly initializes m_tag field. The
one example I've come across so far is the use of m_getcl() to grab
mbufs with an attached cluster -- it never initializes the SLIST
properly, as far as I can tell. Right now that's used in device
drivers, and also in the BPF packet generation code. If the header is
zero'd, this may be OK due to an implicit proper initialization, but
this is concerning. We need to do more work to normalize packet
handling.
I don't see this problem; m_getcl appears to do the right thing.
(4) Code still exists that improperly hand-copies mbuf packet header data.
if_loop.c contains some particular bogus code that also triggers a
panic in the MAC code for the same reason. If m_tag data ever passes
through if_loop and hits the re-alignment case introduced by KAME, the
system will panic when the tag data is free'd. This code all needs to
be normalized, and proper semantics must be enforced.
I don't see this problem; looutput looks to do the right thing. FWIW I've
passed mbufs w/ mtags through the loopback interface.
...other stuff omitted...
Please contact me directly about the problems so we can resolve them
immediately.
Sam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mbuf header bloat ?
I don't see this problem; looutput looks to do the right thing. FWIW
I've
passed mbufs w/ mtags through the loopback interface.
This refers specifically to the following code snippet:
if (m m-m_next != NULL m-m_pkthdr.len MCLBYTES) {
struct mbuf *n;
MGETHDR(n, M_DONTWAIT, MT_HEADER);
if (!n)
goto contiguousfail;
MCLGET(n, M_DONTWAIT);
if (! (n-m_flags M_EXT)) {
m_freem(n);
goto contiguousfail;
}
m_copydata(m, 0, m-m_pkthdr.len, mtod(n, caddr_t));
n-m_pkthdr = m-m_pkthdr;
n-m_len = m-m_pkthdr.len;
n-m_pkthdr.aux = m-m_pkthdr.aux;
m-m_pkthdr.aux = (struct mbuf *)NULL;
m_freem(m);
m = n;
}
Something is wrong with your tree:
ebb% grep aux ../sys/mbuf.h
ebb%
The above code is correct in the repo as is the m_getcl code.
Sam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: mbuf header bloat ?
On Mon, Nov 25, 2002 at 10:46:00AM -0800, Sam Leffler wrote:
I don't see this problem; looutput looks to do the right thing.
FWIW
I've
passed mbufs w/ mtags through the loopback interface.
This refers specifically to the following code snippet:
if (m m-m_next != NULL m-m_pkthdr.len MCLBYTES) {
struct mbuf *n;
MGETHDR(n, M_DONTWAIT, MT_HEADER);
if (!n)
goto contiguousfail;
MCLGET(n, M_DONTWAIT);
if (! (n-m_flags M_EXT)) {
m_freem(n);
goto contiguousfail;
}
m_copydata(m, 0, m-m_pkthdr.len, mtod(n, caddr_t));
n-m_pkthdr = m-m_pkthdr;
n-m_len = m-m_pkthdr.len;
n-m_pkthdr.aux = m-m_pkthdr.aux;
m-m_pkthdr.aux = (struct mbuf *)NULL;
m_freem(m);
m = n;
}
Something is wrong with your tree:
ebb% grep aux ../sys/mbuf.h
ebb%
The above code is correct in the repo as is the m_getcl code.
While the 'aux' part of the code was in fact removed, what Robert is
saying still applies. What happens is that this code 'manually'
performs a mbuf to mbuf+cluster copy because of some pretty bogus
assumption in the KAME code that expects the data to be contiguous in
a single cluster.
So when the 'n' mbuf is allocated and the cluster with it then a
shallow copy of the packet header is done from mbuf 'm' (the old mbuf)
to the newly allocated mbuf 'n'. What Robert is saying is that
this copy breaks his MAC label semantics which require a deeper copy
in this case and he is concerned that it may break the m_tag semantics
too, especially given the fact that the old mbuf 'm' is then freed
(doesn't this destroy the label?!). If that's indeed the case, then
this copy remains bogus.
The real code (i.e. what was checked in when I replaced the aux mbufs w/
tags) doesn't do the above; it does the right thing; albeit using the binary
copy of the mbuf instead of using the appropriate macro.
Regardless Robert and I have been working through the details of revising
the system handling of pkthdr's.
Sam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Harry Potter and the Disappearing Disklabel
Yesterday morning I was having some trouble with XFree consuming much more cpu time than necessary... A truss showed that some kind of shared memory issue going on, but also froze my system hard. After rebooting (kernel was from Nov 26 or 27) fsck could not check my one dirty UFS2 partition. Had to newfs and mtree to recreate /var. No big deal, and I saved an image of it beforehand. After rebooting, there was... NOTHING. GRUB errored out and wouldn't boot. Nothing could see my partitions. After a minimal 4.7-R install (DP2 disklabel whined about offsets and some other STRANGE error messages, so I went with 4.7) on a small fat32 partition, I discovered that the disklabel was empty. Had to edit it by hand... Booted up fine, made a backup, rebooted, and nothing. Not only was there NOTHING, but the disklabel on the new 4.7 install had vanished as well. This time the disklabel had to be recreated with -w -r AND the boot blocks had to be reinstalled. I've seen one post similar to this, but not much else. I think maybe the UFS2 problem had to do with Kirk's recent changes, but the disklabel issue... I'm wary to reboot my machine! What in the hell could be causing this? I'm tempted to point the finger at GEOM, but hate to say anything like that. Same problem hit me yesterday. Haven't figured out the cause yet. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xircom realport rem56g problems
Try the dc driver instead of xe. I have the same card and it worked once I added the cardbus glop to read the MAC address from the CIS. Sam - Original Message - From: Ari Suutari [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 03, 2002 4:41 AM Subject: Xircom realport rem56g problems Hi, I'm trying to get Xircom realport ethernet card (+modem) working on -current (the card works ok on -stable). When plugging the card in, I get: xe0: Xircom CreditCard Ethernet + Modem at port 0x2e8-0x2ef. device_probe_and_attach: xe0 attach returned 19 ie. it returns ENODEV. After browsing around in /sys/dev/xe/if_xe_pccard.c, I noticed that there is a table of various cards against which the driver checks the inserted card. The matching ID for this kind of card would be 0x6 but that is not in table, which causes the driver to return ENODEV. I added an entry with id 0x6 and flags MOHAWK | DINGO (don't know if this is ok, assumed so from -stable messages) No luck with this either. Now there is a loop in driver (line 230 or so) which never reaches XE_CARD_TYPE_FLAGS_DINGO. for(i=1; i!=XE_CARD_TYPE_FLAGS_DINGO; i=i1) , shouldn't this be for(i=1; i!=(XE_CARD_TYPE_FLAGS_DINGO1); i=i1) After changing this, I now get error code 12 (ENOMEM) from xe_activate. There seems to be some kind of a problem in allocating io port or interrupt. Any ideas, what could I try next ? Ari S. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: backgroud fsck is still locking up system (fwd)
Finally, one more bit of info: I have WITNESS enabled in this kernel and get this message during boot: /usr/src/sys/vm/uma_core.c:1330: could sleep with dc0 locked from /usr/src/sys/pci/if_dc.c:691 if_attach does a malloc with M_WAITOK. If the attach happens inside a lock in the driver's attach method (typical) then you'll get this complaint. Fixing it, and some other similar stuff, requires some care since the code assumes malloc will not fail. I decided to leave it until after 5.0. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xircom realport rem56g problems
I just built fresh -current (NEWCARD) but it didn't work. I'm beginning to suspect that we have different cards, since the dc driver won't recognize mine. The dc driver seems to expect that vendor id is 0x115d and device id 0x0003. On my card the vendor id is 0x0105 and device id is 0x110a. On the back of the card is says realport ethernet 10/100+modem 56 and REM56G-100. You're correct, I have the RBEM56G-100 and it has vendor id 0x115d. Sorry. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ipfw userland breaks again.
:Now I would really dislike seeing your patch in the tree, since I :consider it's a rather crude hack to circumvent the ABI problems of :ipfw. As I've already said to luigi in private e-mail (I would be :surprised if this hasn't been already discussed in the lists as well), :the proper way to fix this problem is to separate the kernel and :userland structures of ipfw, and add versioning to the struct. : :This can be done without even breaking the ABI again, since several :pointers in the kernel structures are useless to userland (like the next :field) and can be reused to implement structure versioning. : :Cheers, :Maxime If/when Luigi fixes the ABI problems with IPFW, we can remove this 'hack'. Until then, I do not consider the hackiness nature of the patch sufficient reason to not put it in. I've been bitten by this problem dozens of times, and wasted many hours simply because I couldn't get the damn network working, and so have others. I disagree with committing this hack; keep it as a local mod if you must. As to the problem; don't wait for Luigi to fix the ABI problems, do it yourself. Good things happen when folks are PO'd and won't settle for the status quo. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Maybe we should put in the release notes, that: PFIL_HOOKS is required for IPFILTER The right thing is to force the dependency in the code (I don't think there's a way to express it to config). The ipfilter code should probably have something like #ifndef PFIL_HOOKS #error You must specify PFIL_HOOKS when using ipfilter #endif Unfortunately there's no way that I know to express this if ipfilter is loaded as a module. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PFIL_HOOKS should be made default in 5.0
Maybe we should put in the release notes, that: PFIL_HOOKS is required for IPFILTER The right thing is to force the dependency in the code (I don't think there's a way to express it to config). The ipfilter code should probably have something like #ifndef PFIL_HOOKS #error You must specify PFIL_HOOKS when using ipfilter #endif Unfortunately there's no way that I know to express this if ipfilter is loaded as a module. Duh, there'll probably be unresolved symbols if you try to load ipl.ko w/o PFIL_HOOKS defined in the kernel. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On Fri, Jan 10, 2003 at 09:57:36PM +1100, Tim Robbins wrote: On Fri, Jan 10, 2003 at 01:30:16AM -0800, Juli Mallett wrote: Lately, the data field for sockets, which holds bytes ready (in the EVFILT_ READ case) to be read, is computed to be zero. This means that if you have a low watermark which is 0 per the kq, THE EVENT WILL NEVER HAPPEN. Not to mention that this means when the event IS triggered properly (if you can call it that), it is always said to have =ZERO= bytes ready. [...] I can definitely reproduce this here and also fairly angry about it. In addition to what you mentioned, fstat() gives an incorrect st_size result now and it's likely that non-NOTE_LOWAT low watermarks are firing too early as well. Ugly test program @ http://people.freebsd.org/~tjr/kq.c From what I can tell, mbufs with m_type == MT_HEADER can store data as well as those with m_type == MT_DATA. This patch corrects the tests in sbcompress(), sbdrop(), sballoc() and sbfree() so that data stored in MT_HEADER mbufs is not included in sb_ctl. I'd appreciate comments from people who have a good understanding of this code. You're correct the MT_HEADER-type mbufs may have data in them. Using the mbuf type to infer the type of data held within is probably a bad idea unless the mbufs are specifically tagged as such. I'm not clear on exactly what sb_ctl is supposed to count; the comment in the cvs log is unclear: Track the number of non-data chararacters stored in socket buffers so that the data value returned by kevent()'s EVFILT_READ filter on non-TCP sockets accurately reflects the amount of data that can be read from the sockets by applications. What are non-data characters? Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Serious issues with kqueue on sockets on CURRENT.
On Fri, 10 Jan 2003, Sam Leffler wrote: unless the mbufs are specifically tagged as such. I'm not clear on exactly what sb_ctl is supposed to count; the comment in the cvs log is unclear: Track the number of non-data chararacters stored in socket buffers so that the data value returned by kevent()'s EVFILT_READ filter on non-TCP sockets accurately reflects the amount of data that can be read from the sockets by applications. What are non-data characters? A very zen question. :) In this case, It probably means bytes carried in an mbuf with a type other than MT_DATA. The point was that it's not clear to me that you can infer this data from the inverse set of (MT_DATA +whatever). Garrett suggested MT_SONAME data as an example of non-data characters. I no longer know exactly what the complete set of mbuf types is that comprise non-data characters. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ath0 driver
On Wed, 6 Aug 2003, Sam Leffler wrote: Shouldn't that be 0.9.5.2? I run the latest current, and hw.ath.hal.version is 0.9.5.2. You're right; I committed a slightly older version to FreeBSD than to Linux. Any chance that you could commit the newer version? Or are the differences too marginal? There are no substantive differences. The later version was created to identify some fixes specific to Linux. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 driver
Ive got a Dlink DWL-G520 that Ive installed into a Freebsd system. Ive set up the card with the following ifconfig_ath0=inet 10.0.0.1 netmask 255.255.255.0 ssid daves channel 10 media DS11 mediaopt hostap This system was cvsuped and buildworld about 3 days ago. The card appears to be working because when I try to connect with my PDA it shows full Link and quality, and when I ifconfig ath0 down , the link and quality go down to nothing. However it doesn't give out dhcp addresses over this interface. Im sure my dhcpd.conf is fine because I've used a similar one on a laptop = aka wireless access point that worked very well. So I tried to use dstumbler to see if it could detect the PDA, however it gives me the following error error: unable to ioctl device socket: Operation now in progress and it stays that way. Has anyone had this issue as well or now what it means? Verify you have the latest HAL using sysctl hw.ath The version should be 0.9.5.3 or better (can't remember if I committed .4 or .3). If you have an old version update. Otherwise you might try tapping 802.11 frames with tcpdump on the AP to see what's going on: tcpdump -i ath0 -y IEEE802_11 As to dstumbler, it is intimately tied to the wi driver at the moment. I have a version that works w/ wi and ath drivers but it's a major rewrite and incomplete. If someone wants to pick it up I'd be happy to pass the (incomplete) work on... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ath driver still buggy.
Me and a couple of my friends work on small freebsd version for embedded systems. We all noticed that our wifi cards with atheros chip have problems with the ath driver. The system keeps on spitting out following messages before the link, that is already very slow dies: ath_rate_ctl: 54M - 48M (0 ok, 3 err, 3 retr) ath_rate_ctl: 48M - 36M (0 ok, 1 err, 1 retr) ath_rate_ctl: 36M - 24M (0 ok, 1 err, 1 retr) ath_rate_ctl: 24M - 36M (11 ok, 0 err, 0 retr) ath_rate_ctl: 36M - 48M (23 ok, 0 err, 0 retr) ath_rate_ctl: 48M - 36M (0 ok, 2 err, 2 retr) ath_rate_ctl: 36M - 24M (3 ok, 7 err, 7 retr) ath_rate_ctl: 24M - 18M (0 ok, 1 err, 1 retr) And ping requests end up with following message: ping: sendto: No buffer space available This was tested running 11a and 11g with PCMCIA and mini-PCI cards. hw.ath.hal.version: 0.9.5.2 ath0: Atheros 5212 mem 0x8801-0x8801 irq 11 at device 0.0 on cardbus1 FreeBSD 5.1-CURRENT #0: Wed Aug 20 16:59:24 CEST 2003 Any solution for that Sam? I can remember you mentioned you have fix for that a couple of weeks ago and that you will submit it in a week time or so. I have seen the problem but have been unable to resolve it. Grab a copy of /usr/src/tools/tools/ath/athstats and use it to look at the statistics kept by the driver when this happens. They may give a hint but unfortunately I think it's a problem with the anti-noise-immunity (ANI) code in the HAL and I have no time right now to dig into that. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS: if_sis patch
Please try out this patch if you have a sis based network card. It sets a 400usec interrupt holdoff, and this seems to have a profound impact on network performance. The patch is relative to FreeBSD-current but probably applies on 5.0, 5.1 and even 4.x as well. In my tests, using a soekris 4801 computer I have found: fetch(1)'ing a ftp:// file from a server on the local segment is 43.2% +/-0.7% faster (from around 385 to 640 kBps). FTP of the same file is 10.6% +/-1.2% faster (from 3.11 to 3.44 MB/sec) Checking out src/sbin from a NFS mounted CVSROOT was 17.0% +/-1.0% faster. It is especially important that folks with Soekris 45xx boards try this. My tests appeared to indicate there might be issues, but my operating environment is so different from -current that is was hard to tell if the problems I saw (lost packets) were due to this change or others. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic (with uipc_domain.c, rev 1.33)
latest kernel causes a panic early during boot: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x68 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02667cf stack pointer = 0x10:0xc0641cf8 frame pointer = 0x10:0xc0641d08 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x18f: movl0x68(%ecx),%edx db where _mtx_lock_sleep(c050fbe0,0,0,0) at _mtx_lock_sleep+0x18f net_add_domain(c04bd500) at net_add_domain+0x34 ngs_mod_event(c09e8c80,0,c04bd300,0,c09e8c80) at ngs_mod_event+0x26 ng_mod_event(c09e8c80,0,c04bd300,c050c500,0) at ng_mod_event+0x52 module_register_init(c04bd33c,63ec00,63e000,0,c013d015) at module_register_init+ 0x4b mi_startup() at mi_startup+0x96 begin() at begin+0x2c db backing out rev. 1.33 of kern/uipc_domain.c solved the problem for me. Additional side notice: netgraph is compiled statically into the kernel, no separate module. Thanks, will fix it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP/STATUS: network locking
I've committed a number of changes to lock the middlware parts of the network subsystem. There's still more to come; I'm moving slowly to insure each batch gets exposure. All the pending changes can be found at: http://www.freebsd.org/~sam The major changes that will go in next week are: bridge, dummynet, ipfw, multicast routing (mroute), and the routing table (rtentry). I've been running with all these mods on a variety of machines (desktop, NFS server, laptop, firewall) for weeks but testing everything is difficult so don't be surprised if you encounter issues like lock order reversals. Each patch is pretty much independent so if you regularly use say dummynet then it would be useful to try the patch and send me feedback. In the above directory you'll also find the first tangible benefit of this work: netisr.patch contains changes to push Giant up one level. Note however that unless the network drivers mark their interrupt handlers MPSAFE you're not really going to exercise the locking. I've been running em, sis, fxp, wi, and ath drivers this way for several months with no ill effects (except for a problem running Atheros hardware in HostAP mode). Many other drivers are locked and appear ready to run MPSAFE. Shortly I'll have Giant pushed all the way up through the INET protocols. When that happens it'll be time to remove Giant from the socket layer and lock IPv6 and UNIX domain sockets. At some point we'll need to switch over to a non-Giant top half; at that point drivers and protocols that are not properly locked will need help or be left behind. Note that the current plan is to NOT commit any changes to remove Giant from the socket layer until after 5.2. Folks interested in trying this stuff will need to track the work in perforce or apply patches that I'll make available at stable points. If folks want to talk about this work at BSDCon I'll be around Wed-Fri. I'll also be at the developers summit on Saturday. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? Yes. Bridging happens outside the operation of the driver. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Is the ath(4) driver, like the wi(4) driver, incapable of performing bridging? Sorry, answered too quickly. ath and wi have the same restrictions. You can use bridging to hookup a wired and wireless network but not two wireless networks. I can't tell from your posting what you are trying to do. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
I think what he meant was that at on state was known (I don't know the current state) that as the wi could not be but in promiscuous mode it could not be used for bridging.. Bridging requires promiscuous mode (or some very tricky proxy-arp stuff). You can put wi (and ath) in promiscuous mode. The bridge manual page is wrong and I will fix it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) stopped working
I just built a kernel with latest sources, unfortunately, my ath(4) card stopped working. The device is there, devd sets ip address, route etc., just as it did before the upgrade - the problem is that the link is dead, there's _nothing_ going over the link. It also seems to re-associate with the AP quite often. A kernel from Fri Sep 12 works correctly, with the same configuration. I guess the ath/ieee80211 commits from yesterday/today broke something. I need more help than this. Try supplying some information like the card type (e.g. 5212) and your setup (station, adhoc, hostap, 11a, 11b, 11g). Also try sysctl debug.ieee80211=1 and/or ifconfig ath0 debug and look at the debug messages. Obviously stuff worked for me before I committed (and I tested all types of cards). Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver bridging
Yes, I was referring to bridging two wireless interfaces. David Young (of netbsd) has plans for WDS support that should fit into the existing 802.11 layer. With his design you should be able to bridge WDS links using the standard bridge support. No ETA. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: more network locking commits
I just committed changes to bridge, ipfw, and dummynet. I've been running these for a while but beware. I'm aware of two LOR issues that I want to sort out later, after some more changes have gone in. Regardless, if you encounter problems let me know... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP/STATUS: network locking
On Tue, Sep 16, 2003 at 09:29:07AM -0700, Sam Leffler wrote: Please send me your kernel config and tell me again exactly what fails. I will try to reproduce your problem. Sam After your yesterday/today commits, I got panic while doing netstat -an. On the kernel from about two days ago, with manually added patches, the netstat command render system unusable (with netstat process in LOCK state, or, in other cases - (swi8: tty:sio clock) process in LOCK state). You cannot mix+match the commits and the patches. You also, if I recall, were only applying some of the patches and not all of them. I'm not sure this can work. I haven't looked at the config you sent me; will try today. I think that unless you can track my changes through p4 it may be problematic using the patches. I'll see about updating the patches based on the current CVS. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
I've got a Netgear WAG511 (Atheros 5212-based card) and a Netgear FWAG114 wireless router. I've been trying to get the card and the router talking under FreeBSD. (Both 802.11a and 802.11g work fine under Windows on the same machine.) I'm using -current from September 15th. Anyway, whenever I try to get the card talking to the router, which is running WEP (128 bit keys) on both the a and b/g sides, I get: ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] Here's what the ifconfig looks like: ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether [ card mac address ] media: IEEE 802.11 Wireless Ethernet autoselect mode 11a (OFDM/6Mbps) status: no carrier ssid [my ssid] 1:[my ssid] channel -1 authmode OPEN powersavemode OFF powersavesleep 100 wepmode MIXED weptxkey 1 wepkey 1:128-bit wepkey 2:128-bit wepkey 3:128-bit wepkey 4:128-bit I've verified and re-verified, via cut-and-paste from the router setup screen, that the WEP key is correct. Good news+bad news. I just committed a fix to ifconfig to correctly handle 128-bit WEP keys. I'm not sure how you thought you were setting your key up but ifconfig was barfing on anything more than 104 bits. FWIW ifconfig wrongly indicated keys 5 bytes (40 bits) were 128-bit keys; I also fixed that so ifconfig now indicates keys are 40-, 104-, or 128-bit according to their length. Beware also that wicontrol displays WEP keys longer than 104 bits zero-padded; I believe this is because of limitations in the RID API for fetching keys. Someone else may want to investigate that issue. The bad news is that with 128-bit keys installed I'm getting decryption errors at the AP. Actually, I'm seeing errors for any length key so it's likely a botch in the WEP frame construction in the driver. I've run out of time to look at this right now and will have to investigate later. Anyway, I can't get the ath(4) driver to talk to the router when it is running WEP. I have been able to get it to talk 802.11g to the router without WEP enabled, though. I tried setting the authmode to shared via ifconfig, but from looking at ieee80211_ioctl.c: # if 0 case IEEE80211_IOC_AUTHMODE: sc-wi_authmode = ireq-i_val; break; # endif i.e. I get EINVAL back. Is WEP supposed to work in -current? authmode is not relevant. WEP worked at one time; I seem to have broken it. As I said above I will have to look at it later. In a separate issue, the ath(4) driver can't see the 802.11a side of the wireless router at all when it is running in 108Mbps turbo mode. If I drop it down to 54Mbps, it sees it. (Works fine in Windows.) Is the ath(4) driver supposed to support the 108Mbps turbo mode? I was able to associate with an Atheros AP with turbo mode enabled but didn't get any higher throughput. I'm investigating this. FWIW I enabled turbo mode with: ifconfig ath0 mediaopt turbo I verified turbo mode was in use by disabling it on either station or AP side and with things mismatched the station/AP couldn't see each other. With turbo mode enabled on each side I was able to associate and communicate as normal; but netperf throughput was identical to the non-turbo setup. I'm asking Atheros folks for clarification on this--I may need to do some additional setup work to enable turbo operation. This is actually the first time I've tried turbo mode... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
Hmm. One other thing I'm seeing is that when I configure a 128 bit key with ifconfig or wicontrol (wicontrol shows all 28 characters -- 0x plus 26 hex characters), ifconfig still thinks it is a 104 bit key. This is because ireq.i_len is 13. You must not have the up to date ifconfig. This was the behaviour from before. I believe the mechanism that wicontrol uses to fetch keys does not handle 104-bit keys so you see the zero-padded key string. In a separate issue, the ath(4) driver can't see the 802.11a side of the wireless router at all when it is running in 108Mbps turbo mode. If I drop it down to 54Mbps, it sees it. (Works fine in Windows.) Is the ath(4) driver supposed to support the 108Mbps turbo mode? I was able to associate with an Atheros AP with turbo mode enabled but didn't get any higher throughput. I'm investigating this. FWIW I enabled turbo mode with: ifconfig ath0 mediaopt turbo I had to also set the mode to 11a before it wanted to accept the turbo option. Otherwise I got: ifconfig: SIOCSIFMEDIA (mediaopt): Device not configured Ah, yes. Turbo mode is orthogonal to 11a/b/g. You can use it with 11g too so you need to specifiy 11a or 11g. I was already locked in 11a mode. (But note that 11g+turbo is not yet supported by the driver.) Then I typed: # ifconfig ath0 mode 11a mediaopt turbo atalk 0.0 range 0-0 phase 2 Does it think I'm doing appletalk or something? Hmm, didn't see this, will have to check. It seems to see the base station in turbo mode now, but I'm still getting the authentication failed (reason 13) errors. Are you using WEP? As I explained WEP doesn't work right now. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: PFIL_HOOKS/ipfilter changes
The following changes should be transparent but just in case they are not please be aware... Sam sam 2003/09/23 10:54:04 PDT FreeBSD src repository Modified files: sys/net bridge.c pfil.h pfil.c sys/netinet ip_input.c ip_output.c ip_var.h sys/netinet6 ip6_forward.c ip6_input.c ip6_output.c ip6_var.h ip6protosw.h sys/sys param.h protosw.h sys/modules/bridge Makefile Log: o update PFIL_HOOKS support to current API used by netbsd o revamp IPv4+IPv6+bridge usage to match API changes o remove pfil_head instances from protosw entries (no longer used) o add locking o bump FreeBSD version for 3rd party modules Heavy lifting by: Max Laier [EMAIL PROTECTED] Supported by: FreeBSD Foundation Obtained from: NetBSD (bits of pfil.h and pfil.c) sam 2003/09/23 10:55:04 PDT FreeBSD src repository Modified files: sys/contrib/ipfilter/netinet ip_fil.c sys/modules/ipfilter Makefile Log: update to reflect PFIL_HOOKS api changes Supported by: FreeBSD Foundation ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Could we add PFIL_HOOKS to GENERIC, while we're at it? Please? Eventually this will happen. Almost certainly in time for 5.2. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: PFIL_HOOKS/ipfilter changes
Sam Leffler wrote: Could we add PFIL_HOOKS to GENERIC, while we're at it? Please? Eventually this will happen. Almost certainly in time for 5.2. It was due for 5.0-RELEASE, it hasn't made it in for 5.1-RELEASE and post 5.1-R reminders have been ignored on this list as well. This is starting to become rather ridiculous. Why not just do it? It was not due for 5.0 or any subsequent release. It was requested by certain developers and I requested that they demonstrate that adding it to the GENERIC system would not noticeably impact non-PFIL_HOOKS users. I intend to convert certain network subsystems to use PFIL_HOOKS instead of their (current) adhoc techniques. This will mean that PFIL_HOOKS will be a necessary part of the system and so will be in the GENERIC kernel. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usr.sbin/ipftest build error
After cvsup, buildworld error in usr.sbin/ipftest [snip] Dang, my bad. Will deal with it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wi hostap recently screwed.
Obviously I don't understand enough about locks. A recent (last week or two) checkin screwed the wi driver such that it panic's saying that ic_nodelock is used recursively first in line 525 and then in 547 of net80211/ieee80211_node.c. On my own, I tried chaging line 87 to mtx_init() the lock with MTX_RECURSE, but this causes the kernel to panic on line 472 saying something about trying to spin. I'm relatively certain that this is all only caused by hostap mode ... it doesn't appear to happen on my laptop (also running this week's current). ... Now, that said, some of my disassociation problems on the laptop seem to have cured (associating with other access points) ... So I need help with this really large bug in the wi code. Please send me your config. I'll deal with it. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to compile kernel
I'm looking into it. Everything built+ran fine with the last commit... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to compile kernel [IPFILTER users read this]
vimes# diff GENERIC VIMES 25c25 ident GENERIC --- ident VIMES 63,66c63,66 options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed --- # options INVARIANTS #Enable calls of extra sanity # checking options INVARIANT_SUPPORT #Extra sanity checks of # internal structures, required by INVARIANTS options WITNESS # #Enable checks to detect deadlocks and cycles options # WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed 272a273,278 # These options are a subset of the IPFILTER options. options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFILTER_DEFAULT_BLOCK #block all packets by default I don't see PFIL_HOOKS defined. You need it for IPFILTER. Part of my changes removed some cruft that automatically configured PFIL_HOOKS when IPFILTER was configured. Guess I need to update NOTES and add something to UPDATING. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Tonight's current breaks IPFILTER
Tonight's current breaks compiling IPFILTER. It complains that it can't find the 'PFIL_OUT' symbol. Read UPDATING; you need PFIL_HOOKS in your kernel config file. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
On Monday 29 September 2003 01:30 am, Greg 'groggy' Lehey wrote: After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? Yes, I noticed this late last week. I think it's been busted for 1 week. I tried to pinpoint the commit but ran out of time. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serial debug broken in recent -CURRENT?
On Tuesday 30 September 2003 04:01 am, Bruce Evans wrote: On Tue, 30 Sep 2003, Greg 'groggy' Lehey wrote: On Tuesday, 30 September 2003 at 16:23:35 +1000, Bruce Evans wrote: On Mon, 29 Sep 2003, Greg 'groggy' Lehey wrote: After building a new kernel, remote serial gdb no longer works. When I issue a 'continue' command, I lose control of the system, but it doesn't continue running. Has anybody else seen this? It works as well as it did a few months ago here. (Not very well compared with ddb. E.g., calling a function is usually fatal.) Hmm, that's not what Sam or I are seeing. How old is your kernel? You *are* able to continue, right? Everything else works for me. I didn't test with my kernel; I tested with almost-current SMP and !SMP kernels (amost-current = 217 lines of patches; my kernel = 96934 lines of patches). They were about half an hour old when I tried it. I tested little more than continuing from Debugger(). I didn't test using optional foot shooting devices like acpi or modules. It reliably locks up for me when you break into a running system; set a breakpoint; and then continue. Machine is UP+HTT. Haven't tried other machines. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: routing table locking changes committed
I just committed a large set of changes to lock routing table entries. I've been running with these changes for several months w/o ill effects but as always beware. You will see some LOR's that I expect will go away with forthcoming work from Andre Oppermann. If not they'll get fixed before the 5.2 release. The most likely one you'll see is when ejecting a network card from a laptop. Please contact me directly if you see any problems that look related to these changes. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_em panic
On Wednesday 08 October 2003 05:27 pm, Daniel Eischen wrote:
One of my buddies is having panics with if_em after the last
set of changes a couple of weeks ago. He runs dhclient
on the interface to get a lease from a cable modem. The
panic is a recurse on a non-recursive mutex. I haven't
gotten a traceback from him yet, but a little perusing
through the source seems to show this as a possible problem:
Index: if_em.c
===
RCS file: /opt/FreeBSD/cvs/src/sys/dev/em/if_em.c,v
retrieving revision 1.30
diff -u -r1.30 if_em.c
--- if_em.c 23 Sep 2003 00:18:25 - 1.30
+++ if_em.c 8 Oct 2003 20:12:56 -
@@ -933,7 +933,7 @@
if (ether_poll_register(em_poll, ifp)) {
em_disable_intr(adapter);
-em_poll(ifp, 0, 1);
+ em_poll_locked(ifp, 0, 1);
EM_UNLOCK(adapter);
return;
}
Thanks, I've got work to do on DEVICE_POLLING (changes to the core polling
code are still sitting in my perforce tree). I'll commit after going over
the driver again.
Also, indentation is inconsistent, some lines use tabs, some
uses spaces. It looks like the original code from Intel used
spaces and subsequent mods used tabs. I guess we should be
sticking with the original style, but it is easy to overlook.
Yeah, probably. I wouldn't notice it. I agree that it's important to conform
to local style, regardless of whether it conflicts with style(9).
Sam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 point-to-ponit (turbo mode)
On Wednesday 08 October 2003 08:45 pm, Marcos Biscaysaqu wrote: Hi There. I have 2 PCI wireless card with the Atheros chipset some one know how can i setup a point-to-point with 2 of this wireless card on Freebsd, I could made work Access Point client, but i couln't adhoc turbo mode 11a Apparently adhoc mode is currently busted. It's at the top of my todo list and I may even get to it this week... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is em nic generating interrupts?
On Thursday 09 October 2003 05:57 am, Michael O. Boev wrote: -Original Message- From: Terry Lambert [mailto:[EMAIL PROTECTED] Sent: Thursday, October 09, 2003 5:19 PM To: Michael O. Boev Cc: [EMAIL PROTECTED] Subject: Re: Why is em nic generating interrupts? Michael O. Boev wrote: I've got a [uniprocessor 5.1-RELEASE] router machine with fxp and em nics. I've built my kernel with the following included: options DEVICE_POLLING options HZ=2500 and enabled polling in /etc/sysctl.conf. [ ... ] What's happening? Is polling working in my case? If yes, why is vmstat showing interrupts? I see clearly, that fxp's counter doesn't increase, and em's is constantly growing. Is there anyone who knows for sure that em's polling works? You may want to ask Luigi; polling is his code. However, I believe the issue is that polling doesn't start until you take an interrupt, and it stops as soon as there is no more data to process, and waits for the next interrupt. If you were to jack your load way up, you would probably see an increase in interrupts, then them dropping off dramatically. To this dare I object, that there is traffic going through this machine, and fxp0 is NOT generating interrupts, while em IS. So, if the rule above works, they both have to behave in same ways. If all else fails, read the source code... 8-). )) I've tried to, but... had to ask here. So all is left is to ask Luigi and Intel. I cannot comment on 5.1-R, but I am running DEVICE_POLLING tests today with -current and 2 em NICS and systat -vm shows no interrupts for the IRQs where the NICs are. I can only guess that either 5.1-R has a bug or the polling support was not in the driver at that point. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Locks up with CURRENT
On Saturday 11 October 2003 03:20 am, Antony T Curtis wrote:
On Sat, 2003-10-11 at 10:36, Antony T Curtis wrote:
Hi, I cvsuped at about 10/10/03 11PM GMT and rebuilt world and kernel.
It locks up after displaying:
GEOM: create disk ad0 dp=0xc456d370
ad0: 28615MB TOSHIBA MK3021GAS [58140/16/63] at ata0-master UDMA100
ata1: resetting devices ..
done
System is a Toshiba Satellite 2455 notebook.
Removing the CDRW drive allowed it to boot
I suspect this is the same problem I've encountered with a Toshiba DVD/CDRW
drive on a ServerWorks CSB5 controller. The following change re-enables some
code to workaround a missed interrupt and allows my system to boot::
diff ./ata-queue.c /data/devel/netperf/dev/ata/ata-queue.c
319c319
#if 0
---
#if 1
However the Toshiba drive is not recognized. If after booting I do:
atacontrol reinit 1
I sometimes get the drive properly probed. sos sent me the following change
to try but I still haven't gotten to it. Beware that it's probably out of
date wrt current source:
Index: ata-lowlevel.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v
retrieving revision 1.16
diff -u -r1.16 ata-lowlevel.c
--- ata-lowlevel.c 20 Sep 2003 08:38:33 - 1.16
+++ ata-lowlevel.c 26 Sep 2003 06:50:29 -
@@ -527,7 +527,8 @@
ATA_IDX_OUTB(ch, ATA_ALTSTAT, ATA_A_IDS | ATA_A_RESET);
DELAY(1);
ATA_IDX_OUTB(ch, ATA_ALTSTAT, ATA_A_IDS);
-DELAY(1);
+DELAY(10);
+ATA_IDX_INB(ch, ATA_ERROR);
/* wait for BUSY to go inactive */
for (timeout = 0; timeout 310; timeout++) {
Sam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: pmap_enter: attempted pmap_enter on 4MB page
I've been getting this panic a lot in the past week. Unfortunately it's on my file server so I can't use gdb to get more details than what ddb provides (the kernel is on the machine that's panic'd). This is a UP x86 box. The stack trace is: pmap_enter kmem_malloc page_alloc slab_zalloc uma_zone_slab uma_zalloc_bucket uma_zalloc_arg uma_zalloc_arg ffs_vget ufs_lookup ufs_vnoperate vfs_cache_lookup ufs_voperate lookup nfs_namei nfsrv_lookup nfssvc_nfsd nfssvc Contact me for more details. This really needs to be fixed. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: What's up with the IP stack?
On Sunday 12 October 2003 11:03 am, Andre Guibert de Bruet wrote: On Sun, 12 Oct 2003, Josef Karthauser wrote: On Sun, Oct 12, 2003 at 02:48:01PM +0200, Soren Schmidt wrote: It seems Josef Karthauser wrote: I've just built and installed a new kernel, the first since Aug 6th. There appears to be a problem with the IP stack. What happens is that everything is fine for a few hours, and then the IP stack stops working. I can no longer ping anything on the local network, my default route drops out (which is probably dhclient's doing). Perhaps it is ARP that is broken, it's hard to tell. All I know is that I need to reboot to make it work again. Is anyone else experiencing this kind of problem? Do you have dummynet included in the kernel ? That has been broken for me since sam's latest commit as a backout of ip_dummynet.c fixes the problem for me... No, I've not got dummynet in there. My current kernel config is: I experienced this a week ago. I found that ifconfig'ing the interface down and back up again fixed the problem. I've since reverted to a kernel compiled on September 25th. It would be good to know more details; I still don't have much to go on. Try to identify, for example, if the problem is specific to a particular device/interface or feature you're using (e.g dummynet). If you have ddb in your system, then when the system gets into a bad state break into the debugger and look for threads that are blocked on locks. If you have witness in your kernel then show locks would also be useful. If you don't have witness in your system then rebuild your kernel with it. The most recent round of changes were to lock the routing table. These went in 10/3 and were extensive. They could easily be the problem but w/o more info I can't really help. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath(4) driver problems with WEP...
On Tuesday 16 September 2003 08:12 pm, Kenneth D. Merry wrote: I've got a Netgear WAG511 (Atheros 5212-based card) and a Netgear FWAG114 wireless router. I've been trying to get the card and the router talking under FreeBSD. (Both 802.11a and 802.11g work fine under Windows on the same machine.) I'm using -current from September 15th. Anyway, whenever I try to get the card talking to the router, which is running WEP (128 bit keys) on both the a and b/g sides, I get: ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] ath0: authentication failed (reason 13) for [ base station MAC address ] I just committed a fix to the ath driver for the WEP problem; let me know if you have any more trouble. I verified 40-, 104-, and 128-bit WEP keys work for me. As a bonus I also sped up WEP traffic through the driver. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR (route.c:182 route.c:133).
On Wednesday 15 October 2003 03:21 am, Pawel Jakub Dawidek wrote: Hello. Already reported? lock order reversal 1st 0xc47b6490 rtentry (rtentry) @ /usr/src/sys/net/route.c:182 2nd 0xc44be77c radix node head (radix node head) @ /usr/src/sys/net/route.c:133 Yes, I'm aware of this one. Thank you. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: multicast panic
On Wednesday 15 October 2003 09:08 am, Doug White wrote: On Tue, 14 Oct 2003, David Cornejo wrote: I'm trying to compile a multicast application and the system panics every time I run configure: Might be nice toknow which multicast application, if its publicly available :) I suspect this is fallout from the multicast code reorg that bms has been working on. Yup; it's on my list of bugs to look at. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: cvs commit: src/sys/net80211 ieee80211_output.c ieee80211_var.h
This fixes adhoc mode for wi devices. Adhoc mode is still not working correctly for ath devices. No eta on fixing it. Sam ---BeginMessage--- sam 2003/10/17 14:54:59 PDT FreeBSD src repository Modified files: sys/net80211 ieee80211_output.c ieee80211_var.h Log: o add capability to indicate if device receives all management frames o use recv mgmt capability to decide if outbound frames should be discarded if no node table entry is present Revision ChangesPath 1.7 +17 -6 src/sys/net80211/ieee80211_output.c http://cvsweb.FreeBSD.org/src/sys/net80211/ieee80211_output.c.diff?r1=1.6r2=1.7 1.8 +1 -0 src/sys/net80211/ieee80211_var.h http://cvsweb.FreeBSD.org/src/sys/net80211/ieee80211_var.h.diff?r1=1.7r2=1.8 ---End Message--- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ath0 Crash the PC
On Wednesday 22 October 2003 07:36 pm, Marcos Biscaysaqu wrote: Hi There. With the debug on in hte kernel ZABU I found this when my Atheros card crash: lock order reversal 1st 0xc36c1e84 rl0 (network driver) @ pci/if_rl.c:1485 2nd 0xc0766280 bridge (bridge) @ net/bridge.c:777 Stack backtrace: lock order reversal 1st 0xc0768540 ifnet (ifnet) @ net/bridge.c:424 2nd 0xc379307c radix node head (radix node head) @ net/route.c:544 Stack backtrace: looks like is a Bridge problem, I have the option BRIDGE in my kernel may be I need try another way to make the bridge work? LOR's will not cause a system crash. If a LOR causes a problem it will likely deadlock your system. The two LORs shown above are known and should not be a problem. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic route.c:565
On Tuesday 28 October 2003 04:40 pm, Jiri Mikulas wrote: FreeBSD 5.1-CURRENT #3: Tue Oct 28 23:51:52 CET 2003 ~~~cut~~~ recursed on non-recursive lock (sleep mutex) rtentry @ /usr/src/sys/net/route.c:565 first acquired @ /usr/src/sys/net/route.c:182 panic: recurse ~~~cut~~~ Any chance you can get a stack trace the next time this happens? The LOR by itself is hard to go from... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: MPSAFE network drivers
I'm committing changes to mark various network drivers' interrupt handlers MPSAFE. To insure folks have a way to backout if they hit problems I've also added a tunable that lets you disable this w/o rebuilding your kernel. By default all network drivers that register an interrupt handler INTR_MPSAFE are setup to run their ISR w/o Giant. If you want to defeat this w/o changing the code you can set debug.mpsafenet=0 from the loader when booting and the MPSAFE bit will automatically be removed. I plan to use this to also control forthcoming changes for registering MPSAFE netisrs. The following drivers are marked MPSAFE: ath, em, ep, fxp, sn, wi, sis I've got changes coming for bge. Other drivers probably can be marked MPSAFE but I'm only doing it for those drivers that I can test. Sam ---BeginMessage--- sam 2003/10/29 10:29:50 PST FreeBSD src repository Modified files: sys/kern subr_bus.c Log: Add a temporary mechanism to disble INTR_MPSAFE from network interface drivers. This is prepatory to running more parts of the network system w/o Giant. Revision ChangesPath 1.135 +13 -0 src/sys/kern/subr_bus.c http://cvsweb.FreeBSD.org/src/sys/kern/subr_bus.c.diff?r1=1.134r2=1.135 ---End Message--- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: MPSAFE network drivers
On Thursday 30 October 2003 01:22 am, Pawel Jakub Dawidek wrote: On Wed, Oct 29, 2003 at 11:52:48AM -0700, Sam Leffler wrote: + I'm committing changes to mark various network drivers' interrupt handlers + MPSAFE. To insure folks have a way to backout if they hit problems I've also + added a tunable that lets you disable this w/o rebuilding your kernel. By + default all network drivers that register an interrupt handler INTR_MPSAFE + are setup to run their ISR w/o Giant. If you want to defeat this w/o + changing the code you can set + + debug.mpsafenet=0 + + from the loader when booting and the MPSAFE bit will automatically be removed. + I plan to use this to also control forthcoming changes for registering MPSAFE + netisrs. + + The following drivers are marked MPSAFE: + + ath, em, ep, fxp, sn, wi, sis + + I've got changes coming for bge. Other drivers probably can be marked MPSAFE + but I'm only doing it for those drivers that I can test. Because there is so many drivers, maybe you could prepare some regression tests designed to check changed things. This will allow people to test your changes - it is not very easy now if we don't know what we're looking for exactly PLUS those drivers aren't marked MPSAFE by default. Unfortunately there is no easy way to decide if the locking in a driver is correct; otherwise I'd simply test them and not provide a fallback as a I did. Before I commit any driver I run with it for at least a few weeks (in some cases months) on a variety of machines (workstation, server, laptop, firewall). If there are no problems then I commit the change. The driver changes I committed yesterday I've been running for 4 months. Likewise, the next round of locking changes to push Giant up have been running for ~2 months. Otherwise the main safeguard I use are numerous assertions to validate assumptions. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on ICMP Redirect
On Thursday 30 October 2003 07:33 am, Daniel C. Sobral wrote: I could have stuck a LONG time on this one if I wasn't testing something that results in the very thing that causes the panic. I don't have the exact details, but what I did is the following: ifconfig fxp0 10.0.2.6/16 (well, that's configured during boot) route add 10.0.14.247 10.0.2.7 ping 10.0.14.247 This results in an ICMP Redirect being returned by 10.0.2.7. Upon it's receival, the machine panics. I'm using a current from yesterday (29th). Here are a couple of backtraces: I'll deal with it. The icmp_redirect LOR was next on my list... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jumbograms ( em) nfs a no go
On Thursday 30 October 2003 04:46 am, Michal Mertl wrote: I wanted to test gigabit network performance and found out that current (from 5.0 to up to date -current) doesn't fully work with jumbograms (MTU set to 6000), Intel adapters and nfs (both UDP and TCP). I checked that the same thing works with 4.9. I then left one computer at 4.9 and upgraded the other to 5.0. When I mount a partition from 5.0 machine I found out, that copying reliably works only from 5.0 to 4.9. The other way around I see messages 'em0: discard oversize frame (ether type 800 flags 3 len 67582 max 6014)' on 5.0 and the copying stalls. On 4.9 machine I later see 'nfs server 10.0.0.2:/usr: not responding'. The interface is stuck for some time - can be revived by changing mtu back to 1500 and down/up sequence. I've ran many jumbogram tests of machines connected with a cross-over cable and em devices at each end. If you've got a swtch in the middle make sure it does the right thing. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR route.c:182
On Thursday 30 October 2003 10:30 am, othermark wrote: I'll me too this one.. Another backtrace with a different call sequence (via ipv6), exact same LOR lock order reversal 1st 0xc2177c90 rtentry (rtentry) @ /usr/src/sys/net/route.c:182 2nd 0xc206537c radix node head (radix node head) @ /usr/src/sys/net route.c:544 Stack backtrace: backtrace(c0841847,c206537c,c08472ff,c08472ff,c0847355) at backtrace+0x17 witness_lock(c206537c,8,c0847355,220,c0926300) at witness_lock+0x672 _mtx_lock_flags(c206537c,0,c0847355,220,c8f45868) at _mtx_lock_flags+0xba rtrequest1(1,c8f45874,c8f458c8,0,c24376b0) at rtrequest1+0x59 rtrequest(1,c24376b0,c24376b0,c8f458cc,405) at rtrequest+0x4a in6_ifloop_request(1,c2437600,0,c2437600,40) at in6_ifloop_request+0x76 in6_ifaddloop(c2437600,0,c2437600,0,c8f45a84) at in6_ifaddloop+0x50 in6_ifinit(c200,c2437600,c8f45a2c,1,1be) at in6_ifinit+0x147 in6_update_ifa(c200,c8f45a1c,0,0,20080fe) at in6_update_ifa+0x500 in6_ifadd(c8f45b34,0,40,0,0) at in6_ifadd+0x22a I've got fixes for almost all the outstanding LOR's and recursive lock problems. I'm doing more testing before I committing them. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: More ULE bugs fixed.
On Friday 31 October 2003 09:04 am, Bruce Evans wrote: My simple make benchmark now takes infinitely longer with ULE under SMP, since make -j 16 with ULE under SMP now hangs nfs after about a minute. 4BSD works better. However, some networking bugs have developed in the last few days. One of their manifestations is that SMP kernels always panic in sbdrop() on shutdown. I'm looking at something similar now. If you have a stack trace please send it to me (along with any other info). You might also try booting debug.mpsafenet=0. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with locks and networking as of a day ago
On Friday 31 October 2003 07:49 pm, Doug Ambrisko wrote: I'm getting this panic a fair amount when dhclient is running on with the an(4) driver. My Atheros based card appears to have broke so I can't use that now (it doesn't work in Windows either). Here is the dmesg: lock order reversal 1st 0xc2ebaf08 vm object (vm object) @ vm/swap_pager.c:1319 2nd 0xc0735600 swap_pager swhash (swap_pager swhash) @ vm/swap_pager.c:1835 3rd 0xc103565c vm object (vm object) @ vm/uma_core.c:876 Stack backtrace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0595952 stack pointer = 0x10:0xd0135a40 frame pointer = 0x10:0xd0135afc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 854 (ssh) trap number = 12 panic: page fault syncing disks, buffers remaining... panic: sleeping thread (pid 854) owns a mute x Uptime: 10m22s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 and the trace is: kgdb) where #0 doadump () at ../../../kern/kern_shutdown.c:240 #1 0xc050f61c in boot (howto=260) at ../../../kern/kern_shutdown.c:372 #2 0xc050f9a7 in panic () at ../../../kern/kern_shutdown.c:550 #3 0xc05057db in propagate_priority (td=0x0) at ../../../kern/kern_mutex.c:124 #4 0xc0505fe9 in _mtx_lock_sleep (m=0xc072a76c, opts=0, file=0xc06aa995 ../../../netinet/tcp_timer.c, line=489) at ../../../kern/kern_mutex.c:635 #5 0xc0505a37 in _mtx_lock_flags (m=0xc072a76c, opts=0, file=0xc06aa995 ../../../netinet/tcp_timer.c, line=489) at ../../../kern/kern_mutex.c:333 #6 0xc05a1f10 in tcp_timer_rexmt (xtp=0xc3116164) at ../../../netinet/tcp_timer.c:489 #7 0xc051fea8 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:225 #8 0xc04fb802 in ithread_loop (arg=0xc16c1c80) at ../../../kern/kern_intr.c:540 #9 0xc04fa804 in fork_exit (callout=0xc04fb670 ithread_loop, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:793 (kgdb) I have the core so I can run other commands if needed. This is new. Please contact me offline with a way to collect the kernel+core. BTW before that update to -current I was getting panics when I would insert or remove a card. Dhclient would end up being the process running and the kernel would crash in in_pcbconnect_setup when it did this check: if (ro-ro_rt !(ro-ro_rt-rt_ifp-if_flags IFF_LOOPBACK)) The ro-ro_rt-rt_ifp would be pointing the the ifp that was gone and panic. This one wasn't to bad except for crashing during a suspend/ resume sequence the other panic is happening randomly through the day. I have a line on this one and should have a fix soon. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
hostap+wi
I'm trying to pin down a problem where prism-based AP's constructed from wlan code and the wi driver don't work right. I'm seeing the following when a client/station trys to associate with an AP of this sort: client AP AUTH- - AUTH response ASSOC - - PROBE response - ASSOC response and then the client retries again ad infinitum. If you've got an AP running with recent source and a wi card please contact me. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_auth.o, undefined reference to ieee80211 functions
I'm having trouble getting a kernel with the Atheros driver to compile. I get the following error during linking: You need to patch some files to use the wlan code in sys/net80211 and not the code in sys/net. I will either commit the remaining changes or post a patch that contains the changes soon. I'm hoping to resolve the problem. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: new wlan code
I've committed the changes to switch the 802.11 support over to the code in sys/net80211. The new code is significantly different as it has been revamped to support multi-mode devices, add fine-grained locking, and support more of the 802.11 protocol. Drivers that depend on the code have been changed (e.g. wi). Drivers and programs that included net/if_ieee80211.h have been changed to the new scheme. Ideally you should see no regressions but beware of changes to the wi driver. Please report any new problems to me (not Warner). As a byproduct of these changes you can now use the Atheros driver w/o patching the tree. man ath(4) for info on the driver. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: Atheros 802.11 support
My work to support the Atheros 802.11 hardware is now entirely in the tree and enabled for use. The ath driver supports all Atheros hardware devices and makes FreeBSD the first open source system to support 802.11a and 802.11g*. There are still issues with the driver. man ath(4) for details. Sam *First by a few days--there is also a Linux version of this software available at http://sourceforge.net/projects/madwifi/. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Support for XFS in FreeBSD?
[cross-posting removed] Note: SCO is suing people who have touched Linux code with code from commercial OS's derived from System V. SGI's IRIX, from which XFS comes, is derived from System V, so there is some legal risk involved to anyone doing a port: SCO may sue you, too. I don't know if this effects the projects previous statements. True, this is a danger. There was a certain amount of similarity in XFS sources between FreeBSD kernel internals and Irix interfaces which arguably can be traced to common Unix roots of both systems. SCO might consider XFS theirs some day :) Ignore this FUD. SGI's XFS implementation is all new work. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error with Atheros chipset.
[Not sure about cross-posting but I'll leave it for now.] I've recompiled -CURRENT with support for atheros cards. I have two cards, one PCI(desktop) and one PCMCIA(laptop). Both are Proxim 11a/b/g combo cards with AR5212 chips. The cards are recognized fine. pciconf -l -vv shows: [EMAIL PROTECTED]:4:0: class=0x02 card=0x0a6014b7 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' class= network subclass = ethernet dmesg shows: ath0: Atheros 5212 mem 0x4000-0x4000 irq 5 at device 4.0 on pci2 ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 802.11 address: 00:20:a6:4c:ef:62 I've tried every possible example combo from man ath(4), i.e: ifconfig ath0 inet 192.168.0.1 netmask 0xff00 ssid my_net mode 11a mediaopt adhoc to create adhoc network. The problems start when I try to configure them with ifconfig. Every attempt result in following errors and lack of communication between them: ar5212AniGetCurrentState: Out of space in ANI table for channel 5785/0x140! ar5212AniGetCurrentState: Out of space in ANI table for channel 5805/0x140! ar5212AniGetCurrentState: Out of space in ANI table for channel 5825/0x140! ar5212AniGetCurrentState: Out of space in ANI table for channel 5785/0x140! ar5212AniGetCurrentState: Out of space in ANI table for channel 5805/0x140! etc etc. Any idea how to fix that and how to make the cards work? A simple ping would make my day :) You're stuck for now. This is a bug in the HAL that I've got fixed but is taking forever to verify correctness. With luck I'll have new stuff committed this week (but that's what I thought last week...). Sorry, it was my bad :( Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lucent IBSS mode doesn't work in -CURRENT?
I have a few Orinoco cards, and they 'work' in both ad-hoc and infrastructure mode. However with dhclient it gets tricky, because it will only work the first time dhclient assigns an address to the card. Whenever it tries to refresh it or whatever, I start getting those timeout and busy bit errors, and network connectivity drops. This usually happens within a few minutes or latest after 30 minutes or so - probably depending on your dhcpd/dhclient configuration. Configuring a static IP lets me use the card, and it seems stable. I recently tested adhoc mode 'cuz Greg said it didn't work and verified it worked for me with all my cards: Prism, Lucent (6.something firmware), and Atheros (5211, and 5212 in 11b talking to the Lucent and Prism cards). I did not use dhclient. Everything was statically configured. I am really glad someone else is seeing this, perhaps it can get fixed some day :) Oh and btw.. Get the *latest* firmware onto all your cards. That is essential for anything to work right at all.. I'm stuck upgrading because my Windows 2K Lucent driver is too out of date for any of the newer firmware revs. I believe I need at least rev 6.1 of the Win2K driver to run any of the firmware update tools. How did you upgrade your firmware? If anyone has the bits+pieces to rev firmware I'd like it so I can test the wi driver w/ different firmware revs. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 driver
Verify you have the latest HAL using sysctl hw.ath The version should be 0.9.5.3 or better (can't remember if I committed .4 or .3). Shouldn't that be 0.9.5.2? I run the latest current, and hw.ath.hal.version is 0.9.5.2. You're right; I committed a slightly older version to FreeBSD than to Linux. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: MADWIFI Question
Sorry for the lame post, but here goes. Madwifi works fine on linux laptops, but need support in Freebsd. The post I read I seem to remember saying that it (madwifi) was native in current? I took a new hd in a Dell laptop. Did an ftp install of 5.1 stable. Cvsuped to current for source and ports. Did a buildworld, recompiled the kernel and did a installworld. Everything seemed to work fine. Stuck in a 11a card (works fine with madwifi in linux) and looked for an ath0 interface. Found nothing. Looked in modules and found the ath_hal module. Installed it with kld, but there's got to be another supporting module somewhere for the interface? The answer isn't to grab the ported linux tarball off of sf.net, is it? If it is, I am really missing something here. Any and all help would be great. Either config your kernel with: device ath device wlan device ath_hal or build these as modules, install them, and do kldload ath Module dependencies will do the rest. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: M_NOTIFICATION in sys/mbuf.h?
While trying to port the SCTP-KAME code to CURRENT, I noticed that M_NOTIFICATION is missing from sys/mbuf.h in CURRENT, but it is present in the KAME version of this file. Any reason not to apply this patch? --- sys/sys/mbuf.h.orig Sat Sep 13 19:34:07 2003 +++ sys/sys/mbuf.h Sat Sep 13 19:34:14 2003 @@ -164,6 +164,8 @@ #defineM_FIRSTFRAG 0x1000 /* packet is first fragment */ #defineM_LASTFRAG 0x2000 /* packet is last fragment */ +#define M_NOTIFICATION 0x8000 /* notification event */ + /* * External buffer types: identify ext_buf type. */ I don't know what M_NOTIFICATION is used for but if it's applied sparingly it might be better to use an m_tag instead. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 driver
I just have to ask: is this in any way related to the a/b/g network card in my laptop that shows up as: [EMAIL PROTECTED]:3:0: class=0x028000 card=0x00011028 chip=0x432414e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' class= network if (broadcom == atheros) use ath driver; else ask broadcom for specs on their hardware. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS UP: new wi driver
I just committed a new version of the wi driver. This driver is very different in that it depends on a common core implementation of the 802.11 state machine and mgmt protocols. There should be no visible differences (for now) between the old driver and the new but beware. If you encounter problems please contact me (or Warner). This work is the first step towards significant improvements in the wireless support. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new wi driver
Sorry, for the new wi driver you need to add: device wlan to your config files. This probably belongs in UPDATING. Sam - Original Message - From: Matt Haught [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 9:59 PM Subject: Re: HEADS UP: new wi driver I got this when trying to buildkernel with a cvsup from ~11:30PM EST Jan 15. ---snip--- cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werro r vers.c linking kernel if_wi.o: In function `wi_attach': if_wi.o(.text+0x74d): undefined reference to `ieee80211_rate2media' if_wi.o(.text+0x88d): undefined reference to `ieee80211_ifattach' if_wi.o: In function `wi_detach': if_wi.o(.text+0x943): undefined reference to `ieee80211_ifdetach' if_wi.o: In function `wi_stop': if_wi.o(.text+0x14d5): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_start': if_wi.o(.text+0x1904): undefined reference to `ieee80211_encap' if_wi.o(.text+0x1942): undefined reference to `ieee80211_find_node' if_wi.o(.text+0x19b8): undefined reference to `ieee80211_wep_crypt' if_wi.o: In function `wi_watchdog': if_wi.o(.text+0x1e74): undefined reference to `ieee80211_new_state' if_wi.o(.text+0x1e8c): undefined reference to `ieee80211_watchdog' if_wi.o: In function `wi_ioctl': if_wi.o(.text+0x22f9): undefined reference to `ieee80211_ioctl' if_wi.o: In function `wi_media_change': if_wi.o(.text+0x23af): undefined reference to `ieee80211_media2rate' if_wi.o: In function `wi_media_status': if_wi.o(.text+0x256c): undefined reference to `ieee80211_rate2media' if_wi.o: In function `wi_sync_bssid': if_wi.o(.text+0x2666): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_rx_intr': if_wi.o(.text+0x2a5d): undefined reference to `ieee80211_input' if_wi.o: In function `wi_info_intr': if_wi.o(.text+0x2faf): undefined reference to `ieee80211_new_state' if_wi.o: In function `wi_get_cfg': if_wi.o(.text+0x3ad0): undefined reference to `ieee80211_cfgget' if_wi.o: In function `wi_set_cfg': if_wi.o(.text+0x40e5): undefined reference to `ieee80211_cfgset' if_wi.o: In function `wi_dump_pkt': if_wi.o(.text+0x5588): undefined reference to `ieee80211_dump_pkt' *** Error code 1 Stop in /usr/obj/usr/src/sys/ICY. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. mars# uname -a FreeBSD mars.testserver.net 5.0-CURRENT FreeBSD 5.0-CURRENT #24: Wed Jan 15 10:13:14 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ICY i386 If you need more info, feel free to ask. Matt _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new wi driver
On Thu, 16 Jan 2003, Sam Leffler wrote: ... to your config files. This probably belongs in UPDATING. NB the new wi(4) is probably also an issue for ports/net/bsd-airtools, to be resolved or documented before MFC. (copied maintainer) Why, did they not work/build after the commit? I didn't try all the ports that depend on the driver but the API (ioctls) should be unchanged except for the AP scanning stuff which is why I had to make mods to wicontrol. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new wi driver problems
A couple things regarding this new wireless driver - the wepkey option to ifconfig no longer seems to work; I get a SIOCS80211: Invalid argument. Secondly and more importantly, even when the wepkey is set via wicontrol, I can't seem to get any connectivity at all anymore. I fixed the setting of the wepkey by ifconfig but still have to track down why wep doesn't work (looks like xmit is fine but rcvd packets are being dropped by the card). FWIW you can enable debugging info for the 802.11 state machine with: sysctl debug.ieee80211=1 and get 802.11 frames by the driver printed with: ifconfig wi0 debug link2 Setting the sysctl value to 1 will give more verbose output which is unlikely to be useful. I have to commit some mods to tcpdump and bpf before you can use tcpdump to tap packets at the 802.11 link layer. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new wi0 slowness
I have noticed the following with the new wi0. I have the 802.11 connection between my laptop running XP and my current box running as a hostap. I also have a IPSec tunnel between the current box and the laptop, but I don't think this could be causing the problems. While transferring files from samba on the current box to the laptop I got the following results: With the old wi0: average 5120.3Kb/s peak 7326.5Kb/s With top -S 85% interrupt cpu - 58% swi1: net 21.8% irq10: wi0 With the new wi0: average 877.0Kb/s peak 902.4Kb/s With top -S 11.6% interrupt cpu - 9% swi1: net 0.88% irq10: wi0 I am also getting hundreds of: wi0: tx failed, retry limit exceeded with the new driver under heavy load. In addition it get many random disconnects which I would not notice, except AIM gets logged out. I don't think it has anything to do with the ipsec tunnel as the SAD entries are still there and it only happen with the new wi kernel. I have tried FAST_IPSEC and it does work with the new wi0 driver where it would temporarily lock up the machine with the old one, but I'm not using it since I thought it may be causing a problem and its ends up that it did not make a difference. I am going to try it later without IPSec just to be sure. Ignore IPsec; in fact don't configure it. I just changed the default setting of kern.wi_txerate to 0 to suppress printing tx error messages; do likewise: sysctl kern.wi_txerate=0 This is the way the old driver worked. Under the new driver my card which sold as a D-link DWL-520 2.4GHz Wireless PCI card is shown as a: dmesg wi0: Intersil Prism2.5 mem 0xe600-0xe6000fff irq 10 at device 15.0 on pci0 wi0: 802.11 address: 00:05:5d:fa:0e:b0 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.0.7), Station (1.3.6) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps I can change the media through ifconfig to DS/11Mbps or whatever, but it does not seem to change anything other then ifconfig will show media: IEEE 802.11 Wireless Ethernet DS/11Mbps hostap (DS/2Mbps hostap) rather then autoselect. The same slowness is still there. wicontrol shows it as having a TX rate (actual speed) of 2 no matter what. I can set the (selection) to anything such as 11, and again no change in the throughput or anything. I have also changed things with the old driver, and nothing changed with the throughput, and it also shows the (actual speed) as 2 but I get higher throughput. It seems to kinda have a mind of its own. Well if you need anymore info, just drop me a message. I enabled debugging for wi0 as a earlier post showed, but I had no idea what I was looking at :). You've said nothing about how your interface is configured except that it's running in hostap mode; start by giving the output of ifconfig wi0. The output of netstat -i might indicate the error rate on your Dlink card (tx errors show up as output errors). Finally, you may want to try different station firmware in your Dlink card. I run 1.4.9 in my Senao (Prism 2.5) cards with good success. I don't recall whether there were issues with 1.3.6 (I know some of the intermediate versions had problems especially in hostap mode). You can get 1.4.9 firmware at http://www.netgate.com/support/prism_firmware/. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: how to update Prism-2.5 firmware? (was: Re: new wi0 slowness)
On Sun, Jan 19, 2003 at 07:46:11PM -0800, Sam Leffler wrote: Finally, you may want to try different station firmware in your Dlink card. I run 1.4.9 in my Senao (Prism 2.5) cards with good success. I don't recall whether there were issues with 1.3.6 (I know some of the intermediate versions had problems especially in hostap mode). You can get 1.4.9 firmware at http://www.netgate.com/support/prism_firmware/. Sam, could you briefly explain the procedure for updating the firmware? I have several D-Link 650 cards which are showing problems while doing big transfers with WEP turned on (4.7-RELEASE), and I expect that a new firmware may solve this problem. I use a windows-based tool from Intersil that came with my card. I suspect you can download it from places on the web. Beware however that it is possible to mangle a card doing this--I had a laptop lockup on me while updating one card and had to RMA the card. I take no responsibility for any cards you toast! :-) Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: new wi0 slowness
Alright, I have disabled IPSec and updated the firmware to read: wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) sysctl kern.wi_txerate=0 gives: sysctl: unknown oid 'kern.wi_txerate' Sigh, I screwed up the sysctl's--just fixed it. This one is now located at hw.wi.txerate and must be set to -1 to turn off the msgs. I've done that for the code in tree. I reran my test and I am still transfering at ~870Kb/s. netstat -i -I wi0 shows this after the transfers: NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll wi01500 Link#1 00:05:5d:fa:0e:b029847 05333159 557 wi01500 192.168.168 wifi59 -52085 - - Here is something odd that I found: I set the mediaopt to adhoc in rc.conf and rebooted again, and here is what I found (I was not sure how to clear the counters that you wanted in netstat so I rebooted): The same files transfer at ~5600Kb/s, so its back where it was with the old driver. Here is netstat -i again after this run: NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll wi01500 Link#1 00:05:5d:fa:0e:b027497 05123013 452 wi01500 192.168.168 wifi61 -51200 - - So there are 4 times more Oerrs in hostap mode (59 to 13), and just a few more collisions. I almost forgot, here are ifconfig wi0 outputs: wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.168.1 netmask 0xff00 broadcast 192.168.168.255 ether 00:05:5d:fa:0e:b0 media: IEEE 802.11 Wireless Ethernet autoselect hostap (DS/2Mbps host ap) status: associated ssid HaughtDom 1:HaughtDom stationname FreeBSD WaveLAN/IEEE node channel 3 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 and with adhoc: wi0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.168.1 netmask 0xff00 broadcast 192.168.168.255 ether 00:05:5d:fa:0e:b0 media: IEEE 802.11 Wireless Ethernet autoselect adhoc (DS/11Mbps adho c) status: associated ssid HaughtDom 1:HaughtDom stationname FreeBSD WaveLAN/IEEE node channel 3 authmode OPEN powersavemode OFF powersavesleep 100 wepmode OFF weptxkey 1 I can also start a transfer test in hostap mode (~670Kb/s) and use ifconfig to switch over to adhoc, and after a second or two while my laptop switches over, it transfers at ~5600Kb/s. I don't use wicontrol at all. My transfer test is just 67MB of mp3s off the fbsd machine. If you need any more info, just drop me a message. I have no answer for you. There's just not that much difference between adhoc and hostap mode to explain this. If you were using wep and it was being offloaded to the host I could understand a noticeable difference in performance. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new wi driver
: dstumbler breaks; on startup it reports : unable to ioctl device socket: Input/output error. As root or no? I have a rebuilt system finally that I could test this against and I'm actually getting a different error message on startup of dstumbler: error: unable to ioctl device socket: Invalid argument From ktrace: 43042 dstumbler CALL sigaction(0x12,0x280b5850,0) 43042 dstumbler RET sigaction 0 43042 dstumbler CALL socket(0x2,0x2,0) 43042 dstumbler RET socket 3 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) 43042 dstumbler RET ioctl 0 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) 43042 dstumbler RET ioctl 0 43042 dstumbler CALL ioctl(0x3,SIOCGIFGENERIC,0xbfbff4b0) 43042 dstumbler RET ioctl 0 43042 dstumbler CALL ioctl(0x3,SIOCSIFGENERIC,0xbfbff4c0) 43042 dstumbler RET ioctl -1 errno 22 Invalid argument 43042 dstumbler CALL sigaction(0x12,0x280b5838,0x280b5850) 43042 dstumbler RET sigaction 0 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) 43042 dstumbler RET poll 0 43042 dstumbler CALL poll(0xbfbff3e8,0x1,0) 43042 dstumbler RET poll 0 43042 dstumbler CALL write(0x1,0x806,0x5e) 43042 dstumbler GIO fd 1 wrote 94 bytes \^[[52;22H\^[[34m\^[[1m[\^[[31m error: unable to ioctl device socket: \ Invalid argument \^[[C\^[[39;49m\^[[m\^O dstumbler uses WI_RID_SCAN_REQ to initiate a scan for AP's. This required the application know whether it was talking to a prims/wavelan/symbol card so was replaced by WI_RID_SCAN_APS which provides a device-independent interface. I changed wicontrol to deal with this; it would be good if dstumbler did likewise. Otherwise I can look at adding a backwards compatibility entry for WI_RID_SCAN_REQ. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-STABLE Roadmap
About benchmarks... FWIW, the reiserfs people were excited about SCO's release of AIM: http://caldera.com/developers/community/contrib/aim.html but the announcement went rather unnoticed in freebsd-fs. Thanks. I've worked with AIM. Wasn't aware it had been released. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-STABLE Roadmap
At 4:36 PM -0800 2003/02/13, Scott Long wrote: - the classic 'worldstone' - webstone - /usr/ports/www/webstone - Fstress - http://www.cs.duke.edu/ari/fstress - ApacheBench - /usr/ports/www/p5-ApacheBench - netperf - /usr/ports/benchmarks/netperf Are there any other benchmarks that are being considered? What about LMBench? RawIO? Bonnie++? Other disk benchmarks? Do we care about application-layer benchmarks for other protocols, such as SMTP, POP3, or IMAP? Just curious. Thanks! This can quickly turn into a bikeshed, but suggest ones. We're looking for good benchmarks. lmbench, rawio, and bonniee are rather micro in nature (not bad, just limited in their usefulness). Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-STABLE Roadmap
On Thursday 13 February 2003 11:28 pm, Sam Leffler wrote: At 4:36 PM -0800 2003/02/13, Scott Long wrote: - the classic 'worldstone' - webstone - /usr/ports/www/webstone - Fstress - http://www.cs.duke.edu/ari/fstress - ApacheBench - /usr/ports/www/p5-ApacheBench - netperf - /usr/ports/benchmarks/netperf Are there any other benchmarks that are being considered? What about LMBench? RawIO? Bonnie++? Other disk benchmarks? Do we care about application-layer benchmarks for other protocols, such as SMTP, POP3, or IMAP? Just curious. Thanks! This can quickly turn into a bikeshed, but suggest ones. We're looking for good benchmarks. lmbench, rawio, and bonniee are rather micro in nature (not bad, just limited in their usefulness). SpecFS (NFS ops/sec benchmark) List price on SPEC SFS97 R1 is $900. And my recollection is that it was involved to setup and run. Benchmarks must be unencumbered; be easy to setup+run by one person; and not require lots of equipment. For the most part we are looking for benchmarks that will help tune system performance; not generate press releases. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5-STABLE Roadmap
At 9:47 PM -0800 2003/02/13, Sam Leffler wrote: SpecFS (NFS ops/sec benchmark) List price on SPEC SFS97 R1 is $900. And my recollection is that it was involved to setup and run. $450 for educational organizations. Wouldn't the FreeBSD Foundation qualify? The point was that they cost $$$. Not an option for many developers. Benchmarks must be unencumbered; be easy to setup+run by one person; and not require lots of equipment. For the most part we are looking for benchmarks that will help tune system performance; not generate press releases. Some of the more interesting benchmarks take more hardware to properly run. They're not necessarily particularly hard to setup, but they do want client machines to be used to generate test load. Rick Jones had to use 20 client machines with netperf in order to find the limits of performance for Nominum Authoritative Name Server (ANS), and he works for HP. I think you need to decide just how thorough you want your testing to be. If it's all going to be just single people running benchmarks on single machines, I think that there are going to be a lot of things you may miss. I have this problem myself with the benchmarks I've been running in conjunction with the invited talks I did at LISA 2002 and BSDCon Europe 2002, and people have repeatedly called me to task on this issue. Benchmarks for tuning are frequently different in nature than benchmarks for comparing systems. When tuning or for regression testing you usually want something that's easy to setup and runs fast enough to give you results quickly. For comparisons you usually care more about things like coverage, how well it models real-world behaviour, etc. My point was that we're presently trying to identify good benchmarks to use in comparing performance between -stable and -current. But these must also be ones that we can use for tuning either by reducing the configuration or otherwise directing the activity. Microbenchmarks are valuable here and have already been heavily used. We're at the point where we need something that exercises the system on a bit larger scale. Eventually we'll get to the point where large-scale benchmarks are worth running. Note that these issues have nothing to do with single machine vs. multiple machines. Of course what we really need more than benchmarks are people to actually follow through on the results and fix the problems... Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: ipsec packet filtering change
This may affect your ipfw/ipf rules. If you are happy with the current behaviour then add IPSEC_FILTERGIF to your kernel config file. Sam - Original Message - From: Sam Leffler [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, February 22, 2003 4:47 PM Subject: cvs commit: src/sys/netinet ip_input.c src/sys/conf NOTES options sam 2003/02/22 16:47:07 PST Modified files: sys/netinet ip_input.c sys/conf NOTES options Log: Add a new config option IPSEC_FILTERGIF to control whether or not packets coming out of a GIF tunnel are re-processed by ipfw, et. al. By default they are not reprocessed. With the option they are. This reverts 1.214. Prior to that change packets were not re-processed. After they were which caused problems because packets do not have distinguishing characteristics (like a special network if) that allows them to be filtered specially. This is really a stopgap measure designed for immediate MFC so that 4.8 has consistent handling to what was in 4.7. PR: 48159 Reviewed by:Guido van Rooij [EMAIL PROTECTED] MFC after: 1 day Revision ChangesPath 1.1129+11 -0 src/sys/conf/NOTES http://cvsweb.FreeBSD.org/src/sys/conf/NOTES.diff?r1=1.1128r2=1.1129 1.374 +1 -0 src/sys/conf/options http://cvsweb.FreeBSD.org/src/sys/conf/options.diff?r1=1.373r2=1.374 1.226 +7 -0 src/sys/netinet/ip_input.c http://cvsweb.FreeBSD.org/src/sys/netinet/ip_input.c.diff?r1=1.225r2=1.226 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Errors with wireless
I'm getting a LOT of these. ether_input: drop bdg packet, bif 0x5 This was a stray debugging printf I forgot to remove. Update your system. wi0: tx failed, retry limit exceeded If this happens again show the output of sysctl hw.wi. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Errors with wireless
* De: Sam Leffler [EMAIL PROTECTED] [ Data: 2003-02-25 ] [ Subjecte: Re: Errors with wireless ] wi0: tx failed, retry limit exceeded If this happens again show the output of sysctl hw.wi. I get those constantly when doing e.g. an interactive FTP session. ([EMAIL PROTECTED]:~)10% sysctl hw.wi hw.wi.txerate: -1 hw.wi.debug: 0 Should I be tuning txerate or something? I blew it. The default setting of -1 was supposed to disable all tx error messages (a la the old driver) but instead caused all messages to be printed (no rate limiting). It looks like you need to do something like: sysctl hw.wi.txerate=99 to disable the error messages or set it to some other value N to get no more than N messages/second printed. I'll fix the code to set the default to a large number. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FAST_IPSEC and INET6
The commit message for src/sys/netipsec/ipsec.c r1.1 mentions that FAST_IPSEC and INET6 should not be used together. As far as I can tell from the commit log, nothing has changed that would negate that recommendation since the import. However, when compiling a -current (as of today) kernel with FAST_IPSEC and without INET6, there is some breakage (with -Werror). The prototype and definition of ipsec6_setspidx_in6pcb() are within #ifdef INET6 blocks (line 187 491), but the function is used on line 292, regardless of INET6. Thanks for pointing out the problem. I just committed a fix. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: trap in netisr...
I found on tty0 the following backtrace. I infer, because it died in malloc, that it has something to do with netisr problem. I had to copy it by hand. backtrace(c04b7645,4,1,0,c40be100) at backtrace+0x17 malloc(3c,c050fca0,4,c1531300,d67e6c78) at malloc+0x5b mtag_alloc(0,e,30,4,c151ac00) at mtag_alloc+0x2f ip6_addaux(c1531300,d6706cbc,c037b09c,c1531300,c151ac00) at ip6_addaux+0x59 ip6_setdstifaddr(c1531300,c151ac00,d6te6cbc,c02d2480,c057a254) at ip6_setdstifaddr+0x11 ip6_input(c1531300,0,c04c0a40,e9,c1513ac00) at ip6_input+0x78c swi_net(0,0,c04b672f,217,c15209ec) at swi_net+0x112 ithread_loop(c151f200,d67e6048,c04b65ac,35f,0) at ithread_loop+0x182 fork_exit(c02c95e0,c151f200,d67e6048) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip=0, esp=0xd67e6d7c, ebp=0 --- Fixed last night. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wi driver
* Alfred Perlstein [EMAIL PROTECTED] [030316 21:19] wrote:
um..
...
840 _FLAGS_OUTRANGE) {
841 WI_UNLOCK(sc);
842 return;
843 }
844 KASSERT((ifp-if_flags IFF_OACTIVE) == 0,
845 (wi_start: if_flags %x\n, ifp-if_flags));
846
847 memset(frmhdr, 0, sizeof(frmhdr));
What's up here?
It's a race, we shouldn't be inspecting the ifp without a lock.
I think this kassert should be removed.
Do you guys concurr?
Warner has this pending with some other fixes; perhaps he can accelerate
doing the commit? The assert is actually just bogus (if_start can be called
under certain conditions with IFF_OACTIVE set.
Sam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
system lockup: nfs server not responding 10 9 (tx driver bug?)
I have repeated problems where a machine running -current locks up while running make over an NFS mounted filesystem. The NFS server is an up to date -stable machine. When the lockup occurs I get a message: nfs server mumble: not responding 10 9 The filesystem is mounted r/w with no options. nfsiod's 0, 1, and 2 are in DL, 3 is in IL state. nfsiod 0 is sleeping on sbwait. The -current machine is up to date. 100 Mb/s Ethernet. tx driver. When the lockup occurs I can still login to the console but the network appears dead (no packets appear to pass). Looks like maybe a tx driver bug. Anyone seen this with other NIC's? Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: I can't compile GENERIC, please let's fix this
make cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wst rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extens ions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../. ./contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary =2 -ffreestanding -Werror ../../../netinet6/raw_ip6.c cc: Internal error: Illegal instruction (program cc1) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. *** Error code 1 ll raw_ip6.o -rw-rw-r-- 1 john src 441 Oct 9 16:34 raw_ip6.o Even leaves a truncated .o file around. Not sure if relevant but I was fighting a cpp0 SIGSEGV this morning. I gdb'd cpp0 and tracked it down to data structure partly filled with garbage. I couldn't tell if it was really a cpp0 bug or just memory getting trashed (possibly by the OS). I was eventually able to work around it modifying the source code. Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ip_output panics on recent -CURRENT
On Monday 03 November 2003 12:58 pm, Andrea Campi wrote: Hi, after updating my laptop to last sunday sources, it panics very often with one of two panics. Sam, any chance you might know what's up? Note that both panics seem (to my untrained eye at least) to be related to spammed route entry structures. The second one in particular looks suspicious, with all those null arguments... I've been trying to recreate these panics w/o luck and reports so far have not pvoded me with enough info to work up any real clues. I've got one vmcore for something potentially similar and was about to look at it. The problem appears to be caused by someone reclaming routing table entries while they are in use. This would likely be a reference counting problem. You didn't provide any information about system kernel config or hardware config. Both are important. You don't indicate when last sunday is; is that 11/02? Did you get my recent commit to in_rmx.c that was last night and fixed a reference counting problem (but which would probably not affect you)? Are you running with WITNESS and INVARIANT? If not, do so. Have you tried to identify something that makes the panic happen? (e.g. ping as opposed to using ssh, as opposed to NFS over UDP, etc.) Have you tried setting debug.mpsafenet=0? Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: MPSAFE networking stuff disabled for now
I've disabled the MPSAFE operation of the network drivers. I was trying to commit only part of the work to be move Giant up in the networking code but it appears that's not possible. I'll wait for things to stabilize before trying again. Sam Index: subr_bus.c === RCS file: /home/ncvs/src/sys/kern/subr_bus.c,v retrieving revision 1.135 retrieving revision 1.136 diff -u -r1.135 -r1.136 --- subr_bus.c 29 Oct 2003 18:29:50 - 1.135 +++ subr_bus.c 4 Nov 2003 02:01:42 - 1.136 @@ -25,7 +25,7 @@ */ #include sys/cdefs.h -__FBSDID($FreeBSD: src/sys/kern/subr_bus.c,v 1.135 2003/10/29 18:29:50 sam Exp $); +__FBSDID($FreeBSD: src/sys/kern/subr_bus.c,v 1.136 2003/11/04 02:01:42 sam Exp $); #include opt_bus.h @@ -2138,7 +2138,7 @@ * XXX disable INTR_MPSAFE in network drivers without * XXX recompiling--in case of problems. */ -int debug_mpsafenet = 1; +int debug_mpsafenet = 0; TUNABLE_INT(debug.mpsafenet, debug_mpsafenet); SYSCTL_INT(_debug, OID_AUTO, mpsafenet, CTLFLAG_RW, debug_mpsafenet, 0, Enable/disable MPSAFE network support); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: mtx_lock() of spin mutex in ip_output.c
On Friday 07 November 2003 12:54 pm, Steve Kargl wrote: On Fri, Nov 07, 2003 at 11:31:45AM -0800, Steven G. Kargl wrote: I have a Dell 4150 laptop using dhcp and ntpd on the xl0 interface. I did ifconfig xl0 down and received the following panic (hand transcribed :-( ). panic: mtx_lock() of spin mutex (null) @ /usr/src/sys/netinet/ip_output.c:266 Stack backtrace: backtrace() panic() panic: process 414(ntpd):2 Giant but isn't blocked on a mutex In ddb I get, Debugger() panic() propagate_priority() _mtx_lock_sleep() _mtx_lock_flags() softclock() ithread_loop() fork_exit() fork_trampoline() I have a crash dump and kernel.debug if further info is need Make sure you have rev 1.250 of ip_input.c. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [CURRENT] Panic in -CURRENT of 20031105
On Friday 07 November 2003 07:49 am, Jaco H. van Tonder wrote: Hi All, I get panics at random times of the day with -CURRENT from 20031105, with absolutely no load on the machine. The machine acts as a dial-up server/gateway/firewall for my local lan. I managed to get a coredump. The contents of the rt pointer passed to RTFREE() does really not look right to me. These in particular: rt_llinfo = 0xc0f95880 \220ǼÁ\200qùÀ rn_Key = 0xc1bcc7a0 0AùÀ8AùÀ Anyone got any ideas? This looks like the problem I fixed yesterday. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INPCB panic....
On Monday 10 November 2003 11:37 am, Larry Rosenman wrote: I removed my wi0 card (with DHCLIENT running), and got the following panic on a -CURRENT from yesterday: Thanks. Working on it... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INPCB panic....
On Monday 10 November 2003 02:19 pm, Ian Dowse wrote: In message [EMAIL PROTECTED], Sam Leffler writes: On Monday 10 November 2003 11:37 am, Larry Rosenman wrote: I removed my wi0 card (with DHCLIENT running), and got the following panic on a -CURRENT from yesterday: Thanks. Working on it... FYI, I've been using the following patch locally which seems to trigger the printf sometimes when wi0 is ejected. Without the patch, it used to dereference a stale struct ifnet and crash. I have an approx 1 week old kernel, so this particular problem may have been fixed already. Your fix looks fine; please commit. It mimics what ip_output does. But there still look to be basic races with device removal/ifnet destruction. For example, ip_output grabs an ifnet reference from the routing table entry and uses it w/o any locking for a rather long time. If the device gets yanked in the interim it seems like you could be left holding a bogus reference. Seems like the whole if_detach path needs a careful rework. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR in route.c
On Monday 10 November 2003 02:27 pm, Steve Ames wrote: On Mon, Nov 10, 2003 at 05:19:06PM -0500, Steve Ames wrote: New /usr/src from around 4:30PM EST: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: Make that two: Mon Nov 10 17:16:14 EST 2003 lock order reversal 1st 0xc6761890 rtentry (rtentry) @ /opt/src/sys/net/route.c:182 2nd 0xc668687c radix node head (radix node head) @ /opt/src/sys/net/route.c:565 Stack backtrace: lock order reversal 1st 0xc695a590 rtentry (rtentry) @ /opt/src/sys/net/route.c:744 2nd 0xc06da034 route cache (route cache) @ /opt/src/sys/netinet/ip_input.c:348 3rd 0xc695a690 rtentry (rtentry) @ /opt/src/sys/netinet/ip_input.c:352 Stack backtrace: These go away with forthcoming changes (so I've ignored them). Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic related to in_output.c
On Tuesday 11 November 2003 08:40 am, Steve Ames wrote: Code from yesterday evening (11/10 around 5PM EST). Just updated this morning. I saw no updates to ip_output.c but there were changes to a couple of other files in sys/netinet so figured I'd give it a whirl... panic: mutex inp not owned at /usr/src/sys/netinet/ip_output.c:218 cpuid= -; Debugger(panic) Stopped atDebugger+0x55: xchgl %ebx,in_Deubbger,0 db I'll commit the fix today. I was waiting for testing feedback from the 1st person that tripped the assertion... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheros (ath) driver - media option
On Tuesday 11 November 2003 01:52 pm, Johann Hugo wrote: Hi I've just started playing with some D-link DWL-AG520 PCI adapters with the Atheros 5212 chipset. The one adapter is configured in hostap mode, and the other one as a client. When I set the media option to a lower speed that the maximum, then it only works for the adapter in client mode, but it does not seem to work for the adapter that is in hostap mode. I've tried it on 11a, 11b and 11g at all the supported rates, but the tx speed always defaults to the maximum for the selected mode. I'm using -current from September 07th. Something more recent might be a good idea. e.g. ifconfig ath0 media DS/1Mbps mode 11b mediaopt hostap ssid ath101 channel 11 wicontrol ath0 NIC serial number: [ ] Station name: [ atheros.icomtek.csir.co.za ] SSID for IBSS creation: [ ath101 ] Current netname (SSID): [ ath101 ] Desired netname (SSID): [ ath101 ] Current BSSID: [ 00:05:5d:95:f0:04 ] Channel list: [ ffe ] IBSS channel: [ 11 ] Current channel:[ 11 ] Comms quality/signal/noise: [ 0 8 0 ] Promiscuous mode: [ Off ] Intersil-Prism2 based card: [ 1 ] Port type (1=BSS, 3=ad-hoc):[ 6 ] MAC address:[ 00:05:5d:95:f0:04 ] TX rate (selection):[ 1 ] TX rate (actual speed): [ 11 ]-- RTS/CTS handshake threshold:[ 2312 ] Create IBSS:[ Off ] Access point density: [ 1 ] Power Mgmt (1=on, 0=off): [ 0 ] Max sleep time: [ 100 ] WEP encryption: [ Off ] TX encryption key: [ 1 ] Encryption keys:[ ][ ][ ][ ] Is this correct, or should the tx rate (actual speed) be the same as the media setting ? Not sure what you're trying to accomplish by setting the media when operating in hostap mode. It should be ignored, but I'm not sure exactly what will happen. Locking the tx rate on the client side makes more sense and should be honored correctly. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: atheron driver and netgear WG511T
On Thursday 13 November 2003 06:19 am, Eric Anderson wrote: hi, i get this when inserting my Netgear WG511T card into my laptop: ath0: Atheros 5212 mem 0x8801-0x8801 irq 11 at device 0.0 on cardbus0 ath0: unable to attach hardware; HAL status 13 device_probe_and_attach: ath0 attach returned 6 the ath manpage says that this chip should be supported... any ideas? Do you have the: device ath_hal line in your kernel config? Bernhard and I worked out that his card has a new 2112 radio that's not yet supported by the HAL. I hope to have something to try next week. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
