pin configuration as the configuration only happens after preparing the
configuration where we already need the NMI mask.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41536 a95241bf-73f2-0310-859d-f6bbb57e9c96
actually support it, it make no point to let people think a parallel printer *may* be supported.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41535 a95241bf-73f2-0310-859d-f6bbb57e9c96
the macros. This makes things more readable and also fixes the few remaining
80 char limit violations. No functional change intended.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41533 a95241bf-73f2-0310-859d-f6bbb57e9c96
specify the delivery mode.
* Use that function from ioapic_configure_io_interrupt() and use it when
configuring NMI sources to actually set the entries to NMI.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41531 a95241bf-73f2-0310-859d-f6bbb57e9c96
unavailable for routing so that we don't end up configuring anything on them.
I haven't seen these in actual use though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41530 a95241bf-73f2-0310-859d-f6bbb57e9c96
we use a 64 bit level triggered mask. In practice these don't exist as far as I
know. If we encounter them at a later stage we need to revisit the mask.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41529 a95241bf-73f2-0310-859d-f6bbb57e9c96
at the override entry to trigger the overriden vector so that we don't need
to configure any additional redirections.
* Also configures the polarity and trigger modes found in the override entry.
* When disabling the legacy PIC, retrieve the enabled interrupts and re-enable
then in the IO-APIC. This will for example make the ACPI SCI work that is
installed prior to switching interrupt models. Through the transparent support
for interrupt source overrides it'll also automatically relay from the old to
the new vector.
This should make ACPI interrupts work and should support relocating the ISA PIT
from irq 0 to a different global system interrupt (usually 2) so that it can
still work when IO-APICs are in use.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41528 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
* remove device_type and replace with device_chipset
* change MEMSIZE to >> 10 as r600-r700 store this in bytes (r800 uses MB and will be fixed soon)
* add if statement to select what register locations to use based on chipset
** Maybe use a struct or something to store these in a standardized way?
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41525 a95241bf-73f2-0310-859d-f6bbb57e9c96
* break out most of the CopySetHaikuRevision action into a separate script:
determine_haiku_revision
* fix git branch detection such that it'll actually work for local branches (thanks to
Andreas Färber for the hint)
* add some sanity checks
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41520 a95241bf-73f2-0310-859d-f6bbb57e9c96
* move system_revision.h to headers/private/libroot
* unify libroot's get_system_revision() (the one I introduced recently) with kernel's
get_haiku_revision(), the function is now called get_haiku_revision() in the kernel
and __get_haiku_revision() in libroot
* system_revision.c is now being built as part of libroot and as part of the kernel
* adjusted all callers of get_system_revision() accordingly
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41516 a95241bf-73f2-0310-859d-f6bbb57e9c96
the case, but maybe there's some BIOSes that disable them? More or less poking
around for #5551, doesn't do any harm in any case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41514 a95241bf-73f2-0310-859d-f6bbb57e9c96
but maybe it helps on some chipsets to avoid interrupt storms during handover.
* Remove comments that aren't true anymore.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41513 a95241bf-73f2-0310-859d-f6bbb57e9c96
periodic list cache. This workaround is based on similar patches in NetBSD and
Linux and disables the (Advanced) Periodic List Cache on the affected devices
using ATI/AMD specifc registers (as documented in the corresponding AMD
register reference guide).
Also remove a ton of stray whitespace introduced by the isochronous patches.
Please take more care the next time.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41512 a95241bf-73f2-0310-859d-f6bbb57e9c96
of bufferSize, corrupting entries when multiple items within the same menu were
checked.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41505 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
to the kernel args in a single go. Otherwise we wind up with more link list
entries than expected, which in turn resulted in settings not quite being
parsed properly upon entering the kernel, which meant that if options were
chosen in both the debug and safe mode menus, only the debug ones were
applied. This might also have resulted in the kernel settings not being
loaded correctly in such an instance.
Should fix various issues people have had with safe mode settings not being
applied properly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41500 a95241bf-73f2-0310-859d-f6bbb57e9c96
kernel settings file. As pointed out by Rene, there's otherwise no way to
enable ACPI when the settings file is absent, as there's only a disable switch
in the boot menu.
* Remove MADT dumping as it isn't really implemented. This info can actually be
printed in the IO-APIC code now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41497 a95241bf-73f2-0310-859d-f6bbb57e9c96
While I was missing such an application I also used it as a playground for eventual tracker improvements. At the moment it works this way: The query is read in a background thread where a list of entry_ref is filled. The entries are exchanged thread safe with the display view using two entry_ref lists which are swapped when the view handled all entries from one list... The view is responsible to display the entry_ref's and load all attributes. In a future directory view, the view would be responsible to load all additional attributes. For example, first fetch the sort column and then asynchronously the rest (as discussed on the mailing list).
- I found the following query issue: when displaying the whole collection the query uses a empty string, the problem is that empty strings are not handled in live queries. For example, when adding a new Media:Artist attribute to a file the file does not show up in the query. Running a none empty query, e.g. Media:Artist contains "test" it shows up. Thats a bug right?
- Only tested it with just ~2100 music file and the on the fly performance is very good. Displaying the complete music list is quite slow, though. This seems to be not a query problem but more a BOutlineView issue. Adding new items to the list seems to be expensive...
- At the moment a new query is started each time you typing a char. A faster solution would be to start just one query in the beginning and then just filter this list. Since BOutlineView seems to be the bottleneck I kept it this way for now. Furthermore, it is a nice performance test for queries.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41493 a95241bf-73f2-0310-859d-f6bbb57e9c96
get_system_revision() instead of parsing it from utsname
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41480 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add private function get_system_revision() for accessing the
revision string
* adjust uname to use get_system_revision
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@41479 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
