Re: [osol-discuss] Re: Re: Re: Feature request
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). http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/etc/apSolaris.shar?rev=1.2view=markup oh, and so Joerg included it in Schillix? and is surprised that a utility ported inside Sun doesn't know about it? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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. Unfortunately, xsvc does not exist on OpenSolaris and /dev/mem does not seem to be usable now for this problem. BTW: I did not hea about /dev/fbs/aperture too before I started to work on X for OpenSolaris. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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). http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/etc/apSolaris.shar?rev=1.2view=markup oh, and so Joerg included it in Schillix? and is surprised that a utility ported inside Sun doesn't know about it? Well, I just tried tp point out that now that OpenSolaris is out, we all need to be more careful about portability and usability of software between Sun Solaris and OpenSolaris based distros. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 next SchilliX release. So, on the one hand, iasl should already be using it, because aperture has existed since 1994; but on the other hand, you didn't know about it until recently, and I should now go get it from your distro. I did not know about it 2 weeks ago either. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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). http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/etc/apSolaris.shar?rev=1.2view=markup -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 OpenSolaris unless you create this lrwxrwxrwx 1 root root 12 Jul 7 21:00 xsvc - fbs/aperture symlink. Why does iasl not check for /dev/fbs/aperture? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
[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 check for /dev/fbs/aperture? Probably because the binary was created before fbs/aperture existed :-) 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. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 723599 kern.warning] WARNING: Driver alias pci8086,1029 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,1030 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,1229 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,2449 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 107833 kern.warning] WARNING: Unexpected token ''sb411,12' on line 373 of /etc/driver_aliases Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,1029 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,1030 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,1229 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,2449 conflicts with an existing driver name or alias. What are these errors related to? Check /etc/driver_aliases We did by accident add a second driver vor the intel iprb0 Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 is the ACPI part of the boot messages: 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] Handler for [SystemIO] returned AE_ERROR 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. Dana ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 some AML recipes on how to fix this?
I have an old ASUS CUV4X which has the same problem, it defines an
operating region:
OperationRegion (PCIC, SystemIO, 0x0CF8, 0x08)
Field (PCIC, DWordAcc, NoLock, Preserve)
{
PIND, 32,
PDAT, 32
}
And the uses the following _STA method for the FDC0 (floppy device):
Method (_STA, 0, NotSerialized)
{
Store (0x80002084, PIND)-- bad
Store (PDAT, Local0)-- bad
And (Local0, 0x0100, Local0)
If (LEqual (Local0, 0x00))
{
Return (0x00)
}
Else
{
ENFG ()
Store (IOFN, Local0)
And (Local0, 0x10, Local0)
If (LNot (LEqual (Local0, 0x00)))
{
EXFG ()
Return (0x0F)
}
Else
{
Store (FCIO, Local1)
If (LNot (LEqual (Local1, 0x00)))
{
EXFG ()
Return (0x0D)
}
Else
{
EXFG ()
Return (0x00)
}
}
}
}
This then leads to:
acpica: [ID 972481 kern.warning] WARNING: AcpiOsWritePort: cf8 32 not permitted
acpica: [ID 815887 kern.notice] ACPI-0519: *** Error:
acpica: [ID 441208 kern.notice] Handler for [SystemIO] returned AE_ERROR
acpica: [ID 584230 kern.notice] ACPI-1413: *** Error:
acpica: [ID 810882 kern.notice] Method execution failed
acpica: [ID 363072 kern.notice] [\_SB_.PCI0.PX40.FDC0._STA] (Node c81f3364)
Now if I could rewrite the AML to do the proper thing and install the
replacement
ACPICA table (just as I fixed the Ferrari 4000 batter), such a recipe might
help some to see what the exact problem is.
Casper
PS: What is the status of iasl? Getting a standard Solaris iasl binary
out would be very helpful.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
[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 -- - Rainer Orth, Faculty of Technology, Bielefeld University ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
[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 tables; the AML code will generally show where the issues are which generate the read/write port errors. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
[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.
Perhaps, Dana, you can give us some AML recipes on how to fix this?
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.
I have an old ASUS CUV4X which has the same problem, it defines an
operating region:
OperationRegion (PCIC, SystemIO, 0x0CF8, 0x08)
Field (PCIC, DWordAcc, NoLock, Preserve)
{
PIND, 32,
PDAT, 32
Heavens. This is a non-trivial bit of work.
First of all, you'd need to figure which PCI device's config space is
being accessed; you'll need to work the 0xCF8 access backwards,
and this is pretty helpful:
http://thorkildsen.no/faqsys/docs/pci.txt
And the uses the following _STA method for the FDC0 (floppy device):
Method (_STA, 0, NotSerialized)
{
Store (0x80002084, PIND)-- bad
So I think this is an access to Bus #0, Device#4, offset 0x84
Store (PDAT, Local0)-- bad
and this is a read of the device config space.
So now you need to locate/create a PCI device object underneath
the correct PCI bridge device and create a PCI_Config operation
region underneath it:
Device (FLOPPYTHING)
{
Name (_ADR, 0x0004)
OperationRegion (FTCFS, PCI_Config, 0x84, 0x01)
Field (FTCFS, ByteAcc, NoLock, Preserve)
{
FTSTA, 8
}
And you could then access this field with:
Store(\_SB.table-dependent-PCI-device-path-here.FLOPPYTHING.FTSTA,
Local0);
A couple of notes; only the 'host' (peer) PCI bridge devices
have _BBN objects which (if they're not broken) identify which
PCI bus the bridge hosts. Child buses need to be found by
relating the _ADR() objects of the children to the PCI config
space of the system.
It's non-trivial.
Now if I could rewrite the AML to do the proper thing and install the
replacement
ACPICA table (just as I fixed the Ferrari 4000 batter), such a recipe might
help some to see what the exact problem is.
Sure.
PS: What is the status of iasl? Getting a standard Solaris iasl binary
out would be very helpful.
Dan (Mick) pushed out a useful version on playground at:
ftp://playground.sun.com/pub/dmick/iasl
and, at some point, we'll see about including it in the WOS.
Dana
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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. I seem to recall also that this was work done is response to some mysterious problems which were later root-caused elsewhere? Heavens. This is a non-trivial bit of work. deleted Well, I guess I'll vote for the user option then :-) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
[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 to be pretty mysterious. I seem to recall also that this was work done is response to some mysterious problems which were later root-caused elsewhere? No, not really. This (adding I/O permission checks) was done to prevent possible mysterious issues with unsafe hardware access, in a moment of zeal on my part. Heavens. This is a non-trivial bit of work. deleted Well, I guess I'll vote for the user option then :-) Heh. I'll be including such an option in the current refresh under development. Dana ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 (PCIC, DWordAcc, NoLock, Preserve)
-{
-PIND, 32,
-PDAT, 32
-}
-
Method (ENFG, 0, NotSerialized)
{
Store (One, EN2C)
@@ -1370,10 +1363,16 @@
Device (FDC0)
{
Name (_HID, EisaId (PNP0700))
+ Name (_ADR, 0x0004)
+ OperationRegion (FTC, PCI_Config, 0x84, 0x04)
+ Field (FTC, DWordAcc, NoLock, Preserve)
+ {
+ FTCA, 32
+ }
+
Method (_STA, 0, NotSerialized)
{
-Store (0x80002084, PIND)
-Store (PDAT, Local0)
+Store (FTCA, Local0)
And (Local0, 0x0100, Local0)
If (LEqual (Local0, 0x00))
{
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 directly related to ACPI. Though... The interesting info is that Solaris 10 did work with the same hardware. OK, here is the ACPI part of the boot messages: 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] Handler for [SystemIO] returned AE_ERROR 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. What does this mean? Does this mean that OpenSolaris will not be ble to deal with this ACPI implementation (or with this board)? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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] Handler for [SystemIO] returned AE_ERROR 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. What does this mean? Does this mean that OpenSolaris will not be ble to deal with this ACPI implementation (or with this board)? I *did* tighten the behavior of the ACPI interpreter; the legacy acpi_intp did not filter on such accesses. The truth be told, I can't point at any logged bugs that are clearly due to unsafe ACPI BIOS accesses. 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. Dana ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 line 646...651 optional by a acpi-user-options bit? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED](work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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. So you think of making line 646...651 optional by a acpi-user-options bit? That, and lines 613-620, too. Read and write accesses are filtered independently of each other. Dana ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Re: Feature request
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 should be: Jul 2 11:10:09 s11 genunix: [ID 723599 kern.warning] WARNING: Driver alias pci8086,1029 conflicts with an existing driver name or alias. Jul 2 11:10:09 s11 acpica: [ID 972481 kern.warning] WARNING: AcpiOsWritePort: cf8 32 not permitted This is a write to a bad port, this causes the floppy not to be enumerated. (AML isn't supposed to write to pci config registers) Serial/infrared/priner ports too: Jul 2 11:10:09 s11 acpica: [ID 893048 kern.notice] [\_SB_.PCI0.UAR1._STA] (Node c81f4544) Jul 2 11:10:09 s11 acpica: [ID 124139 kern.notice] [\_SB_.PCI0.UAR2._STA] (Node c81f) Jul 2 11:10:09 s11 acpica: [ID 503650 kern.notice] [\_SB_.PCI0.IRDA._STA] (Node c81f4364) Jul 2 11:10:09 s11 acpica: [ID 808763 kern.notice] [\_SB_.PCI0.LPT1._STA] (Node c81f4264) Jul 2 11:10:09 s11 acpica: [ID 930318 kern.notice] [\_SB_.PCI0.ECP1._STA] (Node c81f4184) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
