. The main device node now supports automatic density selection for
commonly used media densities. So you can stuff your 1.44 MB and
720 KB media into your drive and just access /dev/fd0, no questions
asked. It's all that easy, isn't it? :)
. Device density handling has been completely overhauled. The old way
of hardwired kernel density knowledge is no longer there. Instead,
the kernel now implements 16 subdevices per drive. The first
subdevice uses automatic density selection, while the remaining 15
devices are freely programmable. They can be assigned an arbitrary
name of the form /dev/fd[:digit]+.[:digit:]{1,4}, where the second
number is meant to either implement device names that are mnemonic
for their raw capacity (as it used to be), or they can alternatively
be created as "anonymous" devices like fd0.1 through fd0.15,
depending on the taste of the administrator. After creating a
subdevice, it is initialized to the maximal native density of the
respective drive type, so it needs to be customized for other
densities by using fdcontrol(8). Pseudo-partition devices (fd0a
through fd0h) are still supported as symlinks.
. The old hack to use flags 0x1 to always assume drive 0 were there is
no longer supported; this is now supposed to be done by wiring the
devices down from the loader via device flags. On IA32
architectures, the first two drives are looked up in the CMOS
configuration records though. On PCMCIA (i. e., the Y-E Data
controller of the Toshiba Libretto), a single drive is always
assumed.
. Other specialities like disabling the FIFO and not probing the drive
at boot-time are selected by per-controller or per-drive flags, too.
. Unit attentions (media has been changed) are supposed to be detected
now; density autoselection only occurs after a unit attention. (Can
be turned off by a per-drive flag, this will cause each Fdopen() to
perform the autoselection.)
. FM floppies can be handled now (on controllers that actually support
it -- not all do these days).
. Fdopen() can be told to avoid density selection by setting
O_NONBLOCK; this leaves the descriptor in a half-opened state where
only a few ioctls are accepted. This is necessary to run fdformat
on a device that uses automatic density selection (since you cannot
autoselect on an unformatted medium, obviously).
. Just differentiate between a plain old NE765 and the enhanced chips,
but don't try more; the existing code was wrong and only misdetected
the chips anyway.
BUGS and TODOs:
. All documentation update still needs to be done.
. Formatting not-so-standard format yields unpredictable results; i
have yet to figure out why this happens. "Standard" formats like
720 and 1440 KB do work, however.
. rc scripts are needed to setup device nodes with nonstandard
densities (like the old /dev/fdN.MMM we used to have).
. Obtaining device flags from the kernel environment doesn't work yet,
thus currently only drives that are present in (IA32) CMOS are
really detected. Someone who knows the odds and ends about device
flags is needed here, i can't figure out what i'm doing wrong.
. 2.88 MB still needs to be done.
Non-SMP, i386-only, no polling in the idle loop at the moment.
To use this code you must compile a kernel with
options DEVICE_POLLING
and at runtime enable polling with
sysctl kern.polling.enable=1
The percentage of CPU reserved to userland can be set with
sysctl kern.polling.user_frac=NN (default is 50)
while the remainder is used by polling device drivers and netisr's.
These are the only two variables that you should need to touch. There
are a few more parameters in kern.polling but the default values
are adequate for all purposes. See the code in kern_poll.c for
more details on them.
Polling in the idle loop will be implemented shortly by introducing
a kernel thread which does the job. Until then, the amount of CPU
dedicated to polling will never exceed (100-user_frac).
The equivalent (actually, better) code for -stable is at
http://info.iet.unipi.it/~luigi/polling/
and also supports polling in the idle loop.
NOTE to Alpha developers:
There is really nothing in this code that is i386-specific.
If you move the 2 lines supporting the new option from
sys/conf/{files,options}.i386 to sys/conf/{files,options} I am
pretty sure that this should work on the Alpha as well, just that
I do not have a suitable test box to try it. If someone feels like
trying it, I would appreciate it.
NOTE to other developers:
sure some things could be done better, and as always I am open to
constructive criticism, which a few of you have already given and
I greatly appreciated.
However, before proposing radical architectural changes, please
take some time to possibly try out this code, or at the very least
read the comments in kern_poll.c, especially re. the reason why I
am using a soft netisr and cannot (I believe) replace it with a
simple timeout.
Quick description of files touched by this commit:
sys/conf/files.i386
new file kern/kern_poll.c
sys/conf/options.i386
new option
sys/i386/i386/trap.c
poll in trap (disabled by default)
sys/kern/kern_clock.c
initialization and hardclock hooks.
sys/kern/kern_intr.c
minor swi_net changes
sys/kern/kern_poll.c
the bulk of the code.
sys/net/if.h
new flag
sys/net/if_var.h
declaration for functions used in device drivers.
sys/net/netisr.h
NETISR_POLL
sys/dev/fxp/if_fxp.c
sys/dev/fxp/if_fxpvar.h
sys/pci/if_dc.c
sys/pci/if_dcreg.h
sys/pci/if_sis.c
sys/pci/if_sisreg.h
device driver modifications
a GetAllNext response. Otherwise, we won't unswizzle
it correctly. This was found on linux/PPC.
This mandated creating another inline: isp_get_gan_response.
Introduce an additional device flag for those NICs which require the
transmit buffers to be aligned to 32-bit boundaries.
(the equivalen fix for STABLE is slightly simpler because there are
no supported chips which require this alignment there.)
the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have
a complete set of inline functions in isp_inline.h. Each platform is
responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32}
macros.
The reason this needs to be done is that we need to have a single set of
functions that will work correctly on multiple architectures for both little
and big endian machines. It also needs to work correctly in the case that
we have the request or response queues in memory that has to be treated
specially (e.g., have ddi_dma_sync called on it for Solaris after we update
it or before we read from it). It also has to handle the SBus cards (for
platforms that have them) which, while on a Big Endian machine, do *not*
require *most* of the request/response queue entry fields to be swizzled
or unswizzled.
One thing that falls out of this is that we no longer build requests in the
request queue itself. Instead, we build the request locally (e.g., on the
stack) and then as part of the swizzling operation, copy it to the request
queue entry we've allocated. I thought long and hard about whether this was
too expensive a change to make as it in a lot of cases requires an extra
copy. On balance, the flexbility is worth it. With any luck, the entry that
we build locally stays in a processor writeback cache (after all, it's only
64 bytes) so that the cost of actually flushing it to the memory area that is
the shared queue with the PCI device is not all that expensive. We may examine
this again and try to get clever in the future to try and avoid copies.
Another change that falls out of this is that MEMORYBARRIER should be taken
a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the
entry being added. But there had been many other places this had been missing.
It's now very important that it be done.
Additional changes:
Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry,
the iptr value that gets returned is the value we intend to eventually plug
into the ISP registers as the entry *one past* the last one we've written-
*not* the current entry we're updating. All along we've been calling sync
functions on the wrong index value. Argh. The 'fix' here is to rename all
'iptr' variables as 'nxti' to remember that this is the 'next' pointer-
not the current pointer.
Devote a single bit to mboxbsy- and set aside bits for output mbox registers
that we need to pick up- we can have at least one command which does not
have any defined output registers (MBOX_EXECUTE_FIRMWARE).
MFC after: 2 weeks
pcm0: ac97 codec failed to reset extended mode (0, got 80)
This was due to not masking off the correct extended function bits
in the read value from the extended status reg.
MFC after: 2 days
some Toshiba and Thinkpad laptops.
Wakeup event is generated by power button or sleep button on some
laptops but this also generates SCI interrupt, and shutdown the system
as result. So this is introduced so that acpi driver ignore given
requests for certain period.
the UFI command set. Even with this patch, it's incredibly slow on my
laptop, but at least now it works.
Note that the drive is reported to CAM with the vendor and device IDs from
the device itself, forcing the user to patch the da(4) quirk table
manually.
controllers. There still seems to be some issues with the DRI copying code
for some adapters, at least it doesn't hang the system now. Input would be
appreciated.
PR: 32301
Obtained from: Eric Anhlot <eanholt@gladstone.uoregon.edu>, Joe <joeo@nks.net>
The reason we are required to commit to -current first is so that later
MFC's do not risk the loss of existing bug fixes. Even if this was not
strictly required in -current, it should still be fixed there too.
1. Changed incorrect conditional in fxhw.c which would never
evaluate to true. Thanks to John Polstra for pointing that out.
2. Write to PCI config space by default, enabling memory access and
bus master enable.
Submitted by:Prafulla Deuskar
MFC after:3 days
Similar code was submitted in PR 5559 by Takeshi OHASHI-san, but the
PC Card system has changed much since then, so this is a fresh
implementation.
PR: i386/5559
Submitted by: Takeshi OHASHI
prism2 flag in pccard.conf, but I'm leaving it place for the moment in
case the small sample of PrismII cards that I've tried is not
representative.
MFC After: 30 days
Obtained from: NetBSD
