Re: poor ethernet performance?
On 16-Jul-99 Matthew Dillon wrote: > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. > > -Matt > Matthew Dillon And you seen the nice square waves of 100Mb or !Gb ether on a line then? The techniques used for transmitting 100Mb/s down copper are certainly not digital. Pulse shaping, line estimation, ISI removal are all analogue! The cable itself is less improtant than the impedance matching at connectors and bends in the cable. Duncan --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On 17-Jul-99 Matthew Dillon wrote: > > Obviously you don't get square waves going down the wire - But it is > still a digital communications protocol. > > -Matt However the physical layer, i.e. the cable, is analogue and the discussion was about cables. To carry your reasoning a bit further - a digital cellular phone system is not an RF/Wireless system because the data is digital. I hope we agree that it is! Duncan --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On 23-Aug-99 Cillian Sharkey wrote: > > yes perhaps an /etc/periodic.conf would be good, to control the level > of verbosity and/or set options for each script ? I've hacked periodic here so that the scripts can be turned off with knobs in a periodic.conf file. This would simplify customizing new installitions - one no longer needs to add exit 0 to scripts. Duncan --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help with network driver development
Hi all
I've successfully ported the NetBSD if_ray (Webgear PCCard Wireless LAN)
driver to RELENG_3 but have realised that the driver has a bit of a
problem and I would like some advice on the best way to fix it.
The card doesn't present a register set but uses a mailbox type system
to set up most things. The driver fills in a struct in shared ram, pings
the card that then completes the command and interrupts when finished.
The problem is that the driver returns to userland before the
command (e.g. update to multicast list via an ioctl) actually
completes. The symptom is everything going belly up when something
does:
#!/bin/sh
ifconfig ray0 inet 192.168.247.32
ifconfig ray0 inet 192.168.247.33
(a bit like dhclient) because the card cannot cope with being told to
update (for example) the multicast list until it has finished the
previous update.
I have a number of alternatives to fixing all this within the driver
and sleeping until the user command has completed and I'll go for the
most straight forward.
My question to all the network driver gods is how best to serialise
access to the driver to different userland processes? I want to ensure
that two different processes don't try and access the card
simultaneously and muck each other up.
Am I right in assuming that the ioctl is the only user land entry point
to a network driver?
Is something like this sufficient (and right) for ioctl entry?
ray_ioctl(...)
{
...
s = splimp();
switch (command) {
case SIOCADDMULTI:
case SIOCDELMULTI:
/* Get exclusive lock */
while (1) {
if (!softc->lock) {
softc->lock++;
break;
}
rv = tsleep(softc->lock, 0|PCATCH, "rayexl");
if (rv)
return (rv);
if ((ifp->if_flags & IFF_RUNNING) == 0)
return (EIO);
}
/* Run command and sleep until completed */
ray_update_mcast(sc);
rv = tsleep(softc->lock, 0|PCATCH, "raycmd");
/* Release exclusive lock */
softc->lock = 0;
splx(s);
wakeup(softc->lock);
return (rv);
break;
...
}
}
The last released version of the driver (and raycontrol like
wicontrol(8)) is available at
http://www.ragnet.demon.co.uk/raylink.tar.gz
this works well for tx and rx and "slow" changes to the device
parameters. I can make available later versions with more debugging of
the above problems if needed.
Duncan
PS. Until pccard in RELENG_4 allows access to both attribute and common
memory (a bit like if_xe) the driver won't be advanced to > RELENG_3 :-(
PPS. This is my first driver.
---
Duncan Barclay | God smiles upon the little children,
[EMAIL PROTECTED] | the alcoholics, and the permanently stoned.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Help with network driver development
Hi Mike, On 11-Apr-00 Mike Smith wrote: > > Sorry that this is off-list - I'm blocked by the DUL at the moment, but > please copy your replies there. > >> I've successfully ported the NetBSD if_ray (Webgear PCCard Wireless LAN) >> driver to RELENG_3 but have realised that the driver has a bit of a >> problem and I would like some advice on the best way to fix it. > > Heh. I have a small pile of these cards and I am _itching_ to see the > driver on -current. Consider me at your disposal. 8) Thanks! Where can I go to understand NEWBUS (for later)? I've managed to get 170kB/s ftp to/from Windows and FreeBSD boxes. 170kB/s is a maxed out 2Mb/s IEEE 802.11 link, so I'm reasonably happy. Range isn't bad at about 70m indoors-outdoors and might be a little better if you have the firmware that supports antenna diversity. I might also put in something that turns down the data-rate as the received signal power drops (by slowing the data-rate one increases the signal to noise ratio and range should increase). >> The problem is that the driver returns to userland before the >> command (e.g. update to multicast list via an ioctl) actually >> completes. > > This is actually really easy to handle; you want to use a similar > architecture to a block device. > > Set up a command queue. To submit a command, you do this: [code snipped] Thanks, I was planning on doing something like that but hadn't got it fully worked out. >> My question to all the network driver gods is how best to serialise >> access to the driver to different userland processes? I want to ensure >> that two different processes don't try and access the card >> simultaneously and muck each other up. > > The command queue approach is very simple, easy to debug, and is widely > used in our codebase already. I spend a lot of time looking at other > peoples' drivers (mostly in Linux space) and I've seen a lot of people > trying to solve this problem in a lot of very wrong ways. Save yourself > the trouble. 8) The Linux driver for these cards has calls to a function named spinlock() all over the place - I really hope it doesn't do what's on the box. One of my testers reckons my driver is about twice as fast for random receive/transmit patterns, and I have't implemented chaining tx packets yet because of another race. >> Is something like this sufficient (and right) for ioctl entry? > > It's probably sufficient, but much more complex than necessary. Be very > careful with using PCATCH too - your logic will need to deal with > handling a completed command after the submitter has gone away (the > queued command approach works OK here as long as you remember to dequeue > the command - remember that when tsleep returns you are back at splnet()). I like reusing the queue idea here (with another queue I presume) to serialise t he access. I see what you mean about PCATCH, is it easier to not bother about using it? >> PS. Until pccard in RELENG_4 allows access to both attribute and common >> memory (a bit like if_xe) the driver won't be advanced to > RELENG_3 :-( > > So I understand. Grr. Now that Warner's fried his iOpener, maybe he'll > get back to this. 8) It looks like there is a way to jury rig something for RELENG_4 but by hacking pccard.c to export a few functions. I'll also need to get my head around NEWBUS. Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Help with SIOCADDMULTI, IFF_ALLMULTI and IFF_PROMISC
Hi In my seemingly never ending quest to get a correctly functioning driver for the WebGear wireless LAN cards I need some advice on how to DTRT with multi-casts. The WebGear cards can be programmed with 16 multicast addresses, from these the NIC itself generates hashes. So what should I do when there are more than 16 mutli-cast addresses? Some drivers appear to set ALLMULTI, others set a promiscuous mode. Some of the promiscuous mode drivers do some filtering before sending packets to BPF/ether_input and other don't. What should I do when I see ALLMULTI? Help! Thanks, Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OT] Finding people with GSM phones (was Re: GPS heads up )
On 06-May-00 Mike Smith wrote: >> > With one tower, you're down to describing an arc along which >> > the phone is probably located; still pretty good when it comes to finding >> > someone. >> >> He seemed to imply that they could get it within 25m, even with one >> phone. Like I said, I don't understand how, but I didn't question his >> ability. Plus, he knows alot more about the stuff than I do. http://www.cursor-system.com/ Cambridge positioning Systems have developed some technology to do this for GSM. Positioning isn't built into the GSM system - yes they can tell what sector of a base station a mobile is in but much more than that is difficult. The other cells a mobile is aware of aren't aware of the mobile. Duncan --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Getting an aligned IO port
Hi How can get a 16byte aligned ISA IO port from the resource allocator? I need this to get if_xe working for Realport cards. This aspect of the driver is nothing to do with Warner's changes to PCCard. Thanks Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Getting an aligned IO port
On 08-May-00 Duncan Barclay wrote: > Hi > > How can get a 16byte aligned ISA IO port from the resource allocator? I need > this to get if_xe working for Realport cards. It's okay I've worked it out and got RealPorts (well mine) working in -current again. Patches mailed to -mobile. Duncan --- ____________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting an aligned IO port
On 08-May-00 Warner Losh wrote: > In message <[EMAIL PROTECTED]> Duncan Barclay > writes: >: How can get a 16byte aligned ISA IO port from the resource allocator? I need >: this to get if_xe working for Realport cards. >: >: This aspect of the driver is nothing to do with Warner's changes to PCCard. > > I'm going to have to commit the byte alignment stuff that was posted a > while ago committed. Thanks - I've just worked a less elegant way out. It works but yours is better. Another patch in a moment! So does re-allocating a resource clear the allocation for the old range? Duncan --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Getting an aligned IO port
On 08-May-00 Warner Losh wrote: > In message <[EMAIL PROTECTED]> Duncan Barclay > writes: >: It's okay I've worked it out and got RealPorts (well mine) working in >: -current >: again. >: >: Patches mailed to -mobile. > > Cool. I'll commit them soon. Any chance these will work with the > 33.6 version of the card? Should do as all I've done is "newbusified" the old hacks that were needed to turn on the ethnernet. > Warner --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Algorithm used to delete part of a file
On 29-May-99 Zhihui Zhang wrote: > > Thanks for your valuable information. This explains why I have not found > any routines in the files under /ufs/ffs and /ufs/ufs that re-organize the > on-disk image of a file in that way. If a middle part of a file is > deleted, then all the remaining part of the file must be read by an editor > (such as vi) and written out to another place before the file length is > truncated. This algorithm seems to be not very efficient. But disk is not > like memory, where we can simply modify pointers to point to new locations > easily, I guess there may be no better way to do this. If you have any > ideas about why this is not done by the filesystem itself, please let me > know. Primarily the file system is a "block" orientated storage media where a "block" is the fragment size or a file system block. Addressing in the filesystem is done on a block by block basis. As each block is a number of bytes we cannot use byte addressing to simply move pointers around. If you find the papers written by Rob Pike on the editor "Sam" undr Plan-9 he goes into a lot of detail about algorithms for removing/adding bytes into a storage area with block addressing. Duncan -- ________ Duncan Barclay | God smiles upon the little children, d...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On 16-Jul-99 Matthew Dillon wrote: > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. > > -Matt > Matthew Dillon And you seen the nice square waves of 100Mb or !Gb ether on a line then? The techniques used for transmitting 100Mb/s down copper are certainly not digital. Pulse shaping, line estimation, ISI removal are all analogue! The cable itself is less improtant than the impedance matching at connectors and bends in the cable. Duncan --- ________ Duncan Barclay | God smiles upon the little children, d...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On 17-Jul-99 Matthew Dillon wrote: > > Obviously you don't get square waves going down the wire - But it is > still a digital communications protocol. > > -Matt However the physical layer, i.e. the cable, is analogue and the discussion was about cables. To carry your reasoning a bit further - a digital cellular phone system is not an RF/Wireless system because the data is digital. I hope we agree that it is! Duncan --- ________ Duncan Barclay | God smiles upon the little children, d...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: proposed change for /etc/periodic/* scripts
On 23-Aug-99 Cillian Sharkey wrote: > > yes perhaps an /etc/periodic.conf would be good, to control the level > of verbosity and/or set options for each script ? I've hacked periodic here so that the scripts can be turned off with knobs in a periodic.conf file. This would simplify customizing new installitions - one no longer needs to add exit 0 to scripts. Duncan --- ________ Duncan Barclay | God smiles upon the little children, d...@ragnet.demon.co.uk | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Clustering FreeBSD
On 20-Jan-01 Wes Peters wrote: > "Russell L. Carter" wrote: >> %See the paper "Recursive Make Considered Harmful." Make is an amazing >> %tool when used correctly. >> >> That's not the problem, unfortunately. I've never had a problem >> rebuilding dependencies unnecessarily, or any of those >> other problems described. Well precompiled headers would be >> really really cool. The problem, again, is that parallelism >> is limited by the directory structure, and the directory structure >> is entirely rational. > > The directory structure has nothing to do with the Makefiles. To > obtain the goal the paper suggests, you replace the recursive > Makefiles with a single top-level Makefile that describes ALL of the > targets and ALL of the dependencies. Note that this does not require > a single mono- lithic Makefile; the top level Makefile can be a shell > that includes per-directory Makefiles. The important part is to get a > single dependency tree with no cycles in the graph. I was so impressed by the clarity in the paper and dicussions with friends that use Plan 9's "mk", that I put together "remake". This is a Makefile framework that implements the per-directory Makefiles to build the dependency tree. If anyone one wants to take a look it's at http://www.ragnet.demon.co.uk/RM/remake.html I haven't used it for a year or two and can only point to http://www.ragnet.demon.co.uk/mynews as an example of its use. If anyone gets interested drop me a line and I will try and remember how it works. Duncan > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr > LLC > [EMAIL PROTECTED] > http://softweyr.com/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: httpfs
Hi A thing to keep in mind about the portal file system is that it designed to provide a means of getting a file handle to an object that could be obtained by a call to open(2). It does not then provide a means of reading/writing etc. to that object. If you take a look at the example portal.conf then you can see how this can be used to open a socket via a pathname. Operations on the socket are then make using write(2) etc. I don't really think that portalfs is the right thing to use to build an httpfs with, but I would like to see how you managed to get your example to work. Are you using stdout to create an anonymous file handle? What happens if two processes concurrently read from /p/http/*? Duncan -- _ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King > On Sat, Mar 10, 2001 at 03:15:15AM -0800, Kris Kennaway wrote: > > A few of us were talking on IRC tonight about how cool it would be to > > have an httpfs filesystem -- then it occurred to me we almost have > > this already, in the form of the (under-utilised) portalfs. Portalfs > > works by handing off everything to a userland daemon which handles the > > actual transaction request, so you could easily imagine extending it > > to provide an http method similar to the tcp method it currently has > > for initiating tcp connections. > > > > One could probably make this more generic and finish implementing the > > undocumented 'exec' method (which currently exists as a stub): this > > would run an administrator-specified command (i.e. fixed in > > /etc/portal.conf) and pipe the output back to the user. > > > > A fully navigable httpfs (e.g. one you can ls and cd around in) is > > more work and probably requires a full stacking layer, but this would > > still be pretty cool. > > > > Is anyone feeling inspired to implement this? :-) > > OK, as I've mentioned in a private mail to Kris several hours after he > sent out this message, I've done some initial hacking on mount_portal > which lets me put: > > http/ exec http/ /usr/bin/fetch fetch -q -o - http://$1- > > into /etc/portal.conf, and then do cat /p/http/www.FreeBSD.org/handbook/ > (the $1- part refers to path components below /p/http/; $1- means > 'path components from 1 to last, separated by /') > > The code still needs a lot of cleanup before I would dare submit it for > review and comments; my question is, should I bother^W^W^Wdoes this look > like a reasonable extension to mount_portal, or are there other ways/places > that such functionality should be implemented, if at all? > > G'luck, > Peter > > -- > If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-fs" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Article: Network performance by OS
Hi Matt, On 16-Jun-01 Matt Dillon wrote: > >:> If you intend to push a system to its limits, you damn well better >:> be prepared to tune it properly or you are just wasting your time. >:> On any operating system. You will never find joe-user running his >:> system into the ground with thousands of simultanious connections >:> and ten thousand files in a mail directory, so it's silly to >:> configure the system from a joe-user perspective. >: >:So every FreeBSD server requires an expensive admin to tune it? >:That Win2K solution is looking good now. :-) >: >:These admins now... they never quit their job at just the wrong > > Huh? I'm talking about a reasonably smart 16 year old kid who bothers > to spend a little time learning how a platform works. I don't > know what you are talking about. Expensive sysadmin? Where did that > come from? Any bozo with half a brain who has spent more then a week > playing with FreeBSD in a serious way can tune it better then the idiots > who ran the benchmark. Whilst I agree with your sentiment I would like to bring in the spectre of the "real world". There are many diverse usage models in the world. The "benchmark" under discussion aims to rate various platforms running a package for ISPs. But, I wonder where the majority of FreeBSD/Unix boxes actually live? To take an example - where I work. We are an electronic engineering design consultancy and have a wide mix of projects. The basic IT infrastructure is Windows, a mix of W98, NT4 and W2k with a few Suns for IC design. We have about 200 people on site. The majority of IT support is NOT tuning the machines for best performance (whether it be W2k cross compiling for an embedded system or the Suns for IC design), but just keeping up with people needing a pool machine for a project or customer visit, fixing the switches when they blow up after a power cut, or restoring the Exhange databases...They don't even manage to find the time to recompile a Solaris kernel! Dynamic tuning would be ideal to help our IT get best performance out of NFS and Samba serving project data whilst also running Verilog/VDHL sims on the same box. I guess that this may never get to "best performance" for a given app, and, as such would not want to remove the possibility of tuning. > A person who depends on the ability to run an out-of-the-box solution > into the ground and actually expects it to perform well without having > to know the first thing about the platform he is running his software > on is a complete and utter idiot and the company that employs such a > person has a hellofalot more to worry about then the performance of an > untuned machine. I agree iff the business depends on the solution as its value prop. (e.g. ISP) but, I am sure that there are many more businesses that just use a box as tool to create their value prop. (e.g. an IC vendor). What do we do in those cases? They do not have the staff expertise to tune, to get the best out of the tens of applications that must be run to achieve the overall business goals. As a genuine question, does anyone have an idea of what the split of Suns/HPs /SGIs etc. is between "internet/intranet server" vs. "work station on a desk" is? > -Matt Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: trouble with 802.11 and kernel bridging (more)
- Original Message - From: "list tracker" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 3:27 AM Subject: Re: trouble with 802.11 and kernel bridging (more) > > ok, thank you! This explains my inability to perform bridging like I > expected to > > >I've been told the "wi" driver can't do bridging. The Cisco/Aironet > >"an" driver can. Patches were submitted so you can do this. They are > >in the tree. > > If I want to turn a PC into a full-blown "access point", should I set > wicontrol to peer to peer (3) or BSS (1) ? As Julian said an AP is very different to a standard station in either IBSS or BSS mode. If you want to: have a FreeBSD box with a card in it get the FreeBSD box to be a bridge/router between multiple wireless users and wired networks then Set the card into IBSS mode Turn on "create BSS" (if it works) Either: Use BRIDGEing Take a wired n/w performance hit Or Use routing and set two subnets up Turn on ipforwarding in /etc/rc.conf Make's moving a node from wired to wireless a little harder. I use IBSS and routing at home (with DHCP on a short timeout) to create seperate wired and wireless IP subnets. The FreeBSD box routes between the two and the external Cable Modem seamlessly. What disadvantages does this setup have compared with using a true access point? True APs can double the range for two wireless stations (the hidden node problem) - if both stations can see the AP but not each other they can still do peer to peer networking. True APs allow roaming between APs in an extended service set. True APs can do power saving to stations. I contend that the above are not necessary for a typical home user. An IBSS network with IP routing will serve many home users. > Secondly, should I turn on the "create BSS" (I am almost positive I should) > - but this leads me to: > > thirdly, are the fixes that allow wi to "create BSS" also "in the tree" ? > or does the man page warning that it does not work still valid ? > > (I was using 4.3-RELEASE, btw) > > thanks. > > LT > _ > Get your FREE download of MSN Explorer at http://explorer.msn.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
xxx_stop and ifq->if_snd in NIC drivers
Hi all In a wireless NIC driver should one drain the output queue when the interface is stopped? I've been perusing /sys/dev/awi.c and the output queue is drained in that driver. Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD kernel as a replacement for Linux kernel
On 25-May-00 Jordan K. Hubbard wrote: >> Anyone remember the old Pyramid OSX 'universe' command? > > Yes, I do. It was very evil. :) > > The way Apollo solved this problem was much more elegant and general > purpose and one of my favorite soapbox topics: Variant symlinks. Gosh is that the time...must be going soon... [snip] > Of course, every time we've had this discussion in the past, people > usually jump in and say that the environment variable space is > insufficiently powerful for this and what we really need is something > more like VMS logical names where you can have system-wide, group-wide > and user-specific variables which then are applied to the variant > symlink expansion. > > At that point, everyone generally agrees that it's too hard to do and > we should put off the entire concept for another couple of years. :) I have in my archives some code from the "person" who usually brings up the logical name stuff (the code implements them). However, there is also this snippet: PS: if you need the changes to namei() for variant symbolic links, ask me nicely, and I will disentangle them from my other changes to namei() for layering fixes, Unicode, and alternate namespace support (used by a modified (CIFS enhanced) Samba server which needs to have the DOS short name remain constant across directory searches). So who wants to ask him for them? > - Jordan Duncan, with tongue firmly in left cheek. --- ____ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
wakeup() question
Hi all Does wakeup() ever cause a sleeping processes to run before the wakeup() function returns, or does it just mark the process as running? Duncan --- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bcm4400 driver and Dell 8500
Hello James and Ken, Both of you are having real problems with the bcm driver and both of you have a Dell 8500. This is James' dmesg output, which from memory looks very similar to your Ken? > bcm0: mem 0xfaffe000-0xfaff irq 11 > at device 0.0 on pci2 > bcm0: Ethernet address: ff:ff:ff:ff:ff:ff > panic: bcm0: Strange type for core 0x > I'm running 5.1-current from august 22nd. I can try pulling down the > latest 5.1 tommorow if you think this might help. This is the same result > as when I tried the driver from over a month ago. We think that the problem is something to do with the PCI configuration of the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the memory map is not right. > Before sending this email I was going to obtain a backtrace. I recompiled > with the symbol table and kernel debugger and now the driver appears to > work fine. Should it work this way? Hmm interesting. Ken can you try this and see if the driver then works? Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bcm4400 driver and Dell 8500
On 27-Aug-2003 Kenneth D. Merry wrote:
> On Wed, Aug 27, 2003 at 08:40:25 +0100, Duncan Barclay wrote:
>> Hello James and Ken,
>>
>> Both of you are having real problems with the bcm driver and both of you
>> have a Dell 8500.
>>
>> This is James' dmesg output, which from memory looks very similar to your
>> Ken?
>>
>> > bcm0: mem 0xfaffe000-0xfaff irq 11
>> > at device 0.0 on pci2
>> > bcm0: Ethernet address: ff:ff:ff:ff:ff:ff
>> > panic: bcm0: Strange type for core 0x
>
> Yep, the messages I get are identical when I load it as a module.
>
>> > I'm running 5.1-current from august 22nd. I can try pulling down the
>> > latest 5.1 tommorow if you think this might help. This is the same result
>> > as when I tried the driver from over a month ago.
>>
>> We think that the problem is something to do with the PCI configuration of
>> the machine. The ethernet address being ff:ff:ff:ff:ff:ff indicates that the
>> memory map is not right.
>>
>> > Before sending this email I was going to obtain a backtrace. I recompiled
>> > with the symbol table and kernel debugger and now the driver appears to
>> > work fine. Should it work this way?
>>
>> Hmm interesting. Ken can you try this and see if the driver then works?
>
> I've already got the kernel debugger on. Do you mean changing the module
> compile somehow so that more symbols are included? (It seems to resolve
> the function addresses in the module fine.)
>
> The stack trace from the module load is:
>
> panic()
> bcm_chip_get_core()
> bcm_chip_reset()
> bcm_attach()
> device_probe_and_attach()
> etc.
>
> If I boot a kernel with the bcm driver compiled in, and don't attach to the
> docking station, it comes up fine until I insert my fxp card in the carbus
> slot. Then I get the panic in bcm_ring_rx_eof() that I reported last
> night. FWIW, when I have the driver compiled in, the memory location is
> identical to location used when the module loads (above), but the ethernet
> address is properly decoded:
This is still smelling of memory stuff outside of my experience.
> bcm0: mem 0xfaffe000-0xfaff irq 11 at
> device 0.0 on pci2
> bcm0: Ethernet address: 00:0b:db:94:bf:42
> miibus0: on bcm0
>
> If I boot a kernel with the bcm driver compiled in, and don't attach to the
> docking station, and don't insert my fxp card, I get slightly further. I
> tried running dhclient, and got:
>
> All mbufs or mbuf clusters exhausted, please see tuning(7).
> bcm0: initialization failed: no memory for rx buffers
Just checked dhclient and it works fine for me.
> Then I tried just manually ifconfiging the interface, and it works!
>
> Here's what netstat -m says:
>
> {erebor:/usr/home/ken:1:0} netstat -nm
> mbuf usage:
> GEN cache: 0/0 (in use/in pool)
> CPU #0 cache: 576/608 (in use/in pool)
> Total: 576/608 (in use/in pool)
> Mbuf cache high watermark: 512
> Maximum possible: 34304
> Allocated mbuf types:
> 576 mbufs allocated to data
> 1% of mbuf map consumed
> mbuf cluster usage:
> GEN cache: 0/0 (in use/in pool)
> CPU #0 cache: 575/584 (in use/in pool)
> Total: 575/584 (in use/in pool)
> Cluster cache high watermark: 128
> Maximum possible: 17152
> 3% of cluster map consumed
> 1320 KBytes of wired memory reserved (98% in use)
> 1 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines
>
> Performance, once I manually assigned an address seems okay; I was able to
> ftp a file over from another machine at a little over 11MB/sec.
Cool, thats about right.
> If I insert the fxp card after the bcm driver is configured, the cardbus
> initialization fails, and then I get the following messages over and over
> again:
>
> "eek j=6, macCurrent 511, con288"
This is a little loop that waits for the card to finish DMAing a packet. There
should be a DELAY(1) in there. But it may be commented out.
Do we think that cardbus is trashing the memory space somehow?
> At that point I can 't even break into the debugger.
>
> That's all the time I have for tinkering with it this morning...
>
> Looks like things are working somewhat better, but there is still some
> weird stuff going on...
>
> Ken
> --
> Kenneth Merry
> [EMAIL PROTECTED]
>
--
Duncan Barclay |
[EMAIL PROTECTED] |
[EMAIL PROTECTED]|
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bcm4400 driver and Dell 8500
From: "Kenneth D. Merry" <[EMAIL PROTECTED]> > > This is a little loop that waits for the card to finish DMAing a packet. There > > should be a DELAY(1) in there. But it may be commented out. > > That's bad...in general the chip should DMA the packet and then update the > consumer index and generate an interrupt. I don't know how this particular > chip works, though. The DELAY is commented out. Unfortunately I don't know how the chips works wither. This method comes from the drivers I used as a reference. I have recoded the loop a little so it doesn't DELAY and I've never had a timeout from it. > > Do we think that cardbus is trashing the memory space somehow? > > That could very well be the case. I don't know anything about cardbus, > though. Me neither, but my laptop needs some help in that area, so that's what I'm going to look at next. > Ken > -- > Kenneth Merry > [EMAIL PROTECTED] > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sata on -stable
Hi Soren and all, Having just got a nice new motherboard, a PATA drive and a bunch of SATA disks I discover that my homework wasn't too good. -stable isn't detecting the VIA-8237 controller, and in particuluar it is not finding the SATA disks. I can hack the device recognition code to pick up the 8237 and set UDMA133 mode on the PATA drive I have in the machine, but I cannot seem to find my two SATA drives. Any suggestions on how to at least find the drives - I don't need the h/w RAID as I was going to use Vinum anyway. What other alternatives are there? -currentNot ideal for the machine's use hackWhere to start? Promise Any recommendations for a suitable SATA card for -stable? Thanks in advance, Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sata on -stable
> From: "Soren Schmidt" <[EMAIL PROTECTED]> >> >> I can hack the device recognition code to pick up the 8237 and set UDMA133 >> mode on the PATA drive I have in the machine, but I cannot seem to find my >> two SATA drives. Any suggestions on how to at least find the drives - I >> don't need the h/w RAID as I was going to use Vinum anyway. > > The SATA part of the VIA needs a bit more work, you can how its done in > current, not too bad just a few lines of code.. I've now got the SATA part recognised and find one of the two SATA drives and I'm able to acess the drive. Although there were lots of warnings about UDMA mode etc - not suprising becuase all I did was add a couple of case statements to recognise the device. It gave up on the other drive eventually. It's rather remarkable that it is working at all! I'll grub around in current tomorrow and see what I can do. Do you want patches directly or via a send-pr? Or shall I commit after your review? Thanks Duncan > -Søren > .. but it works under windows!! Who cares ;-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sata on -stable
Thanks Soren, this seems to work. There is a load of chat about incorrect
cable types, but the drives are nice and fast according to a simple dd
if=/dev/zero bs=64k ...
Duncan
- Original Message -
From: "Soren Schmidt" <[EMAIL PROTECTED]>
To: "Duncan Barclay" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, December 03, 2003 11:30 AM
Subject: Re: sata on -stable
It seems Duncan Barclay wrote:
I had a spare minute earlier today, this should do the trick (and is
part of a larger patch due soon), please test and let me know...
Index: ata-dma.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-dma.c,v
retrieving revision 1.35.2.35
diff -u -r1.35.2.35 ata-dma.c
--- ata-dma.c 26 Oct 2003 18:34:23 - 1.35.2.35
+++ ata-dma.c 3 Dec 2003 10:28:07 -
@@ -506,6 +506,22 @@
}
break;
+case 0x31491106: /* VIA 8237 SATA part */
+ if (udmamode) {
+ error = ata_command(atadev, ATA_C_SETFEATURES, 0,
+ ATA_UDMA + udmamode,
+ ATA_C_F_SETXFER, ATA_WAIT_READY);
+ if (bootverbose)
+ ata_prtdev(atadev, "%s setting UDMA%d on VIA chip\n",
+(error) ? "failed" : "success", udmamode);
+ if (!error) {
+ ata_dmacreate(atadev, apiomode, ATA_UDMA + udmamode);
+ return;
+ }
+ }
+ /* we could set PIO mode timings, but we assume the BIOS did that */
+ break;
+
case 0x01bc10de: /* nVIDIA nForce */
case 0x74411022: /* AMD 768 */
case 0x74111022: /* AMD 766 */
@@ -522,7 +538,8 @@
char *chip = "VIA";
if (ata_find_dev(parent, 0x31471106, 0) || /* 8233a */
- ata_find_dev(parent, 0x31771106, 0)) { /* 8235 */
+ ata_find_dev(parent, 0x31771106, 0) || /* 8235 */
+ ata_find_dev(parent, 0x31491106, 0)) { /* 8237 */
udmamode = imin(udmamode, 6);
reg_val = via_modes[3];
}
Index: ata-pci.c
===
RCS file: /home/ncvs/src/sys/dev/ata/ata-pci.c,v
retrieving revision 1.32.2.17
diff -u -r1.32.2.17 ata-pci.c
--- ata-pci.c 22 Oct 2003 14:43:52 - 1.32.2.17
+++ ata-pci.c 3 Dec 2003 10:28:07 -
@@ -189,7 +189,12 @@
return "VIA 8233 ATA133 controller";
if (ata_find_dev(dev, 0x31771106, 0))
return "VIA 8235 ATA133 controller";
+ if (ata_find_dev(dev, 0x31491106, 0))
+ return "VIA 8237 ATA133 controller";
return "VIA Apollo ATA controller";
+
+case 0x31491106:
+ return "VIA 8237 SATA150 controller";
case 0x55131039:
if (ata_find_dev(dev, 0x06301039, 0x30) ||
-Søren
.. but it works under windows!!
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sata on -stable
From: "Soren Schmidt" <[EMAIL PROTECTED]> >It seems Duncan Barclay wrote: >[ Charset windows-1252 unsupported, converting... ] >> Thanks Soren, this seems to work. There is a load of chat about incorrect >> cable types, but the drives are nice and fast according to a simple dd >> if=/dev/zero bs=64k ... > Okies, the cable mumble is a "feature" of the -stable ATA driver not > having the right infrastructure for this. However I could add a hack > that skips the test on pure SATA controllers, but it wont be pretty... Oh, I'm not worried about the mumbling. Hopefully the box won't be rebooted very often! Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Help: patching if_bfe against FreeBSD -stable (4.8, 4.9)
From: "Al-Afu" <[EMAIL PROTECTED]> Sent: Friday, February 06, 2004 6:44 AM > In Reference To: > http://lists.freebsd.org/pipermail/freebsd-bugs/2003-September/003151.html > > the above specifies a patch to include the bfe driver into a 4.8 kernel. How > do I proceed with this? > > Pardon my ignorance, but I am not familiar with kernel's patches, hence the > reason I am asking for some guidance or pointers. > > Any help towards this will be greatly appreciated. Been actively trying to > solve the Broadcom 4401 NIC on my Dell 8500, and the above link seems to be > the closest I can get to. I cant afford to upgrade to -CURRENT as my > notebook is almost the mirror to all the production servers I have . There are another set of patches that "Pavel" prepared a couple of weeks ago. I need to get 4.9 on my laptop and giv e them a whirl and then commit them. I may be able to this over the weekend. I will put the patches up on a web site somewhere when I get home from work tonight. Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Call for Help: patching if_bfe against FreeBSD -stable (4.8, 4.9)
I've put Pavel's patches at http://people.freebsd.org/~dmlb/bfe-4.8.tar.gz Duncan - Original Message - From: "Al-Afu" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, February 06, 2004 6:44 AM Subject: Call for Help: patching if_bfe against FreeBSD -stable (4.8, 4.9) > In Reference To: > http://lists.freebsd.org/pipermail/freebsd-bugs/2003-September/003151.html > > the above specifies a patch to include the bfe driver into a 4.8 kernel. How > do I proceed with this? > > Pardon my ignorance, but I am not familiar with kernel's patches, hence the > reason I am asking for some guidance or pointers. > > Any help towards this will be greatly appreciated. Been actively trying to > solve the Broadcom 4401 NIC on my Dell 8500, and the above link seems to be > the closest I can get to. I cant afford to upgrade to -CURRENT as my > notebook is almost the mirror to all the production servers I have . > > Responses are much appreciated! Thanks > > -- > Feisal > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 4.7R and SATA
From: "Mark" <[EMAIL PROTECTED]> Subject: FreeBSD 4.7R and SATA > Hello, > > Does FreeBSD 4.7R support SATA drives? I was planning on using an ASUS > A7V600 motherboard, which has a serial ATA RAID configuration. Check the archives for a couple of hacks to recognise the chipsets correctly. I cannot remember if this is for the A7V600 board. But it is for a recent Asus board. It should give you some pointers. http://lists.freebsd.org/pipermail/freebsd-hackers/2003-December/004351.html Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 4.7R and SATA
> > > Hello, > > > > > > Does FreeBSD 4.7R support SATA drives? I was planning on using an > > > ASUS A7V600 motherboard, which has a serial ATA RAID configuration. > > > > Check the archives for a couple of hacks to recognise the chipsets > > correctly. > > Thanks for replying. I neglected to mention that the controller is the > VT8237. > > I did indeed see some patches, for 5.2. But I am really needing it for 4.7R > as well (upgrading the system o 5.2 is, for various reasons, undoable). > Would such a patch work on 4.7 too? These are for 4.9, but I think they will apply for 4.7R > Thanks, > > - Mark > > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bluetooth
Hi I might be worth talking to the people at http://www.blueaid.com/ Bill Munday has written and architected a number of the Bluetooth stacks various vendors use. He does free consulting and knows a _lot_ of people in the Bluetooth world. He is likely to know about other Bluetooth efforts for Linux. I can also help out with concepts/overviews etc. I have designed RFICs for Bluetooth and am part of the SIG writing version 1.2 of the standard (and no, I didn't do any of version 1.1 so don't hassle me!). Duncan On 04-Oct-01 Maksim Yevmenkin wrote: > >> Is anyone working on bluetooth drivers and accompanying userland programs >> (bluetooth equivalents of wicontrol, etc.) ? > > ok :) i'm actually working on BlueTooth stack for FreeBSD. so far > i have some code that implements basic functionality for HCI layer. > the implementation is based on Netgraph and supposed to be completely > optional. > > thanks, > max > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > --- ________ Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Bluetooth stack for FreeBSD (full status)
From: "Terry Lambert" <[EMAIL PROTECTED]> > I haven't really taken an active interest in BlueTooth, > since there are no laptops or printers that come with > it already present; I rather think it will end up as > still-born because of 802.11e Gigabit wireless, which > can use as little or less power. There are now a few devices with Bluetooth in them. Sony has had a Viao with it in for a while. 802.11e is not gigabit wireless. .11e is quality of service enhancements to the .11 MAC. You may be confusing it with .11a - 54Mbps at 5.2GHz or the new .11g giving 54Mbps at 2.45GHz. Some people (Proxim) have .11a cards that can operate at 108Mbps. This will have a reduced range though as they probably halve the forward error correction somehow - maybe by increased puncturing. .11 without .11e is worse than Bluetooth for certain data types. For example it cannot carry isochronous data. Bluetooth was never meant to compete with .11 and was designed for a different purpose - mobile phones. Wanderering around the UK's high streets a lot of phone shops and a couple of the bigger consumer electronics chains are now selling Bluetooth enabled stuff. Duncan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
TIOCSCTTY not implemented in linuxulator?
Hi
Does anyone know why TIOCSCTTY isn't implemented in compat/linux_ioctl.c?
The last change in this area was back in 1999 when the ioctl handling was
revamped, but this ioctl was not implemented. Do controlling terminals
work okay in the linuxulator?
Implementing this might solve a problem with Matlab, where it refuses to exit.
Matlab issues calls to two unimplemented ioctls on the tty side of a pty/tty
pair.
linux: 'ioctl' fd=4, cmd=0x1 ('',1) not implemented
linux: 'ioctl' fd=4, cmd=0x1 ('',1) not implemented
linux: 'ioctl' fd=4, cmd=0x540e ('T',14) not implemented
0x540e is TIOCSCTTY, and according to /compat/linux/usr/include/asm/ioctls.h
0x1 is TIOCSER_TEMT (Transmitter physically empty)?
I'm using
4.6-PRERELEASE
linux_base-6.1_1
linux_devtools-6.1
linux_kdump-1.4
Thanks
Duncan
--
____________
Duncan Barclay | God smiles upon the little children,
[EMAIL PROTECTED] | the alcoholics, and the permanently stoned.
[EMAIL PROTECTED]| Steven King
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PCMCIA questions: mapping attribute and common memory?
On 07-Sep-2002 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Bruce M Simpson <[EMAIL PROTECTED]> writes: >: Thanks for your informative response. > > Sure. Sorry for the long delay on this one. I wanted to give a good > answer rather than a fast one. I'm just clarifying a couple of the questions Warner raises. I wrote the ray driver. [snipped[ >: Once I've allocated the window as a resource, how would I go about accessing >: that memory directly? Would I need to establish a page mapping? > > OK. Lemme talk with code (which I've grabbed from ray_res_alloc_am) > > sc->am_rid = RAY_AM_RID; > sc->am_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, > &sc->am_rid, 0UL, ~0UL, 0x1000, RF_ACTIVE); Note that the 0x1000 is the size of the map requested. The code doesn't use the CIS to set the AM map up. It's all hardcoded. In contrast, pccardd set the CM map up for you. > error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc->dev), sc->dev, > sc->am_rid, 0, NULL); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->am_rid, PCCARD_A_MEM_ATTR); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->am_rid, PCCARD_A_MEM_8BIT); > > (I'm not sure why the ray driver doesn't combine the last two calls). /sys/pccard/pcic.c:pcic_set_res_flags() doesn't actually treat the flags as a bit mask, it just uses a switch to test the arguments. The PCCARD_A_MEM_8BIT might not be needed for your cards. > The rid is 3. pccardd abuses window 0 (and the comments in the > ray driver say 1 also, which may be possible). We really should use > window 4 for the CIS, but that's too big a change (and would break > support for media chipsets, which have only one memory map, but those > are only on early pc98 laptops). FYI, the abuses is that sometimes, pccardd and pccardc will remap window 0 to do things, even if it is use by a driver. > Anyway, you pick the window that you want to use. You the map it. To > manage where in the memory you'd like to map it, you set the offset. > To make it the attribute memory, we set the resoruce flags. Ditto > with 8 bit. Allocating the common memory would be similar. > > In the ray driver, it uses rid 0 for the common memory so it can get > the size of the memory. So that code looks like: > > u_long start, count, end; > sc->cm_rid = RAY_CM_RID; > start = bus_get_resource_start(sc->dev, SYS_RES_MEMORY, sc->cm_rid); > count = bus_get_resource_count(sc->dev, SYS_RES_MEMORY, sc->cm_rid); > end = start + count - 1; > sc->cm_res = bus_alloc_resource(sc->dev, SYS_RES_MEMORY, > &sc->cm_rid, start, end, count, RF_ACTIVE); > error = CARD_SET_MEMORY_OFFSET(device_get_parent(sc->dev), sc->dev, > sc->cm_rid, 0, NULL); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->cm_rid, PCCARD_A_MEM_COM); > error = CARD_SET_RES_FLAGS(device_get_parent(sc->dev), sc->dev, > SYS_RES_MEMORY, sc->cm_rid, PCCARD_A_MEM_8BIT); > > which is very similar. This only works because the rid is 0. I'm not > sure what the CIS of the ray cards look like (my ray cards aren't > easily accessible at the moment). The code looks similar but the underlying reasons are different. pccardd has already set up the CM from its parsing of the CIS. This code just ensures that mapping is correct. But the ray cards use 8bit memory and that info isn't in the CIS - so I have to reset the window. If your cards are 16bits, then you won't need to do any of this. Whereas, the AM code above had to create a new mapping for the AM as pccardd doesn't leave that around for the driver (this is all OLDCARD). There is a raylink CIS at http://www.ragnet.demon.co.uk/ray_cis.txt Duncan -- Duncan Barclay | God smiles upon the little children, [EMAIL PROTECTED] | the alcoholics, and the permanently stoned. [EMAIL PROTECTED]| Steven King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
interrupt handlers in -current
Hello, This is more of a confirmation of my understanding than anything else. In -current, should an interrupt thread be created you set up an interrupt handler? If so, then I'd better check my code because I haven't got one! If a PCI device generates an interrupt and there is no handler does the kernel report a stary interrupt? -current for me is 5.1-BETA1 and I'm doing a driver for the BCM 4401 NIC. I'm transmitting packets but my handler isn't being called to clean up the DMA. Duncan -- ________ Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
On 05-Jun-2003 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Duncan Barclay <[EMAIL PROTECTED]> writes: >: This is more of a confirmation of my understanding than anything else. >: In -current, should an interrupt thread be created you set up an interrupt >: handler? If so, then I'd better check my code because I haven't got one! > > No. Just because we handle interrupts in a thread doesn't mean client > devices need to create a thread. The thread is creted automatically > and the routine passed to bus_setup_intr() is then called when an > interrupt happens. Rereading what I wrote, I might have mistyped and asked the wrong question. I think what you saying is that bus_setup_intr() doesn't create the thread, (in the sense of it appear in ps -ax?) but a thread is created automatically when the first interrupt occurs? > You can create threads, taskqueues and other things, but those aren't > required. Good - bus_dma is warping my head too much...I think I've got it right. >: If a PCI device generates an interrupt and there is no handler does the >: kernel report a stary interrupt? > > You'll likely see an interrupt storm. Since the PCI device generates > a level interrupt, the ISRs are run and the level interrupt is still > high, so another interrupt is generated, etc. on 4.x this was fatal, > but on 5.x the system can continue to run in a degraded manner. > >: -current for me is 5.1-BETA1 and I'm doing a driver for the BCM 4401 NIC. >: I'm transmitting packets but my handler isn't being called to clean up the >: DMA. > > So you are doing bus_setup_intr() and that routine is never called? Yup. > What does vmstat say? I'd expect to see something like: > > % vmstat -i > uhci0 irq10 26083 1 ># cause the interrupt to happen > % vmstat -i > uhci0 irq10 26026083 2683 ># eg, a huge number all of a sudden If I load the kld for the driver and it attaches, nothing appears in vmstat -i, or ps -ax. Unfortunately, I've screwed up a lock in the ioctl hander and witness is panic'ing when I ifconfig the interface. As it is now bedtime I'll fix it tomorrow morning and report back. > It may also be the case that the interrupt for this isn't being > properly routed. 5.1-BETA has a bug that, for some laptop machines, > interrupts aren't properly routed. 5.1-RELEASE has fixed this. Okay, I'll do a reinstall. This probably won't happen until after the weekend because I'm going away. Anyway, I'm pleased with my progress as I can see arp requests hitting the wire before it panics. > Warner Thanks, Duncan -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
On 05-Jun-2003 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Duncan Barclay <[EMAIL PROTECTED]> writes: > > It may also be the case that the interrupt for this isn't being > properly routed. 5.1-BETA has a bug that, for some laptop machines, > interrupts aren't properly routed. 5.1-RELEASE has fixed this. I think that this must be it. I had the blindingly obvious idea of looking at the chips interrupt mask in the watchdog (which is getting called). The chip has posted a TX complete interrupt. The kernel hasn't done anything with it so I assume it isn't routed. Until I get back from travelling and can install 5.1R, this at least gives me a hook to continue driver development - fairly icky though using the watchdog to trigger the interrupt handler! > Warner Duncan -- ________ Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Rrrrrr.....
Dear Bill, On 27-May-2003 Bill Paul wrote: > Ok, I've gotten enough e-mail about this now that it's starting to be > annoying, so I'm going to nip this in the bud right now. If this was prompted by my private email earlier today then I am sorry to have been the straw that broke your back. Having searched the archives over the past couple of days and not finding too much hard information on this chipset I decided a short note to you might speed up the effort I am making in porting the Linux driver. Maybe I didn't make that clear. I have been posting to -current and -mobile on the topic over the past week. The information below confirming that the API is different is all that I asked for. I will carry on with my porting effort. Thanks Duncan > People have started asking me about the Broadcom 4400 series chips. > They have noticed that there's this "if_bge" driver with the word > "Broadcom" associated with it, and seem to think it may somehow be > coerced into working with the 44xx chipset, even though the documentation > implies nothing of the sort. So everybody listen up: > > *NO*, the 44xx chips are *NOT* the same as the 57xx chips. The 57xx > devices are 10/100/1000. The 44xx are 10/100 *ONLY*. > > *NO* they do *NOT* have the same programming API. > > *NO*, the bge(4) driver will *NOT* work with the 44xx chips. Ever. I don't > care how much you whine. > > *NO* I don't have any programming manuals for the 44xx chips and don't > know (or care) if I ever will. > > *NO* I will *NOT* port the Linux driver to FreeBSD. > > Is everyone clear on this now? Good, because any further questions > along these lines will be summarily ignored. > > -Bill > > -- > = > -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu > [EMAIL PROTECTED] | Wind River Systems > = > "If stupidity were a handicap, you'd have the best parking spot." > = -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Broadcom 44xx (Re: Rrrrrr.....)
> On Tue, May 27, 2003 at 12:08:22PM -0700, Bill Paul wrote: > > *NO*, the 44xx chips are *NOT* the same as the 57xx chips. The 57xx > > devices are 10/100/1000. The 44xx are 10/100 *ONLY*. > > Where is the 44xx showing up? I've got one in my new Acer 800Cli laptop (try www.acer.co.uk as Warner said he couldn't find it on the main site). It's Centrino based with 5+hrs of battery life. The 44xx seem to be big SoC type devices with the possibility that NIC, USB, Modem, HomePNA, kitchen sink all exist on the same chip. I've got all of the setup side of the driver done (e.g. PHY and MAC tickling) and now have to get my head around bus_dma so I can start sending packets out of it. Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BCM4401 ethernet driver
I am in the process of rewriting this driver for FreeBSD. It can transmit, but RX is not yet going properly. As this is evening work, it's likely to take at elast another week. > This is the onboard ethernet on my dell inspiron 8500 laptop and I > wondered when drivers might get to freebsd. The linux kernel just > imported the drivers that the broadcom wrote for it found: > http://www.broadcom.com/docs/driver-download.html > It doesn't appear they intend to make any freebsd drivers. > > Thanks in advance, > James Nobis > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: [hackers] Re: BCM4401 ethernet driver
On 18-Jun-2003 David Gilbert wrote: >>>>>> "Duncan" == Duncan Barclay <[EMAIL PROTECTED]> writes: > > Duncan> I am in the process of rewriting this driver for FreeBSD. It > Duncan> can transmit, but RX is not yet going properly. As this is > Duncan> evening work, it's likely to take at elast another week. > >>> This is the onboard ethernet on my dell inspiron 8500 laptop and I > > I'm pretty sure this is the chipset on my Dell D800 laptop. I would > be interested in testing the drivers, too. I'm running 5.1-RELEASE. > > Dave. cool - are you a bit of hacker? If so, you should be able to cope with the request below, and the explaination. If not, or you don't understand the stuff below, then maybe the driver is not yet ready for you (no offence intended). The driver is not very ready (as I have some problems interrupt problems), but can transmit. Receive is not working - well not even written. If you can build http://people.freebsd.org/~dmlb/bcm.tar.gz as a module, kldload it and then ifconfig bcm0 192.168.0.1 ping -c 1 192.168.0.0 and send me the copious dmesg output I would be very grateful. The mahcine I am developing on has a problem with interrupts. There is a problem with RX DMA descriptors that I haven't figured out. Sebastian sent me a log this morning and he has the same interrupt problem as I do. Thanks Duncan -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BCM4401 driver
Hello Bruce, From: "Bruce Cran" <[EMAIL PROTECTED]> > I realise that there's a 'beta' FreeBSD driver out for this card, and I've > been attempting to learn the kernel interfaces such as bus_dma and mbuf > handling to debug it, but without much success. On my Dell, it seems to > mostly work if I set the number of RX descriptors very low, around 5, but at > the default of 200 the network stalls with invalid packets. Running a > tcpdump on the interface shows that, with 5 descriptors, there's an occasional > bad packet, but it doesn't stop any network access working. With 200, I get > loads of bad packets, where tcpdump shows the mac addresses (the ethernet > header I guess) quite a few bytes > into the packet. I recently ran the system with the driver preloaded, and > after a while it locked the system up, spamming me with 'bcm0: discarding frame > w/o ethernet header (len 4294967296 pktlen 4294967296)'. It looks as though > there's either a problem with where the chip is putting the data, or > something's wrong with the mbuf handling, but which only gets triggered after > a while. Does anyone know enough about > network drivers to know what the problem might be? > It would be great to have this card supported, and it seems that the driver > is very near to being working, it just needs a bit more debugging work > done on it. Firstly, an apology. I released the beta driver at the end of june just before I went on holiday. Since I got back I've been maxed out at $REALJOB and been too tired in the evenings to do any hacking on the driver - because of the stuff (chip layout) I'm doing at work, the last thing I want to do is sit in front of another monitor! This situation will continue for another week or two. Your report above tallies with my experiences and those of others on a few platforms. Although you have spotted a few more bits and pieces. I hadn't noticed the misaligned MAC addresses on bad packets. I think that the driver might be programming the chip very slightly incorrectly. Either there is a requirement for the chip to see some sort of alignment on the RX buffers or I've got something wrong in handling the extra header that the chip prepends to the packets, or I've simply got mbuf alignment requirements wrong. Sometimes, I see symptoms of kernel memory being trashed - odd sig 11's etc. It is possible that the chip is spamming memory where it shouldn't. FYI, I used two Linux drivers for reference. One from Broadcom (called bcm4400) and one from Redhat, (called b44 I think). I haven't managed to get any docs from Broadcom, so have had to work blind, and may well have something wrong. Thanks for the feedback and once again apologies for being tardy in tracking this bug down. Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BCM4401 Support for FreeBSD
Hello Terry, From: "Terry Lambert" <[EMAIL PROTECTED]> > Joe Marcus Clarke wrote: > > On Mon, 2003-07-28 at 12:18, Aeefyu wrote: > > > i.e. Broadcom 440x NIC support for FreeBSD 4.x and 5.x (as found on > > > latest Dell's Notebooks - mine is a 8500) > > > > > > Would anyone be so kind to enlighten me on the the current status? > > > Last I heard of developments being made was end of June. > > > > This was forwarded to me from Greg Lehey. The dcm driver works okay for > > me, but I had to hack it for some new bus dma changes. I have noticed a > > few issues of slowness with it when using it in a more "normal" sense > > (i.e. using it to read mail, ssh to machines, etc.). > > > Most likely, the interactive performance is a result of the RX > packet coelescing, with a timer set to too long an interval. In > general, it's probably an easy adjustment to make. It shouldn't be as I set the RX coalescing timer at the same settings as the Linux drivers - and it is set to 1 packet. > I notice that he also says he didn't know what to add into some > of the timer and media routines, so that could be part of the > issue as well (e.g. if it's getting wedged and having to unwedge > itself). Nope - no wedging is going on. It's packet aligment issues - either I'm programming the RX DMA pointers wrong or not adjusting them correctly on receipt. TX is absolutly fine, it can easily max out a 100MB/s link with hardly any CPU load. > BTW: As a rule of thumb, if you don't know what to put in a timer > or media routine, put a printf() there. It will likely annoy > someone into fixing it. 8-). Ta - will do when the RX issues are fixed. > -- Terry > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BCM4401 Support for FreeBSD
From: "Aeefyu" <[EMAIL PROTECTED]> > > http://marc.theaimsgroup.com/?l=freebsd-hackers&m=105593188923273&w=2 > > I cant compile the above on my machine > Its only applicable for 5.x and not 4.x? > Sighs Correct, at present it is only for 5.x. A backport should no be too hard though. I now have a bit more free time to pick up the development of the driver again. The first thing on my list is to sort out the receive performance problems. Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
mbuf/mbuf cluster adjustments (bcm driver)
Hi I've finally managed to get back to work on the bcm driver for Broadcom 440x chips. I think the RX packet loss/performance problem that people have with the driver from July is down to how I am accounting for a 30byte header that the chip prepends to an incoming packet. At present, the driver preallocates a load of mbuf clusters for the chip to DMA into. The chip then loads the mbuf cluster with this 30byte header followed by the real packet. I then account for this header by doing an m_adj(m, 30) before if_input(). However, this doesn't seem to work all the time. Looking at the code for m_adj I don't think it is meant for use with mbuf clusters. Is there a tidy way of trimming this header off from the mbuf cluster? I'm going to first try manually copying stuff to confirm that this is the problem and then try m_pullup followed by m_adj. Thanks Duncan -- ________ Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
New BETA of Broadcom 440x chipset driver
Hi I think I have fixed the RX packet loss and memory corruption problems with the previous version of the driver. Please try the code at http://people.freebsd.org/~dmlb/bcm-0308252140.tar.gz I have manged to get full link speed ftping large files in both direction. Also, I have successfully populated an empty /usr/src tree with cvsup whilst up and downloading 50MB files. Would people please try this and feed back good and bad experiences. I would be interested if people could run their favorite net bench marks with the hw.bcm_rx_quick sysctl set to 1 (default) and 0. Setting to zero forces the driver to copy data from the NIC, one causes the driver to do a small 44 byte memory shuffle. Whilst wire speed should not differ, time spent in the interrupt routine should be less with the sysctl set to 1. Please do not use on a "valuable" system. The problem that this release tries to fix sometimes resulted in kernel memory corruption. All the best Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: mbuf/mbuf cluster adjustments (bcm driver)
From: "Harti Brandt" <[EMAIL PROTECTED]> > On Mon, 25 Aug 2003, Duncan Barclay wrote: > > DB>I then account for this header by doing an m_adj(m, 30) before > DB>if_input(). However, this doesn't seem to work all the time. Looking at > DB>the code for m_adj I don't think it is meant for use with mbuf > DB>clusters. Is there a tidy way of trimming this header off from the mbuf > DB>cluster? I'm going to first try manually copying stuff to confirm that > DB>this is the problem and then try m_pullup followed by m_adj. > > m_adj should work on any mbuf whether with a cluster or not given that > you mbuf is setup correctly. Where do you see a dependence on not beeing a > cluster in that code? Just before I went to bed last night I think I realised what the problem is. I don't think I set the mbuf up correctly. doh! Thanks for letting me know it should work. > harti Duncan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [hackers] Re: BCM4401 ethernet driver
On 26-Aug-2003 [EMAIL PROTECTED] wrote: > Greetings; > > Wondering whatever further may have come of this discussion regarding > FreeBSD support of the built-in ethernet for the Dell Inspiron 8500 Notebook. > Running a dual-boot system with MS Windows XP and FreeBSD 4.8 Release since > 5.1 > wouldn't seem to install, but not even sure how to make use of drivers beyond > including their device code in the kernel configuration file, which may just > be an issue with this current release. I fixed the RX problem yesterday. Take a look at http://people.freebsd.org/~dmlb/ and grab the lastest bcm_...tar.gz file. Untar this into /sys then cd /sys/modules/bcm make make install kldload if_bcm This driver is for -current only. Once I've done a bit more work on it and committed it, I'll back port to -stable. Duncan > Other than that, may also ask if anyone's just managed to get the Motorola > SB4200 Cable Modem to work through the USB port instead. > > Thank you, > > > [freebsd.hackers] > > Subject: Re: [hackers] Re: BCM4401 ethernet driver > From: [EMAIL PROTECTED] (Tony Meman) > Newsgroups: freebsd.hackers > Organization: TAC News Gateway > Date: Jun 18 2003 02:52:22 > References: 1 > > David Gilbert wrote: >> Duncan> I am in the process of rewriting this driver for FreeBSD. It >> Duncan> can transmit, but RX is not yet going properly. As this is >> Duncan> evening work, it's likely to take at elast another week. >> >> >>>>This is the onboard ethernet on my dell inspiron 8500 laptop and I >> >> I'm pretty sure this is the chipset on my Dell D800 laptop. I would >> be interested in testing the drivers, too. I'm running 5.1-RELEASE. >> >> Dave. > > This ethernet is onboard on some Asus A7V8X mother boards (VIA KT400 > chipset). I'm running the linux/windows drivers from Broadcom site > without problems. > > If you need more ppl testing the driver I'd be glad to help. I'm running > 4.8-STABLE but could upgrade to 5.1-RELEASE if required. > > Regards, > > -- > Tony Meman > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > -- > COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test > -- > 1. GMX TopMail - Platz 1 und Testsieger! > 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! > 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
