yesterday on powerpc broke overnight. Apparently adding one more
function before the call to dlsym() fixes things again. I hope
I don't have to add another one tomorrow ....
This makes interrupts on cobalt (and probably other Rm5200 machines) work,
and no bad side effect seen on R4400 ews4800mips.
Cobalt GENERIC kernel on RaQ still panics right after mountroot() though:
---
:
atabus1 at viaide0 channel 1
VIA Technologies VT83C572 USB Controller (USB serial bus, revision 0x02) at pci0 dev 9 function 2 not configured
wd0 at atabus0 drive 0
wd0: <QUANTUM FIREBALLlct15 15>
wd0: 14324 MB, 29104 cyl, 16 head, 63 sec, 512 bytes/sect x 29336832 sectors
boot device: wd0
root on wd0a dumps on wd0b
root file system type: ffs
pid 1(init): ABI set to O32 (e_flags=0x1007)
pid 4(sh): trap: cpu0, address error (load or I-fetch) in kernel mode
status=0x8003, cause=0x10, epc=0x801430a0, vaddr=0x8001
tf=0xc6471a88 ksp=0xc6471b28 ra=0x801f0c90 ppl=0x801f0c24
kernel: address error (load or I-fetch) trap
Stopped in pid 4.1 (sh) at netbsd:mutex_abort: lw v1,0(a0)
db> tr
0xc6471b28: mutex_abort+0 (8001,80380530,803cbb10,803ff840) ra 801f0c90 sz 0
0xc6471b28: mips_pmap_map_poolpage+90 (8001,80380530,803cbb10,803ff840) ra 80276788 sz 40
0xc6471b50: pool_grow+4c (8001,80380530,803cbb10,803ff840) ra 80276b64 sz 48
0xc6471b80: pool_catchup+34 (8001,80380530,803cbb10,803ff840) ra 80276418 sz 24
0xc6471b98: pool_get+50c (8001,80380530,803cbb10,803ff840) ra 801f11b8 sz 64
0xc6471bd8: pmap_enter_pv+e8 (8001,80380530,803cbb10,803ff840) ra 801f3054 sz 48
0xc6471c08: pmap_enter+138 (8001,80380530,803cbb10,803ff840) ra 802fd528 sz 64
0xc6471c48: uvm_fault_lower+24c (8001,80380530,803cbb10,803ff840) ra 802fec50 sz 96
0xc6471ca8: uvm_fault_internal+72c (83ed5b40,80380530,1,0) ra 802b5b08 sz 272
0xc6471db8: trap+8d0 (10,8,1,408fb8) ra 8018f22c sz 400
0xc6471f48: mips3_user_gen_exception+cc (10,8,1,408fb8) ra 0 sz 0
User-level: pid 4.1
db>
libgcc_s's __register_frame_info gets called from libc's CSU code before
the libc constructors are run. __register_frame_info in turn calls
pthread_mutex_lock. libpthread is not initialised at this point and
therefore pthread__self() traps when deferencing the thread register.
This worked before because the garbage from pthread__self() is
effectively ignored.
decompression:
-seperate the IPCOMP specific rule that compression must not grow the
data from general compression semantics: Introduce a special name
CRYPTO_DEFLATE_COMP_NOGROW/comp_algo_deflate_nogrow to describe
the IPCOMP semantics and use it there. (being here, fix the check
so that equal size is considered failure as well as required by
RFC2393)
Customers of CRYPTO_DEFLATE_COMP/comp_algo_deflate now always get
deflated data back, even if they are not smaller than the original.
-allow to pass a "size hint" to the DEFLATE decompression function
which is used for the initial buffer allocation. Due to the changes
done there, additional allocations and extra copies are avoided if the
initial allocation is sufficient. Set the size hint to MCLBYTES (=2k)
in IPCOMP which should be good for many use cases.
This case can be triggered from userland cryptodev if the buffer
for decompressed data is too small.
(It would look cleaner if the lengths would be passed explicitely
everywhere, but that would thwart the abstraction done by COPYDATA/COPYBACK
which allows to treat mbufs and iovs the same way.)
njoly