Do not assume there is only a space between #define and the macro name
when grepping for JOBS. The recent style cleanup replaced the space with
a tab and broke job control detection. Little edits, disastrous consequences.
Submitted by: Peter Edwards <pmedwards@eircom.net>
X-MFC when: in about 5 weeks with the other sh arithmetic fixes.
Add support for automatic hardware flow control for 16[679]50 UARTs.
We simply use the detected FIFO size to determine whether we have
a post 16550 UART or not. The support lacks proper serialization of
hardware access for now.
Alan Cox [Sat, 13 Sep 2003 04:29:55 +0000 (04:29 +0000)]
Convert vmapbuf() from using pmap_extract() to using
pmap_extract_and_hold(). Note, however, that GIANT_REQUIRED should not be
removed until all platforms fully implement the "prot" parameter to
pmap_extract_and_hold().
Matt Jacob [Sat, 13 Sep 2003 01:58:26 +0000 (01:58 +0000)]
Some ridiculous target mode botches- like having the wrong definitions
for messages. Some spelling fixes. Some target mode structure cleanups
to reflect reality.
Matt Jacob [Sat, 13 Sep 2003 01:55:44 +0000 (01:55 +0000)]
On reset, make sure that we have some parameters set correctly. This
fixes a longstanding issue WRT resetting the chip after startup- it
would fail if we were connected as an F-port to a switch. If we
were connected as an F-port, we got assigned a hard loop ID of 255,
which is really a bogus loop id. Then when we turned around to
reset ourselves, the firmware would reject the ICB_INIT request
because the loop id was bogus. *sputter*
Minor fixlet from somebody in NetBSD with too much time on their
hands (dma -> DMA).
Thomas Moestl [Fri, 12 Sep 2003 20:13:23 +0000 (20:13 +0000)]
When determining the device class to use for the serial console, check
the "compatible" property too in the ns8250 case. This gets the serial
console to work on Blade 100s, where the device name is just "serial".
Move the parse8601 and parseDWM routines into a new ptime.c file. The
only code-change is to add a "next_time" parameter to both routines (and
that is not used yet). A later update will make "next_time" more useful.
Add support for using uart(4) for pulse capturing for the Pulse Per
Second (PPS) timing interface. The support is non-optional and by
default uses the DCD line signal as the pulse input. A compile-time
option (UART_PPS_ON_CTS) can be used to have uart(4) use the CTS line
signal.
Include <sys/timepps.h> in uart_bus.h to avoid having to add the
inclusion of that header in all source files.
Thomas Quinot [Thu, 11 Sep 2003 17:34:47 +0000 (17:34 +0000)]
(atapi_action, case XPT_PATH_INQ): Handle properly the case of
CAM_TARGET_WILDCARD (target_id_t is an unsigned integer type).
Fixes boot-time crash on Alpha.
Tom Rhodes [Thu, 11 Sep 2003 16:27:16 +0000 (16:27 +0000)]
Remove the unrequired -bi from the newaliases line. Note in the commit log
that the last change should have read: exim_enable="YES" in the changes listing.
Bill Paul [Thu, 11 Sep 2003 07:54:16 +0000 (07:54 +0000)]
Toggle the interface on and off before starting the diag test. This
seems to be necessary for the 8139C+ under certain circumstances, and
doesn't appear to hurt the other chips. (In the failure case, the
packet would be sent through the TX DMA ring but not get echoed
back. I suspect this has something to do with the link state changing
unexpectedly.)
Bill Paul [Thu, 11 Sep 2003 06:56:46 +0000 (06:56 +0000)]
- For the 8169 chips, read the station address by forcing an EEPROM
autoload and then copying the contends of the station address
registers. For some reason, reading the EEPROM on the 8169S doesn't
work right. This gets around the problem, and allows us to read
the station address correctly on the 8169S.
- Insert a delay after initiating packet transmition in re_diag() to
allow lots of time for the frame to echo back to the host, and wait
for both the 'RX complete' and 'timeout expired' bits in the ISR
register to be set.
- Deal more intelligently with the fact that the frame length
field in the RX descriptor is a different width on the 8139C+
than it is on the 8169/8169S/8110S
- For the 8169, you have to set bit 17 in the TX config register
to enter digital loopback mode, but for the 8139C+, you have to
set both bits 17 and 18. Take this into account so that re_diag()
works properly for both types of chips.
Bill Paul [Thu, 11 Sep 2003 03:53:46 +0000 (03:53 +0000)]
Add a PHY driver to support the built-in gigE PHY in the 8169S/8110S
ethernet chips. This driver is pretty simple, however it contains
special DSP initialization code which is needed in order to get
the chip to negotiate a gigE link. (This special initialization
may not be needed in subsequent chip revs.) Also:
- Fix typo in if_rlreg.h (RL_GMEDIASTAT_1000MPS -> RL_GMEDIASTAT_1000MBPS)
- Deal with shared interrupts in re_intr(): if interface isn't up,
return.
- Fix another bug in re_gmii_writereg() (properly apply data field mask)
- Allow PHY driver to read the RL_GMEDIASTAT register via the
re_gmii_readreg() register (this is register needed to determine
real time link/media status).
Rewrite the SAPIC initialization to always program the RTEs with what
we think is the correct trigger mode and polarity. This allows us to
implement BUS_CONFIG_INTR() as an update of the RTE in question.
Consequently, we can trust the RTE when we enable an interrupt and
avoids that we need to know about the trigger mode and polarity at
that time.
Extend the ACPI resource handling to make use of the BUS_CONFIG_INTR()
method. This is necessary on ia64 where it's known that serial interfaces
described in the ACPI namespace may not have the well-known IRQs assigned
to them. This confuses us in thinking they are PCI based interrupts and
wrongly program the APIC.
o Workaround a bug where my T23 reports that it is ACPI 2.0x compatible
but has invalid 64 bit pointers for FACS and DSDT.
o Finish work to print all of the FADT and FACS.
o Resort the comment generating functions. Submitted by: marcel
Introduce BUS_CONFIG_INTR(). The method allows devices to tell parents
about interrupt trigger mode and interrupt polarity. This allows ACPI
for example to pass interrupt resource information up the hierarchy.
The default implementation of the method therefore is to pass the
request to the parent.
Tom Rhodes [Wed, 10 Sep 2003 20:55:09 +0000 (20:55 +0000)]
With the exim port upgrade, modify sysinstall(8):
- Add 'enable_exim="YES"' to rc.conf(5)
- Use the default exim configuration file from the port
- When using sendmail, disable some more scripts that use sendmail specific
parameters
- Have sysinstall tweak mailer.conf(5) substitution
- Use 'N' flag for newsyslog(8)
Submitted by: Oliver Eikemeier <eikemeier@fillmore-labs.com>
Reviewed by: sheldonh, simon
Tested by: myself (trhodes) and submitter
Bill Paul [Wed, 10 Sep 2003 07:21:43 +0000 (07:21 +0000)]
Update hardware revision table. 0x04000000 appears to be the revision
for the 8169S, according to my sample board. The RealTek Linux driver
mentions 0x00800000. I'm assigning this to the 8110S until I get
more info on it. (The (preliminary) RealTek docs only say that 8169S/8110S
chips will have some combination of those two bits set, but doesn't say
exactly what bit combination goes with which chip variant.)
John Baldwin [Wed, 10 Sep 2003 06:00:53 +0000 (06:00 +0000)]
We represent PCI intpin's two different ways. One is the way that the
intpin register is expressed in hardware where 0 means none, 1 means INTA,
2 INTB, etc. The other way is commonly used in loops where 0 means INTA,
1 means INTB, etc. The matchpin argument to pci_cfgintr_search() is
supposed to be the first form, but we passsed in a loop index of the
second. This fix adds one to the loop index to convert to the first form.
If we failed to size the Rx FIFO, assume the worst. This however
is not a size of 1. Since we already know there is a FIFO, we can
safely assume that it is at least 16 bytes. Note that all this is
mostly academic anyway. We don't use the size of the Rx FIFO
currently. If we add support for hardware flow control, we only
care about Rx FIFO sizes larger than 16.
David Xu [Tue, 9 Sep 2003 22:38:12 +0000 (22:38 +0000)]
Original pthread_once code has memory leak if pthread_once_t is used in
a shared library or any other dyanmic allocated data block, once
pthread_once_t is initialized, a mutex is allocated, if we unload the
shared library or free those data block, then there is no way to deallocate
the mutex, result is memory leak.
To fix this problem, we don't use mutex field in pthread_once_t, instead,
we use its state field and an internal mutex and conditional variable in
libkse to do any synchronization, we introduce a third state IN_PROGRESS to
wait if another thread is already in invoking init_routine().
Also while I am here, make pthread_once() conformed to pthread cancellation
point specification.
Switch dotrim() to take advantage of the 'struct conf_entry' that
is already passed in, instead of having the caller copy values from
that struct into additional parameters.
Peter Wemm [Tue, 9 Sep 2003 19:32:09 +0000 (19:32 +0000)]
Clean up get/set_mcontext() and get/set_fpcontext(). These are operated
on data structures on the kernel stack which are guaranteed to be 16 byte
aligned by gcc, the amd64 ABI and __aligned(16).
Ensire the tss_rsp0 initial stack pointer is 16 byte aligned in case
sizeof(pcb) becomes odd at some point. This is convenient for the
interrupt handler case because the ring crossing pushes cause the
required odd alignment before the call to the C code.
Have fast_syscall add an additional 8 bytes to ensure that the trapframe
has the correct odd alignment for the call to C code. Note that there are
no checks to make sure that the trapframe size is appropriate for this.
This makes get/setfpcontext work properly (finally). You get a GPF in
kernel mode if any of this is botched without the alignment fixup code
that is apparently needed on i386.