ACPI 3.00, nVidia high IRQs vs. old drivers

Discussion of ACPI driver (Power management, multi-processor support, PnP)
mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

ACPI 3.00, nVidia high IRQs vs. old drivers

Postby mikeforester » Wed Aug 15, 2007 18:10

I finally discovered ACPI 3.00 and installed it. It's nice to see all the high IRQs.

Only problem is, old drivers (SBlive, SYM8XX.ADD) won't load with their new high IRQs. They're both physically on IRQ 11, but with the new ACPI they're mapped to 17 and 18, respectively. The drivers can't find the hardware, although it does show with PCI.EXE. Any tricks to work around this?

I put "REMAP 17 to 10" and "REMAP 18 to 11" in /os2/boot/acpi.cfg, but that didn't seem to do anything.

Also, using the /ALS switch on this motherboard causes the system to hang as soon as ACPI.PSD loads.
-Mike

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Postby Eugene Gorbunoff » Wed Aug 15, 2007 18:15

OK, I moved your report to the tracker:
http://svn.netlabs.org/acpi/ticket/25

look into ACPI-SMP-DRV.doc, sblive should work in APIC mode.

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Wed Aug 15, 2007 18:49

Eugene Gorbunoff wrote:look into ACPI-SMP-DRV.doc, sblive should work in APIC mode.

It has worked fine in ACPI mode for me up till now. There's no code in the sblive driver to support IRQs higher than 15. I added some definitions for high IRQs to the version of the code that Steven Levine uploaded to svn on netlabs, but that doesn't work either.
-Mike

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Postby Eugene Gorbunoff » Wed Aug 15, 2007 19:13

Q1: I am developing a driver. How to create ACPI compatible driver?
A1: Main rules:
* don't set own restrictions to high IRQs > IRQ15
* read information about IRQ from PCI Config Space or from acpi.psd

How to create driver ready for SMP and APIC mode?
* Use DevEOI helper only, DON'T USE OUT 20h,20h

More suggestions:
* if you don't want ask ACPI which mode is used (PIC or APIC) then
start using IRQ after INIT_COMPLETE only

APM:
* when you init the adapter, look at D-state in PCI,
if the adapter is in D-state (i.e. D-state != 0) then enable it.
Else the devices don't work if computer was suspended by Windows.


--------


Q61: There is old device driver. How to make it work in APIC?
A61: Patch it. It's necessary patch DevHlp_SetIRQ and set shared.
(This will help if DevHlp_EOI are used)
If you have asm source code with headers from DDK then
makefile should contain SMP=1

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Wed Aug 15, 2007 23:15

Eugene Gorbunoff wrote:Q1: I am developing a driver. How to create ACPI compatible driver?
A1: Main rules:
* don't set own restrictions to high IRQs > IRQ15
* read information about IRQ from PCI Config Space or from acpi.psd

How to create driver ready for SMP and APIC mode?
* Use DevEOI helper only, DON'T USE OUT 20h,20h

Well, that's all well and good, Eugene, but I'm not "developing" anything. I tried (and failed, so far) to fix a memory-limit problem with the SBlive driver, but I'm not a programmer and have only the most tenuous understanding of C, C++ and asm.

But I can tell you definitely the existing version will *not* work with IRQs above 15.
-Mike

User avatar
Pasha
Posts: 82
Joined: Fri Apr 21, 2006 14:17

Postby Pasha » Wed Sep 05, 2007 07:27

mikeforester wrote:
Eugene Gorbunoff wrote:Q1: I am developing a driver. How to create ACPI compatible driver?
A1: Main rules:
* don't set own restrictions to high IRQs > IRQ15
* read information about IRQ from PCI Config Space or from acpi.psd

How to create driver ready for SMP and APIC mode?
* Use DevEOI helper only, DON'T USE OUT 20h,20h

Well, that's all well and good, Eugene, but I'm not "developing" anything. I tried (and failed, so far) to fix a memory-limit problem with the SBlive driver, but I'm not a programmer and have only the most tenuous understanding of C, C++ and asm.

But I can tell you definitely the existing version will *not* work with IRQs above 15.


At nvidia you change high IRQ via ACPI.CFG keyword LINK

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Thu Sep 06, 2007 02:28

Pasha wrote:At nvidia you change high IRQ via ACPI.CFG keyword LINK

Thanks, Pasha, I had been meaning to try that. So now I have. It doesn't seem to change anything.

After much head-scratching, I decided these two ACPI names are the SCSI and sound card. Under ACPI 2.22:

Code: Select all

      +*APC2 T:[Device] HID:[PNP0C0F] UID:[21] STA:[0xb] SxD State:[0xff:ff:ff:ff]
 Current state:
     > PrCm 1 IRQ11 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG
 Possible State:
     > PrCm 1 IRQ17 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG
. . .
      |
      +*APC3 T:[Device] HID:[PNP0C0F] UID:[22] STA:[0xb] SxD State:[0xff:ff:ff:ff]
 Current state:
     > PrCm 1 IRQ11 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG
 Possible State:
     > PrCm 1 IRQ18 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG

And I added this to \os2\boot\acpi.cfg:

Code: Select all

LINK APC2 11
LINK APC3 10

But they don't move. This is how they show in ACPI 3.01:

Code: Select all

      +*APC2 T:[Device] HID:[PNP0C0F] UID:[21] STA:[0xb] SxD State:[0xff:ff:ff:ff]
 Current state:
     > PrCm 1 IRQ17 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG
 Possible State:
     > PrCm 1 IRQ17 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG
. . .
      |
      +*APC3 T:[Device] HID:[PNP0C0F] UID:[22] STA:[0xb] SxD State:[0xff:ff:ff:ff]
 Current state:
     > PrCm 1 IRQ18 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG
 Possible State:
     > PrCm 1 IRQ18 triggerred by Edge, polarity Low, Sharable SourceIdx 0
     > ENDTAG

The complete path to these devices appears to be \_SB_.PCI0.ACPx. However, there's something screwy about PCI0: it always shows up as "UNDEFINED". This is from AcpiIrq:

Code: Select all

Show ACPI IRQ routing
@
|
+*_SB_ T:[Device] STA:[0xffffffff] SxD State:[0xff:ff:ff:ff]
   |
   +*PWRB T:[Device] HID:[PNP0C0C] STA:[0xb] SxD State:[0xff:ff:ff:ff]
   |
   +*PCI0 T:[UNDEFINED] HID:] CID:] STA:[0x60034] SxD State:[0x00:00:34:00]

Similarly, in AcpiManager, the name of PCI0 displays as changing garbage characters -- just now, as à^M. Maybe that has something to do with it?

Thanks!
-Mike

Alan Beagley
Posts: 67
Joined: Wed Jul 26, 2006 02:06

Re: ACPI 3.00, nVidia high IRQs vs. old drivers

Postby Alan Beagley » Thu Sep 06, 2007 02:56

mikeforester wrote:I finally discovered ACPI 3.00 and installed it. It's nice to see all the high IRQs.

Only problem is, old drivers (SBlive, SYM8XX.ADD) won't load with their new high IRQs. They're both physically on IRQ 11, but with the new ACPI they're mapped to 17 and 18, respectively. The drivers can't find the hardware, although it does show with PCI.EXE. Any tricks to work around this?

I put "REMAP 17 to 10" and "REMAP 18 to 11" in /os2/boot/acpi.cfg, but that didn't seem to do anything.

Also, using the /ALS switch on this motherboard causes the system to hang as soon as ACPI.PSD loads.


Mike, please remind me exactly what motherboard you have. I know I saw a mention that it's an nForce4, but which of the many? My Asus A8N-E works fine with ACPI 2.22 but stops at the boot screen with ACPI 3.0x if SMP is enabled -- happened when I tried to upgrade my RC1 setup to 3.0 and also when I tried installing RC2; in the latter case, backleveling to 2.22 allowed the system to work again.
Alan

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Re: ACPI 3.00, nVidia high IRQs vs. old drivers

Postby mikeforester » Thu Sep 06, 2007 03:03

Alan Beagley wrote:Mike, please remind me exactly what motherboard you have. I know I saw a mention that it's an nForce4, but which of the many? My Asus A8N-E works fine with ACPI 2.22 but stops at the boot screen with ACPI 3.0x if SMP is enabled -- happened when I tried to upgrade my RC1 setup to 3.0 and also when I tried installing RC2; in the latter case, backleveling to 2.22 allowed the system to work again.

Hi, Alan,

It's a Tyan Tomcat K8E S2865. NForce4, Award BIOS.
-Mike

Alan Beagley
Posts: 67
Joined: Wed Jul 26, 2006 02:06

Re: ACPI 3.00, nVidia high IRQs vs. old drivers

Postby Alan Beagley » Thu Sep 06, 2007 03:07

mikeforester wrote:
Alan Beagley wrote:Mike, please remind me exactly what motherboard you have. I know I saw a mention that it's an nForce4, but which of the many? My Asus A8N-E works fine with ACPI 2.22 but stops at the boot screen with ACPI 3.0x if SMP is enabled -- happened when I tried to upgrade my RC1 setup to 3.0 and also when I tried installing RC2; in the latter case, backleveling to 2.22 allowed the system to work again.

Hi, Alan,

It's a Tyan Tomcat K8E S2865. NForce4, Award BIOS.

Wow! That was a quick reply. What parameters are you using on the ACPI.PSD line?
Alan

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Thu Sep 06, 2007 03:08

Pasha,

One other note. Normally I use just this in config.sys:

PSD=ACPI.PSD /SMP /APIC

I added the /TMR switch and it doesn't change the weird behavior of PCI0. Now in AcpiManger its name shows as "ò^G".

/ALS doesn't "lock up" the system as I said earlier. Rather, it just hangs at the os2logo screen. I can reboot with Ctrl-Alt-Del.
-Mike

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Re: ACPI 3.00, nVidia high IRQs vs. old drivers

Postby mikeforester » Thu Sep 06, 2007 03:10

Alan Beagley wrote:Wow! That was a quick reply. What parameters are you using on the ACPI.PSD line?

Heh. I just answered that too. ;)
-Mike

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Tue Sep 18, 2007 08:19

Pasha wrote:At nvidia you change high IRQ via ACPI.CFG keyword LINK

These problems have been solved in 3.02, using REMAP instead of LINK, per nickk's ticket on netlabs. (Which, heh, is where I started this thread.)

Eugene: You should remove SYM8XX.ADD from acpi-smp-drv.doc. Better, maybe, would be to start a list of drivers we now know don't work with high IRQs, so far:

SBLIVE 0.8.1 and earlier
SYM8XX.ADD
SYM_HI.ADD

I also discovered, using REMAP, that the target IRQ needs to be reserved in the BIOS; otherwise, I got stuttering sounds like an IRQ conflict from the SBlive, and was unable to access the tape drive, even though the SCSI drivers were loaded.

So in my case I have

REMAP 19 to 5
REMAP 17 to 11

and IRQ's 5 and 11 marked RESERVED (i.e., not for PCI sharing).
-Mike

User avatar
Eugene Gorbunoff
Site Admin
Posts: 685
Joined: Sat Apr 09, 2005 11:18
Location: St.Petersburg, Russia

Postby Eugene Gorbunoff » Tue Sep 18, 2007 10:57

OK, I added to ACPI-SMP-DRV.doc such block:


Drivers not ready for ACPI APIC. The device works if use REMAP:

(target IRQ needs to be reserved in the BIOS)


* SYM8XX.ADD (thx nickk, Mike Forester)
* SBLIVE 0.8.1 and earlier
* SYM_HI.ADD

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Tue Sep 18, 2007 14:58

Eugene Gorbunoff wrote:(target IRQ needs to be reserved in the BIOS)

That's fine. To be slightly more precise, you could say "target IRQ might need to be reserved in the BIOS." On my system, IRQ 5 is almost always free, while all the built-in and add-on PCI devices always want to use IRQs 10 & 11.
-Mike

mikeforester
Posts: 32
Joined: Sat Sep 23, 2006 00:56

Postby mikeforester » Wed Sep 19, 2007 19:59

One further note on this, in case someone needs it.

I discovered I have two low IRQs which are never shared and which I'm not using: IRQ12 (reserved for PS/2 mouse) and IRQ15 (reserved for secondary IDE channel). These work fine as REMAP targets, without having to change any BIOS settings.
-Mike


Return to “ACPI for eComStation”

Who is online

Users browsing this forum: No registered users and 1 guest

cron