understand exactly what it is about SMPng that tickles this bug. What I
do know is that the foo_init() routine in most drivers is often called
twice when an interface is brought up. One time is due to the ifconfig(8)
command calling the SIOCSIFFLAGS ioctl to set the IFF_UP flag, and another
is probably due to the kernel calling ifp->if_init at some point. In any
case, the SMPng changes seem to affect the timing of these two events in
such a way that there is a significant delay before any packets are sent
onto the wire after the interface is first brought up. This manifested
itself locally as an SMPng test machine which failed to obtain an address
via DHCP when booting up.
It looks like the second call to fxp_init() is happening faster now than
it did before, and I think it catches the chip while it's in the process
of dealing with the configuration command from the first call. Whatever
the case, a FXP_CSR_SCB_CNA interrupt event is now generated shortly after
the second fxp_init() call. (This interrupt is apparently never generated
by a non-SMPng kernel, so nobody noticed.)
There are two problems with this: first, fxp_intr() does not handle the
FXP_CSR_SCB_CNA interrupt event (it never tests for it or does anything
to deal with it), and second, the meaning of FXP_CSR_SCB_CNA is not
documented in the driver. (Apparently it means "command unit not active.")
Bad coder. No biscuit.
The fix is to have the FXP_CSR_SCB_CNA interrupt handled just like the
FXP_SCB_STATACK_CXTNO interrupt. This prevents the state machine for
the configuration/RX filter programming stuff from getting wedged for
several seconds and preventing packet transmission.
Noticed by: jhb
This is done by misusing the device minor a bit to encode the
track no there.
So to read track #4 just use /dev/acdNt4 where N is the device #.
The driver no automatically sets the blocksize (sectorsize) to
what the track is set to in the TOC.
This has the nice effect that you can now rip audioi tracks
by simply doing:
dd if=/dev/acdNt2 of=audiotrack2.raw bs=2352
it cant be much simpler than that :)
NOTE: the original acdNa & acdNc device still work as usual,
except the blocksize is set according to track0.
from the SCSI id it has. (this avoids the confusing umass-sim32 device. It
should have been umass-sim0 all along (there is only one), and if it is
spoken to as a SCSI device the sim should be umass32.
Make the rescan actually work. We need to fill in a target and lun wildcard
and not the SCSI id of the SIM.
Add a seatbelt.
position, channel 1's dma position register must be quiescent. So
the driver will spl, pause the DMA, delay a bit and hold as still as
possible while snapping the picture.
I'm sure there HAS to be a better way to do this, but if there is, it's
not documented.
So far as I can tell, this fixes recording, which means the Solo is open
for business.
cases the registers are not correctly set on resume.
This solves the problem of USB failing after resuming a machine.
Submitted by: mike+fbsd@medianstrip.net
PR: 18261
Promise Ultra100 / Fasttrak100
HighPoint HPT370 controllers (fx Abit KA7-100 onboard ctrl, Abit HotRod 100)
Intel ICH2 (Intel 815E based motherboards)
So far I can read >90MB/s on the Promise and the HPT370.
I can write >64MB/s on the promise and >50MB/s on the HPT370 so it seems
writing is still done in ATA66 mode :(
The ICH2 support is untested as of yet...
modules to depend on modules in the same file (uhub depends on usb) or
even on themselves (usb on usb, makes the define in usb_port.h a lot
less convoluted).
Use ANSI prototypes.
the scratch RAM for data normally found in the SEEPROM (presumably in the
event that the SEEPROM is unavailable or can't be read). This code causes
a spontaneous reboot on monster.osd.bsdi.com, which has an embedded aic7880
controller. The problem appears to happen either when it writes to the
SCBPTR port and then reads from the SCB_CONTROL port. Somewhere during
the inb/outb operations, the system has a heart attack and restarts.
This code looks very suspicious, particularly since it has unconditionalized
debug mesages such as "Got here!" and "And it even worked!". With this
block #ifdef'ed out, the machine boots and runs properly. I stronly suggest
that it stay #ifdef'ed out until it's properly tested.
opens if the reference count is not decremented on close.
Note that this may result in the reference count being corrupted
on full duplex devices (due to mismatching opens/closes), but the
code doesn't use the reference count for anything on full duplex
devices.
2. Offer half duplex with both playback and record on channel 1 or
full duplex with playback always on channel 2 as a compile-time option.
3. 16 bit record output is byte swapped for some dumb reason. Report the _BE
AFMTs for recording.
if you kldload this driver, all the subordinate devices are probed/attached
as expected. But this is not the case when the driver is statically compiled
into the kernel. Since I do most of my testing with modules, I failed to
notice this. I'm not sure if it's intended behavior or not. I think it may
be, but it seems a little counter-intuitive.
16 bit samples have some sort of choppiness, the nature of which
is not completely clear, but it clearly has something to do with
dma buffer synchronization. But at least channel 1 makes noise now.
appears to be the correct length, but quality of output has not yet
been tested. Also, full duplex audio (that is, playback on channel 1)
does not yet work. Two constants and I am there!
Obtained from: major hints from ALSA
with LEDs on some cards being stomped on when clearing the "jabber disable"
bit. Using DC_SETBIT() has an unwanted side effect of setting a write enable
bit in the watchdog timer register which we really want to be cleared when
we do a write.
