Re: USB mass storage and ARM cache coherency

[Andreas Mohr]

Hi,

On Tue, Feb 02, 2010 at 05:20:11PM +0000, Catalin Marinas wrote:
> My issues is with both I-D coherency and D-cache aliasing caused by
> pages mapped in both user and kernel space (with different colours). The
> flush_dcache_page() call should target both cases.

Yup, it does, and quite successfully at that (aka "at that point in time we
having nothing any more to worry about, everything dealt with" ;-)


usbcore: registered new interface driver ums-datafab                                                                  
hub 2-1:1.0: state 7 ports 2 chg 0002 evt 0000                                                                        
kobject: 'ums-freecom' (81de0a80): kobject_add_internal: parent: 'drivers', set: 'drivers'                            
hub 2-1:1.0: port 1, status 0101, change 0000, 12 Mb/s                                                                
kobject: 'ums-freecom' (81de0a80): kobject_uevent_env                                                                 
kobject: 'ums-freecom' (81de0a80): fill_kobj_path: path = '/bus/usb/drivers/ums-freecom'                              
usbcore: registered new interface driver ums-freecom                                                                  
kobject: 'ums-jumpshot' (81de0c80): kobject_add_internal: parent: 'drivers', set: 'drivers'                           
CPU 0 Unable to handle kernel paging request at virtual address 0000041c, epc == 800171e8, ra == 801da5dc             
Oops[#1]:                                                                                                             
Cpu 0                                                                                                                 
$ 0   : 00000000 10008000 803b0000 00010000                                                                           
$ 4   : 00000408 8143bc60 0043bc60 00000001                                                                           
$ 8   : 81dd7124 81dd7190 00000004 00000000                                                                           
$12   : 0000003b 80380000 00000002 f2d9b780                                                                           
$16   : a1de4020 803b0000 8037f840 81de7f00                                                                           
$20   : 00000000 81dd7080 80000000 00000000                                                                           
$24   : 00000000 80016bb8                                                                                             
$28   : 81c0c000 81c0da98 a1dd414c 801da5dc                                                                           
Hi    : 00000008                                                                                                      
Lo    : 00000000                                                                                                      
epc   : 800171e8 __flush_dcache_page+0x38/0x120
    Not tainted
ra    : 801da5dc ehci_urb_done+0x178/0x1dc
Status: 10008002    KERNEL EXL
Cause : 00805008
BadVA : 0000041c
PrId  : 00029029 (Broadcom BCM3302)
Modules linked in:
Process swapper (pid: 1, threadinfo=81c0c000, task=81c08480, tls=00000000)
Stack : 81dd7080 00000001 10009000 8033dab8 a1dd8120 a1dd4114 ffffff6a ffffff6a
        81de7f00 a1dd414c a1dd4100 801db39c 05b8d800 00000000 00000018 803a0000
        803a0000 0000054c 00000001 00000000 a1dd8180 81dd7080 00000000 a1dd4100
        00000000 81c0dbb8 00000000 80318d24 81dd7158 81dd7080 81dda004 801deb38
        81dd7158 8004f984 01f63104 0000003c 81c0dc78 8033feb8 00000008 00000042
        ...
Call Trace:
[<800171e8>] __flush_dcache_page+0x38/0x120
[<801da5dc>] ehci_urb_done+0x178/0x1dc
[<801db39c>] qh_completions+0x484/0x554
[<801deb38>] ehci_work+0x438/0xb68
[<801df2bc>] ehci_watchdog+0x54/0x94
[<8003d3ec>] run_timer_softirq+0x1b0/0x268
[<80037fbc>] __do_softirq+0xb8/0x174
[<800380d4>] do_softirq+0x5c/0x98
[<80038244>] irq_exit+0x40/0x88
[<8000e12c>] plat_irq_dispatch+0x60/0x178
[<80001444>] ret_from_irq+0x0/0x4
[<80031de8>] vprintk+0x36c/0x3bc
[<8000a48c>] printk+0x24/0x30
[<80151918>] kobject_add_internal+0x124/0x254
[<80151f80>] kobject_init_and_add+0x40/0x58
[<8018e854>] bus_add_driver+0xdc/0x2b4
[<801902c8>] driver_register+0xe0/0x19c
[<801ce000>] usb_register_driver+0x84/0x118
[<8000d640>] do_one_initcall+0x70/0x1f4
[<80354334>] kernel_init+0xd0/0x140
[<8000fb4c>] kernel_thread_helper+0x10/0x18


Code: 00000000  10800029  3c02803b <8c820014> 14400026  3c02803b  8c83001c  2482001c  14620021
Disabling lock debugging due to kernel taint
Kernel panic - not syncing: Fatal exception in interrupt



Any ideas? To my uncaring mind this would look like __flush_dcache_page()
not being quite so happy with a NULL pointer that it is being served
(although I haven't managed to precisely investigate yet where the
dereferencing offset 0000041c is coming from).

Yes, crash is reproducible (three times on boot already, although some bootup
does make it successfully).

My ehci-q.c has:

       if (usb_pipein(urb->pipe) && usb_pipetype(urb->pipe) != PIPE_CONTROL) {
               void *ptr;
               for (ptr = urb->transfer_buffer;
                    ptr < urb->transfer_buffer + urb->transfer_buffer_length;
                    ptr += PAGE_SIZE)
                       flush_dcache_page(virt_to_page(ptr));
       }

Hmm, OTOH this code seems to postulate that urb->transfer_buffer_length
is that 0x41c from above...
(IOW the code is simply missing an urb->transfer_buffer NULL check)
OTOH there would also be the question whether flush_dcache_page() should
have caught the NULL pointer input...
And then there's the question whether urb->transfer_buffer is allowed to end
up as NULL anyway...



BTW, trying to keep open /dev/dsp by another app when closing the playback app
does not prevent the audio OOPS.


Been seeing a nano-tiny wee bit too many crashes these days,

Andreas Mohr
--
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/