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

[Sitsofe Wheeler]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/