RE: Testing: NVidia closed driver fails.

RE: Testing: NVidia closed driver fails.

[Grover, Andrew]

> From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > seconds to start and then consumes as much CPU time as 
> possible. It's an
> > adventure to try to hit something with the mouse pointer.
> > Everything is funktioning perfectly without ACPI.
> > Perhaps an interrupt problem. ACPI shares an interrupt with 
> a bttv card.
> > The GeForce has it's own interrupt.
> Huh! You just mentioned a magic word: bttv. I do have a bt878 
> card, I have to 
> look if that is the problem after all.
> 
> To A. Grover: if the trouble lies in the bttv driver, the 
> kernel will be 
> considered broken until both drivers co-exist..

When you cat /proc/interrupts, is there a huge and ever-increasing number of
interrupts listed for the shared irq?

(Wait, I thought video devices weren't interrupt driven? Or is that only
video out, not video-in, like bt878?)

My understanding was, when an interrupt is shared, the OS calls *all* the
interrupt service routines (ISRs) for devices on that interrupt - it is then
up to the ISR to determine whether its device interrupted and handle it, or
whether just to return.

You might start your investigations by looking at
drivers/acpi/events/evsci.c acpi_ev_sci_handler().

Regards -- Andy


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Ducrot Bruno]

On Thu, Sep 19, 2002 at 03:26:52PM -0700, Grover, Andrew wrote:
> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org] 
> > > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > > seconds to start and then consumes as much CPU time as 
> > possible. It's an
> > > adventure to try to hit something with the mouse pointer.
> > > Everything is funktioning perfectly without ACPI.
> > > Perhaps an interrupt problem. ACPI shares an interrupt with 
> > a bttv card.
> > > The GeForce has it's own interrupt.
> > Huh! You just mentioned a magic word: bttv. I do have a bt878 
> > card, I have to 
> > look if that is the problem after all.
> > 
> > To A. Grover: if the trouble lies in the bttv driver, the 
> > kernel will be 
> > considered broken until both drivers co-exist..
> 
> When you cat /proc/interrupts, is there a huge and ever-increasing number of
> interrupts listed for the shared irq?
> 
> (Wait, I thought video devices weren't interrupt driven? Or is that only
> video out, not video-in, like bt878?)

Some of them are interrupt driven, like some Nvidia cards, certainly when
you configure the so-called Nvidia TwinView(TM) feature of such card.

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Jochen Reinwand]

Grover, Andrew wrote:
> > From: P. Christeas [mailto:p_christ-U04EIuiosng@public.gmane.org]
> >
> > > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > > seconds to start and then consumes as much CPU time as
> >
> > possible. It's an
> >
> > > adventure to try to hit something with the mouse pointer.
> > > Everything is funktioning perfectly without ACPI.
> > > Perhaps an interrupt problem. ACPI shares an interrupt with
> >
> > a bttv card.
> >
> > > The GeForce has it's own interrupt.
> >
> > Huh! You just mentioned a magic word: bttv. I do have a bt878
> > card, I have to
> > look if that is the problem after all.
> >
> > To A. Grover: if the trouble lies in the bttv driver, the
> > kernel will be
> > considered broken until both drivers co-exist..
>
> When you cat /proc/interrupts, is there a huge and ever-increasing number
> of interrupts listed for the shared irq?

No, everything seems to be ok there with my system. For a long time the value 
for interrupt 9 (shared between acpi, usb, bttv) did not even increase.

To test it I removed the bttv card and disabled usb as far as possible (there 
are two controllers, only one could be disabled. But there are no devices 
connected to usb at all.)
Still the same problem: X gets very slow. Looks like it's making a pause every 
few seconds. Working remote via ssh on the system is possible without any 
problems.

> (Wait, I thought video devices weren't interrupt driven? Or is that only
> video out, not video-in, like bt878?)

Strange. Someone told me, that they use interrupts to talk to the graphics 
card. I didn't really believe that...
Now I tried: I just watched a little bit with the bttv and there was NO 
interrupt activity at all!

I found a note on the German Asus web site, that tv cards should have there 
own interrupt. Doesn't seem to be very important. Windows and Linux seem to 
have no problem with it.

Conclusion: The bttv driver is not responsible for the problem! The NVidia 
driver or acpi is the problem. Should someone inform NVidia about the 
problem?

Jochen


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Arnaud Fevrier]

I have just recompiled the 20-pre7 kernel and X works fine with my
nvidia. I have the closed nvidia kernel module :-( and had to
recompile it for the new kernel. 

When I use apm to nap my system, sometimes the X-server got killed. I
did not really investigate, but I thinks it depends on the compilation
options of the kernel.

It's still bad that nvidia did not release an open source
implementation, but I can't change it.

I can provide more information, just ask me what info you want.

sincerely,

-- 

			    Arnaud Février
			    fevrier-94MxA55sdNz4HDTGivPSy1aPQRlvutdw@public.gmane.org
			    +33 () 491 177 926
                  
                 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Arnaud Fevrier]

Hi,

 I have a fujitsu-Siemens CelsiusH which comes with a nvidia card. The
 nvidia driver (1.0-2960) shares it interupts with the allegro sound
 card.

I compiled the kernel 20-pre7 acpi 2002 09 18, and it boots fine. 

I cannot run the make xconfig, and I had to set the SMP. It did not
compile for a uniprocessor.

A lot of acpi features work fine, but I cannot sleep or hibernate the
laptop.

Sincerly,

-- 

			    Arnaud Février
			    fevrier-94MxA55sdNz4HDTGivPSy1aPQRlvutdw@public.gmane.org
			    +33 () 491 177 926
                  
                 


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

CALL FOR TESTING

[Grover, Andrew]

I wanted to make a special request for testing of the 2.4 patch (or should I
say, MEGA-patch).

Marcelo has asked for widespread testing of it, in anticipation of likely
2.4 mainline inclusion. I will be posting a call for testing to linux-kernel
soon, but am posting this here first to hopefully weed out any really bad
bugs that may have crept in.

The main issues of importance are:

- DOES IT BOOT?
- DOES IT ASSIGN INTERRUPTS PROPERLY?

Failure to do so either indicates a bug that we need to fix (fast) or a
system that should go on the blacklist. dmesg now includes the DSDT
signature to aid blacklisting.

Issues like whether the battery reports stats properly are of secondary
importance.

Thanks in advance.

Regards -- Andy

-----------------------------
Andrew Grover
Intel Labs / Mobile Architecture
andrew.grover-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[P. Christeas]

> I wanted to make a special request for testing of the 2.4 patch (or should
> I say, MEGA-patch).
>
>
> - DOES IT BOOT?
> - DOES IT ASSIGN INTERRUPTS PROPERLY?
>

I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon XP 
1.7+, VIA VT8637 KT266 chipset. The system boots and displays some ACPI info 
that looks fine.
However, the proprietary NVidia video driver (I have a Geforce 2 MX card and 
the newest 1.0.3123 proprietary driver) fails to start the X system. I 
strongly suspect (although I don't have enough debug info yet) that the acpi 
patch is the one that makes NVidia fail. The 2.4.19 worked until the acpi 
patch was applied to it.

The situation arising is quite strange. I want the current ACPI to be 
included in the next mainline kernel. However, all NVidia users will be 
disappointed if the stable 2.4.20 comes out before NVidia releases a suitable 
driver.

I suggest: merge the ACPI and tell NVidia to start testing. Put a warning 
label at both sides make sure a correct NVidia driver is out before 2.4.20 
reaches final release (there is plenty of time).


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Ducrot Bruno]

On Thu, Sep 19, 2002 at 03:38:16PM +0300, P. Christeas wrote:
> > I wanted to make a special request for testing of the 2.4 patch (or should
> > I say, MEGA-patch).
> >
> >
> > - DOES IT BOOT?
> > - DOES IT ASSIGN INTERRUPTS PROPERLY?
> >
> 
> I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon XP 
> 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some ACPI info 
> that looks fine.
> However, the proprietary NVidia video driver (I have a Geforce 2 MX card and 
> the newest 1.0.3123 proprietary driver) fails to start the X system. I 
> strongly suspect (although I don't have enough debug info yet) that the acpi 
> patch is the one that makes NVidia fail. The 2.4.19 worked until the acpi 
> patch was applied to it.

I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device with and
without acpi?

-- 
Ducrot Bruno
http://www.poupinou.org        Page profaissionelle
http://toto.tu-me-saoules.com  Haume page


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Jochen Reinwand]

Just an idea:

I read somewhere that NVidia kernel drivers make problems with apm.
In the syslog appears the following when starting X:

kernel: apm: set display: Power management disabled

It's a few seconds after the modules are inserted, so perhaps SuSE does it 
somewhere in the startup scripts... Have not found it yet...


I have a KT133 (Asus A7V) and also a Geforce 2 MX.
With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20 seconds 
to start and then consumes as much CPU time as possible. It's an adventure to 
try to hit something with the mouse pointer.
Everything is funktioning perfectly without ACPI.
Perhaps an interrupt problem. ACPI shares an interrupt with a bttv card. The 
GeForce has it's own interrupt.

Jochen

Am Donnerstag, 19. September 2002 17:06 schrieb Ducrot Bruno:
> On Thu, Sep 19, 2002 at 03:38:16PM +0300, P. Christeas wrote:
> > > I wanted to make a special request for testing of the 2.4 patch (or
> > > should I say, MEGA-patch).
> > >
> > >
> > > - DOES IT BOOT?
> > > - DOES IT ASSIGN INTERRUPTS PROPERLY?
> >
> > I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon XP
> > 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some ACPI
> > info that looks fine.
> > However, the proprietary NVidia video driver (I have a Geforce 2 MX card
> > and the newest 1.0.3123 proprietary driver) fails to start the X system.
> > I strongly suspect (although I don't have enough debug info yet) that the
> > acpi patch is the one that makes NVidia fail. The 2.4.19 worked until the
> > acpi patch was applied to it.
>
> I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device
> with and without acpi?



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[P. Christeas]

>
> I read somewhere that NVidia kernel drivers make problems with apm.
> In the syslog appears the following when starting X:
>
> kernel: apm: set display: Power management disabled
That happens at both my Linux boxes (using ACPI). Consider it normal.

>
> It's a few seconds after the modules are inserted, so perhaps SuSE does it
> somewhere in the startup scripts... Have not found it yet...
>
>
> I have a KT133 (Asus A7V) and also a Geforce 2 MX.
Mine must be a Chaintech.

> With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> seconds to start and then consumes as much CPU time as possible. It's an
> adventure to try to hit something with the mouse pointer.
> Everything is funktioning perfectly without ACPI.
> Perhaps an interrupt problem. ACPI shares an interrupt with a bttv card.
> The GeForce has it's own interrupt.
Huh! You just mentioned a magic word: bttv. I do have a bt878 card, I have to 
look if that is the problem after all.

To A. Grover: if the trouble lies in the bttv driver, the kernel will be 
considered broken until both drivers co-exist..

>
> Jochen
>

> > > I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon
> > > XP 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some
> > > ACPI info that looks fine.
> > > However, the proprietary NVidia video driver (I have a Geforce 2 MX
> > > card and the newest 1.0.3123 proprietary driver) fails to start the X
> > > system. I strongly suspect (although I don't have enough debug info
> > > yet) that the acpi patch is the one that makes NVidia fail. The 2.4.19
> > > worked until the acpi patch was applied to it.
> >
> > Ducrot Bruno:
> > I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device
> > with and without acpi?
Please hold a bit as the system in question is my 'stable' one and I don't 
want to debug it too often. I will certainly do that, but it may take a 
couple of days.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Patrick Mochel]

> To A. Grover: if the trouble lies in the bttv driver, the kernel will be 
> considered broken until both drivers co-exist..

Actually, if it's a problem with an nVidia video card, or something that 
is using the proprietary nVidia driver, the driver is considered broken 
and it is nVidia's problem. 

Because their driver is closed-source, kernel developers should not spend 
the time to reverse engineer the driver or attempt to figure out what 
they're trying to do. There are better things to worry about. 

Now, if you see this happening with an open-source driver, then we can 
help..

	-pat



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Jochen Reinwand]

It really looks like it is NVidia's fault. But I don't think that it is not of 
any interest for Linux, that there are problems with NVidia boards!
The GeForce cards are at the moment the most used graphic boards. Everyone who 
wants to have fast 3D support for Linux seems to prefer NVidia boards. A few 
minutes ago a played a deathmatch with Unreal Tournament 2003 Demo and was 
very happy that everything worked fine within Linux. I really don't want to 
miss it ;-)
Perhaps NVidia just has to disable something within acpi like they do with 
apm... or make there driver open source.......

Jochen

Patrick Mochel wrote:
> > To A. Grover: if the trouble lies in the bttv driver, the kernel will be
> > considered broken until both drivers co-exist..
>
> Actually, if it's a problem with an nVidia video card, or something that
> is using the proprietary nVidia driver, the driver is considered broken
> and it is nVidia's problem.
>
> Because their driver is closed-source, kernel developers should not spend
> the time to reverse engineer the driver or attempt to figure out what
> they're trying to do. There are better things to worry about.
>
> Now, if you see this happening with an open-source driver, then we can
> help..
>
> 	-pat



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[P. Christeas]

> > With ACPI enabled X gets slow. I mean REALLY SLOW! It needs up to 20
> > seconds to start and then consumes as much CPU time as possible. It's an
> > adventure to try to hit something with the mouse pointer.
> > Everything is funktioning perfectly without ACPI.
> > Perhaps an interrupt problem. ACPI shares an interrupt with a bttv card.
> > The GeForce has it's own interrupt.
>
> Huh! You just mentioned a magic word: bttv. I do have a bt878 card, I have
> to look if that is the problem after all.
>
> To A. Grover: if the trouble lies in the bttv driver, the kernel will be
> considered broken until both drivers co-exist..
>
> > Jochen
> >
> > > > I have tried the 2.4.20-pre7 + acpi-20020918 patch on a single Athlon
> > > > XP 1.7+, VIA VT8637 KT266 chipset. The system boots and displays some
> > > > ACPI info that looks fine.
> > > > However, the proprietary NVidia video driver (I have a Geforce 2 MX
> > > > card and the newest 1.0.3123 proprietary driver) fails to start the X
> > > > system. I strongly suspect (although I don't have enough debug info
> > > > yet) that the acpi patch is the one that makes NVidia fail. The
> > > > 2.4.19 worked until the acpi patch was applied to it.
> > >
> > > Ducrot Bruno:
> > > I suspect an interrupt trouble.  Could you 'lspci -xxx -vvv' the device
> > > with and without acpi?
>
> Please hold a bit as the system in question is my 'stable' one and I don't
> want to debug it too often. I will certainly do that, but it may take a
> couple of days.
>
>

I managed to do some initial tests to that machine. The raw conclusion is 
that the machine runs (including NVidia-X) when the pci=noacpi is set.

The fact that there is a way (pci=noacpi) to let the NVidia users upgrade to 
2.4.20+acpi means that there is no reason not to merge the ACPI patch anymore.

There is definitely some trouble when ACPI sets the irq's for PCI. As seen in 
the attached files, ACPI maps the nvidia to irq 11 (instead of 10 as in 
noacpi), where other cards are mapped to, also.
The bttv card does work,  even with ACPI. Thus, the problem lies in the 
NVidia driver. It's their call now to fix that. We shall notify them.

One more point is that the 'stable' configuration cannot sleep. Is that 
normal, since the "pci=notacpi" is set? When I
'echo [1|4] > /proc/acpi/sleep'
the speaker beeps, nothing gets logged and nothing happens.


Here's the tests:
I booted 2.4.20-pre7 + acpi 20020918, runlevel 3 (with ACPI irq)
-->"irq-noX.log", "pci-noX.log"
I ran a tv prog (to a remote display, still no X server on the system). The 
bttv was used and I could watch to tv.
-->"irq-noX.2.log"

I re-booted the same (with ACPI irq), runlevel 5. 
The kernel was alive, X was frozen. This is when the system is in trouble:
--> "irq.log",  "pci.log"

I re-booted w/o acpi (pci=noacpi), runlevel 5
System was up, with X running OK
--> "irq-noacpi.log", "pci-noacpi.log"
I started the bttv, watched tv
--> "irq-noacpi.2.log"

Please ask any more question you want.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Pavel Machek]

Hi!
> One more point is that the 'stable' configuration cannot sleep. Is that 
> normal, since the "pci=notacpi" is set? When I
> 'echo [1|4] > /proc/acpi/sleep'
> the speaker beeps, nothing gets logged and nothing happens.

can we remove /proc/acpi/sleep so users don't waste time trying to make 
s3/s4 work in 2.4.x?
								Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Charl P. Botha]

On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
> can we remove /proc/acpi/sleep so users don't waste time trying to make 
> s3/s4 work in 2.4.x?

If swsusp is setup, echoing 4 to /proc/acpi/sleep does of course work on
2.4.  In addition, 5 can be used to switch off and 1 can be used on some
machines as well, all with 2.4.x.  How about a syslogged message rather if
someone tries something with /proc/acpi/sleep that's not supported?

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Pavel Machek]

Hi!

> On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
> > can we remove /proc/acpi/sleep so users don't waste time trying to make 
> > s3/s4 work in 2.4.x?
> 
> If swsusp is setup, echoing 4 to /proc/acpi/sleep does of course work on
> 2.4.  In addition, 5 can be used to switch off and 1 can be used on some
> machines as well, all with 2.4.x.  How about a syslogged message rather if
> someone tries something with /proc/acpi/sleep that's not supported?

Do you think you could produce patch to do just that? printk() on S4 if
not config_software_suspend and printk() on S3 under 2.4.X is the best way
to go. Unfortunately I do not have 2.4.X tree easily available...
								Pavel

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Charl P. Botha]

On Sun, Sep 22, 2002 at 04:31:48AM +0000, Pavel Machek wrote:
> > On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
> > > can we remove /proc/acpi/sleep so users don't waste time trying to make 
> > > s3/s4 work in 2.4.x?
> > 
> > If swsusp is setup, echoing 4 to /proc/acpi/sleep does of course work on
> > 2.4.  In addition, 5 can be used to switch off and 1 can be used on some
> > machines as well, all with 2.4.x.  How about a syslogged message rather if
> > someone tries something with /proc/acpi/sleep that's not supported?
> 
> Do you think you could produce patch to do just that? printk() on S4 if
> not config_software_suspend and printk() on S3 under 2.4.X is the best way
> to go. Unfortunately I do not have 2.4.X tree easily available...

I would like to, but I'm still running acpi 20020726, mostly due to swsusp
and such-like.  Seeing that hard working hackers have graced us with 2.4.18
+ 20020918 + swsusp 12, I am considering upgrading... as soon as I've done
this I could make a patch.  This might take a while, with RealLife(tm)
taking inordinate amounts of time at the moment.

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Shay Elkin]

On Tue, 24 Sep 2002 23:33:34 +0200, Charl P. Botha wrote:

> On Sun, Sep 22, 2002 at 04:31:48AM +0000, Pavel Machek wrote:
>> > On Sun, Sep 22, 2002 at 12:53:10AM +0000, Pavel Machek wrote:
>> > > can we remove /proc/acpi/sleep so users don't waste time trying to
>> > > make s3/s4 work in 2.4.x?
>> Do you think you could produce patch to do just that? printk() on S4 if
>> not config_software_suspend and printk() on S3 under 2.4.X is the best
>> way to go. Unfortunately I do not have 2.4.X tree easily available...
> I would like to, but I'm still running acpi 20020726, mostly due to swsusp
> and such-like.  Seeing that hard working hackers have graced us with
> 2.4.18 + 20020918 + swsusp 12, I am considering upgrading... as soon as
> I've done this I could make a patch.  This might take a while, with
> RealLife(tm) taking inordinate amounts of time at the moment.

Is something along the attached patch is okay, or should it be done in
acpi_suspend() instead? (I don't think acpi_suspend is called from anywhere
else but acpi_system_write_sleep()).

	Shay.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Shay Elkin]

On Wed, 25 Sep 2002 18:26:32 +0300, Shay Elkin wrote:

> Is something along the attached patch is okay, or should it be done in
> acpi_suspend() instead? (I don't think acpi_suspend is called from
> anywhere else but acpi_system_write_sleep()).

I forogot to include the patch. Here:

=== cut here ===

--- drivers/acpi/system.c.orig  2002-09-25 18:14:11.000000000 +0300
+++ drivers/acpi/system.c       2002-09-25 18:09:34.000000000 +0300
@@ -510,10 +511,22 @@
        if (!system->states[state])
                return_VALUE(-ENODEV);
 
-       status = acpi_suspend(state);
-       if (ACPI_FAILURE(status))
-               return_VALUE(-ENODEV);
-
+       switch (state) {
+       case ACPI_STATE_S4:
+#ifdef CONFIG_SOFTWARE_SUSPEND
+               software_suspend_pending();
+               break;
+#endif 
+       case ACPI_STATE_S3:
+               printk("unsupported sleep mode %d", state);
+               break;
+       default:
+               status = acpi_suspend(state);
+               if (ACPI_FAILURE(status))
+                       return_VALUE(-ENODEV);
+               break;
+       }
+
        return_VALUE(count);
 }
 
=== cut here ===

	Shay.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Testing: NVidia closed driver fails.

[Maciek Gorniak]

On nie, 2002-09-22 at 02:53, Pavel Machek wrote:
> Hi!
> > One more point is that the 'stable' configuration cannot sleep. Is that 
> > normal, since the "pci=notacpi" is set? When I
> > 'echo [1|4] > /proc/acpi/sleep'
> > the speaker beeps, nothing gets logged and nothing happens.
> 
> can we remove /proc/acpi/sleep so users don't waste time trying to make 
> s3/s4 work in 2.4.x?

S1 works fine and uses /proc/acpi/sleep. Removing it would be a step
backward...

-- 
Maciek




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf