that I have. Wait up to 1.1s for the card to become ready. Document
what the standards say, and use that to justify the behavior in the
code: PCI standard says that a card must respond to configuration
cycles within 2^25 cycles after reset goes high, which is
approximately 1s. Therefore, give cards a little break and wait for
up to 1.1s for VENDOR to become valid. Only look at the vendor part
of the ID, since only it can't be 0xffff (although in practice
vendor/device will always be != 0xfffffffff). Include detailed
pointers to standards so epople understand why we're doing what we're
doing and why it just might be OK. Make it clear in the timeout
message that it is just a warning, sinc we try to soldier on as best
we can anyway.
This should eliminate an error message that r181453 produced on
certain Atheros cards.
more mappings to the same physical page have different memory types, i.e.,
PAT settings. Consequently, if pmap_change_attr() is applied to a virtual
address range within the kernel map, then the corresponding ranges of the
direct map also need to be changed. Enhance pmap_change_attr() to handle
this case automatically.
Add a comment describing what pmap_change_attr() does.
Discussed with: jhb
and also holds things up, check every 20ms to see if we can read the
vendor of device 0.0. It will be 0xffffffff until the card is out of
reset. Always wait at least 20ms, for safety.
I think this is a better fix to the reset problem. However, I did it
as a separate commit in case something bad happens, people can roll
back to the commit before this one to see if that gives them reliable
behavior. I don't have FreeBSD up on enough machines to do exhaustive
testing on all known bridges...
some bridge + card combinations that take longer for reasons unknown.
Adjust the timeout to be 100ms on all !RICOH bridges, but leave RICOH
at 400ms. The 400ms is "lore" from other open source projects, and
I've never see my ricoh bridge chips take this long. Maybe it is the
same thing? Maybe a bit should be read instead of a hard-wired pause?
After this adjustment, a few cards that I'd insert and get only:
cbb0: card_power: 3V
cbb0: card_power: 0V
with full debugging enabled would actually try to attach.
Reported by: sam@ (I think)
MFC after: 3 days
set the %eflags used during a BIOS call via BTX to 0x202. Previously
the flags field was uninitialized garbage, and thus it was "random" if
interrupts were enabled or not during BIOS calls.
- Use constants from <machine/psl.h> for fields in %eflags.
MFC after: 3 days
- I had errantly assumed that all user requests should run with interrupts
enabled. User requests for software interrupts, however, need to disable
interrupts (and tracing) just like hardware interrupts.
- Disable alignment checking when emulating a hardware interrupt as well
(based on the description of the real mode operation of the 'INT'
instruction in the IA-32 manuals).
- Use constants for fields in %eflags.
Tested by: bz
MFC after: 3 days
features of CPUs like reading/writing machine-specific registers,
retrieving cpuid data, and updating microcode.
- Add cpucontrol(8) utility, that provides userland access to
the features of cpuctl(4).
- Add subsequent manpages.
The cpuctl(4) device operates as follows. The pseudo-device node cpuctlX
is created for each cpu present in the systems. The pseudo-device minor
number corresponds to the cpu number in the system. The cpuctl(4) pseudo-
device allows a number of ioctl to be preformed, namely RDMSR/WRMSR/CPUID
and UPDATE. The first pair alows the caller to read/write machine-specific
registers from the correspondent CPU. cpuid data could be retrieved using
the CPUID call, and microcode updates are applied via UPDATE.
The permissions are inforced based on the pseudo-device file permissions.
RDMSR/CPUID will be allowed when the caller has read access to the device
node, while WRMSR/UPDATE will be granted only when the node is opened
for writing. There're also a number of priv(9) checks.
The cpucontrol(8) utility is intened to provide userland access to
the cpuctl(4) device features. The utility also allows one to apply
cpu microcode updates.
Currently only Intel and AMD cpus are supported and were tested.
Approved by: kib
Reviewed by: rpaulo, cokane, Peter Jeremy
MFC after: 1 month
There is no need to mark this device node to use Giant. The only
architectures that use io(4) (i386 and amd64) only change a flag in
td->td_frame, which is only accessed by curthread.
Apart from this change, I think some fishy things may happen when using
/dev/io in multithreaded applications. I haven't tested, but looking at
the code, the flag doesn't get cleared when close() is called from
another thread, but this may not be this important.
I'm not removing D_NEEDGIANT from mem(4), because this driver isn't
Giant safe at all (it calls GIANT_REQUIRED).
no particular reason for them to be implemented in assembler and
having them in C allows easier extension as well as using more C
macros and {d,i}tlb_slot_max rather than hard-coding magic (and
actually spitfire-only) values.
- Fix the compilation of pmap_print_tte().
- Change pmap_print_tlb() to use ldxa() rather than re-rolling it
inline as well as TLB_DAR_SLOT and {d,i}tlb_slot_max rather than
hardcoding magic (and actually spitfire-only) values.
- While at it, suffix the above mentioned functions with "_sun4u" to
underline they're architecture-specific.
- Use __FBSDID and macros instead of magic values in locore.S.
- Remove unused includes and smp_stack in locore.S.
msleep/mtx_sleep or the various cv_*wait*() routines. Currently, the
"unlock" behavior of PDROP and cv_wait_unlock() with Giant is not
permitted as it is will be confusing since Giant is fully unrecursed and
unlocked during a thread sleep.
This is handy for subsystems which wish to allow unlocked drivers to
continue to use Giant such as CAM, the new TTY layer, and the new USB
stack. CAM currently uses a hack that I told Scott to use because I
really didn't want to permit this behavior, and the TTY and USB patches
both have various patches to permit this.
MFC after: 2 weeks
NEC PC-9801N-J02 and PC-9801N-J02R. I can't test the former because
it requires resources that conflict with my laptop. I can't test the
latter because my dog chewed up my -J02R card and it didn't survive
well enough for me to test.
http://www.t10.org/lists/1spc-lst.htm
Note opcodes for scanner and communication devices are taken from the previous
revision because they are not listed in the files any more.
Also, note newly added ASCs are all marked with 'XXX TBD' and take SS_RDEF action
for now. Some ASCs need SS_TUR for error recovery or SS_FATAL to prevent further
retrials. We should deal with them later.
Reviewed by: scottl, ken
would call ed_release_resources() when we should have called
ed_detach() to properly undo the effects of prior calls to
ed_attach(). This would leave a stray ed interface ifnet alive in the
system, which was, well, bad, since we called if_free() on the
underlying memory... Fix the ed_detach routine to cope being called
in this context now.
This should never come up because the miibus is always there. Except
for now when it seems to be failing for reasons unknown... That's a
different bug that hits at least ed, xl, dc and fxp...
performed with snapshot option, while the mp->mnt_opt is NULL.
Protect against NULL pointer dereference.
Noted by: Mateusz Guzik <mjguzik gmail com>
MFC after: 3 days
procedure. There were some subtle differences before that could lead
to a variety of bugs, including resources being lost (in one case
forever). pccard_probe_and_attach_card does this now, and includes
comments about what's going on and why, since it isn't obvious from
the code. Please let me know if I've missed anything...
Provide a new function called pccard_select_cfe that allows drivers to
select which configuration entry to use. This is needed for some
older pre-MFC standard cards with many functions that want to activate
all their functions by selecting alternative entries, or to work
around broken ones. pccard_select_cfe will migrate into the
pccard_if.m interface as its interface stabilizes to keep all the
pccard drivers from referencing any symbols in the pccard.ko module
directly.
Fix a printf to refer to the right function name.
pci_add_map(). First, this condition is already handled earlier in
the function. Second, as written the check would never fire as the
'start' value was overwritten with a long value (rman_get_start() returns
long) before the comparison was done.
Discussed with: imp
MFC after: 2 weeks
routine wakes up proc0 so that proc0 can swap the thread back in.
Historically, this has been done by waking up proc0 directly from
setrunnable() itself via a wakeup(). When waking up a sleeping thread
that was swapped out (the usual case when waking proc0 since only sleeping
threads are eligible to be swapped out), this resulted in a bit of
recursion (e.g. wakeup() -> setrunnable() -> wakeup()).
With sleep queues having separate locks in 6.x and later, this caused a
spin lock LOR (sleepq lock -> sched_lock/thread lock -> sleepq lock).
An attempt was made to fix this in 7.0 by making the proc0 wakeup use
the ithread mechanism for doing the wakeup. However, this required
grabbing proc0's thread lock to perform the wakeup. If proc0 was asleep
elsewhere in the kernel (e.g. waiting for disk I/O), then this degenerated
into the same LOR since the thread lock would be some other sleepq lock.
Fix this by deferring the wakeup of the swapper until after the sleepq
lock held by the upper layer has been locked. The setrunnable() routine
now returns a boolean value to indicate whether or not proc0 needs to be
woken up. The end result is that consumers of the sleepq API such as
*sleep/wakeup, condition variables, sx locks, and lockmgr, have to wakeup
proc0 if they get a non-zero return value from sleepq_abort(),
sleepq_broadcast(), or sleepq_signal().
Discussed with: jeff
Glanced at by: sam
Tested by: Jurgen Weber jurgen - ish com au
MFC after: 2 weeks
for a PCI device during the boot-time probe of the parent PCI bus, then
zero the BAR and clear the resource list entry for that BAR. This forces
the PCI bus driver to request a valid resource range from the parent bridge
driver when the device driver tries to allocate the BAR. Similarly, if the
initial value of a BAR is a valid range but it is > 4GB and the current OS
only has 32-bit longs, then do a full teardown of the initial value of the
BAR to force a reallocation.
Reviewed by: imp
MFC after: 1 week
of having duplicate versions in each bus attachment.
- Add a DRIVER_MODULE() instance so that the iicbus(4) driver will
actually attach to pcf(4) driver instances.
- Fix compile of envctrl.c.
Pointy hat: jhb (3)
- ad7418(4) uses an sx lock instead of a mtx since the iicbus(4) stuff it
calls can sleep (request_bus()). Also, I expanded the locking slightly
to serialize writes to data stored in the softc.
- Similarly, the icee(4) driver now uses an sx lock instead of a mutex.
I also removed the pointless OPENED flag and flags field from the softc.
- The locking for the ic(4) driver was a bit trickier:
- Add a mutex to the softc to protect softc data.
- The driver uses malloc'd buffers that are the size of the interface
MTU to send and receive packets. Previously, these were allocated
every time the interface was brought up and anytime the MTU was
changed, with various races that could result in memory leaks. I
changed this to be a bit simpler and more like other NIC drivers in
that we allocate buffers during attach for the default MTU size and
only reallocate them on MTU changes. The reallocation procedure
goes to some lengths with various flags to not replace either the
the receive or transmit buffers while the driver is busy receiving
or transmitting a packet.
- Store the device_t of the driver in the softc instead of detours into
new-bus using if_dunit from the ifnet and an even more bizarre detour
to get the softc instead of using if_softc.
- Drop the driver mutex when invoking netisr_dispatch() to pass the
packet up to IP.
- Use if_printf().
- Add an sx lock to the iic(4) driver to serialize open(), close(), read(),
and write and to protect sc_addr and sc_count in the softc.
- Use cdev->si_drv1 instead of using the minor number of the cdev to
lookup the softc via newbus in iic(4).
- Store the device_t in the softc to avoid a similar detour via minor
numbers in iic(4).
- Only add at most one instance of iic(4) and iicsmb(4) to each iicbus(4)
instance, and do it in the child driver.
- Add a mutex to the iicbus(4) softc to synchronize the request/release bus
stuff.
- Use __BUS_ACCESSOR() for IICBUS_ACCESSOR() instead of rolling our own.
- Add a mutex to the iicsmb(4) softc to protect softc state updated in the
interrupt handler.
- Remove Giant from all the smbus methods in iicsmb(4) now that all the
iicbus(4) backend is locked.
- Just grab Giant in the ixp425_iic(4) driver since this driver uses
a shared address/data register window pair to access the actual
I2C registers. None of the other ixp425 drivers lock access to these
shared address/data registers yet and that would need to be done before
this could use any meaningful locking.
- Add locking to the interrupt handler and 'iicbus_reset' methods of the
at91_twi(4) driver.
- Add locking to the pcf(4) driver. Other pcf(4) fixes include:
- Don't needlessly zero the softc.
- Use bus_foo rather than bus_space_foo and remove bus space tag and
handle from softc.
- The lpbb(4) driver just grabs Giant for now. This will be refined later
when ppbus(4) is locked.
- As was done with smbus earlier, move the DRIVER_MODULE() lines to match
the bus driver (either iicbus or iicbb) to the bridge driver into the
bridge drivers.
Tested by: sam (arm/ixp425)
- Add a mutex to the softc to protect the softc and device hardware.
- Use a private timer routine to drive the transmit watchdog timer instead
of using if_watchdog/if_timer.
- If if_alloc() fails during attach, fail the attach with an error rather
than panic'ing.
- Clear RUNNING and OACTIVE only in sncstop().
- Don't mess with IFF_UP.
- Don't leak 'struct ifnet' on detach.
- Setup interrupt handler after ether_ifattach().
- Call ether_ifdetach() rather than if_detach() in the pccard detach
routine.
Tested by: no one despite repeated requests
- let the loop iterate every page (as intended), and not some multiplies
(which led to a fake exhaustion of the ARM_NOCACHE_KVA_SIZE)
- eliminate using MIN(): it compared number of pages vs. address
(ARM_TP_ADDRESS), which was bogus
Reviewed by: cognet, imp
Obtained from: Piotr Ziecik kosmo ! semihalf dot com
MFC after: 3 days
