| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- If pf_test6 returns a NULL mbuf, just return.
- Reinitialize pointer to header after pf_test6().
ok frantzen@
|
|
|
|
second i did not see the final diff.
third i never said you should commit this.
fourth, 10x for running around offending lusers i'm
trying to resolve their problems with.
|
|
on Lchr. Notice Lmessage is using Lchr's return, and it has always
been a 16-bit call.
This should be the root of many (most?) of the Drive:0 Partition:3
hangs.
tip o the hat to mickey, who fixed it without necessarily knowing it,
and toby, who put the final nail in.
gas sucks.
|
|
|
|
from another interface/machine/network.
|
|
|
|
|
|
|
|
|
|
|
|
(with minimal ddb tricks I have a working vga console with usb keyboard
on blade100)
|
|
|
|
|
|
macro, by a different version of the aforementioned macro.
|
|
|
|
in big endian order, swap if flags was given.
reported by: Hans-Joerg Hoexer <Hans-Joerg.Hoexer@yerbouti.franken.de>
|
|
|
|
cgsix from sparc and vgafb from macppc).
|
|
gem works, but is not overly stable yet, sometimes recieves one
packet and stops. hme works fine, if the interrupts are connected
properly (not yet).
|
|
the passed in type. This allows PCI devices to create big endian mappings
which is necessary for vgafb.
|
|
the upper layer anyway).
|
|
Attempt to deal with pci-pci bridges and the irq handling. It is incorrect,
but allows one port of a 4 port hme card to work.
|
|
route the interrupts correctly.
|
|
|
|
|
|
mvme68k still lacks some -Wfoo flags, until it is warnings clean.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have
a complete set of inline functions in isp_inline.h. Each platform is
responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32}
macros.
The reason this needs to be done is that we need to have a single set of
functions that will work correctly on multiple architectures for both little
and big endian machines. It also needs to work correctly in the case that
we have the request or response queues in memory that has to be treated
specially (e.g., have ddi_dma_sync called on it for Solaris after we update
it or before we read from it).
One thing that falls out of this is that we no longer build requests in the
request queue itself. Instead, we build the request locally (e.g., on the
stack) and then as part of the swizzling operation, copy it to the request
queue entry we've allocated. I thought long and hard about whether this was
too expensive a change to make as it in a lot of cases requires an extra
copy. On balance, the flexbility is worth it. With any luck, the entry that
we build locally stays in a processor writeback cache (after all, it's only
64 bytes) so that the cost of actually flushing it to the memory area that is
the shared queue with the PCI device is not all that expensive. We may examine
this again and try to get clever in the future to try and avoid copies.
Another change that falls out of this is that MEMORYBARRIER should be taken
a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the
entry being added. But there had been many other places this had been missing.
It's now very important that it be done.
For OpenSD, it does a ddi_dmamap_sync as appropriate. This gets us out of
the explicit ddi_dmamap_sync on the whole response queue that we did for SBus
cards at each interrupt. Now, because SBus/sparc doesn't use bus_dma, some
shenanigans were done to support this. But Jason was nice enough to test the
SBus/sparcv9 changes for me, and they did the right thing as well.
Set things up so that platforms that cannot have an SBus don't get a lot of
the SBus code checks (dead coded out).
Additional changes:
Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry,
the iptr value that gets returned is the value we intend to eventually plug
into the ISP registers as the entry *one past* the last one we've written-
*not* the current entry we're updating. All along we've been calling sync
functions on the wrong index value. Argh. The 'fix' here is to rename all
'iptr' variables as 'nxti' to remember that this is the 'next' pointer-
not the current pointer.
Devote a single bit to mboxbsy- and set aside bits for output mbox registers
that we need to pick up- we can have at least one command which does not
have any defined output registers (MBOX_EXECUTE_FIRMWARE).
Explicitly decode GetAllNext SNS Response back *as* a GetAllNext response.
Otherwise, we won't unswizzle it correctly.
Nuke some additional __P macros.
|
|
|
|
|
|
|
|
|
|
No way you could have compiled a kernel from this.
|
|
|
|
'commit that' jason@
|
|
|
|
that can have more than one system bus attached to mainbus
|
|
the response queue. Instead of the ad hoc ISP_SWIZZLE_REQUEST, we now have
a complete set of inline functions in isp_inline.h. Each platform is
responsible for providing just one of a set of ISP_IOX_{GET,PUT}{8,16,32}
macros.
The reason this needs to be done is that we need to have a single set of
functions that will work correctly on multiple architectures for both little
and big endian machines. It also needs to work correctly in the case that
we have the request or response queues in memory that has to be treated
specially (e.g., have ddi_dma_sync called on it for Solaris after we update
it or before we read from it).
One thing that falls out of this is that we no longer build requests in the
request queue itself. Instead, we build the request locally (e.g., on the
stack) and then as part of the swizzling operation, copy it to the request
queue entry we've allocated. I thought long and hard about whether this was
too expensive a change to make as it in a lot of cases requires an extra
copy. On balance, the flexbility is worth it. With any luck, the entry that
we build locally stays in a processor writeback cache (after all, it's only
64 bytes) so that the cost of actually flushing it to the memory area that is
the shared queue with the PCI device is not all that expensive. We may examine
this again and try to get clever in the future to try and avoid copies.
Another change that falls out of this is that MEMORYBARRIER should be taken
a lot more seriously. The macro ISP_ADD_REQUEST does a MEMORYBARRIER on the
entry being added. But there had been many other places this had been missing.
It's now very important that it be done.
For OpenSD, it does a ddi_dmamap_sync as appropriate. This gets us out of
the explicit ddi_dmamap_sync on the whole response queue that we did for SBus
cards at each interrupt. Now, because SBus/sparc doesn't use bus_dma, some
shenanigans were done to support this. But Jason was nice enough to test the
SBus/sparcv9 changes for me, and they did the right thing as well.
Set things up so that platforms that cannot have an SBus don't get a lot of
the SBus code checks (dead coded out).
Additional changes:
Fix a longstanding buglet of sorts. When we get an entry via isp_getrqentry,
the iptr value that gets returned is the value we intend to eventually plug
into the ISP registers as the entry *one past* the last one we've written-
*not* the current entry we're updating. All along we've been calling sync
functions on the wrong index value. Argh. The 'fix' here is to rename all
'iptr' variables as 'nxti' to remember that this is the 'next' pointer-
not the current pointer.
Devote a single bit to mboxbsy- and set aside bits for output mbox registers
that we need to pick up- we can have at least one command which does not
have any defined output registers (MBOX_EXECUTE_FIRMWARE).
Explicitly decode GetAllNext SNS Response back *as* a GetAllNext response.
Otherwise, we won't unswizzle it correctly.
Nuke some additional __P macros.
|
|
|
|
crashing randomly a little later.
|
|
|
|
|
|
the processor type in the configuration files, if you specify a board type.
Also, some syntaxic sugar for the MVME187 case as well.
|
