Commit Graph

14888 Commits

Author SHA1 Message Date
Poul-Henning Kamp
77dfeead45 Fix various typos and brainos in last commit.
Submmited by:	Andrew Turner <andrew@fubar.geek.nz>
2006-05-30 07:56:57 +00:00
Paul Saab
f83695f5e9 Spin until a request structure is available in the ioctl path. 2006-05-30 06:42:02 +00:00
Matt Jacob
ec5fe39d39 Add acknowledgements to LSI-Logic for support 2006-05-29 20:34:28 +00:00
Matt Jacob
800d362b5d + Change some debug messages to MPT_PRT_NEGOTIATE level (so we
can see the results of SPI negotiation w/o being overwhelmed
with other crap).

+ For U320 devices, check against both Settings *and* DV flags before
deciding whether we need to skip actual SPI settings for a device.

+ Go back to creating a 'physical disk' side of a raid/passthru bus that
is limited to the number of maximum physical disks. Actually, this isn't
probably *quite* right yet for one RAID volume, and if we ever end up
with finding a device that supports more than one RAID volume (not likely),
it probably won't quite be right either.

The problem here is that the creating of this 'physical' passthru sim is
just a cheap way to leverage off the CAM midlayer to do our negotiation
for us on the subentities that make up a RAID volume. It almost causes
more trouble than it is worth because we have to remember which side
we're talking to in terms of forming commands and which target ids are
real and so on. Bleah.

+ Skip trying to actually do SPI settings for the RAID volumes on the
real side of the raid/passthru bus pair- this just confuses the issue.
The underlying real physical devices will have the negotiation performed
and the Raid volume will inherit the resultant settings. At the sime time,
non-RAID devices can be on the same real bus, so *do* perform negotiations
with them.

+ At the end of doing all of the settings twiddling, *ahem*, remember to
go update the settings on the card itself (dunno how this got nuked).

At this point, negotiations *seem* to be being done (again) correctly for
both RAID volumes and their subentities. And they seem to be *mostly*
now right for other non-RAID entities on the same bus (I ended up with
3 out of 8 other disks still at narror/async- haven't the slightest
idea why yes).

Finally, negotiations on a normal bus seem to work (again).

There's still more work coming into this area, but we're in the
final stretch.
2006-05-29 20:30:40 +00:00
Matt Jacob
a0e4c26aae Add a mpt_is_raid_volume function which will tell you whether
the passed target id is one of the RAID VolumeID. This result
is used to decide whether to try and do actual SPI negotiations
on the real side of the raid/passthru bus pair. The reason we
check this is that we can have both RAID volumes and real devices
on the same bus.
2006-05-29 20:20:45 +00:00
Matt Jacob
ac219b98bd Add a MPT_PRT_NEGOTIATION print level. 2006-05-29 20:15:29 +00:00
Ruslan Ermilov
2916c293b6 Fix build with -Wundef. 2006-05-29 17:37:41 +00:00
Matt Jacob
38a56edbe3 When setting verbose, *set* it, don't *add* it. 2006-05-29 16:59:38 +00:00
Ian Dowse
46f1e0d36c If a zero-length bulk or interrupt transfer is requested then assume
USBD_FORCE_SHORT_XFER to ensure that we actually build and execute
a transfer. This means that the various alloc_sqtd_chain functions
will always construct a transfer, so it is safe to modify the
allocated descriptors on return. Previously there were cases where
a zero length transfer would cause a NULL dereference.

Reported by:	bp
2006-05-28 23:37:04 +00:00
Mike Silbersack
3981b687c0 Back out the BUS_DMA_ALLOCNOW change from rev 1.39. Scottl informed me that
it's unnecessary, as the TX/RX lists are static allocations.
2006-05-28 20:35:39 +00:00
Mike Silbersack
f99da8e0d8 Re-revert back to rev 1.8:
- Reduce the number of RX and TX buffers bfe uses so that it does not use more
  bounce buffers than busdma is willing to allow it to use

See if_bfe.c for comments on why this is now safe to do.
2006-05-28 18:44:39 +00:00
Mike Silbersack
678d2a9a8c 1. Make sure that the TX and RX descriptor rings are 4096 byte aligned.
Also use BUS_DMA_ALLOCNOW to be on the safe side.

2.  Look for the Descriptor Error, and Descriptor Protocol Error flags from
    the card, and down the interface if we detect either.

#1 (along with fixes to busdma) makes sure that this card works in all
memory situations.  Prior to this change, it was just luck that 512 count
RX/TX lists were properly aligned.  Now we can use any size of RX/TX lists
and still have them properly aligned.

#2 ensures that we don't get into an endless interrupt storm if busdma fails
us.  Descriptor Protocol Error would occur if we misaligned the TX/RX rings,
and Descriptor Error would occur if we tried to give the card descriptors
or rings with addresses > 1G.  Trying to reinitialize the card isn't going
to fix these errors, hence we don't try.
2006-05-28 18:41:47 +00:00
Alexander Leidinger
451651c72e Use a more appropriate printf format for size_t.
This should unbreak the tinderbox build (64bit architectures).
2006-05-28 14:07:47 +00:00
Ian Dowse
368030a87a Use the limited scatter-gather capabilities of ehci, ohci and uhci
host controllers to avoid the need to allocate any multi-page
physically contiguous memory blocks. This makes it possible to use
USB devices reliably on low-memory systems or when memory is too
fragmented for contiguous allocations to succeed.

The USB subsystem now uses bus_dmamap_load() directly on the buffers
supplied by USB peripheral drivers, so this also avoids having to
copy data back and forth before and after transfers. The ehci and
ohci controllers support scatter/gather as long as the buffer is
contiguous in the virtual address space. For uhci the hardware
cannot handle a physical address discontinuity within a USB packet,
so it is necessary to copy small memory fragments at times.
2006-05-28 05:27:09 +00:00
Ian Dowse
e97ba859b3 NULL out ii->stdstart and ii->stdend when they are invalid. This
is not necessary for correct operation but makes it clearer that
freed transfer descriptors cannot be accessed.
2006-05-28 01:17:13 +00:00
Ian Dowse
a7c15197cf Fix a harmless typo where the software pointer in the dummy QH for
control transfers did not match the hardware pointer.
2006-05-28 01:07:46 +00:00
Ian Dowse
203eec4b02 Defer axe_tick processing to a USB task, since axe miibus operations
need to sleep. This avoids an INVARIANTS panic. It looks like if_rue
and if_aue need a similar change, but I don't have hardware to test.
2006-05-27 23:46:13 +00:00
Matt Jacob
1d79ca0e46 Work in progress toward fixing IM checked in after having
lost one set to a peninsula power failure last night. After
this, I can see both submembers and the raid volumes again,
but speed negotiation is still broken.

Add a mpt_raid_free_mem function to centralize the resource
reclaim and fixed a small memory leak.

Remove restriction on number of targets for systems with IM enabled-
you can have setups that have both IM volumes as well as other devices.

Fix target id selection for passthru and nonpastrhu cases.

Move complete command dumpt to MPT_PRT_DEBUG1 level so that just
setting debug level gets mostly informative albeit less verbose
dumping.
2006-05-27 17:26:57 +00:00
Alexander Leidinger
f510d240d3 Commit the new (old) midi framework. It's based in parts on the NetBSD code,
but large parts are rewritten by matk and tanimura.

This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.

This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.

To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.

To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.

Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)

If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.

Written by:	matk, tanimura
Submitted by:	"Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon:	code from NetBSD
2006-05-27 16:51:37 +00:00
Alexander Leidinger
206b17d711 Commit the new (old) midi framework. It's based in parts on the NetBSD code,
but large parts are rewritten by matk and tanimura.

This is old code, it's not maintained since 2003. We also don't have a
maintainer for this! Yuriy Tsibizov took it and uses it in his emu10kx
driver. Since the emu10kx driver will enter the tree "soon" (some bugs
have to be fixed after Yuriy return from his holidays), I add it here
already.

This also contains some changes to emu10k1 and cmi, so if you're lucky,
you can now make some kind of use of midi with those soundcards.

To all those poor souls which don't have such a card: feel free to send
patches, we don't have a maintainer for this.

To those which miss a specific feature in the midi code: feel free to
submit patches, we don't have a maintainer for this.

Oh, did I already told that it would be nice if someone would take care
of it? Maintainer with midi equipment wanted! :-)

If you get LOR's, submit a PR and notify multimedia@ please. If you get
panics, submit a PR with a backtrace (compile the sound system into your
kernel instead of using modules in this case) and notify multimedia@
please.

Written by:	matk, tanimura
Submitted by:	"Yuriy Tsibizov" <Yuriy.Tsibizov@gfk.ru>
Based upon:	code from NetBSD
2006-05-27 16:32:05 +00:00
Simon L. B. Nielsen
f6f4187202 Fix typo in printf string.
MFC after:	1 week
Approved by:	cperciva (mentor)
2006-05-27 09:28:59 +00:00
Poul-Henning Kamp
05c3592e13 Update to new console api. 2006-05-26 18:25:34 +00:00
Poul-Henning Kamp
7672c95932 Convert to new console api 2006-05-26 13:54:27 +00:00
Poul-Henning Kamp
a58a1ea03d Convert to new console interface. 2006-05-26 13:51:38 +00:00
Poul-Henning Kamp
9b188af13c Eliminate gdb_checkc member from GDB_DBGPORT(), it is never used.
Use polling behaviour for gdb_getc() where convenient, this edges us
closer to the console code.
2006-05-26 11:54:32 +00:00
Poul-Henning Kamp
3fc7129ed1 Convert to use CONSOLE_DRIVER() macro:
Remove cngetc, rename cncheckc to cngetc (fix GDB console accordingly)
2006-05-26 11:21:52 +00:00
Poul-Henning Kamp
12e9e65766 Insert a '_' in the console function names to be more consistent with
the future.
2006-05-26 10:44:47 +00:00
Poul-Henning Kamp
16b1613a31 GC the cn_dbctl_t hook for consoles, it is unused.
This used to make syscons switch to vty0 when we entered DDB but this
was lost in the KDB shuffle.  We may want to bring it back down the road
but it should be done by calling cn_init_t/cn_term_t instead, possibly
with a flag argument saying "Debugger!"
2006-05-26 10:24:00 +00:00
John-Mark Gurney
d13fc3e62d don't require a buffer if all we are doing is manipulating the GPIO pins...
MFC after:	3 weeks
2006-05-26 07:36:50 +00:00
Matt Jacob
a3116b5a27 Get most of the way back to having Integrated Mirroring work
again- the addition of target mode support broke it massively.
2006-05-26 05:54:21 +00:00
Matt Jacob
8bf91348e5 gratuitous formatting changes 2006-05-26 05:43:14 +00:00
Matt Jacob
0e3b145ea3 Fix spellings. Prototype mpt_dump_request. Add a 'raid_enabled' tag. 2006-05-26 05:42:00 +00:00
Matt Jacob
1043516d26 Remove handrolled raw dump of a request from
mpt_send_cmd and replace with a new debug function.
2006-05-26 05:41:14 +00:00
Warner Losh
d708737568 APM was calling the suspend process from a timeout. This meant that
other timeouts could not happen while suspending, including timeouts
for things like msleep.  This caused the system to hang on suspend
when the cbb was enabled, since its suspend path powered down the
socket which used a timeout to wait for it to be done.

APM now creates a thread when it is enabled, and deletes the thread
when it is disabled.  This thread takes the place of the timeout by
doing its polling every ~.9s.  When the thread is disabled, it will
wakeup early, otherwise it times out and polls the varius things the
old timeout polled (APM events, suspend delays, etc).

This makes my Sony VAIO 505TS suspend/resume correctly when APM is
enabled (ACPI is black listed on my 505TS).

This will likely fix other problems with the suspend path where
drivers would sleep with msleep and/or do other timeouts.  Maybe
there's some special case code that would use DELAY while suspending
and msleep otherwise that can be revisited and removed.

This was also tested by glebius@, who pointed out that in the patch I
sent him, I'd forgotten apm_saver.c

MFC After: 3 weeks
2006-05-25 23:06:38 +00:00
John Baldwin
bc5521260c Only reference the firmware module once rather than twice. The extra call
was accidentally added in 1.55 and resulted in an extra reference count
being held on the linker file.

MFC after:	1 week
2006-05-25 22:04:46 +00:00
Warner Losh
fef035542a Export the pribus, secbus and subbus as sysctls for information
purposes only.  Additional information may be exported in the future.
2006-05-24 17:27:55 +00:00
Warner Losh
2f6303b0f6 Suspend the children before we turn off card events in hardware. This
was done, I believe, to work around some cards having issues in the
suspend case.  I think that this helped my Sony VAIO TS505 work better
when it had certain wireless cards in it and I did a apm -z.  I've not
tested suspend/resume on other laptops in a long time, so I hope this
doesn't cause greif.  Please let me know if it does.
2006-05-24 17:26:16 +00:00
Warner Losh
1b2ec08c94 Fix a race when detaching the cbb worker thread. There were a couple
of cases where we didn't take out the lock before setting or clearing
a bit.  This apparently can lead to a race at kldunload time (at least
on my Turion64 laptop, never saw it on my Sony Vaio).
2006-05-24 17:22:53 +00:00
John Baldwin
53b8229e97 Workaround a hang on some nForce2 systems that can happen if the CPU goes
into and out of the halt state very quickly.

Submitted by:	Andriy Gapon <avg at icyb dot net dot ua>
MFC after:	1 week
2006-05-24 14:08:31 +00:00
Gleb Smirnoff
16a67f532d Rename device name in the last commit. According to PR, the ID is
more likely to belong to chips of 8168 family.

PR:		kern/96734
Submitted by:	Sven Petai <hadara bsd.ee>
2006-05-24 11:55:25 +00:00
Ian Dowse
093daa268f Attempt to follow the procedure described in section 4.10 of the
EHCI spec for linking in new qTDs into an asynchronous QH. This
requires that there is a qTD marked as not active and not halted
at the start of the QH's list, and the hardware will know to re-fetch
the qTD on each pass rather than just looking at the overlay qTD:

  "The host controller must be able to advance the queue from the
  Fetch QH state in order to avoid all hardware/software race
  conditions. This simple mechanism allows software to simply link
  qTDs to the queue head and activate them, then the host controller
  will always find them if/when they are reachable."

This is achieved by keeping an "inactivesqtd" entry on the QH list,
and re-using it each time as the start of the next transfer, and
allocating a new qTD to become the next inactivesqtd. Then a new
transfer can be activated by just setting its "active" flag, which
avoids all the previous messing with overlay qTD state in
ehci_set_qh_qtd().
2006-05-24 03:04:11 +00:00
Warner Losh
2c24bd34d6 Whitespace nits 2006-05-23 23:33:57 +00:00
Marcel Moolenaar
eb2198ec84 Remove definitions of uart_[gs]etdreg. They are not used anymore and
were in fact wrong.
2006-05-23 22:33:44 +00:00
Pawel Jakub Dawidek
f6bd1faf76 Forgot to remove the line. 2006-05-23 09:02:14 +00:00
Benno Rice
8bceca4f48 The lcr variable in ns8250_probe is now unused. Remove it.
Missed by:	benno
2006-05-23 06:04:45 +00:00
Ian Dowse
1bbda613eb When usb_event_thread() first starts, wait significantly longer
before starting exploring (4 seconds), and extend the wait period
if new USB buses are attached while waiting.

This works around a problem seen when there is more than one EHCI
controller in the system and you kldload usb.ko after the system
has booted. The problem is that usb.ko contains 3 separate PCI
drivers which get initialised one by one (uhci, ohci, ehci), and
when each driver is initialised, all PCI buses are re-probed after
just the addition of that driver. This means that there can be a
significant delay between the attaching of a companion controller
and the subsequent EHCI attach, so it is possible for the companion
controller's USB 1.x bus to be scanned before the EHCI driver gets
a chance to check if there is really a USB 2.x device connected.
2006-05-23 01:27:23 +00:00
Benno Rice
58957d8717 Allow uart(4)'s ns8250 driver to work with devices whose regshift is > 0.
- Rename REG_DL to REG_DLL and REG_DLH.
- Always treat DLL and DLH as two separate 8-bit registers instead of one
  16-bit register.

Additionally, remove the probe for the high 4 bits of IER being 0 and don't
assume we can always read/write 0 to/from those bits.

These changes allow uart(4) to drive the UARTs on the Intel XScale PXA255.

Reviewed by:	marcel
2006-05-23 00:41:12 +00:00
Pawel Jakub Dawidek
411da41e91 Fix HMACs handling with uio's by not using crp_mac for storing calculated
HMAC. crp_mac is going to be removed.
2006-05-22 16:18:21 +00:00
Yoshihiro Takahashi
097f448416 - Fix the busname in the DRIVER_MODULE.
- Skip PnP devices as some wedge when trying to probe them as C-NET(98)S.

This fix makes le(4) actually work with the C-NET(98)S.

Reviewed by:	marius
Tested by:	Watanabe Kazuhiro < CQG00620 at nifty dot ne dot jp >
2006-05-22 13:43:36 +00:00
Pawel Jakub Dawidek
e6cb03f155 Protect the sc_needwakeup field with the sc_freeqlock mutex. 2006-05-22 10:11:18 +00:00