we actually use. Originally, the code reserved 0x8000 to 0x80ff inclusive
which on my hardware conflicts with the acpi timer. This broke the amdpm
driver since it was actually given ports 0x800c to 0x810b (which should
not have happened, IMHO).
This also allows us to considerably simplify the handling of the nForce
smb driver, removing the need for a separate nfpm driver. With this, SMB
accesses appear to work on my Tyan Tiger MP board. Your mileage may vary.
In particular, the nForce changes have not been tested.
we can switch to 64M-sized identity mappings and not having to map the
first 64M. This is especially important because the first 1M contains
the VGA frame buffer and is otherwise a legacy memory range. Best to
make as little assumptions about it as possible. Switching to 64M-sized
mappings is important to avoid creating overlapping translations, which
have the side-effect of triggering machine checks. This is currently
what's preventing us to boot on an Intel Tiger 4.
Note that since we currently use 256M-sized identity mappings, we
would reduce the size of the mappings and consequently increase the
TLB pressure. The performance implications of this are minimal if
measurable at all because identify mappings are not our primary
means for memory management.
Also note that there's no guarantee that physical memory exists at
64M. Then again, we didn't had the guarantee when we were loading at
5M. We'll deal with this when it's a problem.
Discussed with: arun@
Special thanks to Pavlin Radoslavov <pavlin@icir.org> for testing and
fixing numerous problems.
Sponsored by: FreeBSD Foundation
Reviewed by: Pavlin Radoslavov <pavlin@icir.org>
and/or INTR_FAST. This belongs elsehwere and perhaps under bootverbose;
I'm committing it for now as it's uesful to know which drivers have
been converted and which have not.
we return to kernel or userland. This triggered a panic in a KSE
application when TDF_USTATCLOCK was set in the case userland was
interrupted, but we never called ast() on our way out. As such,
we called ast() at some other time. Unfortunately, TDF_USTATCLOCK
handling assumes running in the interrupt thread. This was not
the case anymore.
To avoid making the same mistake later, interrupt() now returns
to its caller whether we interrupted userland or not. This avoids
that we have to duplicate the check in assembly, where it's bound
to fall off the scope. Now we simply check the return value and
call ast() if appropriate.
Run into this: davidxu
to protect the vlan state in each ifnet (e.g. vlan count). The latter is
probably better handled through an ifnet-centric means but since changes
are infrequent shouldn't matter for now.
Sponsored by: FreeBSD Foundation
For the floppy driver, use fdcontrol to manipulate density selection.
For the CD drivers, the 'a' and 'c' suffix is without actual effect and
any applications insisting on it can be satisfied with a symlink:
ln -s /dev/cd0 /dev/cd0a
Ongoing discussion may result in these pieces of code being removed before
the 5-stable branch as opposed to after.
such a card is ejected, we'd panic. Instead, just ignore it.
I should also add a sanity check in the FUNCID code as well, but this
isn't wrong since the check is cheap and happens infrequently.
into targreadfilt(). Unlock around calls to notify_user(). If an application
is sending CCBs while the endpoint is shutting down, this may result in
incomplete disable. A more complete solution will come with a "dying" flag.
Submitted by: simokawa
a correctable DMA error. Failing to do so can cause the error interrupt
to be triggered over and over again.
- Clean up the comments for UEAFSR_* constants, fix a typo (UEAFSR_BLK is
(1 << 23), not (1 << 22)), and add two more. Also, add similar constants
for the CE AFSR bits.
We can't update the device description in attach (why not ?), so
we device_print() what we find.
Conditionalize the short cable fix on this being older than rev 16A.
Call device_printf() when we apply short cable fix.
Include interrupt hold-off setting for rev 16+ under "#ifdef notyet"
The device_printf()'s will go under bootverbose once the various
issues have settled a bit.
out of cdregister() and daregister(), which are run from interrupt context.
The sysctl code does blocking mallocs (M_WAITOK), which causes problems
if malloc(9) actually needs to sleep.
The eventual fix for this issue will involve moving the CAM probe process
inside a kernel thread. For now, though, I have fixed the issue by moving
dynamic sysctl variable creation for these two drivers to a task queue
running in a kernel thread.
The existing task queues (taskqueue_swi and taskqueue_swi_giant) run in
software interrupt handlers, which wouldn't fix the problem at hand. So I
have created a new task queue, taskqueue_thread, that runs inside a kernel
thread. (It also runs outside of Giant -- clients must explicitly acquire
and release Giant in their taskqueue functions.)
scsi_cd.c: Remove sysctl variable creation code from cdregister(), and
move it to a new function, cdsysctlinit(). Queue
cdsysctlinit() to the taskqueue_thread taskqueue once we
have fully registered the cd(4) driver instance.
scsi_da.c: Remove sysctl variable creation code from daregister(), and
move it to move it to a new function, dasysctlinit().
Queue dasysctlinit() to the taskqueue_thread taskqueue once
we have fully registered the da(4) instance.
taskqueue.h: Declare the new taskqueue_thread taskqueue, update some
comments.
subr_taskqueue.c:
Create the new kernel thread taskqueue. This taskqueue
runs outside of Giant, so any functions queued to it would
need to explicitly acquire/release Giant if they need it.
cd.4: Update the cd(4) man page to talk about the minimum command
size sysctl/loader tunable. Also note that the changer
variables are available as loader tunables as well.
da.4: Update the da(4) man page to cover the retry_count,
default_timeout and minimum_cmd_size sysctl variables/loader
tunables. Remove references to /dev/r???, they aren't used
any longer.
cd.9: Update the cd(9) man page to describe the CD_Q_10_BYTE_ONLY
quirk.
taskqueue.9: Update the taskqueue(9) man page to describe the new thread
task queue, and the taskqueue_swi_giant queue.
MFC after: 3 days
in a list head instead of a pointer to the first element at the time of
the first call. These lists are subject to change, and getdirtybuf()
would refetch from the wrong list in some cases.
Spottedy by: tegge
Pointy hat to: me
