debugging and its main use is in device drivers. Its used there to signal
that the flagged buffer has a special meaning or should be handled
differently.
OK'd by Bill Sudenmund on tech-kern.
register was inherited from proc0. Set the new process's status register
to PSL_LOWIPL. Raidframe reconstruction no longer causes my Amiga to lose
time.
- use proper macro to assert/clear ctrl_int2 port for softintr
- use KDASSERT() rather than #ifdef DEBUG + assert()
- don't count uvmexp.softs twice in softintr_dispatch()
XXX: Maybe we should have common m68k/softintr.c like mips ports.
freaks out when a cardbus device is present.
enable with options PB3400_CARDBUS_HACK
- add a hack to make the DEC 21140 found on UMAX E100 cards work, for some
reason OF doesn't see it
enable with options UMAX_E100_HACK
console keyboard and mouse on them.
We are not there yet because currently both wsdisplay and zstty assume
that they are the console. On sun-4, zstty wins because it attaches
last and overwrites the console device that wscons had set previously.
writes they might issue to be delayed which keeps us from deadlocking
- don't splhigh() in cuda_intr() - usually we're there already. Instead do
the splhigh()/splx() dance when we're polling
- remove some leftover debugging gunk
kernel VM range is supposed to be mapped via reserved TLB entries,
so allow such VAs through.
Fixes kgdb failure observed by Jean-Francois Boudreault on port-powerpc
(thanks for testing, too).
ports have different IPL hierarchies. On macppc, IPL_VM is below IPL_AUDIO
and IPL_SERIAL so the queues got corrupted due to priority inversion.
Also fix a race condition in softintr_schedule() when testing "si_refs > 1",
it can lead to queue corruption and subsequent panic (below). As a side
effect, using PSL_EE directly is faster than going via spl*()/splx().
This is supposed to fix (XXX I don't have the hw):
Panic: kernel diagnostic assert "si->si_refs > 0" failed: file
"[...]arch/powerpc/powerpc/softintr.c" line 116
reported for example in:
http://mail-index.netbsd.org/port-macppc/2007/01/25/0001.html
Discussed with briggs@ and macallan@.
Patch by Slava Semushin <slava.semushin@gmail.com>
Again, this was tested by comparing obj files from a pristine and a patched
source tree against an i386/ALL kernel, and also for src/sbin/fsck_ffs,
src/sbin/fsdb and src/usr.sbin/makefs. Only changes in assert() line numbers
were detected in 'objdump -d' output.
not used partition ID 0x165 for many, many years, and the presence of
this option in INSTALL kernels can cause overwriting of existing FreeBSD
installations when sysinst writes back the disklabel. Those with very,
very old NetBSD installations may find that they must update their fdisk
partition tables to use partition ID 0x169 for their NetBSD partitions.
This seems like the best of a number of lousy choices for dealing with
this problem. Sysinst should perhaps grow code that asks whether an
existing 0x165 partition should be converted.
~
by Slava Semushin <slava.semushin@gmail.com>.
To verify that no nasty side effects of duplicate includes (or their
removal) have an effect here, I've compiled an i386/ALL kernel with
and without the patch, and the only difference in the resulting .o
files was in shifted line numbers in some assert() calls.
The comparison of the .o files was based on the output of "objdump -D".
Thanks to martin@ for the input on testing.
the BIOS bug workaround for the i82443BX chipset's DRAM leadoff timing
parameter is not needed for revisions >= C0, so avoid tweaking that
parameter in that case.
Earlier, this would trigger NMIs on fully memory-populated Compaq
1850R systems, where the BIOS appears to program and require a non-
standard value for this parameter.
Thanks to Chris Ross for the diagnosis and the fix!
by adding the "nargs" argument to the macppc version, and fix the macppc
ports uses of OF_interpret() accordingly.
Also move the declaration of OF_interpt() from macppc's autoconf.h to
ofw/openfirm.h. This fixes the build of the macppc port.
Approved by macallan@.
SUN4 as well.
The data and stack limits are definitely needed, otherwise MI code will try
and map shared libraries in the 4/4c MMU hole. The UBC limits may not be
necessary, but SUN4 machines are unlikely to have much larger amounts of
memory than this caters for (64Mb).
SUN4 machines will now boot userland with this change.
Thanks to martin@, mrg@ and uwe@ for hints while debugging this.
behavior is to choose 0.5 GB for <= 192 MB, 1 GB normally, and 2 GB
for >= 1 GB. This should make the defaults work additionally old
Thinkpad 600Es, and also on notebooks with lots of RAM (e.g. T60 with
2GB).
ok christos@
zaurus# ./timetest -A -t 600
Will test active counter and counters with positive quality from saost_count(q=100, f=3686400 Hz) clockinterrupt(q=0, f=100 Hz) dummy(q=-1000000, f=1000000 Hz)
Testing time for monotonicity of timecounter "saost_count" for 600 seconds...
claimed resolution 271 nsec (3690036.900369 Hz) or better, observed minimum non zero delta 2712 nsec
switching to timecounter "saost_count"...
Testing time for monotonicity of timecounter "saost_count" for 600 seconds...
claimed resolution 271 nsec (3690036.900369 Hz) or better, observed minimum non zero delta 2712 nsec
switching to timecounter "clockinterrupt"...
Testing time for monotonicity of timecounter "clockinterrupt" for 600 seconds...
claimed resolution 10000000 nsec (100.000000 Hz) or better, observed minimum non zero delta 9999999 nsec
TEST SUCCESSFUL
ok peter@
Conexant TV encoder and the Microsoft dashboard is set to widescreen AND
you are using a standard definition AV pack, the loader configures the
framebuffer to 1024x576. Reported by riz@
XXX: The Xcalibur encoder is misconfigured by Xromwell in HDTV mode, and the
test will not be centered as a result. Xcalibur still works in SDTV mode.
Note that the safe area is not applied to the X server, only the console text.
- In xencons_handler(), update in_cons inside the loop, otherwise,
we would trigger the xenconscn_getc() workaround wich reset cons and prod
to their original values, and this creates an infinite loop
Should fix the console hang reported by several users on port-xen@.
(the relevant changes haven't been done though).
Call built binary bootxx_fat16 for consistency.
Use 'push %cs' to push a zero value in places where we had relied on %bx
being zero from much higher up the code.
mapping of msgbuf during startup may map invalid physical adresses
Apply a similar patch as in the i386 case.
The amd64 version was supplied by Blair Sadewitz, thanks.
mapping of msgbuf during startup may map invalid physical adresses
"If the last available physical memory segment on a system is less 16k,
than the startup code that will map the kernel message buffer, will fail
and map physical pages behind the last segment. This may either only lead
to a message buffer without physical memory behind it, or to an
overlapping message buffer with something else."
Fix by allowing multiple physical memory segments to be used for msgbuf.
Also remove some leftover msgbuf manipulation from pmap.c.
Fix supplied by Wolfgang Stukenbrock in the PR, with some modifications
from me, mainly to use the already existing constant VM_PHYSSEG_MAX as the
static limit of number of msgbuf segments.
Attached is a patch to add generic base support for systems based on the
OMAP 1 family. The devices supported in this patch are serial console
and MPU timers for OS timing purposes.
I ran into a problem when I tried to set up a mapping that started at virtual
address 0xFFF00000 and was 0x00100000 long. In other words, the mapping
should have gone to the end of the 32 bit address space. The mapping was made
with no problem, but pmap_devmap_find_va() wouldn't find an address within the
mapping. For example, if I told it to find a mapping for 0x1000 bytes at
0xFFF01000, it would try to make sure that 0xFFF01000 was greater than
0xFFF00000 and that (0xFFF01000+0x1000) was less than (0xFFF00000+0x00100000).
However, that last expression (0xFFF00000+0x00100000) wrapped around to be
simply 0x00000000 so it wasn't found. This patch fixes this problem in
pmap_devmap_find_va() and pmap_devmap_find_pa() by subtracting one off of the
sizes to be compared, so in my example, (0xFFF01000+0x1000-1) will be less
than (0xFFF00000+0x00100000-1).
This one is really simple. I wanted to use KERNEL_BASE in an assembly source,
but arch/arm/include/arm32/vmparam.h wasn't protected by #ifndef
__ASSEMBLER__. The patch adds the protection.
identify_arm_cpu() prints out a helpful message when it detects that you're
trying to run on a CPU that you didn't configure for. Unfortunately, the
check for class_option being NULL is backward, so it either won't print the
class_option, or it will try to dereference a NULL. The patch just flips the
!= NULL to be == NULL.
Attached is a patch to add generic base support for systems based on the
OMAP 1 family. The devices supported in this patch are serial console
and MPU timers for OS timing purposes.
This patch depends upon patches previously sent by Scott Allan: "Three
small patches for ARM" on 07/26/2006 and "Patch to add support for
ARM9E" on 07/31/2006.
A staggering number of mobile phones, PDAs, and other portable devices
are based on these systems, and OMAP would make a great addition to
NetBSD. If there are any concerns we can address or other things we can
do to get this code accepted upstream please let me know, thanks,
ad