Re: Turning off camera also kills card reader on EeePC 900

Sitsofe Wheeler
2008-09-15T21:41:18Z

Alan Jenkins wrote:
> Sitsofe Wheeler wrote:
>>
>> Alan Jenkins wrote:
>>
>>> The "HC died" message is interesting. Sounds like the controller for
>>> these two USB devices stops working. Maybe try unloading and reloading
>>> the ehci module? I don't think I can help any more though.
>>
>> I compiled the kernel without module support so unless there's some
>> sysfs trick that can be done...
>>
> Well, since you ask :-P. Here's an equivalent incantation. I hope it's
> not too brittle. Don't forget to unmount the SD card first.
>
> cd /sys/module/ehci_hcd/drivers/pci:ehci_hcd
> echo -n 0000:00:1d.7 | sudo tee unbind; echo -n 0000:00:1d.7 | sudo tee
> bind
>
> The magic number is the PCI ID for the USB Host Controller, taken from
> your error message.
>
> If the manual "bind" works you should then see a symlink, "0000:00:1d.7"
> in that directory.

Unfortunately when the SD card disappears so do the typical shell
commands (as that's the device I'm booting off). I was left having to
use source to look at the contents of things in /sys when the SD card died.

>>> - It might be necessary to compare with the pre-installed OS
>>> - Is the pre-installed kernel any better (files might be under
>>> /proc/acpi/asus instead)? I guess you might not have the time or
>>> resources to test that though.
>>
>> The Xandros 2.6.21.4-eeepc install has the following files in
>> /proc/acpi/asus/
>> brn camera cardr cpufv disp hdps init type wlan
>>
>> I have no idea what cpufv, disp, hdps, init or type are. Doing echo 1
>> > camera && echo 0 > camera under this setup does NOT disappear the SD
>> card.
> Rats. So there is some secret the mainline driver is missing :-(.

Looks it.

>> Additionally brn seems to really represent the current LCD brightness
>> (whereas it does not on a stock kernel and seems to always be set to -19)
> It might have bitrotted on stock kernels? The newer interface is under
> /sys/class/backlight.

Ah I see - the stuff in there is correct. Does that mean that brn should
quietly disappear now this alternative interface is present?

>> and the hotkeys (e.g. for brightness) seem to respond far more quickly
>> than the stock kernel too.
> Heh heh. I know all too much about that. It's a problem with the ACPI
> Embedded Controller driver, a hardware bug which triggered a regression
> in 2.6.25.
>
> I'm currently running... it claims to be 2.6.27-rc4 but it might be
> 2.6.27-rc5 or something in between... which includes a fix. I'm not
> confident that they haven't broken it again since then. The problem is
> there are just so many different types of buggy EC's. "Fixes" for some
> buggy hardware break other buggy hardware. Very nasty.

Sigh. I think I've seen those posts (
http://thread.gmane.org/gmane.linux.acpi.devel/32779/focus=33442 ? ) and
hadn't fully comprehended what you were fighting against. Doesn't this
just lead to DMI based quirks?

>>> - The source code is... a 2Gb+ rar file someone would have to download
>>> and pick apart.
>>
>> Does anyone know if the archives on
>> http://support.asus.com/download/download_item_4.aspx?product=20&model=Eee%20PC%20900/Linux&SLanguage=en-us&os=5
>> (release dates appear to be 5th September 2008) are actually any
>> different?
>>
> Why do you say that? Are the filesizes suspiciously identical?

I wish I could say - for some reason every option to download the source
code in the dropdown on http://eeepc.asus.com/global/download.htm goes
to a 404 page. I can't say I'm looking forward to downloading 2.6Gbytes
on this network connection regardless.

--
Sitsofe