Bug 141947

Pavel, can you look into this please?

Timo did some work on the additional acpi modules and special laptop keys... any idea Timo?
Edwards: Do you still have a free partition to test whether you get a simliar failure on current Open Suse 10.1 distribution?
Please also add full dmesg output.

Created attachment 62456 [details]
Fresh full dmesg output

I have room if I resize the Linux partition - will the yast2 partition manager do that on the fly?  I think I could resize the WinXP partition another 4GB to create room - I'll start work on that while you look this over.

What kind of ugly driver is sonypi.c?
For me it is doing the same/similar stuff sony_acpi should do, but reads/writes are predefined IO adresses instead of using ACPI abstraction?

Ahhh, the author is the same...
Does someone know who loads this modules? Shouldn't sony_acpi be preferred?

I note that /etc/modprobe.conf references sonypi thus:

alias char-major-10-250  sonypi
options sonypi           minor=250

and that sony_acpi does not appear.  Should I try sony_acpi, instead, and would it also use 10/250?

Ed

Hmm, Timo told me that those extra acpi modules that are not included in mainline kernel, will not be available for 10.1. So possibly it may be even better to use sonypi. Not sure how much functionality that one has, seems as if it maps some special keys to some key codes?
Could you also try whether you have these problems on a Open Suse 10.1 (a lot changed in this module) if you still have a partition free.
I better assign this one to Timo, don't know much about the special keys on a sony.

(In reply to comment #6)
> Hmm, Timo told me that those extra acpi modules that are not included in
> mainline kernel, will not be available for 10.1.

not true. We will either create a km_acpi_extra package or (again) patch our kernel, this is an ongoing discussion with the kernel team.

I'm installing OpenSUSE 10.1 Alpha 4 on the Sony, now - note that I had to use the "Installation - ACPI Disabled" option - selecting the default installation option resulted in a freeze of the system - blank screen, no activity, required power reset.  But, with ACPI Disabled, the install is proceeding.

This is just FYI - it's a pain, and I'd rather have the ACPI enabled by default - but I thought this was relevant enough to this discussion to report it...

Ed

Argggh, this is sever!
The next OpenSuse version should have more ACPI warning/error output...
Would be nice if you could update at least the kernel and try to boot in text mode and tell us the last lines where it hangs.

However this could be hard to identify and to fix remotely or via bugzilla.
Seife: Have you already tried to install a recent Alpha on your Sony?

Timo or whoever is still working for a kernel module package for the sony_acpi driver for 10.1. However the freeze with ACPI enabled is much more sever, let's figure out this one first.

Re-ran the CD1 install (default, with ACPI enabled).

Put display in text mode so I could see it run.

Kernel loaded and delivered an 
Oops:  0000 [#1]
Modules linked in:
CPU: 0
EIP:    0060:[<c0381c3b>]   Not tainted VLI
EFLAGS:  00010082  (2.6.15-rc5-git3-2-default)
EIP is at unreachable_devices+0x6b/0x90
eax: 000003a9  ebx: e0000000  ecx: e0000173  edx: 00002000
esi: 00000000  edi: 00000000  ebp: 00000217  esp: df681fb8
ds:  007b  es:  007b  ss:  0068
Process swapper (pid: 1, threadinfo=df680000 task=dfe79a50)
Stack:  25908086 c039443c df680000 00000000 00000000 c0381cc0 c02f4c7d c036480d
        c01002a0 00000000 00000000 c01002cc c01012f9 00000000 00000000 00000000
        00826042 00000000

Call Trace:
c0381cc0 pci_mmcfg_init+0x60/0x70
c036480d do_initcalls+0x4d/0xb0
c01002a0 init+0x0/0x140
c01002cc init+0x2c/0x140
c01012f9 kernel_thread_helper+0x5/0xc
Code: c0 74 2f 89 fa c1 e2 0f 09 c2 3b 15 64 6c 3e c0 74 19 8b 0d 58 25 31 c0 b8
....
This is hand typed (rather than copyed from a boot log) but I think it's accurate.

Ed

this is a shot in the dark: try booting with "pci=noacpi" commandline. Maybe we have a "ACPI misconfigures pci" bug again....

Okay - this is getting worse.

I've installed 10.1a with acpi disabled, but after the installation is complete, whe the user logs in, kde reports "Could not start kstartupconfig.  Check your installation." in what looks like a basic X-windows alert box ("okay" button in lower left corner of window).  No window manager, etc.  The X cursor is there and responds, but of course KDE isn't there.  Testing other window managers, TWM works, as does FailSafe.

Looking at boot.msg, see
<4>PCI: No IRQ known for interrupt pin A of device 0000:00:01.0.  Please try using pci=biosirq.


then further down
<4>pcie_portdrv_probe->Dev[2591:8086] has invalid IRQ.  Check vendor BIOS

I'll try booting the installation disk with pci=noacpi, and then again with "pci=biosirq" to see what happens...

the system is unuseable without KDE.  No, I didn't install GNOME.

Booting the default installation option from the CD1 install disk, into text mode with pci=noacpi resulted in the same Oops, call trace 

pci_mmcfg_init+0x60/0x70
do_initcalls+0x4d/0xb0
...

same as before.  Stack is the same, except the next to last entry is all zeros instead of 00826042, and the last entry is 00000049 instead of all zeros.

Booting the default installation option from the CD1 install disk, into text mode with pci=biosirq results in a very similar Oops.  Registers are a little different, but the call stack looks the same.  Yep - the last two stack entries are different, but all else is the same (registers, threadinfo, task, and other stack values).

From BIOS Setup on the box:

BIOS Version:     R0103V0
EC BIOS Version:  RK103V0
Video BIOS Version: V0N44_55

Machine Name:     VGN-S560P
Total Memory:     512MB

I don't figure you need the UUDI nor Serial Number

LCD Expansion is "NO" on the Advanced page.

And, once again, though this is being reported under a SuSE Linux 10 bug, we're talking about the OpenSuSE 10.1 Alpha 4 installation kernel - the one that is the "normal" Installation kernel from the CD1 bootable disk.

Okay - so the issue isn't restricted to OpenSuSE 10.1a4 -

Attempting to use the default installation mode for SuSE Linux Pro 9.3, the default installation kernel loads, I can escape the splash screen and watch it's progress until it reaches

"Activating PCMCIA devices..."

at which point the cursor disappears and the system is frozen.

At this point I'm going back and trying my SUSE Linux 10.0 install disk to see how I got that installed - did I have to turn acpi off (that would explain the problems sonypi is having ;-)

Nope - the SuSE Linux 10.0 default install boots and runs okay.  But, with the acpi problems reported at the beginning of this thread.

summary:

Sony notebook VGN-S560P, with BIOS details listed above

SuSE Linux Pro 9.3 default installation - freezes trying to activate PCMCIA devices

SuSE LInux 10.0 (Final) - default installation works, but acpi functionality (buttons support, dim/bright display) don't work

SuSE LInux 10.1 Alpha4 - default installation issues a kernel Oops (detailed above).

SuSE Linux 10.1 Alpha4 - acpi disabled installation proceeds, but KDE fails to come up.

Ed

(In reply to comment #12)
> Okay - this is getting worse.
> 
> I've installed 10.1a with acpi disabled, but after the installation is
> complete, whe the user logs in, kde reports "Could not start kstartupconfig. 
> Check your installation." in what looks like a basic X-windows alert box
> ("okay" button in lower left corner of window).  No window manager, etc.  The X
> cursor is there and responds, but of course KDE isn't there.  Testing other
> window managers, TWM works, as does FailSafe.

see
http://www.opensuse.org/Bugs:Most_Annoying_Bugs#SUSE_Linux_10.1_Alpha4

(In reply to comment #18)
> Nope - the SuSE Linux 10.0 default install boots and runs okay.  But, with the
> acpi problems reported at the beginning of this thread.
> 
> summary:

> SuSE LInux 10.0 (Final) - default installation works, but acpi functionality
> (buttons support, dim/bright display) don't work

the sony_acpi module seems loaded on 10.0 (otherwise you would not have the brightness file). sonypi seems to be nonfunctional, but maybe it interferes with sony_acpi. You could try to remove the module (move it from /lib/modules/...../sonypi.ko to /tmp), reboot and try if setting the brightness works after that. On the sony i used, i had no luck with special buttons at all, but at least setting the brightness worked.

Generally, sony machines seem to be a big mess and the vendor refuses to give any support. Something to consider when buying a new machine. There are definitely vendors whose machines don't give you so much trouble ;-)

Okay - I'm back to SuSE Linux 10.0

Have commented out the sonypi entry and it's associated argument from /etc/modprobe.conf.

I know ACPI is working because when I close the lid it starts the screen saver, just as I asked.

There is a /proc/acpi/sony directory with two 'file' entries:  brightness and brightness_default.

when I echo 4 > brighness
nothing happens.

when I press fn-F5 (dimmer) nothing happens

There is a /var/log/acpid file here.  It contains event notifications about the LID0 event closing and opening.  There is 1 client rule loaded, here.

The dmesg file indicates that the Sony Notebook Control Driver v0.2 successfully installed, following notices of what look like ACPI event registration entries for

ACAD, BAT1, LID0 and PWRB.

Those things all seem to work, too.

So, the sonypi messages are gone (good, cause it didn't get loaded).  But no brighness control, here.

Ed

try reading out the brightness file with "cat" - it might be that 4 is just the default so you don't see any changes. IIRC sony_acpi takes values from 1 to 8, so try echoing 1 and 8 into it, this should give a recognizable difference.
If we cannot get this to work in 10.0 there is not too much hope for 10.1 since the sony module has not changed (it might benefit from general acpi fixes though, so not everything is lost :-)

yes, I use cat to read out brightness - it's usual value is 8.  Changing it makes no difference.

I also found where the sonypi module is used - there's a Sony Vaio Laptop control center system configuration applet for looking at battery capacity, how many batteries you have loaded, etc. that uses sonypi instead of sony_acpi.

Finally, I realize that I do, indeed, have acpi=no on the kernel boot line, which is odd, since powersaved does, indeed, report battery stuff correctly, and the lid  switch works.

For today, I'll try modulating the kernel command line acpi value to see what breaks.  My guess is that the install of 10.0 froze up with acpi enabled at all...

Ed

(In reply to comment #23)

> Finally, I realize that I do, indeed, have acpi=no on the kernel boot line,
> which is odd, since powersaved does, indeed, report battery stuff correctly,
> and the lid  switch works.

Okay, that's not true - I just reviewed the boot line and acpi is enabled on 10.0.  I had to turn it off on both 9.3 and 10.0.42, but 10.0 has it on.  Sorry for the confusion - 

AFAICT, sonypi will not work on your machine, it only worked on older models.
"acpi=no" will have no effect, only "acpi=off" will switch acpi off, so it is no wonder that lid switch and battery reporting works.

For sony_acpi not working, you could try to contact the author of this module, Stelian Pop directly via his website http://www.popies.net/.
Maybe it is just another model string or AML method that needs to be added to the driver; i simply don't know that.

Thank you, Stefan - I'll try Stelian Pop's site.

Shall we close this one bug out?  If the Oops issues reported above need to live on, they should be associated with a 10.1 bug, not this one.

Thanks for the detailed infos.
Just leave it open, I will change the subject and see, whether I can fix the pci=noacpi requirement. Options like this could result in later hangs or non-working devices like you reported with your pcmcia device.
Even worse, users are confused if they put in the installation CD and end up in an early freeze..., specially when it's the machine they like to access the internet with and can't google.
Would be nice if you eventually could test a kernel without pci=noacpi in some days if I can come up with something.
However, this could take some time, workload grew the last days ...

np - I'll be happy to try later versions of the kernel and to help out.  I have a small partition dedicated to 10.1 with which to test.

I've also pinged Stelian Pop to see if the trouble I had with sonypi can be addressed.  It looks to me as though sonypi should (and generally, it does) work with sony_acpi, but that it's sonypi_enable call is failing (that's what is causing the 4 error messages I'm seeing in syslog), and will report back what we find.

Keep me in the loop.

Status update:

1) running 2.6.15-rc5-git3-2-default kernel, acpi=off is still required, but...

2) sonypi loaded and the kde Sony Laptop applet works, giving correct Battery and AC Power indications, and

3) Stelian Pop (stelian@popies.net) directed me towards http://www.acc.umu.se/erikw/program/smartdimmer.0.1.tar.bz2 which does command the brighness of the display up and down

The smartdimmer README indicates its changes will be incorporated into the nvclock "in the near future".

So, the Sony laptop brightness can be commanded (but I just noticed my mouse cursor disappeared...will test further).

sonypi works on 10.1 (without issuing error messages to syslog) (it now detects a type 3 model, so the hardware has changed).

And 10.1 definitely needs acpi=off to work.  

I've downloaded the kotd from 11 Jan but haven't tested it, yet.

FYI.

Confirming that SuSE 10.1 (2.6.15-rc5-git3-2-default) loses it's mouse cursor when you use smartdimmer to dim and brighten the display.  Refreshing the desktop doesn't recover it.  SuSE 10 (linux-2.6.13-15.7-default), though, doesn't lose the mouse.

Ah, I'm not at all sure I have the nVidia proprietary drivers installed on 10.1, and I know I do on 10.0.  Since online updates aren't working on 10.1, yet, I hadn't pulled them down.

Well, the 10.0 fetchnvidia.sh fails to run on the 10.1 rc5-git3 kernel (it fails to successfully build a kernel interface for the kernel, and it fails the compilation - but that's a separate issue).

So, I can't test the nVidia proprietary driver on 10.1 (given what I know, now).

'nuf.

Any word on the status on this?  I've tried the network boot of the OpenSuSE 10.1 Beta1, but the install failed as it tried to find suggested software packages, so I'm downloading the 5 CDs, now.

Any progress on this to report, or are y'all waiting on me for something?

Ed

For the pci=noacpi issue, it is worth to wait a bit.
There have been a lot modifications in the ACPI tree, that have not yet been commited. We are currently discussing which patches are necessary and safe to add and which will not make it in SL 10.1...
For the pci stuff, it is likely that it is not included as it potentially may break more machines than it heals. But I cannot say anything for sure at the moment.

regarding the brightness setting, i have heard rumors that there are new sony models which are not (yet?) supported by the sony_acpi module, but unfortunately i do not know any details.

for your heard Brightness is working fine with a Vaio VGN-A197 but not the additional Funktionkeys. Only with ke keyboard buttons.

There changed some things in acpi code, it's worth to try the latest Beta kernel for 10.1 from here:
ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/kernel-default.i586.rpm

If it does not work, it's hard to debug the pci=noacpi stuff...
Can you boot the kernel with sysreq=1 option and then hit Sysrq-T button and try to catch the latest invoked function(s).
Seife, your vaio boots without pci=noacpi?

Closing for now as there hasn't been an answer for a longer time.
Please reopen if you still see the bug and you can provide info.
Best would be a serial console output.

I can't tell you how happy I am to have read about the problems with Beta 4, and to know that I just didn't have time to check this out, then ;-)

I'm happy to report that I'm installing Beta8 on the system now, and doing so without invoking the installer without ACPI, which is to say, I'm running the normal installation image, presumably with ACPI included.

Further, the installation completed without incident, the system is booted and appears to be working fine.  dmesg has lots of satisfying ACPI messages in it.

I think you fixed it.

Thanks.

Reopen to see if I can close it "fixed".

Beta8 is working fine.

cool, thanks for the report.
I have heard rumours about a driver for newer sony models which might help setting the brightness etc. on your machine, but don't have any details, sorry. But there seems to be still some hope :-)