regression), since the tables are bigger than that.
Accessing unmapped memory was doing bad things on
XenServer.
Fixes ticket #7497.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42068 a95241bf-73f2-0310-859d-f6bbb57e9c96
menu item it's associated with rather than an input string. This allows it
to calculate the position to start the input at, as well as the correct
line to place it on. The previous solution always put the input at the
center line, which happened to be the right place by happy coincidence
unless one also had the menu items for viewing/saving the debug syslog
present.
* Implement input buffer scrolling, and consequently lift the previous size
limit on user input (it is now only limited by the size of the passed in
buffer).
* Implement parsing of the input buffer to allow it to handle comma-separated
options. Thus, one can now input things like "disable_smp true, serial_debug_output false"
and it will be handled properly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41706 a95241bf-73f2-0310-859d-f6bbb57e9c96
generator). There are chipsets (namely ATI/AMD SBx00) where mode 2 doesn't seem
to work (the counter isn't reloaded after the countdown has completed). Mode 0
has the same resolution as mode 2 and, as interrupts are disabled at this point
in booting, is otherwise equivalent as well. I've tested this on 5 machines
available to me and it doesn't seem to have any negative effect.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41683 a95241bf-73f2-0310-859d-f6bbb57e9c96
With that we will usually start right away without having to wait for the
timer to be in the desired state, which removes roughly 116ms of spinning
around for a normal calibration run.
* Read back the value once after programming. The delay this introduces
accounts for the fact that the counter will only start counting down on the
next clock cycle.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41680 a95241bf-73f2-0310-859d-f6bbb57e9c96
bound to prevent spinning forever if we have a very unstable TSC that we
simply can't calibrate. Shouldn't really happen though.
* Set the gate low for channel 2 on exit if we used it as the counter.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41678 a95241bf-73f2-0310-859d-f6bbb57e9c96
copies of it with a call to that.
* Make the variable names more readable and spacing cleanup.
No functional change intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41670 a95241bf-73f2-0310-859d-f6bbb57e9c96
timer code has such definitions too, but they're not quite as verbose. Will
eventually make the latter use these too.
* Prepare for possibly using other PIT channels for the calibration. Right now
everything's the same still.
* Add disabled print of the resulting factors.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41669 a95241bf-73f2-0310-859d-f6bbb57e9c96
aren't otherwise exposed via the safe mode menus. The option can be
found under the debug options menu, where additional settings can be
added one at a time with the same syntax used in kernel settings files
(i.e. disable_acpi on).
Scrolling of the input buffer is not yet supported (will implement that
soon), so currently the input is clamped to the size of one line. This
shouldn't be a problem for our current set of options though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41577 a95241bf-73f2-0310-859d-f6bbb57e9c96
all reports so far have been positive. We fall back to legacy mode in the cases
where we can't figure out the correct routing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41527 a95241bf-73f2-0310-859d-f6bbb57e9c96
all inter-CPU messaging. The previously described timekeeping is just an extra
function of local APICs. Before, if you'd select "disable local APIC" it would
still blindly write to invalid memory (targetting the non-mapped local APIC) and
then just hang waiting for the other CPUs (that were obviously not responding
to the init sequence that wasn't programmed).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41504 a95241bf-73f2-0310-859d-f6bbb57e9c96
configuring SMP via MP tables. We don't support that method anyhow, but it
should still report correctly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41503 a95241bf-73f2-0310-859d-f6bbb57e9c96
at all and, since there can be multiple IO-APICs, we need to do the
enumeration again in the kernel anyway. Also only set ioapic_phys the first
time we encounter an IO-APIC object as it looks cleaner when we arrive at the
first IO-APIC default address.
* Therefore we don't have to worry about already mapped IO-APICs when
enumerating them in the kernel.
* Also remove the mapping function that is now not used anymore.
* We still use the ioapic_phys field of the kernel args to determine whether
there is an IO-APIC at all to avoid needlessly doing the enumeration again.
This fixes multi IO-APIC configurations, because before we would indeed map
the last IO-APIC listed in the MADT, but then in the kernel assumed we mapped
the first one. We'd end up with mapping the last listed IO-APIC twice and the
first IO-APIC never, always programming the last one when we actually targetted
the first one.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41476 a95241bf-73f2-0310-859d-f6bbb57e9c96
IO-APIC can be easily enabled to test it on various configurations. Note that
the previous default opt-out didn't work because the safemode options would not
be touched at all when not actually entering the boot menu.
Once IO-APIC is more broadly tested this can be removed again and the opt-out
option reenabled.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41370 a95241bf-73f2-0310-859d-f6bbb57e9c96
a problem on the Mac which obviously messed up its BIOS.
* This busy loops, but CPU utilization should be a maxed out in the boot loader
anyway - we could add a pause, though.
* This closes bug #2654.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41117 a95241bf-73f2-0310-859d-f6bbb57e9c96
I hope I didn't break anything, as I can and have only test
bios_ia32's haiku_loader. Flame me otherwise.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40240 a95241bf-73f2-0310-859d-f6bbb57e9c96
used by tarfs anyway) instead of RLE.
While this should allows larger logo/icons, it doesn't remove the
current 300000 bytes size limits for haiku_loader, so #6710 is not yet fixed.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40215 a95241bf-73f2-0310-859d-f6bbb57e9c96
the address variable is incremented in the loop above and at the end will be
equal to sNextVirtualAddress if the address space can be reused. Fixes early
boot resets due to wrongly reused virtual addresses (and them being freed while
still in use by the original user). Fixes#7026, thanks to Urias for testing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39961 a95241bf-73f2-0310-859d-f6bbb57e9c96
the trace output against header being NULL (i.e. failed to map).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39958 a95241bf-73f2-0310-859d-f6bbb57e9c96
In r21611, about 3 years ago, the switch into protected mode was moved
from stage1 to stage2, which makes stage1 obsolete. You have to use
"pxehaiku-loader" when booting Haiku by PXE on x86.
Trying to use stage1 to boot stage2 resulted in tripple fault during
setup of ss segment, because stage1 switches to protected mode before
calling stage2, but stage2 expects real mode. The documentation is not
up to date.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39881 a95241bf-73f2-0310-859d-f6bbb57e9c96
Btw Axel, keyboard.cpp (forked from the bios_ia32 one) is still under "OpenBeOS licence" with 2 other copies, I suppose you are ok to change to MIT ?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39548 a95241bf-73f2-0310-859d-f6bbb57e9c96
- fix nat_feat_call() macro for more than 1 arg,
- add BOOTSTRAP natfeat calls get_bootdrive() and get_bootargs().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39491 a95241bf-73f2-0310-859d-f6bbb57e9c96
passing an additional -Wall to the compiler, which may actually
have unwanted effects. -Wall is standard by the build system.
Also, -Wno-multichar was passed unnecessarily for Haiku targets.
I didn't remove it for the bfs_shell, hope this is what Ingo meant
in the ticket.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@39314 a95241bf-73f2-0310-859d-f6bbb57e9c96
