From: [EMAIL PROTECTED]
Reply-To: [email protected]
To: [email protected]
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
[email protected]
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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN
controller
To: Benjamin Close <[EMAIL PROTECTED]>
Cc: Massimo Lusetti <[EMAIL PROTECTED]>, Florent Thoumie
<[EMAIL PROTECTED]>, [email protected],
[EMAIL PROTECTED], Attilio Rao <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Max
Laier <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Subject: Review request: new OMNIKEY CardMan 4040 driver
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
------------------------------
Message: 3
Date: Sat, 27 Jan 2007 07:42:14 -0800
From: Daniel Rudy <[EMAIL PROTECTED]>
Subject: sysctl(3) interface
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
Subject: how to determine if we are building lib32 in Makefile?
To: [email protected]
Message-ID:
<[EMAIL PROTECTED]>
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." <[EMAIL PROTECTED]>
Subject: Re: Updated Driver for 3945ABG Intel 3945ABG Wireless LAN
controller
To: "Gilbert Cao" <[EMAIL PROTECTED]>
Cc: Massimo Lusetti <[EMAIL PROTECTED]>, Benjamin Close
<[EMAIL PROTECTED]>, Florent Thoumie <[EMAIL PROTECTED]>,
[email protected], [EMAIL PROTECTED], Attilio Rao
<[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], Max Laier <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
Subject: Re: atacontrol kernel crash (atausb?)
To: [EMAIL PROTECTED]
Cc: [email protected], [email protected],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: Text/Plain; charset=us-ascii
In message: <[EMAIL PROTECTED]>
Hans Petter Selasky <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Subject: Re: unique hardware identification
To: "Devon H. O'Dell" <[EMAIL PROTECTED]>
Cc: Koen Martens <[EMAIL PROTECTED]>, [email protected]
Message-ID: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>:
>> 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
> _______________________________________________
> [email protected] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
>
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
------------------------------
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
End of freebsd-hackers Digest, Vol 200, Issue 7
***********************************************
