| Age | Commit message (Collapse) | Author |
|---|
|
ok pedro@
|
|
something really big. The SCSI layer isn't yet ready for it.
|
|
in the inquiry error paths, as the HBA will have already completed the
ata_xfer with an error.
Reminder and ok dlg@
|
|
etc, just work.
|
|
For those people who have reported about broken MAC address at attach
time, this should fix the problem.
|
|
so that atascsi can deal with it.
|
|
|
|
passed; makes it less of nfs kind of code; henning@ ok
|
|
resetting it and stuff to avoid garbled dmesg output; found on some arm
|
|
|
|
|
|
routine, and check the return of the mapiodev, and dbdma_create functions.
Tested on Power Macintosh 9500MP and a 9600MP.
"the diff looks fine to me." dlg@
|
|
|
|
of the wdcreg.h include in atascsi.
"feel free to remove" pascoe@
|
|
before we enable AHCI, so enable it before resetting saved capabilities.
|
|
|
|
etc), and request that the D2H FIS at the completion of all (DMA) commands
generate an interrupt.
This makes each data transfer generate one interrupt instead of two and
should guarantee that the interrupt that is generated actually arrives
after the command has completed.
|
|
works.
From dlg@
|
|
|
|
|
|
simply include a pointer to the command FIS that we will issue to the device.
Include another space where we can copy back an error register set from a
failed command.
This means that we can now build and issue arbitrary commands from atascsi,
and retrieve errors back.
|
|
atascsi will be driving, and add it to the AHCI CCB.
This effectively gives us all the resources we need for a transfer in one
hit, meaning that we don't need to worry about whether we will have a pool
shortage or not enough CCBs. The SCSI mid layer should take care to never
exceed the number of CCBs we have available, based on our sc_link.openings.
|
|
|
|
|
|
From tbert <bret.lambert@gmail.com>
|
|
OK claudio@
|
|
the hard way on sparc64. Now acx(4) no longer panics but it does not yet
work. OK mglocker@
|
|
so prototype them there rather than in softraidvar.h.
shuffle these funcs a little bit while here to make it look more like
everything else.
ok marco@
|
|
|
|
|
|
|
|
|
|
tlb shootdowns in the reaper.
mickey@ ok
|
|
ok marco
|
|
way, rather than requiring some glue in each machines mainbus probe.
it is still commented out.
based on a discussion with miod@ ok marco@ deraadt@
|
|
|
|
accessing FFS1 fields, okay art@, quite some testing by ckuethe@, simon@
and thib@, thanks.
|
|
|
|
we had to put this workaround in since /etc/rc used to use the exit code
if "ifconfig pflog0" to decide wether we run on a kernel with pflog support.
rc has been fixed to explicitely create pflog0 when pf and pflogd are
enabled in November 2006, so now is the time to remove this compat hack.
pplz who haven't updated rc since 2006/11/16 lose pflogd. ok ryan theo
|
|
The "lapic" timer is ripped out since it wasn't actually a lapic timer,
but a hacked up tsc timer with some synchronization for MP. There is no
tsc timer right now since they are very unreliable on MP systems, systems
with apm, and systems that change the cpu clock. Which basically means
every modern machine out there. We're running with the i8259 timer now.
deraadt@ ok
|
|
the timedelta sensor when no PPS signal is available.
Previously, the timestamp was taken at the leading '$' character
of a GPRMC message, which was not always correct, as some GPS units
send other messages first; we do not know when the GPRMC message
is sent within a data block (we refer to a data block as the set
of NMEA messages that are sent by a GPS unit in one go, usually
once per second).
nmea(4) now takes the timestamp at the first '$' character received
after the start of a new seconds. Since GPS units transmit a data
block every second, the first message can be found by measuring the
gap between consecutive messages: after the longest gap, the first
message of the next second follows. And it is at the leading '$'
character of this message that we take the timestamp.
$GPGGA,..... <- take timestamp here
$GPGSA,.....
$GPRMC,..... <- decode time here
... <- possibly more messages
<- longer gap till start of next second
$GPGGA,..... <- it starts all over, take next timestamp
This code has been designed to work independent of the baudrate and
the rate at which the GPS sends out it's data blocks (usually 1 Hz,
but 5 Hz units are common as well):
With this change, precision is greatly improved in the absence of a
PPS signal and as a side effect, jitter is reduced.
Note that while this is much better than before, there is still a
slight offset to the real time, as calculating the fix in the GPS unit
and transmitting the '$' character takes a short, but unpredictable
amount of time.
When tty timestamping is enabled, but there is no PPS signal available,
the sensor status will be degraded to CRITICAL, which means "check your
hardware".
Thanks to Chris Kuethe for testing and feedback. ok ckuethe.
|
|
|
|
implementation of a RAID 1 is included in this but it does not deal with
failures yet. Disabled in GENERIC.
Suggestions from and ok beck@ miod@ krw@ dlg@ deraadt@
|
|
BCM5756). They still don't work but when they do they won't use an
inappropriate Jitter bug workaround. No effect on other chips.
From Michael Chan of Broadcom, via Linux tg3 via Brad.
ok reyk@
|
|
This provides a similar functionality as ARP balancing,
but also works for traffic that comes across routers.
IPv6 is supported as well.
The configuration scheme will change as soon we have sth better.
Also add support for changing the MAC address on carp(4)
interfaces. (code from mcbride)
Tested by pyr@ and reyk@
OK mcbride@
|
|
ok deraadt@
|
|
|
|
|
|
controllers don't. Put in a temporary hack for pxammc on Zaurus.
|
|
|
