login
Search
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 --
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/ --
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> --
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 ...
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 --
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/ --
[ 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 ...