with some Dell servers that booted w/o a problem[*] on 5.4, but failed
with 6.0-BETA.
On the PCI bus, when we do lazy resource allocation, we narrow the
range requested as we pass through bridges to reflect how the bridges
are programmed and what addresses they pass. However, when we're
doing an allocation on a bus that's directly connected to a host
bridge, no such translation can take place. We already had a fallback
range for memory requests, but none for ioports. As such, provide a
fallback for I/O ports so we don't allocate location 0, which will
have undesired side effects when the resources are actually used.
This fixes a problem with booting a Dell server with usb in the
kernel. However, it is an unsatisfying solution. I don't like the
hard coded value, and I think we should start narrowing the resources
returned to not be in the so-called isa alias area (where the ranage &
0x0300 must be 0 iirc). Doing such filtering will have to wait for
another day.
This may be a good 6 candidate, maybe after its had a chance to be
refined.
Tested by: glebius@
possible method to prevent panicing in interrupt handler
after re_shutdown(), sometimes seen on SMP systems.
This would work here only because re_detach() clears
IFF_UP (to prevent another race) and it was demonstrated
that it's not enough to call vr_detach() in vr_shutdown()
to prevent a panic.
- Fixed if_free() logic screw-up that can either result
in freeing a NULL pointer or leaking "struct ifnet".
- Move if_free() after re_stop(); the latter accesses
"struct ifnet". This bug was masked by a previous bug.
- Restore the fix for a panic on detach caused by racing
with BPF detach code by Bill by moving ether_ifdetach()
after re_stop() and resetting IFF_UP; this got screwed
up in revs. 1.30 and 1.36.
attempts to deallocate busdma tags and resources that haven't been
allocated yet, causing a panic every time a dc interface fails to
attach. Fix by checking that we really have something to dealloc
before calling bus_dma*() functions.
Approved by: jhb
MFC after: 1 week
that with the NIC set of registers rather than the ASIC registers. I
believe this was a harmless oversight, since we set ED_P0_CR to the
same value 5ms later, but just to be safe...
risky because the "current time" is supposed to be fed to the card during
initialization, and the current time is supposed to be put into each command
that is sent to the card. Hopefully either the card doesn't actually care
about the timestamps, or it doesn't care about the absolute values so long
and the relative values are consistent. Not an MFC candidate until more
thorough testing can be done.
While I'm here add KASSERT(9) to notify failure of SYSUNINIT handler.
Reported by: Ben Kaduk < minimarmot AT gmail DOT com >
Tested by: Ben Kaduk < minimarmot AT gmail DOT com >
o Attach AX88x90's MII bus to system, and require its presence.
o Reorg the mii code a little, and move more of it into pccard attachment.
o Eliminate ed_pccard_{read,write}_attrmem in favor of a more appropriate
function in the pccard layer.
o Update comments to reflect knowledge gained.
o Update how re recognize a NE-2000 ROM. I found a couple of different
datasheets that define the structure of the PROM data, so the code's
old heuristics have been removed, and comments updated to reflect the
structure.
o Eliminate work around for EC2T. It is no longer needed, and was wrong
headed since the EC2T has a Winbound 82C926C in it, not a AX88x90.
o Add copyright to if_ed_pccard.c, since I believe I've re-written more than
3/4 of it.
# With these changes, all of my 20-odd ed based cards work, except for the
# NetGear FA-410, and I'm pretty sure that's a MII/PHY problem.
attach to. These cards are combo cards (in that they have a modem
inside of them), but not true MFC cards. Full support of these cards
will have to wait until we can pick the config to use and for the PFC
support that I have brewing.
- Remove an assertion in sound.c, it's not needed (and causes a panic now).
From the conversation via mail between glebius and Ariff:
---snip---
> Well, but which mutex protects now? Do we own anything else
> in pcm_chnalloc()? I see some queue(4) macros in pcm_chnalloc(),
> they should be protected, shouldn't they?
Queue insertion/removal occur during
1) driver loading (which is pretty much single thread /
sequential) or unloading (mutex protected, bail out if there is
any channel with refcount > 0 or busy).
2) vchan_create()/destroy(), (which is *sigh* quite complicated), but
somehow protected by 'master'/parent channel mutex. Other
thread cannot add/remove vchan (or even continue traversing
that queue) unless it can acquire parent channel mutex.
---snip---
Fix the locking in dsp.c to prevent a LOR (AFAIK not on the LOR page).
Submitted by: Ariff Abdullah <skywizard@MyBSD.org.my>
Tested with: INVARIANTS[1] and DIAGNOSTICS[2]
Tested by: netchild [1,2], David Reid <david@jetnet.co.uk> [1]
'buffers' pending NMIs from multiple interrupting PMCs and delivers
them serially.
Reported by: Olivier Crameri <olivier.crameri@epfl.ch>
MFC after: 3 days
In case this causes trouble for some other chipsets add a comment how to
proceed. If we don't get bugreports, this should be removed after a while
(some releases?).
PR: 56617 [1], 29465, 39260, 40574, 68225
Submitted by: Matthew E. Gove <mgove@comcast.net> [1]
believe that there are PC98 systems with an OPTi chip.
I don't know enough about this special PC architecture to be sure about
this, so let's find out by letting people with such a system complain in
case this commit breaks the sound system for them. It's easy to revert
then.
PR: 45673
Submitted by: Watanabe Kazuhiro <CQG00620@nifty.ne.jp>
