Alan Coopersmith wrote:
Dan Mick wrote:
1) I've never heard of /dev/fbs/aperture
It's basically an open source version of xsvc included in Xorg
for Solaris systems without xsvc (really ancient Solaris x86 or
any version of Solaris SPARC).
Dan Mick [EMAIL PROTECTED] wrote:
Mmm, aperture exists since ~ 1994.
The isal binary above is from June 21st 2005
It should be modified to check for /dev/fbs/aperture too.
1) I've never heard of /dev/fbs/aperture
2) xsvc is a hack that should be replaced by a proper /dev/mem
3) sigh.
Dan Mick [EMAIL PROTECTED] wrote:
1) I've never heard of /dev/fbs/aperture
1a) I don't have one on my x86 system. It's existed since 1994 where,
exactly?
So get it from ftp.berlios.de/pub/schillix/ or wait for the next SchilliX
release.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg
Dan Mick [EMAIL PROTECTED] wrote:
It's basically an open source version of xsvc included in Xorg
for Solaris systems without xsvc (really ancient Solaris x86 or
any version of Solaris SPARC).
Dan Mick [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
Dan Mick [EMAIL PROTECTED] wrote:
1) I've never heard of /dev/fbs/aperture
1a) I don't have one on my x86 system. It's existed since 1994 where,
exactly?
So get it from ftp.berlios.de/pub/schillix/ or wait for the
Dan Mick wrote:
1) I've never heard of /dev/fbs/aperture
It's basically an open source version of xsvc included in Xorg
for Solaris systems without xsvc (really ancient Solaris x86 or
any version of Solaris SPARC).
Rainer Orth [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] writes:
PS: What is the status of iasl? Getting a standard Solaris iasl binary
out would be very helpful.
Dan Mick put one at
ftp://playground.sun.com/pub/dmick/iasl
A nice program, but unfortunately, it does not work on
[EMAIL PROTECTED] wrote:
Dan Mick put one at
ftp://playground.sun.com/pub/dmick/iasl
A nice program, but unfortunately, it does not work on OpenSolaris
unless you create this
lrwxrwxrwx 1 root root 12 Jul 7 21:00 xsvc - fbs/aperture
symlink. Why does iasl not
Dragan Cvetkovic [EMAIL PROTECTED] wrote:
On Wed, 6 Jul 2005, Joerg Schilling wrote:
Jul 2 11:10:09 s11 genunix: [ID 243001 kern.warning] WARNING: The binding
file entry iprb 214 conflicts with a previous entry on line 201 of
/etc/name_to_major
Jul 2 11:10:09 s11 genunix: [ID
Joerg Schilling wrote:
If I plug in a PS/2 mouse (even after the system is booted successfully)
the keyboard becomes non-functional until the system is rebooted.
That's odd. I'll have to forward this to the keyboard/mouse team;
it doesn't sound directly related to ACPI. Though...
OK, here
The system ACPI BIOS is attempting to access PCI configuration space
directly rather than using the correct PCI Config space operation regions.
This is unsafe - directly accessing config space like this is non-atomic.
The OSL implementation blocks these accesses.
Perhaps, Dana, you can give us
[EMAIL PROTECTED] writes:
PS: What is the status of iasl? Getting a standard Solaris iasl binary
out would be very helpful.
Dan Mick put one at
ftp://playground.sun.com/pub/dmick/iasl
some time ago.
Rainer
--
[EMAIL PROTECTED] writes:
PS: What is the status of iasl? Getting a standard Solaris iasl binary
out would be very helpful.
Dan Mick put one at
ftp://playground.sun.com/pub/dmick/iasl
some time ago.
Excellent; with iasl -g you can extract the AML code from the
system and the ACPI
[EMAIL PROTECTED] wrote:
The system ACPI BIOS is attempting to access PCI configuration space
directly rather than using the correct PCI Config space operation regions.
This is unsafe - directly accessing config space like this is non-atomic.
The OSL implementation blocks these accesses.
I'm more inclined to add an additional acpi-user-options bit
to permit users to relax the I/O permission checks. Legacy
acpi_intp had no permission check and I don't recall any
bugs filed, though any problem resulting from non-atomic access
to PCI config space is likely to be pretty mysterious.
[EMAIL PROTECTED] wrote:
I'm more inclined to add an additional acpi-user-options bit
to permit users to relax the I/O permission checks. Legacy
acpi_intp had no permission check and I don't recall any
bugs filed, though any problem resulting from non-atomic access
to PCI config space is likely
Well, with the fixed AML the system now detects its floppy
again; not that I can check that it works, remotely, but this
is nice.
@@ -1350,13 +1350,6 @@
FDCT, 8
}
-OperationRegion (PCIC, SystemIO, 0x0CF8, 0x08)
-Field
Dana H. Myers [EMAIL PROTECTED] wrote:
Joerg Schilling wrote:
If I plug in a PS/2 mouse (even after the system is booted successfully)
the keyboard becomes non-functional until the system is rebooted.
That's odd. I'll have to forward this to the keyboard/mouse team;
it doesn't sound
Joerg Schilling wrote:
Dana H. Myers [EMAIL PROTECTED] wrote:
Jul 4 21:41:45 s11 acpica: [ID 972481 kern.warning] WARNING: AcpiOsWritePort:
cf8 32 not permitted
Jul 4 21:41:45 s11 acpica: [ID 815887 kern.notice] ACPI-0519: *** Error:
Jul 4 21:41:45 s11 acpica: [ID 441208 kern.notice]
Dana H. Myers [EMAIL PROTECTED] wrote:
Have a look here:
http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/io/acpica/osl.c#570
What I'm contemplating is adding yet another acpi-user-options bit to
disable access control for those willing to experiment with it.
So you think of making
Joerg Schilling wrote:
Dana H. Myers [EMAIL PROTECTED] wrote:
Have a look here:
http://cvs.opensolaris.org/source/xref/usr/src/uts/i86pc/io/acpica/osl.c#570
What I'm contemplating is adding yet another acpi-user-options bit to
disable access control for those willing to experiment with it.
Jul 2 11:10:09 s11 genunix: [ID 243001 kern.warning] WARNING: The binding
file entry iprb 214 c
onflicts with a previous entry on line 201 of /etc/name_to_major
There's an issue here with corruption in the /etc/*_* files;
/etc/name_to_major has duplicate entries and these are also not
as they
22 matches
Mail list logo
