with the use-compat-native-irq property. It was caused by handling irqs from
both channels at once with the wrong interrupt handler routine
(pciide_pci_intr). Now pciide_compat_intr is installed for each channel.
Also renamed the function to via_pegasos_mapregs_native(), which seems more
appropriate.
PR kern/38761.
The condvar must access the sleepq with the sleepq lock held, doing so
is causing inconsistent sleepq state to be read.
This is because some accesses to the sleepq don't come via the cv code,
but are call directly into sleepq_changepri and sleepq_lendpri, which take
the sleepq lock, and removes then re-inserts lwps into the sleepq.
Running a build.sh with -j8 now completes on my quad-core, also tested by
Simon@ on a 8-core server and matt@ on a quad-core.
I believe there is room to be more efficient with this, as we now take the
sleepq lock for all cv_broadcast and cv_signal calls. I'll look into this
and post a diff to tech-kern.
suggestion from isaki@ on port-m68k.
For sun68k (sun2, sun3 and sun3x):
- export ipl2psl_table[] and make it uint16_t
- make makeiplcookie(9) inline
- put PSL_S bit into ipl2psl_table[] rather than adding it in makeiplcookie(9)
suggestion from isaki@ on port-m68k.
For news68k:
- export ipl2psl_table[] and make it uint16_t
- make makeiplcookie(9) inline
- put PSL_S bit into ipl2psl_table[] rather than adding it in makeiplcookie(9)
- define both IPL_SCHED and IPL_HIGH independently to avoid confusion
bank registers from the PCI host bridge. Previously the RAM size was
hardcoded to 64MB.
Also fill out ibm82660reg.h with more definitions from the PowerPC to
PCI Bridge and Memory Controller User's Manual.
Many thanks to Tim Rightnour for helping with this patch.
Test if VOP_BMAP actually works before using bmap/strategy.
When you create an image with
dd if=/dev/zero of=./netbsd.img bs=1m count=1 seek=1000
then the current check actually determines the "file system"
in the image supports VOP_BMAP and VOP_STRATEGY, but VOP_BMAP can't
translate any logical block numbers which results in EIO failures.
When you try to access the image in a Xen DomU you see all disk operations
failing. Therefore test if VOP_BMAP actually works and fall back to
VOP_READ/VOP_WRITE if it doesn't.
This makes a Xen DomU installation working. When you boot your fresh
installed Xen DomU with a valid disklabel and file system in the image,
VOP_BMAP actually works and is used.
This allows you to create an image with dd as above on the Dom0 and
run a DomU installation or to quickly create another virtual disk for
an existing DomU without having to create a disklabel and file system
by hand.
PR port-hpcarm/38591
XXX: There is still a hard hang that I've seen on both shark and hpcarm in
the process exit path; I don't know much beyond that yet.
christos