Re: bfe0: couldn't map memory
On 1/13/07, Nuno Antunes <[EMAIL PROTECTED]> wrote: Hi, I'm having trouble getting my bfe network interface card to work on dragonfly. Ooh, this is on HEAD from yesterday. Thanks, Nuno
bfe0: couldn't map memory
Hi, I'm having trouble getting my bfe network interface card to work on dragonfly. The following appears on dmesg (hand transcribed): bfe0: irq 17 at device 1.0 on pci6 bfe0: couldn't map memory device_probe_and_attach: bfe0 attach returned 6 The interface does not appear on "ifconfig -a" Any help would be very appretiated. Thanks, Nuno
Re: bfe0: couldn't map memory
On 1/13/07, Nuno Antunes <[EMAIL PROTECTED]> wrote: Hi, I'm having trouble getting my bfe network interface card to work on dragonfly. The following appears on dmesg (hand transcribed): bfe0: irq 17 at device 1.0 on pci6 bfe0: couldn't map memory device_probe_and_attach: bfe0 attach returned 6 The interface does not appear on "ifconfig -a" Any help would be very appretiated. http://leaf.dragonflybsd.org/mailarchive/users/2006-01/msg00097.html Hope this will be helpful. Best Regards, sephe -- Live Free or Die
Re: bfe0: couldn't map memory
On 1/13/07, Sepherosa Ziehau <[EMAIL PROTECTED]> wrote: On 1/13/07, Nuno Antunes <[EMAIL PROTECTED]> wrote: > Hi, > > I'm having trouble getting my bfe network interface card to work on > dragonfly. The following appears on dmesg (hand transcribed): > > bfe0: irq 17 at device 1.0 on pci6 > bfe0: couldn't map memory > device_probe_and_attach: bfe0 attach returned 6 > > The interface does not appear on "ifconfig -a" > > Any help would be very appretiated. http://leaf.dragonflybsd.org/mailarchive/users/2006-01/msg00097.html Hope this will be helpful. Best Regards, sephe -- Live Free or Die Hi Sephe, Thanks for the tip. A BIOS upgrade solved it. Cheers, Nuno
Re: Request for swapcontext and getcontext to be ported to our libc
Ah sh*t. Devs: have you got any comment on this and what are the chances of updating gcc 3.4 before the release? Petr Matt Emmerton wrote: Petr, Based on information scattered about the Internet, as well as what the FreeBSD folks have done, it appears that powerdns-recursor requires gcc-3.4.6 to compile properly. This is a problem as DFly's native gcc is 3.4.5 and the pkgsrc version of 3.4.6 does not support DFly. To do this right, we will need DFly to support the 3.4.6 compiler before we can support this package. Regards, -- Matt Emmerton I see. What about getting someone to get powerdns-recusor compiling and running? Once that is done we shall arrange for your payment. Petr Matt Emmerton wrote: Hey, Any progress on the fully libc *context functions? I've toyed with it a bit, but there are some issues I'm not sure how to solve (such as accessing curthread -- a kernel construct -- from userland). I would welcome discussion with the person who suggested it (corecode?). Also, I felt it pertinent to focus on the quick-start FreeBSD port to get it into the 1.8-release. -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
On Sun, Jan 14, 2007 at 03:17:33AM +1100, Petr Janda wrote: > Ah sh*t. > > Devs: have you got any comment on this and what are the chances of > updating gcc 3.4 before the release? > > Petr I'd say the chances are very high. --Peter pgpniW7BHjGIr.pgp Description: PGP signature
Re: Request for swapcontext and getcontext to be ported to our libc
Petr Janda wrote: Devs: have you got any comment on this and what are the chances of updating gcc 3.4 before the release? the commit just went in. cheers simon PS: could you (and others) please try and avoid top-posting? this full quote thing is making mails really unreadable. -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /"\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \ signature.asc Description: OpenPGP digital signature
Re: Request for swapcontext and getcontext to be ported to our libc
> :So is the current context code going into cvs HEAD or whats happening? > : > :Petr > > I'm going to let the discussion continue for another day or two but > I will note that Matt is the person doing the work so it depends on > how much time he has available to do the libc version prior to the > release (assuming he agrees with the assessment that it is better to > do the libc version for the release then the syscall version). > > -Matt I agree with the assessment. Last night I moved all the requisite bits from kernel-space into libc, with the exception of the low-level [get|set]_mcontext routines. (My Intel assembly knowledge is very limited, especially for anything after the 8086, so I could use some help to write this code.) I'm almost done the syscall work to get/set the signal mask and pending signal mask, so should have something up on the web before the end of the afternoon (EST) for review. Regards, -- Matt Emmerton
Re: Request for swapcontext and getcontext to be ported to our libc
:I agree with the assessment. Last night I moved all the requisite bits from :kernel-space into libc, with the exception of the low-level :[get|set]_mcontext routines. (My Intel assembly knowledge is very limited, :especially for anything after the 8086, so I could use some help to write :this code.) I'm almost done the syscall work to get/set the signal mask and :pending signal mask, so should have something up on the web before the end :of the afternoon (EST) for review. : :Regards, :-- :Matt Emmerton I can do that bit. If you post the bits you have I can supply and test the low level switch code. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: RFR: Port of FreeBSD *context routines to DFly
Oh. I am going to commit the mcontext structural changes right now. In fact, since I have already ripped up the signal context, I am going to make the same changes to struct sigcontext. That is, adding the mc_len, mc_fpformat, and mc_ownedfp fields. This also properly aligns the FP context in the structure and will allow better handling of the floating point state. -Matt Matthew Dillon <[EMAIL PROTECTED]>
Re: Request for swapcontext and getcontext to be ported to our libc
I found one other issue, and that is we can't really determine whether the FP unit is being used from userland or generate an exception-on-first-use visible to userland, which means we can't optimize-out the FP state save/restore. I don't think this is a showstopper, though. For now we can just unconditionally save/restore the FP state... it only takes 69ns or so on my test box for a save+restore sequence. Later on the kernel can easily supply the required information via shared memory or something similar (along with the signal mask and pending bits). Either way, just doing it uncoditionally is still far faster then making a system call. -Matt Matthew Dillon <[EMAIL PROTECTED]>
why null kernel module? why kernel listed in kldstat?
Why would someone use "null" kernel module? Is "nullfs" same as "null"? If so, how is loader configuration called nullfs_load while file is null.ko? I see a system that has "null" listed by kldstat but nullfs_load is NO (by default). Why is kernel also listed in kldstat output? Jeremy C. Reed
Re: why null kernel module? why kernel listed in kldstat?
Jeremy C. Reed wrote: Is "nullfs" same as "null"? If so, how is loader configuration called nullfs_load while file is null.ko? nullfs == null.ko It's a typo in the default loader.conf, I guess. I'll fix it along with some other stuff. Sascha -- http://yoyodyne.ath.cx
Re: why null kernel module? why kernel listed in kldstat?
On Sun, 14 Jan 2007, Sascha Wildner wrote: > Jeremy C. Reed wrote: > > Is "nullfs" same as "null"? If so, how is loader configuration called > > nullfs_load while file is null.ko? > > nullfs == null.ko > > It's a typo in the default loader.conf, I guess. I'll fix it along with some > other stuff. I may misunderstand still... I think the loader.conf is probably correct, but the kernel object should be called nullfs.ko? As it is now, I am confused because I never heard of null(4) for /dev/null being a kernel module. Anyone have a nullfs(4) manual page? Jeremy C. Reed
Re: why null kernel module? why kernel listed in kldstat?
Jeremy C. Reed wrote: It's a typo in the default loader.conf, I guess. I'll fix it along with some other stuff. I may misunderstand still... I think the loader.conf is probably correct, but the kernel object should be called nullfs.ko? As it is now, I am confused because I never heard of null(4) for /dev/null being a kernel module. Anyone have a nullfs(4) manual page? I think the convention here is that the information related to the msdos.ko, null.ko, ext2fs.ko, etc. modules is on the respective mount_(8) manpage, e.g. mount_null(8). Sascha -- http://yoyodyne.ath.cx
Re: why null kernel module? why kernel listed in kldstat?
Hello, On 14-01-2007, Jeremy C. Reed <[EMAIL PROTECTED]> wrote: > As it is now, I am confused because I never heard of null(4) for /dev/null > being a kernel module. > > Anyone have a nullfs(4) manual page? Those are different beasts: see mount_null(8). Regards, Francis
DWL-G650EU
Hello, I'm trying to have a DLink wifi adapter working (model DWL-G650EU, H/W ver. C2 F/W ver. 3.1.6). I kldload if_ath and then insert the card. Here's the console output: -- found-> vendor=0x168c, dev=0x0013, revid=0x01 class=[NETWORK]02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x0a (2500 ns), maxlat=0x1c (7000 ns) intpin=a, irq=255 Manufacturer ID: 71021200 Product version: 7.1 Product name: Atheros Communications, Inc. | AR5001-- | Wireless LAN Reference Card | 00 | Functions: Network Adaptor, Memory Function Extension: 02808d5b00 Function Extension: 0240548900 Function Extension: 02001bb700 Function Extension: 0280a81201 Function Extension: 0200366e01 Function Extension: 0200512502 Function Extension: 02006cdc02 Function Extension: 0280f93703 Function Extension: 0200a24a04 Function Extension: 0308 Function Extension: 0406047f Function Extension: 0501 CIS reading done ath0.cardbus0.cbb0.pci0.pcib0.legacypci0.nexus0.root0 ath0: [tentative] mem 0x8801-0x8801 irq 10 at device 0.0 on cardbus0 ath0: unable to attach hardware; HAL status -- I tried to rebuild the modules with AH_DEBUG and AH_DEBUG_ALQ defined, and also assigned '1' to sysctl hw.ath.debug, but got nothing more. Any chance to get it up and usable ? Thanks in advance for your help, Francis
