Re: startup options
On Fri, Aug 15, 2008 at 02:52:21PM -0700, Sam Leffler wrote: Stefan Sperling wrote: That page pretty much summarises the state of affairs, yes. Basically, you need a VIA-based ethernet card card (vr driver) and -CURRENT, or a vr card with 7.0 and patches from here: http://www.stsp.name/wol/FreeBSD-8-CURRENT-wol-backported-to-7.0/ All of those. Except the patch for pxe.c, that's there by accident. If you don't have a vr card, you will likely need to do some hacking. Follow the links from the wiki page for more information. trouble% cd sys/dev/ trouble% grep -l IFCAP_WOL */*.c age/if_age.c jme/if_jme.c re/if_re.c stge/if_stge.c vr/if_vr.c So 5 drivers right now support WOL. Jack said em had support a while back but he seems to have not hooked it up. Nice! I'll update the wiki page accordingly. What's with if_sis? Isn't it in yet because my patch only supports the NatSemi variant? (I have no idea whether the other variants work alike or not.) Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: startup options
On Fri, Aug 15, 2008 at 10:00:25PM +0100, Vincent Hoffman wrote: Chuck Robey wrote: I was wondering if it was possible, with a machine that has about 2 year old dual AMD64 processors and an up-to-date AMI BIOS, to get the machine to be able to start up from a power shutdown, after some sort of a network signal? If it might be possible, could you maybe put me onto the path of whatever info there might be on that subject? Wake on LAN is I believe a work in progress. http://wiki.freebsd.org/WakeOnLan its not an area I have much knowledge of though so other might be able to help more. That page pretty much summarises the state of affairs, yes. Basically, you need a VIA-based ethernet card card (vr driver) and -CURRENT, or a vr card with 7.0 and patches from here: http://www.stsp.name/wol/FreeBSD-8-CURRENT-wol-backported-to-7.0/ All of those. Except the patch for pxe.c, that's there by accident. If you don't have a vr card, you will likely need to do some hacking. Follow the links from the wiki page for more information. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 CVS
On Tue, Aug 05, 2008 at 02:16:35PM +0400, Maxim Konovalov wrote: On Tue, 5 Aug 2008, 19:52+1000, Tim Clewlow wrote: Hi all, Does anyone know if there are any IPv6 CVS servers for FreeBSD? (As in receiving the STABLE and ports branches) I currently use cvs.freebsd.org but it dosent have an record. Ta Peg dig cvsup4.freebsd.org cvs != cvsup. Speaking of cvsup -- cvsup4.ru.freebsd.org has an ipv6 address as well. AFAIK the Modula3 runtime does not support IPv6. Stefan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SCHED_4BSD bad interactivity on 7.0 vs 6.3
On Sun, Jul 13, 2008 at 01:34:11AM -0700, Nate Eldredge wrote: On Sun, 13 Jul 2008, Kris Kennaway wrote: Nate Eldredge wrote: I wrote a small program which forks two processes that run gettimeofday() in a tight loop to see how long they get scheduled out. On 6.3 the maximum latency is usually under 100 ms. On 7.0 it is 500 ms or more even when nothing else is running on the system. When a compile is also running it is sometimes 1400 ms or more. This test shows a difference even in single user mode, when X is not running at all. I was seeing similar problems (audio stutter during compiles, jerky mouse) after upgrading to 7.0. The box is an Athlon-XP 2400+ with 1GB of RAM. Since removing SMP support from the kernel and switching to ULE, interactivity has been acceptible again. I did not update the xserver at the time, and I can't recall if it has been updated since. Stefan pgpwzVr88QUYs.pgp Description: PGP signature
Re: Summer of Code 2008 Project Ideas
On Wed, Mar 19, 2008 at 10:17:21PM +0100, Kris Kennaway wrote: You can also come up with your own project ideas if we have missed one :) I've got one: Implement wake on lan support for every ethernet device driver in the tree. ifconfig in -CURRENT already supports configuring WOL, but there's not a single driver yet that makes use of this. There should be enough information to get interested people going at http://wiki.freebsd.org/WakeOnLan Apart from if_vr patches by Yongari (linked from the wiki page) and some other patches that sit in a few peoples' mailboxes, nothing has been happening around this in a while. I myself am busy working on Subversion atm and will start working on my Bachelor theses starting next semester (April-Juli), so I'm out :/ I'd be available to answer questions if necessary, however. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpv2O4mHcYXj.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
On Sat, Feb 02, 2008 at 11:49:10PM +0800, OutBackDingo wrote: I dont think I follow why people think its that hard to convert the FreeBSD src tree to some other RCS with history, branches and tags I seem to think this is doable. Seeing as Ive done it. And how did you convert it exactly? -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpou1f3Nettf.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
On Thu, Jan 31, 2008 at 11:00:25AM +0100, Johan Bucht wrote: I've only tried CVS, Mericurial, Clearcase and a bit of Subversion. And if you don't need IDE integration Mercurial seems to be working pretty good. I just read an article about the new merging and branching support coming in Subversion 1.5 and it looks like it might have some future. The IDE support is probably the best of the modern open source VCS. http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html Yes, merge tracking will definitely make it much easier to maintain branches in Subversion, including vendor branches containing a FreeBSD source tree. You can achieve much of the same effect by using the svnmerge.py script that ships with Subversion 1.4, but with 1.5 the server and client have merge tracking built in, so it's not a python script wrapper anymore, but a well-integrated feature. 1.5 has finally been branched a few days ago actually, so if you want to try it out go ahead and check out the branch and report any issues you find: svn co http://svn.collab.net/repos/svn/branches/1.5.x svn-1.5 -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgp5oO6TiUytn.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
On Fri, Feb 01, 2008 at 02:00:47AM +0200, Giorgos Keramidas wrote: Most tools seem to insist on trying to import the whole history of a CVS repository before they let you start doing any work in the newly converted repository. All conversion tools I've tried failed converting the FreeBSD repository. Not really. You can keep 'importing' snapshots of the src tree from any arbitrary CVS branch, if you are willing to wait until CVS checks out the first copy of the snapshot. Yes, sure. As described I eventually got around to use a cvs working copy as a base for importing snapshots of FreeBSD code as well. What would be nicer though would be something that could be pointed at the RCS files in the CVS repo to do the same, i.e. skip the working copy step. That's what I was looking for, also because of pure technical interest. But it's clear that from a functional point of view a script achieves the same thing just fine, albeit it's slower and wastes a bit of disk space. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpjhtzsGtju0.pgp Description: PGP signature
Re: [OT] Q: what would you choose for a VCS today
On Thu, Jan 31, 2008 at 08:45:55AM +0200, Adrian Penisoara wrote: Hi, Side-topic, if you bear with me: if you were to choose again what to use as source revision control system (VCS) from today's offerings, what would you choose to maintain FreeBSD's sources or a side-off project tracking FreeBSD as base that would allow better teams cooperation and easy code merging between projects/branches ? Finally a thread to vent about this topic :) I'd very much like to hear how others are doing this, please post, people, I'll read it all. Here's my take on it. I'm only talking about maintaining local changes, not what the FreeBSD project per se should use for change management, and also I don't really talk about working in a team but it's probably still relevant and might help: Don't _ever_ follow development(7) and try to maintain one or more custom branches inside a cvsup'd copy of the FreeBSD CVS repo. I've been down that road. It sucks. It really prevented me from getting any work done while waiting for hours on end for cvs to set a tag, do an update, a commit, let alone a merge. Every operation took ages and ages. With two branches, one based on RELENG_6 and CURRENT at the time, merging changes between the two was a major pain. CVS had so much overhead for me that using it made the whole point of doing version control fly out the window from, say, the 42nd floor. I've investigated quite a few options to maintain modifications to FreeBSD since, mainly to manage wake on lan patches (see http://stsp.name/wol/) but also local bug fixes I need for my system (e.g. enabling AIGLX does not lock up my 6.3 box so I can run compiz, see PR #114688). I'm quite serious about version control. In fact I'm a partial and (currently) paid committer for the subversion project, so I could even say that I'm involved in version control professionally. What I wanted instead of CVS sounds fairly simple to me: To maintain my local mods to FreeBSD I don't really care about the whole CVS history. I just need to be able to take a snapshot at some point, put it on a branch, and keep importing upstream changes incrementally to that branch from there on. So a vendor branch, but without any (or as little as possible) manual labour involved in updating it. I could not find any tool that does this properly among subversion, git, monotone and mercurial. That's not a big list, but I don't have time to try out version control systems all day. Also, proprietary VCS's were never considered (I also keep my freebsd kernels blob-free, call me a hippie or whatever if you want :P) Most tools seem to insist on trying to import the whole history of a CVS repository before they let you start doing any work in the newly converted repository. All conversion tools I've tried failed converting the FreeBSD repository. git-cvsimport fails after a few minutes because cvsps produces bad output when run on the FreeBSD repo. I reported this to the git developers and as a result they made git-cvsimport error out correctly, but did not fix the actual issue. The monotone built-in cvs converter segfaulted after running a whole day. The generic tailor VCS conversion tool failed as well -- I don't remember how, it errored out after running for a while. Even though I am subversion dev I did not try cvs2svn, because I wanted to take this as an opportunity to get my feet wet in another VCS. Mercurial failed to convert the repo, too, and there was no way of telling it not to try to import the whole history either. But its handbook describes interesting alternative approach to vendor branches: Patch queues. If you think you need a vendor branch, take a look at mercurial patch queues and consider if they might do the job just as well: Managing change with Mercurial Queues: http://hgbook.red-bean.com/hgbookch12.html#x16-26700012 Advanced uses of Mercurial Queues: http://hgbook.red-bean.com/hgbookch13.html#x17-30200013 I won't explain the details in this mail, as duplicating information from the handbook is a waste of time, but I'll give you my opinion: Patch queues are quite powerful, and even though you end up versioning diffs instead of whole files, the patch queue provides a nice enough abstraction that makes maintaining local changes as comfortable as maintaining a vendor branch. A big plus is that you do not need to take an extra step to generate diffs to send upstream, because you already have the diffs right in your .hg/patches directory. Conflict resolution works almost the same way as during a normal VCS's merge (whatever normal means in version control land :P), and as you get to incrementally make the patches in your queue apply again, you don't have to deal with a source tree full of all conflicts of a merge, but only with conflicts caused by a single patch at a time. Patch guards let you apply patches conditionally, this is where it gets interesting if you maintain changes for, say, RELENG_7 and CURRENT at the same time, and still
presenting WOL to the user (was: Re: How to add wake on lan support for your card)
On Wed, Nov 28, 2007 at 07:45:45PM +0100, Stefan Sperling wrote: On Wed, Nov 28, 2007 at 10:28:24AM -0800, Sam Leffler wrote: I really want to see the WOL support get into the tree. Cool. I looked at it before and had some issues with ifconfig integration which is mostly why it's not already there. You mean you are hacking on it as well (independently) or you were trying my patch? Sam, nevermind that question of mine. I thought about this again. I suppose you have issues with the way I made ifconfig present WOL information to the user? $ ifconfig vr0 vr0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet 10.42.42.2 netmask 0xff00 broadcast 10.42.42.255 ether 00:0b:6a:d5:1e:b1 media: Ethernet autoselect (100baseTX full-duplex) status: active --- supported wake events: unicast magic --- will wake on: magic Adding two new lines of output for a minor feature like that is indeed overkill. Actually I have been thinking about this for a while. Maybe the WOL information should somehow be integrated into interface flags? There would be quite a few wake on lan options to be squeezed into the flags though: magic packet, link status, unicast, broadcast, multicast (at least). This would look somewhat like: vr0: flags=UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,WOLMAGIC,WOLLINK,WOLUCAST,WOLBCAST,WOLMCAST mtu 1500 Would that be better? I don't know how crowded the flag bit space already is though, because I had no time to look at it yet. How do you think could the available WOL options be presented to the user? Clearly flags can't be used for this. Maybe we should simply drop this functionality, and operate like the ifconfig polling option -- simply return an error if the interface does not support the requested WOL event, but don't provide other means of finding out what it does actually support? Or should we introduce a special ifconfig subcommand to query this information? Has anyone got better ideas? Thanks, -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpIYcYWMyZfn.pgp Description: PGP signature
Re: How to add wake on lan support for your card (was: Re: FreeBSD WOL sis on)
On Wed, Nov 28, 2007 at 05:13:28PM +0100, Julian H. Stacey wrote: Well, I hope I haven't missed anything important, but I guess that's about it. Wow ! seems like you spent a fair time assembling that lot, About 2 hours. it'd sure be a shame if it just got dusty in mail archives, (OK apart from current readers who might latch it). Thanks. Maybe you could send it to [EMAIL PROTECTED] list or via send-pr suggest it be swallowed as an Annex to main docs ? Seems useful. I guess the wiki would be more appropriate than the main docs. Maybe we should add a wiki page about wake on lan? Reading http://wiki.freebsd.org/AboutWiki it seems that if I created an account there and someone added me to the ContributorsGroup for a new WakeOnLan page I would be good to go. Another place I could add it to is the wake on lan PR, which is at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/83807 Anyway, it's not lost in any case, because it's in the archives, and at least I know about it and can always link people there if they want to read it (or if they ask me to add support for their card, heheh). -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgp6zAcHHkE7k.pgp Description: PGP signature
Re: How to add wake on lan support for your card (was: Re: FreeBSD WOL sis on)
On Wed, Nov 28, 2007 at 07:57:57PM +0100, Alexander Leidinger wrote: Maybe we should add a wiki page about wake on lan? Reading http://wiki.freebsd.org/AboutWiki it seems that if I created an account there and someone added me to the ContributorsGroup for a new WakeOnLan page I would be good to go. This is right. If you tell us the name you registered (we have the convention to use FirstnameLastname), I try to get the time to add you. OK, I've created an account in the wiki. My login is StefanSperling Thanks :) -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpfGhqos5q8j.pgp Description: PGP signature
Re: FreeBSD WOL sis on
Hey David, (I'm Cc'ing this reply to hackers@ with David's consent.) On Sat, Nov 24, 2007 at 11:31:24PM -0800, David Leslie wrote: Have an Intel ITX size board (D201GLY2) with a SiS 900 NIC, which supports WOL and has a WOL-enabled FreeBSD driver, but does not actually wake after powering down (ACPI S5) from FreeBSD. Have verified that WOL works using ethtool in Linux. Am not a BSD user, but am attracted to the FreeNAS project which has recently integrated your WOL patch (hopefully a recent version). The sis driver supports at least two different types of cards. What does dmesg print for your card? I have only one type of NIC the sis driver supports and have only implemented support for this one: sis0: NatSemi DP8381[56] 10/100BaseTX port 0xac00-0xacff mem 0xdb001000-0xdb00 sis0: Silicon Revision: DP83816A From userspace it appears ready to set the NIC to wake (i.e. ifconfig returns will wake on: magic), but the system ignores magic packets and does not wake from FreeBSD. If the card type isn't a DP83815 or DP83816, this is a bug. The driver should not let you configure cards for WOL it has no support for. Have verified that there is no reconfiguration of the adapter as part of the FreeNAS shutdown scripts. I see that your patch integrates changes to this driver, so maybe you might have seen the issue on other platforms? Any ideas where to look as a next step-- would appear to be something in if_sis that is not working on this board? There are many things that can go wrong with WOL. Here's a quick checklist (the first three are probably not causing your problem because you've verified that WOL works with Linux): Is the WOL cable plugged in properly (if needed)? Are BIOS WOL settings OK? Is ACPI enabled (in BIOS and OS)? Have you used shutdown -p to shut down the box? Using shutdown -h or halt and then turning the power off might not work (at least I've never tried this...) Does the card enter D3 sleep mode properly after the box shuts down, i.e. does a NIC LED stay on after shutdown? Do wake packets (e.g. magic packets) actually reach the box? To find out, I do: while true; do wol -h 10.42.42.255 mac addr; sleep 1; done and then if the box doesn't wake up I look at the NIC LEDS to check for periodic blinking of the tx/rx LED. Adjust the broadcast IP address to your network of course. Hope this helps, -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgp1h7VugA2Up.pgp Description: PGP signature
Re: WOL not working with 3Com NIC
On Sat, Nov 03, 2007 at 04:47:05PM +0100, Stefan Sperling wrote: On Fri, Nov 02, 2007 at 09:16:59PM -0500, M E wrote: I am able to get will wake on: magic, when typing ifconfig in FreeNAS (built on FreeBSD); however, I am still unable to wake up the box. I know that xl does not work yet. Hi again, I finally got my development box running again with the help of two guys at uni (got a disk controller and a hard drive), many thanks :) I've just woken up a FreeBSD-7 box with a 3com card successfully. Having hardware to test with really helps. The rxfilter not being configured correctly was what prevented WOL from working with if_xl altogether. Also, I've added support for wake on link status change. This is currently used by if_xl only, but it's easy to add it to the other drivers, too. Test wake on link by unplugging the network cable before the box shuts down, and plug the cable back in - the box should now wake up. Quite a useless feature, but fun anyway :) New patches for RELENG_6_2 and RELENG_7 can be found here: http://www.stsp.name/wol/FreeBSD-6.2-wol-2007-11-25.diff http://www.stsp.name/wol/FreeBSD-7-wol-2007-11-25.diff Instructions here: http://www.stsp.name/wol/README.txt If you need other branches, please just try to apply one of the above and sort out the rejects - I have no time to maintain more than those two. There's still lots left to be done, especially additional device support. I'm also planning on getting rid of the secureOn password stuff in ifconfig because few chips support it and clear text passwords aren't really that secure at all. This will also trim the ioctl argument size down from a struct to a simple int. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpNZsTK9ympl.pgp Description: PGP signature
How to add wake on lan support for your card (was: Re: FreeBSD WOL sis on)
On Sun, Nov 25, 2007 at 10:53:59AM -0800, David Leslie wrote:
Linux does support WOL for (at least) this SiS900 NIC
(I can verify that it does work on this board), so
maybe it will be supported in FreeBSD in the future?
Sure, it's possible.
Adding support for a card is not that hard actually.
It can be done in one or two evenings by someone who has
messed with any kind of driver before, and maybe a week
by someone who hasn't and is willing to learn basics about
device drivers, e.g. how to access and manipulate registers from C.
Knowing C is a prerequisite of course. I myself had no idea at all
about drivers either before I started working on the WOL patch.
But I currently rarely have time to work on this (except the odd
Sunday like today), and I keep getting requests to support more
chipsets that queue up faster than I can handle :-/
Maybe if I provide a little guide some people will get interested
and help a bit.
Here it goes:
= How to add WOL support for your card =
To add WOL support for your card, and you have no data sheet
for the card, first look at the Linux driver to find out whether
the card can do WOL under Linux. There should be some routines for
configuring WOL. Look at the ethtool_ops struct, if the driver
sets pointers to get_wol and set_wol routines inside it, it supports WOL.
For example, the via-rhine driver on Linux (if_vr on FreeBSD)
does this:
static struct ethtool_ops netdev_ethtool_ops = {
// snip
.get_wol= rhine_get_wol,
.set_wol= rhine_set_wol,
// snip
Now that you know that you can get this to work, apply the WOL patch
to your system: http://stsp.næme/wol/
See the README.txt for instructions.
== How do I tell the chip on my card to do WOL? ==
You can do this in a new driver routine called dev_enable_wol(), where
dev_ is the usual driver name prefix, e.g. xl_enable_wol() for if_xl.
If you have a data sheet, it will probably tell you how to enable WOL
in detail. The data sheet for my NatSemi card is freely available
on the web and has a very good section on configuring wake on lan:
http://www.national.com/ds/DP/DP83815.pdf
Look at page 90 in that PDF. Even if your chip is different the general
procedure is likely the same on most chips so this serves as a good
example (along with a working implementation for the if_sis driver
in my patch). That page helped me getting started at lot.
How exactly WOL is configured depends on the device, but usually involves
a) configuring the receive filter
b) some WOL configuration register
c) putting the device into D3 (sleep) power state
=== The receive filter ==
The receive filter will simply need to accept *any* kind of packet.
There is usually a register in the chip with bits that define
what kind packets the receiver on the card should hand on to
the driver and which it should just ignore -- typically the filter
understands unicast, multicast and broadcast packet types.
In case of the 3com chip, the Linux driver (3c59x) does this in
the acpi_set_WOL() function to set the bits in the receive register:
/* The RxFilter must accept the WOL frames. */
iowrite16(SetRxFilter|RxStation|RxMulticast|RxBroadcast, ioaddr + EL3_CMD);
iowrite16(RxEnable, ioaddr + EL3_CMD);
The FreeBSD (almost) equivalent in xl_enable_wol() is this:
/* Configure the receive filter to accept any kind of packet. */
XL_SEL_WIN(5);
rxfilt = CSR_READ_1(sc, XL_W5_RX_FILTER);
rxfilt |= XL_RXFILTER_INDIVIDUAL | XL_RXFILTER_ALLMULTI |
XL_RXFILTER_BROADCAST | XL_RXFILTER_ALLFRAMES;
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_RX_SET_FILT | rxfilt);
Of course, register business is highly chip specific.
For example, other chips I've dealt with didn't have register
windows at all so the XL_SEL_WIN isn't needed there, and the bit
mask macros for the receive filter config register will of course
be named somewhat differently in each driver.
Of course, a data sheet helps. If you don't have one, looking
at what the Linux driver does and matching register offsets and
bit masks with the FreeBSD driver will probably help.
=== The WOL config register ===
The WOL config register is usually a 16bit (e.g. if_xl) or 32bit
(e.g. if_sis) register somewhere in the chip memory with each bit
corresponding to a certain type of wake event -- magic packet,
link status change, unicast packet reception, broadcast packet
reception, etc.
The device will only wake the system if an event happens that it has
been configured for.
Using the NatSemi card an example, there is a 32bit WOL configuration
register at offset 0x40 in the chip register space and bit number 9
(the 8th bit from the right) tells the chip to wake up if it receives
a magic packet. See the DP83815 data sheet again, page 55.
So to add wake on magic packet support, we add the follwing
to /usr/src/sys/dev/if_sisreg.h:
/* NS DP83815/6 registers */
// other registers omitted...
Re: How to add wake on lan support for your card (was: Re: FreeBSD WOL sis on)
On Sun, Nov 25, 2007 at 10:48:50PM +0100, Stefan Sperling wrote: Using the NatSemi card an example, there is a 32bit WOL configuration register at offset 0x40 in the chip register space and bit number 9 (the 8th bit from the right) As usual I got the numbers wrong :) Sorry if this is causing confusion for someone reading this. Just skip the text inside the parentheses. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpjhlMkV2P6m.pgp Description: PGP signature
Re: questions on development(7)
On Fri, Nov 09, 2007 at 04:56:24AM +, Aryeh M. Friedman wrote: 1. If I am modifing code and such should I have a local branch? You can either maintain a local branch or keep backing up your diffs against the main source tree. Which one is better depends on the size of your changes and your workflow. I've used both. Maintaining your own local branch means much more cvs-related overhead but may be worth it if you need your changes versioned properly. 2. If yes to #1 how do I setup keeping everything except my modified code in sync (and if possible to retro activally apply patchs from the local branch unto the main source tree [/usr/src2]) Just run cvsup to update your copy of the cvs repository as usual, it should not delete your branch. The development(7) man page says that it can in some cases delete your branch though, so you should regularly back up your branch as a diff against the upstream branch you are based on, and possibly back up your copy of the cvs repository before updating. 3. The documentation said very little about how to generate patchs between my local code and the main branch a. Ideally I want to set it up where when I am done with a modification it automatically creates a patch (I have never used CVS for anything except through csup and cvsup so I am totally lost here) I don't think this list is appropriate for basic CVS questions, but I give you a few hints anyway because development(7) does not mention them: You need to tag the point you are branching from in CVS, otherwise you cannot create meaningful diffs between your own branch and the upstream branch. So to create a branch you can actually use, you need to run the rtag command TWICE. For example, to branch RELENG_7, use: export CVS_LOCAL_BRANCH_NUM=424242 cvs -d $CVSROOT rtag -r RELENG_7 MY_BRANCH_BP cvs -d $CVSROOT rtag -r RELENG_7 -b MY_BRANCH You should also create descriptive tags on both branches before and after doing a merge, to make it easier to track what has been merged where and when. Otherwise continuously syncing your branch with upstream becomes a pain quickly. You can maintain several custom branches in a single repository by switching CVS_LOCAL_BRANCH_NUM. Just don't end up confusing your branches. Always use the same CVS_LOCAL_BRANCH_NUM setting for all tag and rtag commands operating on the same branch. Warning: Branching and merging in CVS is hard! Not because branching and merging in general is hard, but simply because CVS is brain damaged. You will very likely mess it up the first time. You should practise on a test repo until you feel confident that you understand it properly. For more information see http://cvsbook.red-bean.com/ and especially http://cvsbook.red-bean.com/cvsbook.html#Branches -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpJtXFRst0hc.pgp Description: PGP signature
Re: questions on development(7)
You won't be able to commit to the BSD repo from your server. Well, Aryeh wants to commit to a _local_ copy of the BSD repo. This works. See development(7). One thing the man page does not mention is that you need to change the commit hook in CVSROOT (which you only copy on first sync and never ever again) to simply 'exit 0' to allow commits. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpSKYuK7dRID.pgp Description: PGP signature
Re: WOL not working with 3Com NIC
On Fri, Nov 02, 2007 at 09:16:59PM -0500, M E wrote: Hello Stefan, Hello, I'm Cc'ing hackers@ in my reply to your mail so people can overhear this conversation. It would be great to get some help. I am able to get will wake on: magic, when typing ifconfig in FreeNAS (built on FreeBSD); however, I am still unable to wake up the box. I know that xl does not work yet. The driver hears you requesting WOL and internally makes a note to configure WOL at shutdown time. But configuring the device for WOL does not work correctly for some reason. I haven't yet figured out what exactly the problem is, even with looking at the specs. The NIC is a 3Com EtherLink XL 10/100 PCI For Complete PC Management NIC (3C905C-TX). I've found 3 spare ones of those at uni I could bring home to test with. There have been requests for fxp (Intel) support, too, and by accident I also found one of those cards at uni in a spare server no one was using. But the hard disk in my development box is dying, I have to get it replaced. And my desktop got a new motherboard a while ago. The old one had bad capacitors, it was totally unstable so I returned it. I only later realised that the new one has no WOL connector! Doh! So now I finally have some cards, but no hardware to use them with. It used to be the other way around for like a year or more. Meh :-/ I need to find some time to buy a disk and set up my dev box again before I can continue working on this. Do you have any sugestions? My free time is scarce at the moment. More eyes and brains to throw at the problem would really, really help. There are data sheets for 3com cards at http://people.freebsd.org/~wpaul/3Com/ If someone found something obviously wrong in the xl_enable_wol() routine it would help an awful lot. I already went over it twice but I cannot find the error. It could also be something else the driver is doing behind my back that prevents WOL from working. I'm not experienced enough in device drivers to really understand all the subtleties of the whole thing. For those who don't know, the WOL patch is here: http://stsp.name/wol/ -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpOKC0DxOzZr.pgp Description: PGP signature
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
On Mon, Jun 25, 2007 at 12:45:37PM -0500, Stephen Montgomery-Smith wrote: Also, does setting CPUTYPE make a lot of difference to performance? I don't notice any difference in performance on my Athlon xp 2400 box if I set CPUTYPE=athlon-xp vs. leaving it alone. YMMV though, ask the gentoo people :) Right now I have no CPUTYPE set at all. Also leaving CPUTYPE unset means I can plug the system disc into any other old x86 box without hitting illegal instructions. In case my motherboard fries itself again some time like the old one did a few weeks ago I'll be glad I can do this. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpJ6Nazagig5.pgp Description: PGP signature
Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD
On Sun, Jun 10, 2007 at 04:45:04PM +0200, Stefan Sperling wrote:
I usually use either if_em or if_xl chipsets, so I hoped landing this code
in at least -CURRENT (should go there first, I guess) would result in more
chipsets supported ;)
There is code for enabling wake on lan in the Linux drivers for both
if_xl and if_em cards. See drivers/net/3c59x.c and
drivers/net/e1000/e1000_ethtool.c in the linux source tree.
So I don't think adding support for these cards is a problem.
Just need to find some time to do it...
Updated patch attached. Also available at http://stsp.name/wol/
Now contains untested support for if_xl. Please test.
I have no such card so I cannot test this myself.
Note that apparently only 3C905B type cards support wake on lan.
And they only support magic packet events, no unicast, broadcast
or multicast events.
The patch is against RELENG_6_2. Sorry I have no -CURRENT system
set up at the moment. I don't know if the patch even applies to
-CURRENT.
Once if_xl is working I'll look into getting if_em supported.
If any nve users are reading this, I still need feedback
on if_nve as well. I cannot test nve myself either.
Thanks,
--
stefan
http://stsp.name PGP Key: 0xF59D25F0
Index: sbin/ifconfig/Makefile
===
RCS file: /usr/local/ncvs/src/sbin/ifconfig/Makefile,v
retrieving revision 1.29
diff -u -u -r1.29 Makefile
--- sbin/ifconfig/Makefile 5 Jun 2005 03:32:51 - 1.29
+++ sbin/ifconfig/Makefile 6 May 2006 11:08:41 -
@@ -28,6 +28,8 @@
SRCS+= ifbridge.c # bridge support
+SRCS+= ifwol.c # wake on lan support
+
.if !defined(RELEASE_CRUNCH)
SRCS+= af_ipx.c # IPX support
DPADD= ${LIBIPX}
Index: sbin/ifconfig/ifconfig.8
===
RCS file: /usr/local/ncvs/src/sbin/ifconfig/ifconfig.8,v
retrieving revision 1.95.2.17
diff -u -u -r1.95.2.17 ifconfig.8
--- sbin/ifconfig/ifconfig.8 3 Nov 2006 09:14:24 - 1.95.2.17
+++ sbin/ifconfig/ifconfig.8 13 Jan 2007 12:18:33 -
@@ -939,6 +939,27 @@
If that is the case, then the first four keys
(1-4) will be the standard temporary keys and any others will be adaptor
specific keys such as permanent keys stored in NVRAM.
+.It Cm wakeon Ar events
+Enable Wake On Lan support, if available. The
+.Ar events
+argument is a comma seperated list of package types that shall
+trigger wake events. The set of valid package types is
+.Dq Li unicast ,
+.Dq Li multicast ,
+.Dq Li broadcast ,
+and
+.Dq Li magic .
+These enable wake on unicast, multicast, broadcast and Magic Packet(tm),
+respectively.
+A SecureOn password, if supported, can be be enabled using the
+.Dq Li sopasswd:password
+event.
+SecureOn passwords only work in combination with
+.Dq Li magic .
+The password must consist of 12 hexadecimal digits.
+.It Fl wakeon
+Disable Wake On Lan.
+.Pp
.It Cm wme
Enable Wireless Multimedia Extensions (WME) support, if available,
for the specified interface.
@@ -946,7 +967,6 @@
efficient communication of realtime and multimedia data.
To disable WME support, use
.Fl wme .
-.Pp
The following parameters are meaningful only when WME support is in use.
Parameters are specified per-AC (Access Category) and
split into those that are used by a station when acting
Index: sbin/ifconfig/ifwol.c
===
RCS file: sbin/ifconfig/ifwol.c
diff -N sbin/ifconfig/ifwol.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sbin/ifconfig/ifwol.c 20 Oct 2006 10:29:10 -
@@ -0,0 +1,229 @@
+/* $Id$ */
+
+/*
+ * Copyright (c) 2005 Stefan Sperling.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote products
+ *derived from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
+ * BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
+ * AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT
Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD
On Sat, Jun 09, 2007 at 05:07:39PM +0200, Edwin Mons wrote: I currently have one -CURRENT machine, and several 6.2-STABLE machines. For at least two of them (the -CURRENT and an x86 -STABLE machine) I'd really like to have WoL support, as these are my workstation and a home server, both of them really do not need to be on all the time, but I want to be able to reach them when I need a file from them when I'm elsewhere. Yes, wake on lan, if used properly, makes computers a bit more friendly to the environment :-) I usually use either if_em or if_xl chipsets, so I hoped landing this code in at least -CURRENT (should go there first, I guess) would result in more chipsets supported ;) There is code for enabling wake on lan in the Linux drivers for both if_xl and if_em cards. See drivers/net/3c59x.c and drivers/net/e1000/e1000_ethtool.c in the linux source tree. So I don't think adding support for these cards is a problem. Just need to find some time to do it... If anyone has data sheets for these cards I'd like a copy if possible. By the way if anyone has data sheets for if_vr I'd like a copy as well please because there is something the Linux driver does that I do not understand because the code is not obvious enough. Specifically I need to understand what the hell they mean exactly by patterns for WOL. If anyone has a card that does wake on lan after shutdown from Linux but not after shutdown from FreeBSD with my patch applied let me know. You may need to use the ethtool utility to enable WOL on Linux. I don't run Linux on either machine. Perhaps I could do some tests on my workstation with a CD-based linux distribution. No need to test your cards with Linux since we know now there is code for this in Linux so it should work anyway. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpOZxTHbA4SM.pgp Description: PGP signature
Re: kern/83807: [sis] [patch] if_sis: Wake On Lan support for FreeBSD
On Sat, Jun 09, 2007 at 11:08:01AM +0200, Edwin Mons wrote: Will this feature ever be incorporated in mainstream FreeBSD? I'm eagerly waiting for it to land in -CURRENT... I have no idea. I haven't got much feedback on this patch, apart from one or two people who sent me a quick thank you note :) So I have no idea how many people are actually using the patch. I know that: * if_sis and if_vr wake on lan support is very stable for me. I've been using this code for nearly 2 years now. * if_nve support has afaik never been tested (plus it's a binary blob driver and will apparently be replaced with OpenBSD's nfe driver soon.) I run a single 6.2 box here that I maintain the patch for. I'd be happy to setup a -current box to port the patch to -CURRENT. But I need to know whether it's worth doing the work. I'd like to get feedback on my patch by someone who is willing and able to help me get it into the tree. I need to know what needs to be done and/or changed to make the patch ready for mainline. There are some small bits in the patch that are incomplete, e.g. secure on password support. I've been thinking about simply dropping this feature because I consider it useless but ymmv. I'd also be happy to add WOL support for more chipsets. Adding support is relatively easy as long as another open source OS (e.g. Linux) supports wake on lan for a chipset and even easier if a good datasheet is available (as in case of if_sis). If anyone has a card that does wake on lan after shutdown from Linux but not after shutdown from FreeBSD with my patch applied let me know. You may need to use the ethtool utility to enable WOL on Linux. Cc'ing hackers@ in case someone there is interested in helping out. Kind regards, Edwin Mons -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpnZkvUQyfvv.pgp Description: PGP signature
Re: Freebsd 6.2 panic
On Tue, May 29, 2007 at 10:56:40PM +0200, didier derny wrote: I have some machines running php/mysql/postfix from time to time the computers running FreeBSD 6,2 crashes with the following messages fatal trap 12:page fault while in kernel mode cpuid=0; apic id=00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer= 0x20:0xc066c731 stack pointer=0x28:0xe74fec90 frame pointer=0x28:0xe74fec9c code segment=base 0x0,limit 0xf,type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflag=resume,IOPL=0 Is it always the exact same panic or is it random? A box here had a few random trap 12 page fault panics recently, especially while booting up cold but also at run time, and the problem turned out to be bad capacitors on the motherboard. If you have physical access look at the capacitors on the board to see if they are bulged of even leak. cannot dump. no dump device defined You might want to configure dumping, see dumpon(8). Look at the traces you get from the dumps: kgdb /boot/kernel/kernel dumpfile bt It helps to run a kernel compiled with DEBUG=-g. I think this is default in GENERIC on 6.2. If the crashes are at seemingly random points in the kernel code you probably have a hardware problem. If it's always the same trace then post it. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpIIlOG5NjCt.pgp Description: PGP signature
Re: Problems with FreeBSD 6.0
On Wed, Apr 12, 2006 at 07:22:27PM -0400, Kris Kennaway wrote: On Wed, Apr 12, 2006 at 10:48:44PM +, [EMAIL PROTECTED] wrote: I tried out FreeBSD 6.0 (sorry, I copied just part or uname -a and I got something like LINUX 2.4.2 FreeBSD 6.0 - Release #0: Nov 3 09:36:13 UTC 2005 i686 i686 i386 GNU/LINUX) No you didn't, since no version of FreeBSD reports itself as LINUX from uname. Unless uname is a Linux binary. -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
On Thu, Apr 06, 2006 at 12:37:03PM -0700, Darren Pilgrim wrote: Access control is done via permissions of files in /dev. If I have proper permissions to a device file, I can mount it at a directory I own. If I don't have proper permissions to a device file, I cannot mount it at all. This has nothing to do with fstab. But it does. GNOME/KDE provides a means of mounting devices by users that would otherwise require a suid mount program. If GNOME/KDE allowed this functionality to be used directly with devices, rather than through fstab, then without writing an parallel access control system into GNOME/KDE, there would be nothing stopping a user from exploiting it to mount system volumes. So GNOME/KDE are already using suid binaries for mounting? I do not see how else users would be able to mount arbitrary volumes. People said they do not like suid binaries. This is exactly what could be avoided with just using vfs.usermount to control mounting from within KDE/GNOME. Proper access control system is already there with vfs.usermount and /dev permissions. No need to write a parallel system. There is one already - in fact, it looks like GNOME/KDE are already duplicating functionality. I don't really see a reason to have suid binaries at all if you have something like vfs.usermount. It is much better than how Linux does it (/bin/mount is setuid in Linux). That's true - but you could provide sane default options, and make them changable via the gui. If there are quotas on a file system, or anything else you don't want the user to mess with, well, don't give the user access to the device node in /dev. That's the point exactly, we don't want users having direct access to the device nodes. fstab allows that by providing a means of referencing device nodes without specifying them to the mount command and also allows devices to be marked with the filesystem and mount options desired. If GNOME/KDE had code to parallel fstab, then the GNOME/KDE developers have to keep up with changes to available filesystems and mount options for every supported OS out there. That's a lot of work just to parallel and already adequate system. It's true that changing the way GNOME and KDE operate involves lots of porting work. But that's what the FreeBSD/KDE and FreeBSD/Gnome projects are there for, aren't they? I bet they've made much larger adjustments than changing they way mounts are handled (but I don't know and I'm just bluntly guessing here). And the current system is not adequate: Consider massive multi-user installations, like university computer pools. You don't want to list every student in fstab just so they can mount a CD or a USB stick. I do not administrate an environment on that scale, but I know people who do and they told me they find it easier to do administrate large pools with Linux, because it has a user mount option for fstab. -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote: So why not have GNOME/KDE create mount points for the user if vfs.usermount is 1? pardon my ignorance, but how any of those methods described earlier may be superior to simply using sudo? Using sudo is a hack? :) -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
On Wed, Apr 05, 2006 at 01:37:11PM +0100, Jan Grant wrote: On Wed, 5 Apr 2006, Stefan Sperling wrote: On Tue, Apr 04, 2006 at 09:52:17PM -0800, [EMAIL PROTECTED] wrote: So why not have GNOME/KDE create mount points for the user if vfs.usermount is 1? pardon my ignorance, but how any of those methods described earlier may be superior to simply using sudo? Using sudo is a hack? :) I don't buy that aesthetic argument. I wasn't serious. Sudo is fine by me as well. However, having something that is in the base system (and not in ports) to allow user mounts would be neat. Still, KDE and GNOME and even xorg are in ports as well, so that point is not a really strong one either. The only thing that still nags me about the sudo solution is that if you have to use sudo anyway, why was vfs.usermount even implemented in the first place? Using sudo makes it redundant. -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RFC: Adding a ``user'' mount option
On Tue, Apr 04, 2006 at 02:47:18AM -0400, Joe Marcus Clarke wrote: On Tue, 2006-04-04 at 08:30 +0200, Alex Dupre wrote: Joe Marcus Clarke wrote: What I'd like to achieve is a simple out-of-the-box way of mounting media such as CDs, and floppy disks without users necessarily needing to know about sysctl. While I can't speak for KDE, I know GNOME already has the ability to detect user-mountable media, and gives the users icons on the desktop to mount said volumes. I don't know what exactly you mean with 'detect user-mountable media', but a KDE user may have desktop icons for every device/fs listed in /etc/fstab. I assume GNOME works in a similar way. And clicking on the icon of course will mount the media with the 'mount' command. KDE also monitor changes to the fstab file and can open a dialog window when a new media appears, but since the fstab file is not automatically updated on FreeBSD (I don't know how it works exactly on Linux) this feature is quite useless. GNOME works in a similar fashion. Currently if vfs.usermount=1, FreeBSD scans the fstab list, and if the mount point is owned by the current user, it adds an icon for it. Why do GNOME/KDE rely on /etc/fstab on FreeBSD? What are admins supposed to do on systems with more than, say, a hundred users. Having to add a line to /etc/fstab for every user is of course scriptable, but that does not make it less insane. As far as I got it, the current design boils down to the user creating a mount point, and then mounting the media manually, e.g. mount /dev/cd0 ~/cdrom. Granted the admin has set vfs.usermount to 1, of course. I don't really think that user mount has been designed with /etc/fstab in mind. So why not have GNOME/KDE create mount points for the user if vfs.usermount is 1? Since FreeBSD uses devfs, every device in /dev that usually represents a device with removable media can assumed to be present in hardware. GNOME/KDE could be patched to create mount points somewhere in the user's home directory, and issue a 'mount device mount_point' instead of 'mount mount_point' if the user clicks the device icon. This still requires novice home desktop users to set vfs.usermount to 1 though, so it's not a perfect solution. But it prevents having another suid binary just for convinience, and is suitable for large multi user installations. For dynamic updates, Linux has mtab. For FreeBSD (in GNOME, that is), we just periodically check for changes in the list of available file systems. Where? In /etc/fstab or /dev ? -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel hack
Sorry, this went to -current by accident, but should have gone here... - Forwarded message from Stefan Sperling [EMAIL PROTECTED] - Date: Sun, 25 Sep 2005 18:35:53 +0200 From: Stefan Sperling [EMAIL PROTECTED] To: kamal kc [EMAIL PROTECTED] Cc: freebsd-current@freebsd.org Subject: Re: kernel hack On Sun, Sep 25, 2005 at 03:31:51AM -0700, kamal kc wrote: does anybody know what is the best way to start kernel hack. IMHO, the best way to start kernel hacking is to invest an awful lot of time into reading books. I presume you know C _really_ well already :) And by really well I also mean you know what is wrong about C! Any modern book on writing device drivers should be a good starting point. It does not really matter which UNIX-derivative the book is about. Hint: There are a lot of these books about Linux. Read programmer's datasheets, preferably for devices you own, and learn how to talk to registers from C. ftp.alsa-project.org has datasheets for sound cards, for example. Make sure you also learn about multi-threading (mutexes, semaphores etc). A lot of kernels are multi-threaded these days. A very good overview of the FreeBSD kernel is given in The Design and Implementation of the FreeBSD Operating System, by Mr. McKusick and Mr. Neville-Neil. Read all of it. Having learned about drivers and multi-threading beforehand helps a lot. Any references to any web page would be appreciated Get books, it's worth it! You really don't want to read this much material on your monitor! (Unless you have a 28 TFT of course ;). Plus books are often much better written, easier to understand, and a lot more detailed than tutorials on the web. http://www.NetBSD.org/Documentation also has an interesting kernel section to get you started before your books arrive :) -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 - End forwarded message - -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to use the function copyout()
On Mon, Jul 25, 2005 at 04:35:20PM +0400, Felix-KM wrote: I can't understand how to use the function copyout(). It is necessary to write the data from a device driver to the array defined in user program. I do it this way: #define IOCTL_GET_B_IOWR(F, 127, 0x4) snip Here I get EFAULT. What have I done wrong? How can I do it correctly? You may need to add your ioctl to another middle layer. For example, to add ioctls to network devices, I first added defines to sockio.h only, and it wouldn't work (device not configured). Then I found out that I had to add my ioctls to a rather large switch statement in if.c too. hope this helps, -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
rfc: wake on lan patches for review
Hello Hackers, I have written a patch for the if_sis driver that enables wake on lan on the NatSemi DP8381[56] network chip. This did not work before because the driver needs to explicitely configure the card to enter wake on lan mode on system shutdown. I also added ioctls to make wake events configurable from userspace, and added an according 'wakeon events' command to ifconfig. The ioctls should be general enough to be used with other chips that require a similar configuration procedure for wake on lan. Before making efforts to get this committed I'd appreciate any comments and suggestions you may have. I'd especially appreciate people trying this at home if they have access to a network card with above mentioned chip. If you have a different card with wake on lan support that did not yet work as expected (i.e. your box does not wake up after shutting it down from FreeBSD), and have a datasheet available you might want to have a look at my code as an example on how to add wake on lan support to your card's driver. In my case, there wasn't much more to it than writing a couple of registers during the driver's shutdown procedure and implementing the new ioctls. You can find the patch at http://stsp.in-berlin.de/wol/ The patch applies cleanly to -current as of July 17th, and will probably apply to RELENG_6 just as well. regards, -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
bus error in strsep
Hello hackers,
I am getting a bus error in my application when I call strsep
and it matches a character. It doesn't matter whether I call
the strsep from my libc or a freshly compiled one, the error
stays the same.
This is my test case:
$ cat strsep.c
#define NULL ((void*)0)
/* copied verbatim from /usr/src/lib/libc/string/strsep.c,
* except for the name change
*/
char *
mystrsep(stringp, delim)
char **stringp;
const char *delim;
{
char *s;
const char *spanp;
int c, sc;
char *tok;
if ((s = *stringp) == NULL)
return (NULL);
for (tok = s;;) {
c = *s++;
spanp = delim;
do {
if ((sc = *spanp++) == c) {
if (c == 0)
s = NULL;
else
s[-1] = 0;
*stringp = s;
return (tok);
}
} while (sc != 0);
}
/* NOTREACHED */
}
int main(int argc, char* argv[])
{
char *c = whats:your:name:buddy?;
(void*)mystrsep(c, :);
}
$ gcc -g -o strsep strsep.c
$ gdb strsep
gnu license
(gdb) run
Starting program: /home/stsp/test/strsep
Program received signal SIGBUS, Bus error.
0x080484f2 in mystrsep (stringp=0xbfbfea34, delim=0x80485e6 :) at strsep.c:26
26 s[-1] = 0;
(gdb) print s[-1]
$1 = 58 ':'
(gdb)
When I single step through mystrsep the program works fine.
I am running FreeBSD-current from 17th June 2005 on an Athlon-XP,
no SMP involved. I can reproduce the error on a dual Celeron box
running FreeBSD-5.4-RELEASE with SMP.
And I also get the same error with similar code using strtok.
Can anyone else reproduce this?
thanks a lot,
--
stefan
http://stsp.in-berlin.de PGP Key: 0xF59D25F0
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bus error in strsep
On Wed, Jul 06, 2005 at 12:10:23PM -0700, Maksim Yevmenkin wrote: Maksim Yevmenkin wrote: char *c = whats:your:name:buddy?; that is not read only copy. you can not write into it. replace it with made type. that should read that is read only copy :) Dark corners of C... So it's my own fault, as usual :) thanks a lot :) -- stefan http://stsp.in-berlin.de PGP Key: 0xF59D25F0 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
