harti [Thu, 8 Jul 2004 09:08:09 +0000 (09:08 +0000)]
Get rid of the THISHOST variable when building on sparc64. The problem
with it is that it is set by calling hostname and hostname isn't normally
in the path at that point.
Add a function to iterate over all characters in a particular character
class. This is necessary in order to implement tr(1) efficiently in
multibyte locales, since the brute force method of finding all characters
in a class is infeasible with a 32-bit (or wider) wchar_t.
Remove cache flush, 256Mb 1:1 BAT mapping, and BAT clearing. This doesn't
work on a G5 (no BAT registers) or on PearPC (dBAT3 used for mapping
the framebuffer and BATs not re-inited on OpenFirmware calls).
All hell breaks loose if the loader image is released before
jumping to the kernel. Another bug exposed by removing the
1:1 BAT mapping. Sparc64 doesn't do this either.
Compile tested on: panther (sparc64). Code built, but not used, on sparc64.
Correctly calculate size of memory to be mapped when copying. Removal
of the 256Mb 1:1 BAT mapping exposed this as copying into memory that
hadn't been claimed from OpenFirmware.
compiled-tested on: panther (sparc64). Code built, but not used, on sparc64
I think this is my fourth complete rewrite of the dir-creation
code. <whew!> This version handles all of the following edge cases:
* Restoring explicit dirs with 000 permissions (star fails this test)
* Restore of implicit or explicit dirs when umask=777
(gtar and star both fail this test)
* Restoring dir paths containing "." and ".." components
This version initially creates all dirs with permission 700 (ignoring
umask), then does a post-extract "fixup" pass to set the correct
permissions (which may or may not depend on umask, depending on the
restore flags and whether it's an explicit or implicit dir).
Permissions are restored depth-first so that permissions within
non-writable dirs can be correctly restored. (The depth-sorting does
correctly account for dirs with ".." components.)
Break out the isa and pccard front ends from fdc. This is the first
step in making this driver more attachment neutral. Others plan on
adding acpi front ends.
Still need to cleanup the MI part of the driver because it isn't as
bus independent as it could be.
Break out the isa and pccard front ends to the fdc controller device.
This should allow us to more easily break out the acpi and 'legacy pc'
front ends as well (so only the bus front end would touch rtc, for
example).
This isn't a great separation, since isa dma routines are still called
from the MI code, but it is a start.
Bumped document date for the recent changes here.
Fixed bad example of how to start a new sentence.
Added missing punctuation.
Fixed cut-n-paste error in the STANDARDS section.
Mention modern POSIX and C standards.
- In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags
used for shared memory allocations with a lowaddr of 0x3E7FFFFF.
This forces the buffers to be mapped to physical/bus addresses within
the first 1GB of physical memory. It seems that at least one card
(Linksys Instant Wireless PCI V2.7) depends on this behavior. I
don't know if this is a hardware restriction, or if the NDIS
driver for this card is truncating the addresses itself, but using
physical/bus addresses beyong the 1GB limit causes initialization
failures.
- Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in
if_ndis.c to test whether the device has been initialized rather
than checking for the presence of the IFF_UP flag in if_flags.
While debugging the previous problem, I noticed that bringing
up the device would always produce failures from ndis_setmulti().
It turns out that the following steps now occur during device
initialization:
- IFF_UP flag is set in if_flags
- ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle)
- ifp->if_ioctl() called with SIOCADDMULTI
- ifp->if_ioctl() called with SIOCADDMULTI (again)
- ifp->if_ioctl() called with SIOCADDMULTI (yet again)
- ifp->if_ioctl() called with SIOCSIFFLAGS
Setting the receive filter and multicast filters can only be done
when the underlying NDIS driver has been initialized, which is done
by ifp->if_init(). However, we don't call ifp->if_init() until
ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been
set. It appears that now, the network stack tries to add multicast
addresses to interface's filter before those steps occur. Normally,
ndis_setmulti() would trap this condition by checking for the IFF_UP
flag, but the network code has in fact set this flag already, so
ndis_setmulti() is fooled into thinking the interface has been
initialized when it really hasn't.
It turns out this is usually harmless because the ifp->if_init()
routine (in this case ndis_init()) will set up the multicast
filter when it initializes the hardware anyway, and the underlying
routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC
haven't been initialized yet, but you end up spurious error messages
on the console all the time.
Something tells me this new behavior isn't really correct. I think
the intention was to fix it so that ifp->if_init() is only called
once when we ifconfig an interface up, but the end result seems a
little bogus: the change of the IFF_UP flag should be propagated
down to the driver before calling any other ioctl() that might actually
require the hardware to be up and running.
Pathnames as .Nm arguments in the NAME section isn't a
good idea, as they appear in the whatis(1) output. So
replace them with the lowercase version of the document
title. While here, do some tiny markup fixes.
When avoiding the zeroing of "bogus_page" when it appears in a buf,
be sure to advance the pointers into the data for successive pages.
The bug caused file corruption when read(2)ing from a "hole" in a
file where a previous page of the read block had already been faulted
in: fsx tripped up on this pretty quickly. The particular access
pattern is probably pretty unusual, so other applications probably
wouldn't have had problems, but you'd never know.
des [Tue, 6 Jul 2004 15:15:14 +0000 (15:15 +0000)]
Fix a number of incorrect assumptions regarding the size of time_t.
The code has its own TIME type, which is actually defined to time_t,
but it still used u_int32_t in some places.
In addition, dhclient not only had two separate global cur_time
variables, one of which was defined as u_int32_t and the other as
TIME, but cur_time was sometimes shadowed by local variables, leading
to widespread confusion as to which of these variable was being
referenced.
There is a lesson in here somewhere: a decent compiler with warnings
enabled should have caught all of this long before it became a
problem.
This patch has been submitted to the vendor, but it will likely be
some time before they release a version that includes it.
projects / FreeBSD / FreeBSD.git / log