Re: Segfault in _Unwind_* code called from pthread_exit

[Andreas Tobler]

On 30.10.17 15:32, Tijl Coosemans wrote:

On Sun, 29 Oct 2017 20:40:46 +0100 Andreas Tobler  
wrote:

Attached what I have for libgcc. It can be applied to gcc5-8, should
give no issues. The mentioned tc from this thread and mine,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.

What do you think?


Like I said before the return address can be anything.  It could for
instance point to some instruction in a random function and then the
stack unwinder will think thread_start was called from that function.
There's no check you can add to libgcc to distinguish that from a
normal valid return address.

Maybe not, and most probably I do not understand what is happening. But 
with my modification I survive the test case.


If no objections from your or Konstantin's side come up I will commit it 
to the gcc repo. It will not 'fix' the issue, but it will improve the 
gcc behavior.


Andreas
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: pcsc-lite hangs up after unplugging an USB card reader

[Hans Petter Selasky]

On 10/30/17 18:10, Jairo Montes González wrote:

Jairo Montes schrieb am 30.10.2017 17:09
_

Hi people!

My problem appears only when unplugging one device. I can have more than
one connected, but when I disconnect one, an error occurs, and if I plug in
a device, even the same I just unplugged, it won't be loaded. I don't know
if the problem comes from pcsc-lite or FreeBSD (libusb).


Information requested for support at:
http://pcsclite.alioth.debian.org/ccid.html#support

Versions:
- ccid-1.4.27
- pcsc-lite-1.8.22,2
- Inside Secure AT90SCR200
- Enabled features: FreeBSD amd64-portbld-freebsd12.0 serial usb libusb
     usbdropdir=/usr/local/lib/pcsc/drivers/ ipcdir=/var/run/pcscd
     configdir=/usr/local/etc/reader.conf.d

Platform:
- FreeBSD 10.4-STABLE and 12.0-CURRENT r323761 amd64
- Standard compatible PC (Intel i5-6500)
- No card involved. It does the same with or without a card.
- SCM Microsystems Inc. SCR 335,  Inside Secure AT90SCR200.

The output of pcscd is attached to this email.

Any thoughts on this? Thanks in advance people.



Check the output from "procstat -ak".

--HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

pcsc-lite hangs up after unplugging an USB card reader

[Jairo Montes González]

Jairo Montes schrieb am 30.10.2017 17:09
_

Hi people!

My problem appears only when unplugging one device. I can have more than
one connected, but when I disconnect one, an error occurs, and if I plug in
a device, even the same I just unplugged, it won't be loaded. I don't know
if the problem comes from pcsc-lite or FreeBSD (libusb).


Information requested for support at:
http://pcsclite.alioth.debian.org/ccid.html#support

Versions:
- ccid-1.4.27
- pcsc-lite-1.8.22,2
- Inside Secure AT90SCR200
- Enabled features: FreeBSD amd64-portbld-freebsd12.0 serial usb libusb
usbdropdir=/usr/local/lib/pcsc/drivers/ ipcdir=/var/run/pcscd
configdir=/usr/local/etc/reader.conf.d

Platform:
- FreeBSD 10.4-STABLE and 12.0-CURRENT r323761 amd64
- Standard compatible PC (Intel i5-6500)
- No card involved. It does the same with or without a card.
- SCM Microsystems Inc. SCR 335,  Inside Secure AT90SCR200.

The output of pcscd is attached to this email.

Any thoughts on this? Thanks in advance people.

BALLY WULFF Games & Entertainment GmbH, Maybachufer 48-51, 12045 Berlin, 
Postanschrift: Postfach 44 01 57, 12001 Berlin Tel.: 030-620 02-0 FAX: 030-620 
02-200, Geschaeftsfuehrer: Thomas Niehenke, Lars Rogge, Wolfram Seiffert, Thomas 
Wendt, Amtsgericht Berlin-Charlottenburg HRB 139020 B, UST-IdNr. DE815328376
_
Dieses E-Mail ist nur fuer den Empfaenger bestimmt, an den es gerichtet
ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes
Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs-
aeusserung ist die des Autors und stellt nicht notwendigerweise die
Ansicht oder Meinung von Bally Wulff Games & Entertainment GmbH dar.
Sind Sie nicht der Empfaenger, so haben Sie diese E-Mail irrtuemlich
erhalten und jegliche Verwendung, Veroeffentlichung, Weiterleitung,
Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt.

Weder Bally Wulff Games & Entertainment GmbH noch der Absender
uebernehmen die Haftung fuer Viren. Es obliegt Ihrer Verantwortung,
die E-Mail und deren Anhaenge auf Viren zu pruefen.
1 Anhaenge:
log.txt
_
Versand am 30.10.2017 17:09 von Montes Jairo

 debuglog.c:289:DebugLogSetLevel() debug level=debug
0130 debuglog.c:310:DebugLogSetCategory() Debug options: APDU
0013 pcscdaemon.c:350:main() Force colored logs
1329 configfile.l:361:DBGetReaderList() Parsing conf file: 
/usr/local/etc/reader.conf.d
0055 pcscdaemon.c:658:main() pcsc-lite 1.8.22 daemon ready.
7823 hotplug_libusb.c:440:HPEstablishUSBNotifications() Driver 
ifd-ccid.bundle does not support IFD_GENERATE_HOTPLUG. Using active polling 
instead.
0024 hotplug_libusb.c:449:HPEstablishUSBNotifications() Polling forced 
every 1 second(s)
02706597 hotplug_libusb.c:536:HPAddHotPluggable() Adding USB device: 0:3:0
0119 readerfactory.c:1074:RFInitializeReader() Attempting startup of Inside 
Secure AT90SCR200 00 00 using 
/usr/local/lib/pcsc/drivers//ifd-ccid.bundle/Contents/FreeBSD/libccid.so
0244 readerfactory.c:949:RFBindFunctions() Loading IFD Handler 3.0
0064 ifdhandler.c:1965:init_driver() Driver version: 1.4.27
2735 ifdhandler.c:1982:init_driver() LogLevel: 0x0003
0021 ifdhandler.c:1993:init_driver() DriverOptions: 0x
1206 ifdhandler.c:111:CreateChannelByNameOrChannel() Lun: 0, device: 
usb:2406/6407:libusb-1.0:0:3:0
0053 ccid_usb.c:302:OpenUSBByName() Using: 
/usr/local/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist
1026 pcscdaemon.c:191:signal_thread() Received signal: 30
0022 hotplug_libusb.c:651:HPReCheckSerialReaders()
1146 ccid_usb.c:320:OpenUSBByName() ifdManufacturerString: Ludovic Rousseau 
(ludovic.rouss...@free.fr)
0017 ccid_usb.c:321:OpenUSBByName() ifdProductString: Generic CCID driver
0012 ccid_usb.c:322:OpenUSBByName() Copyright: This driver is protected by 
terms of the GNU Lesser General Public License version 2.1, or (at your option) 
any later version.
0695 ccid_usb.c:656:OpenUSBByName() Found Vendor/Product: 2406/6407 (Inside 
Secure AT90SCR200)
0018 ccid_usb.c:658:OpenUSBByName() Using USB bus/device: 0/3
0009 ccid_usb.c:717:OpenUSBByName() bNumDataRatesSupported is 0
00058934 ifdhandler.c:382:IFDHGetCapabilities() tag: 0xFB3, 
usb:2406/6407:libusb-1.0:0:3:0 (lun: 0)
0020 readerfactory.c:396:RFAddReader() Using the reader polling thread
0340 ifdhandler.c:382:IFDHGetCapabilities() tag: 0xFAE, 
usb:2406/6407:libusb-1.0:0:3:0 (lun: 0)
0016 ifdhandler.c:477:IFDHGetCapabilities() Reader supports 1 slot(s)
02329676 pcscdaemon.c:191:signal_thread() Received signal: 30
0022 hotplug_libusb.c:651:HPReCheckSerialReaders()
00714597 hotplug_libusb.c:626:HPRemoveHotPluggable() Removing USB device[0]: 
0:3:0
0028 readerfactory.c:609:RFRemoveReader() UnrefReader() count was: 1

FYI about native-xtools / Poudriere jail -x change in head

[Bryan Drewery]

The latest FreeBSD head's native-xtools support (jail -x) requires
poudriere-devel-3.1.99.20171028 or poudriere-3.1.22 after r325082.

Otherwise it will build but not install.

Also with the new Poudriere and latest head native-xtools no longer
requires a /usr/src checkout but uses the jails own source after r325001.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: Segfault in _Unwind_* code called from pthread_exit

[Tijl Coosemans]

On Sun, 29 Oct 2017 20:40:46 +0100 Andreas Tobler  
wrote:
> Attached what I have for libgcc. It can be applied to gcc5-8, should 
> give no issues. The mentioned tc from this thread and mine, 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635 do pass.
> 
> What do you think?

Like I said before the return address can be anything.  It could for
instance point to some instruction in a random function and then the
stack unwinder will think thread_start was called from that function.
There's no check you can add to libgcc to distinguish that from a
normal valid return address.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Segfault in _Unwind_* code called from pthread_exit

[Tijl Coosemans]

On Sun, 29 Oct 2017 21:13:58 +0200 Konstantin Belousov  
wrote:
> On Sun, Oct 29, 2017 at 06:23:51PM +0100, Tijl Coosemans wrote:
>> On Sat, 26 Aug 2017 21:40:34 +0300 Konstantin Belousov  
>> wrote:  
>>> On Sat, Aug 26, 2017 at 08:28:13PM +0200, Tijl Coosemans wrote:  
 I did consider using
 a CFI directive (see patch below) and it works, but it's architecture
 specific and it's inserted after the function prologue so there's still
 a window of a few instructions where a stack unwinder will try to use
 the return address.
 
 Index: lib/libthr/thread/thr_create.c
 ===
 --- lib/libthr/thread/thr_create.c  (revision 322802)
 +++ lib/libthr/thread/thr_create.c  (working copy)
 @@ -251,6 +251,7 @@ create_stack(struct pthread_attr *pattr)
  static void
  thread_start(struct pthread *curthread)
  {
 +   __asm(".cfi_undefined %rip");
 sigset_t set;
  
 if (curthread->attr.suspend == THR_CREATE_SUSPENDED)
>>> 
>>> I like this approach much more than the previous patch.  What can be
>>> done is to provide asm trampoline which calls thread_start().  There you
>>> can add the .cfi_undefined right at the entry.
>>>
>>> It is somewhat more work than just setting the return address on the
>>> kernel-constructed pseudo stack frame, but I believe this is ultimately
>>> correct way.  You still can do it only on some arches, if you do not
>>> have incentive to code asm for all of them.  
>> 
>> Ok, but then there are two ways to implement the trampoline:
>> 
>> 1)
>>  movq $0,(%rsp)
>>  jmp thread_start
>> 2)
>>  subq $8,%rsp
>>  call thread_start
>>  /* NOTREACHED */
>> 
>> With 1) you're setting the return address to zero anyway, so you might
>> as well do that in the kernel like my first patch.  With 2) you're
>> setting up a new call frame, basically redoing what the kernel already
>> did and on i386 this also means copying the function argument.  
> I do not quite understand the second variant, because the stack is not
> guaranteed to be zeroed, and it is often not if reused after the previously
> exited thread.

The problem is that the return address of thread_start can be garbage.
Solution 1 sets it to zero.  Nothing else changes, once thread_start runs
it's as if the trampoline never existed.  Solution 2 creates a new frame
and calls thread_start giving it a valid return address back to the
trampoline.  The trampoline still has a return address that can be garbage,
but it has a CFI directive saying its return address is undefined so
that's ok.

> The first variant is what I like, but perhaps we need to emulate the
> frame as well, i.e. push two zero longs.

That would be a hybrid of 1 and 2.

> Currently kernel does not access the usermode stack for the new thread
> unless dictated by ABI (i.e. it does not touch it for 64bit process
> on amd64, but have to for 32bit).  I like this property.  Also, the
> previous paragraph is indicative: we do not really know in kernel
> what ABI the userspace follows.  It might want frame, may be it does
> not need it.  It could use other register than %rbp as the frame base,
> etc.

Yes, but then the kernel should just set the stack pointer to the first
byte after the stack and pass the argument in a register.  Then userspace
can align the stack and store function arguments the way it likes and
call a C function or whatever else it wants to do.  Now the kernel is
already setting up the stack so the entry point can be a C function.

But anyway, we're both talking about hypothetical situations now so I'm
just going to make the decision and go with my earlier patch.  Then it's
clear that the kernel sets up the frame and there isn't some sort of split
responsibility between kernel and userland.  If there's ever a situation
where the kernel should not set up a call frame a new syscall can be
added.  In the end we're talking about the best way to set a word to zero
here.  We've spent too many emails on that already.

>> Do you have any preference (or better alternatives), because I think I
>> still prefer my first patch.  It's the caller's job to set up the call
>> frame, in this case the kernel.  And if the kernel handles it then it
>> also works with (hypothetical) implementations other than libthr.
>> 
>>> Also crt1 probably should get the same treatment, despite we already set
>>> %rbp to zero AFAIR.
>> 
>> I haven't checked but I imagine the return address of the process entry
>> point is always zero because the stack is all zeros.
> Stack is not zero. The environment and argument strings and auxv are copied
> at top, and at the bottom the ps_strings structure is located, so it
> is not.

Yes, what I meant is that it's newly allocated so even if the return
address is uninitialised it will be zero.  If it wasn't people would
have reported problems with 

Re: Host CPUTYPE?=bdver2 unable to build release target for CPUTYPE?=slm

[Alastair Hogge]

On Mon, 30 Oct 2017-10-30 15:38:02 Alastair Hogge wrote:
> On Fri, 27 Oct 2017-10-27 12:59:30 Alastair Hogge wrote:
> > Hi,
> > 
> > I am attempting to build a release ${SRC}/release/release.sh -c
> 
> > ${custom_release.conf}, however, the build fails with:
> Updated log from a host r325110:
> 
> [...]
> --- installconfig_subdir_usr.bin/vtfontcvt ---
> [29/2032]
> ===> usr.bin/vtfontcvt (installconfig)
> --- installconfig_subdir_usr.bin/usbhidaction ---
> ===> usr.bin/usbhidaction (installconfig)
> --- installconfig_subdir_usr.bin/usbhidctl ---
> ===> usr.bin/usbhidctl (installconfig)
> --- installconfig_subdir_usr.bin/last ---
> ===> usr.bin/last (installconfig)
> --- installconfig_subdir_usr.bin/users ---
> ===> usr.bin/users (installconfig)
> --- installconfig_subdir_usr.bin/who ---
> ===> usr.bin/who (installconfig)
> --- installconfig_subdir_usr.bin/vi ---
> --- installconfig_subdir_usr.bin/vi/catalog ---
> ===> usr.bin/vi/catalog (installconfig)
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat
> 32-bit compatibility ldconfig path:
> make: "/usr/src/Makefile" line 335: warning: "LC_ALL=C date" exited on a
> signal --- buildworld ---
> make[1]: "/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER: Determined that
> CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
> make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date
> +-%Y-%m-%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date
> +-%Y%m%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date
> +%Y.%m.%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date
> +-%Y-%m-%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d"
> exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date
> +-%Y%m%d" exited on a signal
> make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date
> +%Y.%m.%d" exited on a signal
> --- buildworld_prologue ---
> --
> 
> >>> World build started on
> 
> --
> --- _worldtmp ---
> 
> --
> 
> >>> Rebuilding the temporary build tree
> 
> --
> rm -rf /usr/obj/usr/src/tmp
> mkdir -p /usr/obj/usr/src/tmp/lib
> mkdir -p /usr/obj/usr/src/tmp/lib/casper
> mkdir -p /usr/obj/usr/src/tmp/usr
> mkdir -p /usr/obj/usr/src/tmp/legacy/bin
> mkdir -p /usr/obj/usr/src/tmp/legacy/usr
> mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist  -p
> /usr/obj/usr/src/tmp/legacy/usr >/dev/null
> Illegal instruction (core dumped)
> *** [_worldtmp] Error code 132
> 
> make[1]: stopped in /usr/src
> 1 error
> 
> make[1]: stopped in /usr/src
> *** [buildworld] Error code 2
> 
> make: stopped in /usr/src
> 1 error
> 
> make: stopped in /usr/src
> 
> # cd /scratch/fafnir/usr/obj/usr/src/tmp/legacy/
> # gdb
> GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
>  This is free software: you are free to
> change and redistribute it. There is NO WARRANTY, to the extent permitted
> by law.  Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) core mtree.core
> [New LWP 101468]
> warning: Unexpected size of section `.reg-xstate/101468' in core file.
> Core was generated by `mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist -p
> /usr/obj/usr/src/tmp/legacy/usr'.
> Program terminated with signal SIGILL, Illegal instruction.
> warning: Unexpected size of section `.reg-xstate/101468' in core file.
> #0  0x000800d8e6de in ?? ()
> (gdb) bt
> #0  0x000800d8e6de in ?? ()
> #1  0x7fffdf50 in ?? ()
> #2  0x000800d9009d in ?? ()
> #3  0x7fffe1e0 in ?? ()
> #4  0x000100c69028 in ?? ()
> #5  0x0001 in ?? ()
> #6  0x000800667014 in ?? ()
> #7  0x0400 in ?? ()
> #8  0x0008006a1000 in ?? ()
> #9  0xe57f4b95 in ?? ()
> #10 0x7fffe1ec in ?? ()
> #11 0x0068d000 in ?? ()
> #12 0x000801021fb0 in ?? ()
> #13 

Re: Host CPUTYPE?=bdver2 unable to build release target for CPUTYPE?=slm

[Alastair Hogge]

On Fri, 27 Oct 2017-10-27 12:59:30 Alastair Hogge wrote:
> Hi,
> 
> I am attempting to build a release ${SRC}/release/release.sh -c
> ${custom_release.conf}, however, the build fails with:

Updated log from a host r325110:

[...]
--- installconfig_subdir_usr.bin/vtfontcvt ---  

  
[29/2032]
===> usr.bin/vtfontcvt (installconfig)   
--- installconfig_subdir_usr.bin/usbhidaction ---   
   
===> usr.bin/usbhidaction (installconfig)
--- installconfig_subdir_usr.bin/usbhidctl ---  
   
===> usr.bin/usbhidctl (installconfig)   
--- installconfig_subdir_usr.bin/last ---
===> usr.bin/last (installconfig)   
   
--- installconfig_subdir_usr.bin/users ---   
===> usr.bin/users (installconfig)  
   
--- installconfig_subdir_usr.bin/who --- 
===> usr.bin/who (installconfig) 
--- installconfig_subdir_usr.bin/vi ---  
--- installconfig_subdir_usr.bin/vi/catalog ---  
===> usr.bin/vi/catalog (installconfig)  
ELF ldconfig path: /lib /usr/lib /usr/lib/compat 
32-bit compatibility ldconfig path: 
   
make: "/usr/src/Makefile" line 335: warning: "LC_ALL=C date" exited on a signal
--- buildworld ---   
make[1]: "/usr/src/Makefile.inc1" line 162: SYSTEM_COMPILER: Determined that 
CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date +-%Y-%m-%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date +-%Y%m%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date +%Y.%m.%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.ec2" line 9: warning: "date +-%Y-%m-%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.azure" line 20: warning: "date +-%Y-%m-%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.gce" line 22: warning: "date +-%Y-%m-%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 32: warning: "date +-%Y%m%d" 
exited on a signal
make[2]: "/usr/src/release/Makefile.vagrant" line 35: warning: "date +%Y.%m.%d" 
exited on a signal 
--- buildworld_prologue ---  
--  
   
>>> World build started on   
--  
   
--- _worldtmp ---

--  
   
>>> Rebuilding the temporary build tree  
--  
   
rm -rf /usr/obj/usr/src/tmp  
mkdir -p /usr/obj/usr/src/tmp/lib
mkdir -p /usr/obj/usr/src/tmp/lib/casper 
mkdir -p /usr/obj/usr/src/tmp/usr
mkdir -p /usr/obj/usr/src/tmp/legacy/bin 
mkdir -p /usr/obj/usr/src/tmp/legacy/usr 
mtree -deU -f /usr/src/etc/mtree/BSD.usr.dist  -p 
/usr/obj/usr/src/tmp/legacy/usr >/dev/null   
Illegal instruction (core dumped)
*** [_worldtmp] Error code 132   

make[1]: stopped in /usr/src 
1 error  

make[1]: stopped in /usr/src 
*** [buildworld] Error code 2

make: stopped in /usr/src
1 error  

make: stopped in /usr/src

# cd /scratch/fafnir/usr/obj/usr/src/tmp/legacy/
# gdb 
GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]   
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later    
   
This is free software: you are free to change 

Re: iwm not in GENERIC kernel

[yaneurabeya]

> On Oct 29, 2017, at 11:01, Warner Losh  wrote:

...

> The blobs run on the actual card itself, not on the host. This is the 
> firmware for the wireless SoC that's on the card. We have allowed those in 
> the kernel since the very early days of the project when scsi controllers 
> like isp(4) downloaded firmware.
> 
> This is somewhat different than the recently discussed HBAs that have binary 
> blobs that run on the host, which have no business in GENERIC…

I’m just the messenger relaying what’s currently in place in the code based on 
what I remember from past discussions.

If you disagree with what’s in place with MK_SOURCELESS_UCODE, please feel free 
to change it (how it works is already documented in multiple places, and this 
is what Linux does too with their firmware blobs).

Also, it helps when the firmware driver is properly wired up to the kernel 
build system: r324470, r325122. The kernel module could compile on its own if 
someone cd’ed to the modules directory, but was broken otherwise, meaning that 
it wasn’t compiling as a module, or compiling into the kernel, prior to the 
before mentioned commits.

Cheers,
-Ngie


signature.asc
Description: Message signed with OpenPGP using GPGMail