On Fri, 6 Mar 2020, [iso-8859-1] M� Rullg� wrote: > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > > > On Thu, 5 Mar 2020, M� Rullg� wrote: > > > >> While trying to capture some USB traffic, this happened: > >> > >> 8<--- cut here --- > >> Unable to handle kernel paging request at virtual address ffeff000 > > ... > >> [<c069e0a8>] (memcpy) from [<c050c88c>] (mon_copy_to_buff+0x4c/0x6c) > >> [<c050c88c>] (mon_copy_to_buff) from [<c050cd2c>] (mon_bin_event+0x480/0x7b8) > >> [<c050cd2c>] (mon_bin_event) from [<c050ade4>] (mon_bus_complete+0x50/0x6c) > > ... > > > >> It is easily reproducible. What can I do to narrow down the cause? > > > > What kind of USB traffic were you monitoring? Isochronous? > > Scatter-gather? > > > > Can you add printk statements in drivers/usb/mon/mon_bin.c: > > mon_bin_get_data() to determine which of the pathways was used for > > calling mon_copy_buff() and what the values of the arguments were? > > OK, I added a printk to mon_bin_get_data(), and the bad call has > offset=4736, length=4096 urb->num_sgs=0 urb->transfer_flags=0x281, > urb->transfer_buffer=0xffefee00. The values seem reasonable enough, except for transfer_buffer. > I guess the question now is how transfer_buffer got assigned that value. Depending on how your kernel is configured (in particular, whether CONFIG_MUSB_PIO_ONLY is enabled), it might be assigned in musb_alloc_temp_buffer() (in drivers/usb/musb/musb_host.c) or usb_sg_init() (in drivers/usb/core/message.c). With a little more detective work you ought to be to determine which pathway is being used and what its important values are. I wouldn't be surprised to learn that 0xffefee0 was the value from sg_virt(sg) in usb_sg_init(). Alan Stern
