Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: > On Thu, 5 Mar 2020, Måns Rullgård 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. I guess the question now is how transfer_buffer got assigned that value. -- Måns Rullgård
