Date: Mon, 29 Jan 2007 00:17:39 +0000 From: "Hugo Alfredo Cano Bravo" <bckno@hotmail.com> To: freebsd-hackers@freebsd.org Subject: RE: freebsd-hackers Digest, Vol 200, Issue 7 Message-ID: <BAY110-F7255331A6749F061315CDA4A70@phx.gbl> In-Reply-To: <20070128120039.E125916A4F6@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I want to be a member. What can I do.? >From: freebsd-hackers-request@freebsd.org >Reply-To: freebsd-hackers@freebsd.org >To: freebsd-hackers@freebsd.org >Subject: freebsd-hackers Digest, Vol 200, Issue 7 >Date: Sun, 28 Jan 2007 12:00:39 +0000 (UTC) > >Send freebsd-hackers mailing list submissions to > freebsd-hackers@freebsd.org > >To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >or, via email, send a message with subject or body 'help' to > freebsd-hackers-request@freebsd.org > >You can reach the person managing the list at > freebsd-hackers-owner@freebsd.org > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of freebsd-hackers digest..." > > >Today's Topics: > > 1. Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN > controller (Gilbert Cao) > 2. Review request: new OMNIKEY CardMan 4040 driver > (Daniel Roethlisberger) > 3. sysctl(3) interface (Daniel Rudy) > 4. how to determine if we are building lib32 in Makefile? > (Rong-en Fan) > 5. Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN > controller (Sam Fourman Jr.) > 6. Re: atacontrol kernel crash (atausb?) (M. Warner Losh) > 7. Re: unique hardware identification (Daniel Rudy) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Sat, 27 Jan 2007 11:19:00 +0100 >From: Gilbert Cao <hika@bsdmon.com> >Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN > controller >To: Benjamin Close <Benjamin.Close@clearchain.com> >Cc: Massimo Lusetti <mlusetti@gmail.com>, Florent Thoumie > <flz@freebsd.org>, freebsd-hackers@freebsd.org, > freebsd-drivers@freebsd.org, Attilio Rao <attilio@freebsd.org>, > damien.bergamini@free.fr, sam@freebsd.org, gabor@freebsd.org, Max > Laier <max@love2party.net> >Message-ID: <20070127101900.GB1099@bsdmon.com> >Content-Type: text/plain; charset="us-ascii" > >On Fri, Jan 26, 2007 at 11:09:51PM +1030, Benjamin Close wrote: > > Hi Gilbert, > > Thanks for the custom version. I've integrated the changes into the > > driver I'm working on. > > For those wanting to test out the driver which is now fully up to date > > with all change from NetBSD & OpenBSD - and has a few minor improvements > > over them, grab it from: > > > > http://www.clearchain.com/~benjsc/download/ > > > > File is: 20070125-wpi-freebsd.tar.gz > > > > Full instructions on how to build / install the driver are in the README > > in the tar file. > > > > This should work both under -current and 6.2-Stable now. > > > > Info about the driver and what's working/broken can be found at: > > > > http://www.clearchain.com/wiki/wpi > > > > Cheers, > > Benjamin > >I have tried the new 20070125 version. >However, I did not manage to make work. At least, it compiles. >I have installed, both wpi_fw.ko and the if_wpi.ko, as the README said. >wpi_fw.ko lies in /boot/modules and if_wpi.ko in /boot/kernel. > >When, I "kldload if_wpi", here is a small sample of /var/log/messages > >Jan 27 10:30:39 vaio kernel: wpi0: <Intel(R) PRO/Wireless 3945ABG> mem >0xcc000000-0xcc000fff irq 18 at device 0.0 on pci6 >Jan 27 10:30:39 vaio kernel: bus_dmamem_alloc failed to align memory >properly. >Jan 27 10:30:39 vaio last message repeated 6 times >Jan 27 10:30:39 vaio kernel: wpi0: Ethernet address: 00:18:de:5c:cb:9a >Jan 27 10:30:39 vaio kernel: wpi0: [GIANT-LOCKED] >Jan 27 10:30:39 vaio kernel: wpi0: 11a rates: >Jan 27 10:30:39 vaio kernel: wpi0: 11b rates: >Jan 27 10:30:40 vaio kernel: firmware_get: failed to load firmware image >wpi_fw >Jan 27 10:30:40 vaio kernel: wpi0: could not load firmware image 'wpi_fw' >Jan 27 10:30:40 vaio kernel: firmware_get: failed to load firmware image >wpi_fw >Jan 27 10:30:40 vaio kernel: wpi0: could not load firmware image 'wpi_fw' >Jan 27 10:32:19 vaio kernel: firmware_get: failed to load firmware image >wpi_fw >Jan 27 10:32:19 vaio kernel: wpi0: could not load firmware image 'wpi_fw' > >In kldstat, both modules are loaded. >Then, I have "kldunload if_wpi" (and if_wpi seems to be reload, >automatically, I don't know why). Same problem, it seems that wpi_fw >could not be load (found ?). > >As a result, no AP is "associated". > > >After a fresh reboot, I have reinstall the custom 20070121 version of >mine, and all returns OK. >Another strange thing: when "kldload if_wpi" with 20070121 version, and >then kldstat, I don't see "wpi_ucode". It seems that wpi_ucode.ko does >not need to be loaded, in my case. >My wpi_ucode.ko lies in /boot/modules > >After another fresh reboot, I first moved wpi_ucode.ko to another place. >When I "kldload if_wpi", I got the following message: > >Jan 27 09:47:16 vaio kernel: wpi0: <Intel(R) PRO/Wireless 3945ABG> mem >0xcc000000-0xcc000fff irq 18 at device 0.0 on pci6 >Jan 27 09:47:16 vaio kernel: bus_dmamem_alloc failed to align memory >properly. >Jan 27 09:47:16 vaio last message repeated 6 times >Jan 27 09:47:16 vaio kernel: wpi0: Ethernet address: 00:18:de:5c:cb:9a >Jan 27 09:47:16 vaio kernel: wpi0: [GIANT-LOCKED] >Jan 27 09:47:16 vaio kernel: wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps >24Mbps 36Mbps 48Mbps 54Mbps >Jan 27 09:47:16 vaio kernel: wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >Jan 27 09:47:16 vaio kernel: wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >Jan 27 09:47:16 vaio kernel: firmware_get: failed to load firmware image >wpi_ucode >Jan 27 09:47:16 vaio kernel: wpi0: could not load firmware image >'wpi_ucode' > >So, it seems that wpi_ucode.ko have to lied in my /boot/modules (the >place where I have also put if_wpi 20070121 version), even if it is not >loaded. > >-- >-------------------------------- > (hika) Gilbert Cao > http://www.miaouirc.com > - MiaouIRC Project 2002-2003 > http://www.bsdmon.com > - The BSD DMON Power to serve > IRC : #miaule at IRCNET Network >-------------------------------- >-------------- next part -------------- >A non-text attachment was scrubbed... >Name: not available >Type: application/pgp-signature >Size: 187 bytes >Desc: not available >Url : >http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070127/db655aef/attachment-0001.pgp > >------------------------------ > >Message: 2 >Date: Sat, 27 Jan 2007 14:53:59 +0100 >From: Daniel Roethlisberger <daniel@roe.ch> >Subject: Review request: new OMNIKEY CardMan 4040 driver >To: freebsd-hackers@freebsd.org >Message-ID: <20070127135359.GA2167@dragon.roe.ch> >Content-Type: text/plain; charset=us-ascii > >I've already tried -drivers, but got no answers so far, so I am trying >here. > >I'm looking for source code review or early testers for my new OMNIKEY >CardMan 4040 `cmx' driver (pccard smartcard reader). It seems to work, >but there are some areas I am unsure about, especially the mutex, >callout and msleep interaction when detaching. > >Here is a diff against RELENG_6_1: > > http://dragon.roe.ch/~roe/cmx/cmx-6.1-20070124.diff.gz > >There's no manual page yet, but the driver itself should be complete. >I can make the code available in other forms than a diff vs 6.1 if >desired. > >Thanks, >Dan > >-- >Daniel Roethlisberger <daniel@roe.ch> > > >------------------------------ > >Message: 3 >Date: Sat, 27 Jan 2007 07:42:14 -0800 >From: Daniel Rudy <dr2867@pacbell.net> >Subject: sysctl(3) interface >To: freebsd-hackers@freebsd.org >Message-ID: <45BB72D6.9070809@pacbell.net> >Content-Type: text/plain; charset=ISO-8859-1 > > >Hello List, > >I've been taking apart and analyzing the sysctl(8) program to gain a >better insight into how to use the sysctl(3) interface. Adding some >debugging code to the program in strategic locations, this is what I >have as an output: > >debug: name: dev >debug: all: oid: 0 2 440 >debug: name: dev.nexus.%parent >debug: oid: 440 912 913 >debug: all: oid: 0 2 440 912 913 >debug: name: dev.nexus.0.%desc >debug: oid: 440 912 914 915 >debug: all: oid: 0 2 440 912 914 915 >debug: name: dev.nexus.0.%driver >debug: oid: 440 912 914 916 >debug: value: nexusdev.nexus.0.%driver: nexus >debug: all: oid: 0 2 440 912 914 916 >debug: name: dev.nexus.0.%location >debug: oid: 440 912 914 917 >debug: all: oid: 0 2 440 912 914 917 >debug: name: dev.nexus.0.%pnpinfo >debug: oid: 440 912 914 918 >debug: all: oid: 0 2 440 912 914 918 >debug: name: dev.nexus.0.%parent >debug: oid: 440 912 914 919 >debug: value: root0dev.nexus.0.%parent: root0 >debug: all: oid: 0 2 440 912 914 919 >debug: name: dev.acpi.%parent >debug: oid: 440 920 921 >debug: all: oid: 0 2 440 920 921 >debug: name: dev.acpi.0.%desc >debug: oid: 440 920 922 923 >debug: value: AMIINT dev.acpi.0.%desc: AMIINT >debug: all: oid: 0 2 440 920 922 923 >debug: name: dev.acpi.0.%driver >debug: oid: 440 920 922 924 >debug: value: acpidev.acpi.0.%driver: acpi >debug: all: oid: 0 2 440 920 922 924 >debug: name: dev.acpi.0.%location >debug: oid: 440 920 922 925 >debug: all: oid: 0 2 440 920 922 925 >debug: name: dev.acpi.0.%pnpinfo >debug: oid: 440 920 922 926 > >It's using an oid of 0 and 2 to get something, then it comes up with 440 >and then a sequence of numbers that are incrementing in a peculiar >pattern. I went looking and found that 0 is CTL_UNSPEC which according >to the comment is unused, but I see it here in the program output. > > >I also noticed this little blurb in the source code too: > >/* > * These functions uses a presently undocumented interface to the kernel > * to walk the tree and get the type so it can print the value. > * This interface is under work and consideration, and should probably > * be killed with a big axe by the first person who can find the time. > * (be aware though, that the proper interface isn't as obvious as it > * may seem, there are various conflicting requirements. > */ > >But I figure it's for the actual display of the various variables and >not for returning information about the dev tree. > > >So, my question is, how do I walk the tree to get the PnP info for all >the devices in the system? > >-- >Daniel Rudy > > >------------------------------ > >Message: 4 >Date: Sun, 28 Jan 2007 03:36:07 +0800 >From: "Rong-en Fan" <grafan@gmail.com> >Subject: how to determine if we are building lib32 in Makefile? >To: freebsd-hackers@freebsd.org >Message-ID: > <6eb82e0701271136n5538792eu31f464414e7dbaae@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >I'm working on wide character support in base's ncurses. For some >reason, I have to make lib/ncurses/ncursesw to include ncurses.h from >its object directory. However, current lib32 uses something like > >cc ... -I${LIB32TMP}/usr/includes ... -IFROM_NCURSES_MAKEFILE ... > >Right now, I have the following: > >.if ${.TARGET} == "installincludes" && !empty(${DESTDIR:M*/lib32/*}) > INCS= ${HEADERS} ${SRCHDRS} > INCSLINKS= curses.h ${INCLUDEDIR}/ncurses.h >.endif > >It works, but it's really ugly. Is there any other way to do this? > >Thanks, >Rong-En Fan > > >------------------------------ > >Message: 5 >Date: Sat, 27 Jan 2007 13:14:04 -0600 >From: "Sam Fourman Jr." <sfourman@gmail.com> >Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN > controller >To: "Gilbert Cao" <hika@bsdmon.com> >Cc: Massimo Lusetti <mlusetti@gmail.com>, Benjamin Close > <Benjamin.Close@clearchain.com>, Florent Thoumie <flz@freebsd.org>, > freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org, Attilio Rao > <attilio@freebsd.org>, damien.bergamini@free.fr, sam@freebsd.org, > gabor@freebsd.org, Max Laier <max@love2party.net> >Message-ID: > <11167f520701271114j66f82398h83c43885b9d25e12@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed > >I can also confirm that i get the firmware_get: failed to load >firmware image wpi_fw on the >20070125 version. >I should note that I tried it on a fresh 6.2 RELEASE install. > >Sam Fourman Jr. > >On 1/27/07, Gilbert Cao <hika@bsdmon.com> wrote: > > On Fri, Jan 26, 2007 at 11:09:51PM +1030, Benjamin Close wrote: > > > Hi Gilbert, > > > Thanks for the custom version. I've integrated the changes into the > > > driver I'm working on. > > > For those wanting to test out the driver which is now fully up to date > > > with all change from NetBSD & OpenBSD - and has a few minor >improvements > > > over them, grab it from: > > > > > > http://www.clearchain.com/~benjsc/download/ > > > > > > File is: 20070125-wpi-freebsd.tar.gz > > > > > > Full instructions on how to build / install the driver are in the >README > > > in the tar file. > > > > > > This should work both under -current and 6.2-Stable now. > > > > > > Info about the driver and what's working/broken can be found at: > > > > > > http://www.clearchain.com/wiki/wpi > > > > > > Cheers, > > > Benjamin > > > > I have tried the new 20070125 version. > > However, I did not manage to make work. At least, it compiles. > > I have installed, both wpi_fw.ko and the if_wpi.ko, as the README said. > > wpi_fw.ko lies in /boot/modules and if_wpi.ko in /boot/kernel. > > > > When, I "kldload if_wpi", here is a small sample of /var/log/messages > > > > Jan 27 10:30:39 vaio kernel: wpi0: <Intel(R) PRO/Wireless 3945ABG> mem >0xcc000000-0xcc000fff irq 18 at device 0.0 on pci6 > > Jan 27 10:30:39 vaio kernel: bus_dmamem_alloc failed to align memory >properly. > > Jan 27 10:30:39 vaio last message repeated 6 times > > Jan 27 10:30:39 vaio kernel: wpi0: Ethernet address: 00:18:de:5c:cb:9a > > Jan 27 10:30:39 vaio kernel: wpi0: [GIANT-LOCKED] > > Jan 27 10:30:39 vaio kernel: wpi0: 11a rates: > > Jan 27 10:30:39 vaio kernel: wpi0: 11b rates: > > Jan 27 10:30:40 vaio kernel: firmware_get: failed to load firmware image >wpi_fw > > Jan 27 10:30:40 vaio kernel: wpi0: could not load firmware image >'wpi_fw' > > Jan 27 10:30:40 vaio kernel: firmware_get: failed to load firmware image >wpi_fw > > Jan 27 10:30:40 vaio kernel: wpi0: could not load firmware image >'wpi_fw' > > Jan 27 10:32:19 vaio kernel: firmware_get: failed to load firmware image >wpi_fw > > Jan 27 10:32:19 vaio kernel: wpi0: could not load firmware image >'wpi_fw' > > > > In kldstat, both modules are loaded. > > Then, I have "kldunload if_wpi" (and if_wpi seems to be reload, > > automatically, I don't know why). Same problem, it seems that wpi_fw > > could not be load (found ?). > > > > As a result, no AP is "associated". > > > > > > After a fresh reboot, I have reinstall the custom 20070121 version of > > mine, and all returns OK. > > Another strange thing: when "kldload if_wpi" with 20070121 version, and > > then kldstat, I don't see "wpi_ucode". It seems that wpi_ucode.ko does > > not need to be loaded, in my case. > > My wpi_ucode.ko lies in /boot/modules > > > > After another fresh reboot, I first moved wpi_ucode.ko to another place. > > When I "kldload if_wpi", I got the following message: > > > > Jan 27 09:47:16 vaio kernel: wpi0: <Intel(R) PRO/Wireless 3945ABG> mem >0xcc000000-0xcc000fff irq 18 at device 0.0 on pci6 > > Jan 27 09:47:16 vaio kernel: bus_dmamem_alloc failed to align memory >properly. > > Jan 27 09:47:16 vaio last message repeated 6 times > > Jan 27 09:47:16 vaio kernel: wpi0: Ethernet address: 00:18:de:5c:cb:9a > > Jan 27 09:47:16 vaio kernel: wpi0: [GIANT-LOCKED] > > Jan 27 09:47:16 vaio kernel: wpi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps >24Mbps 36Mbps 48Mbps 54Mbps > > Jan 27 09:47:16 vaio kernel: wpi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > Jan 27 09:47:16 vaio kernel: wpi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps > > Jan 27 09:47:16 vaio kernel: firmware_get: failed to load firmware image >wpi_ucode > > Jan 27 09:47:16 vaio kernel: wpi0: could not load firmware image >'wpi_ucode' > > > > So, it seems that wpi_ucode.ko have to lied in my /boot/modules (the > > place where I have also put if_wpi 20070121 version), even if it is not > > loaded. > > > > -- > > -------------------------------- > > (hika) Gilbert Cao > > http://www.miaouirc.com > > - MiaouIRC Project 2002-2003 > > http://www.bsdmon.com > > - The BSD DMON Power to serve > > IRC : #miaule at IRCNET Network > > -------------------------------- > > > > > > > > >------------------------------ > >Message: 6 >Date: Sat, 27 Jan 2007 19:22:04 -0700 (MST) >From: "M. Warner Losh" <imp@bsdimp.com> >Subject: Re: atacontrol kernel crash (atausb?) >To: hselasky@c2i.net >Cc: freebsd-hackers@freebsd.org, freebsd-stable@freebsd.org, > ed@fxq.nl, pietro.cerutti@gmail.com >Message-ID: <20070127.192204.-862243883.imp@bsdimp.com> >Content-Type: Text/Plain; charset=us-ascii > >In message: <200701241254.51900.hselasky@c2i.net> > Hans Petter Selasky <hselasky@c2i.net> writes: >: Instead of having all these quirks, isn't it possible that the SCSI layer >can >: auto-probe this? > >The short answer is no. There's no reliable way to tell if a device >supports a given scsi command, and some devices freak out (lock up) >when sent one. > >Warner > > >------------------------------ > >Message: 7 >Date: Sat, 27 Jan 2007 21:35:32 -0800 >From: Daniel Rudy <dr2867@pacbell.net> >Subject: Re: unique hardware identification >To: "Devon H. O'Dell" <devon.odell@gmail.com> >Cc: Koen Martens <fbsd@metro.cx>, freebsd-hackers@freebsd.org >Message-ID: <45BC3624.3000608@pacbell.net> >Content-Type: text/plain; charset=ISO-8859-1 > >At about the time of 12/19/2006 7:19 AM, Devon H. O'Dell stated the >following: > > 2006/12/19, Koen Martens <fbsd@metro.cx>: > >> Hi All, > >> > >> I was wondering, if something like a unique hardware identification > >> would be possible on FreeBSD. > >> > >> I'd like a machine to authenticate to a server, for which it will > >> need a unique identification. Problem is, it should be generated > >> automatically and not easy to fake / detect without already having > >> root access to the box. > >> > >> I'm thinking of something like combining serial numbers from > >> CPU/disks for example, but there does not seem to be a clear way to > >> obtain these (not all cpu's even have a serial number in there). > >> > >> I am just inquiring if someone on this list has an idea that might > >> help with this problem. > >> > >> Gr, > >> > >> Koen > > > > Hey Koen, > > > > I know a lot of people / companies use the MAC address of a given > > interface for this purpose, but it's not generally very useful since > > most interfaces will allow you to set your own MAC address. > > > > Something you could use instead is a one-wire device, attached to the > > motherboard (if it has a header for it). If the motherboard does not, > > you can get LCDs from e.g. CrystalFontz that provide an interface to > > such devices. The Dallas one-wire thermometers have a unique 64-bit > > identifier on them, however this is only really useful if you have the > > ability to control the hardware platform. > > > > If you are attempting to identify a specific hardware platform (e.g. a > > standard set of motherboards and devices), you can enumerate devices > > and device IDs on the PCI bus, creating some sort of hash of those. > > > > In the end, with the client controlling the hardware, client-side > > security and validation is rather difficult. Even hacking the kernel > > to only run signed binaries is going to be difficult to keep secure, > > even keeping the key in some hardware secured storage, shipping the > > system without a debugger or symbols, and controlling the hardware. > > > > Thank you, media, for blowing the Pentium III CPUID feature up into > > something horrible. Uniquely identifiable hardware is very useful when > > licensing :\. > > > > Regarding your questions, the serial number of the hard drive is > > usually not too difficult to figure out. Take a look at atacontrol(8), > > for instance: > > > > dho# atacontrol cap ad4 > > > > Protocol Serial ATA II > > device model WDC WD1600JS-75NCB2 > > serial number WD-WCANM3753524 > > > > The serial number should be unique. camcontrol(8) can probably give > > you similar information for SCSI disks. > > > > Hope this is of some use. I'd be interested in seeing what others are >doing. > > > > Kind regards, > > > > Devon H. O'Dell > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to >"freebsd-hackers-unsubscribe@freebsd.org" > > > > >I've had this very question myself. Here's what I've done: > >1) Use a USB Flash Drive as a hardware dongle. These devices have a >vendor id, product id, and a serial number that is garunteed to be unique. > >2) Get the Link Layer Address off all the network interfaces in the system. > >3) Get the model, serial, and firmware revision off the first harddrive >in the system. > >4) Using the sysctl(3) interface, I found some undocumented stuff that >let's you enumerate the pnp devices in the system. Well, the kernel >tells you what they are. > > >-- >Daniel Rudy > > >------------------------------ > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >End of freebsd-hackers Digest, Vol 200, Issue 7 >*********************************************** _________________________________________________________________ Visita MSN Latino Noticias: Todo lo que pasa en el mundo y en tu paín, ¡en tu idioma! http://latino.msn.com/noticias/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BAY110-F7255331A6749F061315CDA4A70>