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
The symptom being treated in 1.98 was to avoid freeing a
pagedep dependency if there was still a newdirblk dependency
referencing it. That change is correct and no longer prints
a warning message when it occurs. The other part of revision
1.98 was to panic when a newdirblk dependency was encountered
during a file truncation. This fix removes that panic and
replaces it with code to find and delete the newdirblk
dependency so that the truncation can succeed.
cpu_mp_start() is never called, mp_ncpus will have a non-zero value.
This prevents systat from dying with an arithmatic exception caused
by a divide-by-zero error on UP alphas running a GENERIC kernel.
