- Use db_printf() instead of printf().
- Clean up decode_syscall() to use regular if-then-else rather than goto's.
- Use the same method of parsing PID's for per-process traces as the x86
code does: that is, if the address passed in is not a valid kernel
address, treat it is a decimal pid.
- If the pid of the current process is specified, fall back to using the
"default" parameters for the trace as curproc's pcb is not valid at this
point.
MFC after: 1 week
we want the checksums calculated on a per-packet basis using control bits
in the extsts field of the DMA descriptor structure. For TX, the chip
seems to want these bits set in the field of the first descriptor in
a fragment chain, not the last.
412: warning: long unsigned int format, unsigned int arg (arg 3)
418: warning: long unsigned int format, unsigned int arg (arg 3)
424: warning: long unsigned int format, unsigned int arg (arg 3)
take a const 'name', since they dont modify anything.
159: warning: passing arg 1 of `getenv_int' discards qualifiers...
167: warning: passing arg 1 of `getenv' discards qualifiers from pointer..
vinumhdr.h:80: warning: redundant redeclaration of `vinum_cdevsw'
vinumext.h:239: warning: previous declaration of `vinum_cdevsw'
in each of the following files:
vinum.c, vinumconfig.c, vinumdaemon.c, vinuminterrupt.c, vinumio.c,
vinumioctl.c, vinumlock.c, vinummemory.c, vinumraid5.c, vinumrequest.c,
vinumrevive.c, vinumstate.c, vinumutil.c
musycc.c:449: warning: long unsigned int format, unsigned int arg (arg 3)
musycc.c:449: warning: long unsigned int format, unsigned int arg (arg 4)
musycc.c:453: warning: long unsigned int format, unsigned int arg (arg 3)
musycc.c:453: warning: long unsigned int format, unsigned int arg (arg 4)
musycc.c:453: warning: long unsigned int format, unsigned int arg (arg 5)
These warnings used to be confined to the alpha but are on all now.
554: passing arg 4 of `resource_string_value' from incompatible pointer type
576: passing arg 4 of `resource_string_value' from incompatible pointer type
593: passing arg 4 of `resource_string_value' from incompatible pointer type
commands that complete (with no apparent error) after
we receive a LIP. This has been observed mostly on
Local Loop topologies. To be safe, let's just mark
all active commands as dead if we get a LIP and we're
on a private or public loop.
MFC after: 4 weeks
could only get a chance of testing it under 4.3, but together with the
if_oltr.c fixes at least it seems to work now. If someone has the chance
to test this under -current, please do.
Unfortunaltey, the TR code itself (if_iso88025subr.c) is not written
in a way that would allow to make a seaparate KLD out of it. By now,
just link it directly into the oltr KLD since it's probably the POLA
to be able to load the TR code together with the only TR hardware
driver we've got by now.
I've got one single unexplained panic (in doreti_switch or somewhere
there, calling a 0xc1XXXXXX address that did no longer belong to the
kernel at all) after unloading the modules once, thus i don't propose
a MFC of this module despite my testing has been done solely on 4.3,
unless someone is really going to test this stuff in -current.
This avoids a null pointer deref panic in TRlldClose() inside the
vendor-supplied object code. It's now possible to unload the driver
at all.
Implement deallocation of malloc()ed memory regions.
MFC after: 2 months
