It's a bug either way (a regression from the 701 hardware).  I think you
should be able to isolate it.

Firstly, I understand these kill-switches are supposed to be persistent
over reboots.  You should check that the SD card stays disabled when you
reboot.

Next, these settings are also exposed in the BIOS configuration screen,
right?  If it's the same as my 701 then the BIOS will have a separate
option for disabling the cardreader.  So you could see if the platform
driver "camera" switch is simply disabling and enabling the two switches
together.

Or if there's only a BIOS option for the camera, and not the SD card,
then you should test whether it disables the SD card.

Regards
Alan
--

[ message continues ]

The settings are persistent (so changing a camera value that is 0 to 1 
will show the camera as being enabled if you go to the BIOS). However 

The option for disabling the cardreader is indeed separate from the one 
to disable the camera. There is, however a switch for disabling USB in 

OK there are separate switches in the BIOS for disabling (among other 
things) the Camera, CardReader, and USB Ports.

Doing echo 0 > camera when camera is already 0 does nothing. The value 
in cardr remains 1.
Doing echo 0 > camera when camera is 1 seemingly results in the SD card 
disappearing too (ehci_hcd 0000:00:1d.7: HC died; cleaning up). cardr 
value remains 1. The CardReader and USB Ports options will be in the 
enabled state when looking in the BIOS after rebooting. The Camera 
option will be in the disabled state in the BIOS.
Doing echo 1 > camera after the SD card  has disappeared (but before 
rebooting) in the above step will result in the SD card seemingly coming 
back at a different address and the kernel reporting 'irq 23: nobody 
cared (try booting with the "irqpoll" option)' and a usb_hcd_irq backtrace.
Doing echo 0 > cardr when cardr is 1 results in the SD card disappearing 
and an ext3 error being printed on the console. The CardReader option 
will be in the disabled state in the BIOS after rebooting.
Doing echo 0 > camera after the SD card  has disappeared (but before 
rebooting) in the above step will result in 'ehci_hcd 0000:00:1d.7: HC 
died; cleaning up' being printed.

-- 
Sitsofe | http://sucs.org/~sits/
--

[ message continues ]

Ok.  So the platform driver settings do match those in the BIOS.  My
guess would be the platform driver is fine and the BIOS screws up.

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 CC: the maintainer, maybe Corentin has other reports or ideas

- Are any BIOS upgrades available?  None of them mention this problem,
but the descriptions often miss out details. [1][2]

- 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 source code is... a 2Gb+ rar file someone would have to download
and pick apart.

Regards
Alan

[1] Asus downloads <http://eeepc.asus.com/global/download.htm>
[2] BIOS update howto <http://wiki.eeeuser.com/howto:updatebios>
--

[ message continues ]

On Mon, Sep 15, 2008 at 3:37 PM, Alan Jenkins

The issue also exist on 701 on 2.6.27-rc7 so the regression is in the
kernel not in the hardware

Disabling camera :

ehci_hcd 0000:00:1d.7: HC died; cleaning up
hub 1-0:1.0: hub_port_status failed (err = -19)
hub 1-0:1.0: connect-debounce failed, port 8 disabled
usb 1-8: USB disconnect, address 3
usb 1-5: USB disconnect, address 2

Enabling it again :

irq 23: nobody cared (try booting with the "irqpoll" option)
Pid: 0, comm: swapper Not tainted 2.6.27-desktop-0.rc6.3.2mnb #1
 [<c0380022>] ? printk+0x18/0x1e
 [<c016bdc7>] __report_bad_irq+0x27/0x90
 [<c016c08c>] note_interrupt+0x25c/0x290
 [<c016aef9>] ? handle_IRQ_event+0x39/0x70
 [<c016c63b>] handle_fasteoi_irq+0xab/0xd0
 [<c0106eb0>] do_IRQ+0x40/0x80
 [<c01048bf>] common_interrupt+0x23/0x28
 [<c0150eba>] ? tick_nohz_stop_sched_tick+0xca/0x350
 [<c01027aa>] cpu_idle+0x2a/0x130
 [<c0372b3e>] rest_init+0x4e/0x60
 =======================
handlers:
[<e005b800>] (usb_hcd_irq+0x0/0x90 [usbcore])
[<e005b800>] (usb_hcd_irq+0x0/0x90 [usbcore])
Disabling IRQ #23

Reloading ehci_hcd

ehci_hcd 0000:00:1d.7: remove, state 0
usb usb1: USB disconnect, address 1
ehci_hcd 0000:00:1d.7: USB bus 1 deregistered
ehci_hcd 0000:00:1d.7: PCI INT A disabled
usb 4-1: new full speed USB device using uhci_hcd and address 2
usb 4-1: configuration #1 chosen from 1 choice
scsi3 : SCSI emulation for USB Mass Storage devices
usb 4-1: New USB device found, idVendor=0951, idProduct=1606
usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=4
usb 4-1: Product: UB6225
usb 4-1: Manufacturer: ENE
usb 4-1: SerialNumber: 146030377350
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usb 5-2: new full speed USB device using uhci_hcd and address 2
usb 5-2: configuration #1 chosen from 1 choice
uvcvideo: Found UVC 1.00 device <unnamed> (eb1a:2761)
uvcvideo: Using UVC_MAX_ISO_PACKETS=40
input: UVC Camera (eb1a:2761) as /class/input/input10
usb 5-2: New ...
[ message continues ]

On the bright side, that means more people should have the hardware to 
test it on (including me :-).

I've certainly used the camera enable/disable at some point.  But I 
could have missed the error message, and frankly I don't use the camera 
or cardreader very often.  I'll have a bash at it tomorrow.

Sitsofe says it reproduced on kernel.org 2.6.21 (presumably with an 
out-of-tree eeepc module).  So I guess this isn't a simple git-bisect 
job - more thinking required...

Thanks
Alan
--

[ message continues ]

Er turns out I might be mistaken wrt to 2.6.21. I do have a 2.6.21 
kernel but it turned out I don't have an eeepc/asus-acpi module. As I'm 
going away for the next few days I won't have an opportunity to test 
this soon.

The problem also seems to have vanished in Ingo's linux-tip ...

-- 
Sitsofe | http://sucs.org/~sits/

--

[ message continues ]

[ deleted ]

something like this happened to me on the latest Fedora 9 kernel
when I turned off my USB hard drive. The second USB drive got killed
by this until ehci reload. 
The F9 kernel is reported tainted (dont know the reason), perhaps can
somebody enlighten me:

Sep 23 19:06:12 kipc2 kernel: Modules linked in: vfat fat reiserfs
usb_storage nls_utf8 cifs nfs lockd nfs_acl tun ipt_MASQUERADE
iptable_nat nf_nat bridge bnep rfcomm l2cap bluetooth ib_iser rdma_cm
ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi
scsi_transport_iscsi fuse sunrpc ipv6 nf_conntrack_netbios_ns
nf_conntrack_ftp ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state
nf_conntrack iptable_filter ip_tables x_tables loop dm_multipath
snd_usb_audio snd_intel8x0 snd_ac97_codec snd_seq_dummy snd_bt87x
ac97_bus snd_seq_oss snd_seq_midi_event snd_seq snd_pcm_oss
snd_mixer_oss snd_pcm sr_mod cdrom tvaudio snd_usb_lib snd_rawmidi
snd_seq_device snd_hwdep bttv videodev v4l1_compat snd_timer i915
firewire_ohci firewire_core snd ir_common compat_ioctl32 v4l2_common
pata_sil680 ppdev crc_itu_t i2c_i801 tg3 parport_pc videobuf_dma_sg
videobuf_core btcx_risc tveeprom drm i2c_algo_bit i2c_core parport
soundcore iTCO_wdt iTCO_vendor_support pcspkr snd_page_alloc sg floppy
dm_snapshot dm_zero dm_mirror dm_log dm_


Sep 23 19:05:31 kipc2 kernel: usb 1-5: USB disconnect, address 22
Sep 23 19:05:31 kipc2 kernel: usb 1-3: reset high speed USB device using ehci_hcd and address 21
Sep 23 19:05:31 kipc2 kernel: usb_storage: can't resubmit intr, 0000:00:1d.7-3/input0, retval -19
Sep 23 19:05:31 kipc2 kernel: ehci_hcd 0000:00:1d.7: HC died; cleaning up
Sep 23 19:05:31 kipc2 kernel: usb 1-3: USB disconnect, address 0
Sep 23 19:05:32 kipc2 kernel: usb 1-3: device not accepting address 21, error -22
Sep 23 19:05:32 kipc2 kernel: hub 1-0:1.0: cannot reset port 3 (err = -19)
Sep 23 19:05:32 kipc2 kernel: sd 24:0:0:0: [sde] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
Sep 23 19:05:32 kipc2 kernel: end_request: I/O ...
[ message continues ]