Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

RcarH3 Salvator-xs USB3.0 use the shared external clock of USB2.0 issues #2

Open
jekenpwn opened this issue Aug 26, 2020 · 1 comment
Open

RcarH3 Salvator-xs USB3.0 use the shared external clock of USB2.0 issues #2

jekenpwn opened this issue Aug 26, 2020 · 1 comment

Comments

@jekenpwn
Copy link

Hi renesas team,

We want to USB2.0 and USB3.0 to share using the USB2.0 external clock.
图片

I tried to follow the BSP document (RENESAS_RCH3M3M3NE3_USB3.0H_UME_v2.01.pdf)
However, the USB3.0 host interface just can using the USB2.0 function, and USB3.0 devices will show below errors:
PLS give me some suggestions.

[ 774.606035] usb 10-1: New USB device found, idVendor=067b, idProduct=2731
[ 774.612852] usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber3
[ 774.620101] usb 10-1: Product: USB SD Card Reader
[ 774.625260] usb 10-1: Manufacturer: Prolific Technology Inc.
[ 774.630938] usb 10-1: SerialNumber: ABCDEF0123456789AB
[ 774.652706] usb 10-1: can't set config #1, error -71
ls /v[ 775.673402] usb 10-1: USB disconnect, device number 13
[ 777.661768] usb 10-1: Device not responding to setup address.
[ 777.873709] usb 10-1: Device not responding to setup address.
[ 778.085395] usb 10-1: device not accepting address 14, error -71
[ 779.117685] usb 10-1: Device not responding to setup address.
[ 779.329666] usb 10-1: Device not responding to setup address.
[ 779.541394] usb 10-1: device not accepting address 15, error -71
[ 779.547452] usb usb10-port1: attempt power cycle
[ 781.725687] usb 10-1: Device not responding to setup address.
[ 781.937706] usb 10-1: Device not responding to setup address.
[ 782.149394] usb 10-1: device not accepting address 16, error -71
[ 782.349790] usb 10-1: new SuperSpeed USB device number 17 using xhci-hcd
[ 782.377895] usb 10-1: New USB device found, idVendor=067b, idProduct=2731
[ 782.384699] usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber3
[ 782.391945] usb 10-1: Product: USB SD Card Reader
[ 782.397091] usb 10-1: Manufacturer: Prolific Technology Inc.
[ 782.402787] usb 10-1: SerialNumber: ABCDEF0123456789AB
[ 782.430178] usb 10-1: can't set config #1, error -71
[ 782.617401] usb 10-1: USB disconnect, device number 17
[ 783.241784] usb 10-1: new SuperSpeed USB device number 18 using xhci-hcd
[ 783.270070] usb 10-1: New USB device found, idVendor=067b, idProduct=2731
[ 783.276881] usb 10-1: New USB device strings: Mfr=1, Product=2, SerialNumber3
[ 783.284127] usb 10-1: Product: USB SD Card Reader
[ 783.289272] usb 10-1: Manufacturer: Prolific Technology Inc.
[ 783.294950] usb 10-1: SerialNumber: ABCDEF0123456789AB

BR
Jeken ZHUANG
@CyberAutonomous
Copy link

Hi Jeken,

USB 3.0 on the Salvator-xs is not be enable by default, you need to add USB3.0 node in device tree and re-build kernel, you can refer my changes on kernel configuration looks like to add usb 3.0 firmware and rebuild kernel again:

##Kernel configuration
Device Drivers --->
Generic Driver Options --->
-*- Userspace firmware loading support
(r8a779x_usb3_v3.dlmem) External firmware blobs to build into the kernel binary
(firmware) Firmware blobs root directory

		Device Drivers --->  
			[*] USB support ---->  
				<*> Support for Host-side USB  
				...  
				<*>xHCI HCD (USB 3.0) support  
				-*-Generic xHCI driver for a platform device  
				< >xHCI support for Mediatek MT65xx  
				<*>xHCI support for Renesas R-Car SoCs    

	##USB3.0 clock configuration  
		Device Drivers --->  
			PHY Subsystem --->  
				-*- PHY Core  
				...  
				<*> Renesas R-Car generation 3 USB 2.0 PHY driver  
				<*> Renesas R-Car generation 3 USB 2.0 clock selector PHY driver  
				<*> Renesas R-Car generation 3 USB 3.0 PHY driver  

	##Enable USB Video Class (UVC)  
		Device Drivers --->  
			Multimedia support --->  
				[*] Media USB Adapters  
					[M] USB Video Class (UVC)  
					[*] UVC input events device support (NEW)

Hope this helps

Best regards,
Tai NGuyen.

oleksiimoisieiev referenced this issue in oleksiimoisieiev/linux-bsp Jun 10, 2021
@fhrbata
drm/nouveau: bail out of nouveau_channel_new if channel init fails
a3b7aa3 
Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC
ioctl. This was reported by trinity[1] fuzzer.

[   71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17
[   71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0
[   71.088928] #PF: supervisor read access in kernel mode
[   71.094059] #PF: error_code(0x0000) - not-present page
[   71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0
[   71.104842] Oops: 0000 [#1] SMP NOPTI
[   71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2
[   71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014
[   71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau]
[   71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41
[   71.147074] RSP: 0018:ffffb4a1809cfd38 EFLAGS: 00010246
[   71.152526] RAX: 0000000000000000 RBX: ffff98cedbaa1d20 RCX: 00000000000003bf
[   71.159651] RDX: 00000000000003be RSI: 0000000000000000 RDI: 0000000000030160
[   71.166774] RBP: ffff98cee776de00 R08: ffffdc0144198a08 R09: ffff98ceeefd4000
[   71.173901] R10: ffff98cee7e81780 R11: 0000000000000001 R12: ffffb4a1809cfe08
[   71.181214] R13: ffff98cee776d000 R14: ffff98cec519e000 R15: ffff98cee776def0
[   71.188339] FS:  00007fd926250500(0000) GS:ffff98ceeac80000(0000) knlGS:0000000000000000
[   71.196418] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   71.202155] CR2: 00000000000000a0 CR3: 0000000106622000 CR4: 00000000000406e0
[   71.209297] Call Trace:
[   71.211777]  ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
[   71.218053]  drm_ioctl_kernel+0xac/0xf0 [drm]
[   71.222421]  drm_ioctl+0x211/0x3c0 [drm]
[   71.226379]  ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau]
[   71.232500]  nouveau_drm_ioctl+0x57/0xb0 [nouveau]
[   71.237285]  ksys_ioctl+0x86/0xc0
[   71.240595]  __x64_sys_ioctl+0x16/0x20
[   71.244340]  do_syscall_64+0x4c/0x90
[   71.248110]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   71.253162] RIP: 0033:0x7fd925d4b88b
[   71.256731] Code: Bad RIP value.
[   71.259955] RSP: 002b:00007ffc743592d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
[   71.267514] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd925d4b88b
[   71.274637] RDX: 0000000000601080 RSI: 00000000c0586442 RDI: 0000000000000003
[   71.281986] RBP: 00007ffc74359340 R08: 00007fd926016ce0 R09: 00007fd926016ce0
[   71.289111] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000400620
[   71.296235] R13: 00007ffc74359420 R14: 0000000000000000 R15: 0000000000000000
[   71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod
[   71.365269] CR2: 00000000000000a0

simplified reproducer
---------------------------------8<----------------------------------------
/*
 * gcc -o crashme crashme.c
 * ./crashme /dev/dri/renderD128
 */

struct drm_nouveau_channel_alloc {
	uint32_t     fb_ctxdma_handle;
	uint32_t     tt_ctxdma_handle;

	int          channel;
	uint32_t     pushbuf_domains;

	/* Notifier memory */
	uint32_t     notifier_handle;

	/* DRM-enforced subchannel assignments */
	struct {
		uint32_t handle;
		uint32_t grclass;
	} subchan[8];
	uint32_t nr_subchan;
};

static struct drm_nouveau_channel_alloc channel;

int main(int argc, char *argv[]) {
	int fd;
	int rv;

	if (argc != 2)
		die("usage: %s <dev>", 0, argv[0]);

	if ((fd = open(argv[1], O_RDONLY)) == -1)
		die("open %s", errno, argv[1]);

	if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 &&
			errno == EACCES)
		die("ioctl %s", errno, argv[1]);

	close(fd);

	printf("PASS\n");

	return 0;
}
---------------------------------8<----------------------------------------

[1] https://github.com/kernelslacker/trinity

Fixes: eeaf06a ("drm/nouveau/svm: initial support for shared virtual memory")
Signed-off-by: Frantisek Hrbata <frantisek@hrbata.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
hoailuu pushed a commit that referenced this issue May 24, 2022
PCI: Avoid PCI device removing/rescanning through sysfs triggers a de…
5a3d673 
…adlock

This patch fixes deadlock warning in removing/rescanning through sysfs
when CONFIG_PROVE_LOCKING is enabled.

The issue can be reproduced by these steps:
1. Enable CONFIG_PROVE_LOCKING via defconfig or menuconfig
2. Insert Ethernet card into PCIe CH0 and start up.
   After kernel starting up, execute the following command.
   echo 1 > /sys/class/pci_bus/0000\:00/device/0000\:00\:00.0/remove
3. Rescan PCI device by this command
   echo 1 > /sys/class/pci_bus/0000\:00/bus_rescan

The deadlock warnings will occur.
============================================
WARNING: possible recursive locking detected
4.14.70-ltsi-yocto-standard #27 Not tainted
--------------------------------------------
sh/3402 is trying to acquire lock:
 (kn->count#78){++++}, at: kernfs_remove_by_name_ns+0x50/0xa8

but task is already holding lock:
 (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(kn->count#78);
  lock(kn->count#78);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

4 locks held by sh/3402:
 #0:  (sb_writers#4){.+.+}, at: vfs_write+0x198/0x1b0
 #1:  (&of->mutex){+.+.}, at: kernfs_fop_write+0x108/0x210
 #2:  (kn->count#78){++++}, at: kernfs_remove_self+0xe0/0x130
 #3:  (pci_rescan_remove_lock){+.+.}, at: pci_lock_rescan_remove+0x1c/0x28

stack backtrace:
CPU: 3 PID: 3402 Comm: sh Not tainted 4.14.70-ltsi-yocto-standard #27
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795
ES3.0+ with 8GiB (4 x 2 GiB) (DT)
Call trace:
dump_backtrace+0x0/0x3d8
show_stack+0x14/0x20
dump_stack+0xbc/0xf4
__lock_acquire+0x930/0x18a8
lock_acquire+0x48/0x68
__kernfs_remove+0x280/0x2f8
kernfs_remove_by_name_ns+0x50/0xa8
remove_files.isra.0+0x38/0x78
sysfs_remove_group+0x4c/0xa0
sysfs_remove_groups+0x38/0x60
device_remove_attrs+0x54/0x78
device_del+0x1ac/0x308
pci_remove_bus_device+0x78/0xf8
pci_remove_bus_device+0x34/0xf8
pci_stop_and_remove_bus_device_locked+0x24/0x38
remove_store+0x6c/0x78
dev_attr_store+0x18/0x28
sysfs_kf_write+0x4c/0x78
kernfs_fop_write+0x138/0x210
__vfs_write+0x18/0x118
vfs_write+0xa4/0x1b0
SyS_write+0x48/0xb0

This warning occurs due to a self-deletion attribute using in the sysfs
PCI device directory. This kind of attribute is really tricky,
it does not allow pci framework drop this attribute until all active
.show() and .store() callbacks have finished unless
sysfs_break_active_protection() is called.
Hence this patch avoids writing into this attribute triggers a deadlock.

Referrence commit 5b55b24 ("scsi: core: Avoid that SCSI device
removal through sysfs triggers a deadlock")
of scsi driver

Signed-off-by: Tho Vu <tho.vu.wh@renesas.com>
Signed-off-by: Hoang Vo <hoang.vo.eb@renesas.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@CyberAutonomous @jekenpwn