Panic at USB drive plugging in
Hi all, as personal preference I compiled kernel with drivers as module as possible. Recently I found that plugging in USB drives causes kernel to panic. But it does not happen when booting with GENERIC kernel which has USB drivers compiled in. panic screenshot: http://goo.gl/pIIDaF back trace: http://goo.gl/ww4yy6 the kernel is compiled: FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 the back trace looks like devd and something had timing issues. Any ideas? Regards, Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic at USB drive plugging in
On 07/23/13 17:12, Jia-Shiun Li wrote: Hi all, as personal preference I compiled kernel with drivers as module as possible. Recently I found that plugging in USB drives causes kernel to panic. But it does not happen when booting with GENERIC kernel which has USB drivers compiled in. panic screenshot: http://goo.gl/pIIDaF back trace: http://goo.gl/ww4yy6 the kernel is compiled: FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 the back trace looks like devd and something had timing issues. Any ideas? Hi, This looks like a CAM/SCSI problem and not directly USB stack problem. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic at USB drive plugging in
On 23.07.2013 19:07, Hans Petter Selasky wrote: On 07/23/13 17:12, Jia-Shiun Li wrote: Hi all, as personal preference I compiled kernel with drivers as module as possible. Recently I found that plugging in USB drives causes kernel to panic. But it does not happen when booting with GENERIC kernel which has USB drivers compiled in. panic screenshot: http://goo.gl/pIIDaF back trace: http://goo.gl/ww4yy6 the kernel is compiled: FreeBSD 4cbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r253395: Fri Jul 19 15:20:08 CST 2013 jsli@4cbsd:/usr/obj/usr/src/sys/Minimal amd64 the back trace looks like devd and something had timing issues. Any ideas? This looks like a CAM/SCSI problem and not directly USB stack problem. It seems crashed inside the CAM sg driver, that is not part of GENERIC kernel. Are you using it is some way? -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic at USB drive plugging in
On Wed, Jul 24, 2013 at 12:13 AM, Alexander Motin wrote: > On 23.07.2013 19:07, Hans Petter Selasky wrote: >> This looks like a CAM/SCSI problem and not directly USB stack problem. > > It seems crashed inside the CAM sg driver, that is not part of GENERIC > kernel. Are you using it is some way? > No. I do not use it at all. kernel conf & loader.conf: ---8<-- # # GENERIC -- Generic kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/amd64/conf/GENERIC 252867 2013-07-06 07:49:41Z delphij $ cpu HAMMER ident Minimal options MSGBUF_SIZE=327680 makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel # Debugging support. Always need this: options KDB # Enable kernel debugger support. # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use this instead: options DDB # Support DDB. options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control device cpufreq # Bus support. device acpi device pci # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver options VESA # Add support for VESA BIOS Extensions (VBE) device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for th
Re: Panic at USB drive plugging in
On 23.07.2013 21:28, Jia-Shiun Li wrote: On Wed, Jul 24, 2013 at 12:13 AM, Alexander Motin wrote: On 23.07.2013 19:07, Hans Petter Selasky wrote: This looks like a CAM/SCSI problem and not directly USB stack problem. It seems crashed inside the CAM sg driver, that is not part of GENERIC kernel. Are you using it is some way? No. I do not use it at all. cam.k kernel module includes all existing periph drivers in one bundle. Loading cam.ko you are probably getting sg driver also, that triggers reported issue. You may try to rip out sg with single line hack to module's Makefile. The real fix require looking closer on sg, which I never used. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic at USB drive plugging in
On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin wrote: > cam.k kernel module includes all existing periph drivers in one bundle. > Loading cam.ko you are probably getting sg driver also, that triggers > reported issue. You may try to rip out sg with single line hack to module's > Makefile. The real fix require looking closer on sg, which I never used. > Indeed. Test result did confirm that if sg is not included in cam.ko USB drives will not cause kernel to panic. Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Panic at USB drive plugging in
2013/7/24 下午10:26 於 "Jia-Shiun Li" 寫道： > On Wed, Jul 24, 2013 at 4:02 AM, Alexander Motin wrote: > > cam.k kernel module includes all existing periph drivers in one bundle. > > Loading cam.ko you are probably getting sg driver also, that triggers > > reported issue. You may try to rip out sg with single line hack to > module's > > Makefile. The real fix require looking closer on sg, which I never used. > > > > Indeed. Test result did confirm that if sg is not included in cam.ko > USB drives will not cause kernel to panic. > > Hi all, turns out, it may be conflicts between assumed and actual sg usage. The sg driver specifically assumes a write-read sequence. If a read comes first it will cause sg to panic at msleep() in sgread. In my case the process is hald-probe-storage tasting new devices. But it can be as simple as "dd if=/dev/sgX". I am wondering that, is sg necessary on FreeBSD? Since most applications seem to live happily without it in GENERIC kernel. Maybe we can isolate it from cam.ko to make cam usable as module, and make the standalone sg module depending on cam module before sg got more resistant to misuse? Regards, Jia-Shiun. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
