[lkml]   [2008]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Turning off camera also kills card reader on EeePC 900
    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 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 ( ? ) 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
    >> (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 goes
    to a 404 page. I can't say I'm looking forward to downloading 2.6Gbytes
    on this network connection regardless.


     \ /
      Last update: 2008-09-15 23:43    [W:0.027 / U:25.644 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site