Re: Why are cardbus drivers cbb(4) and pccard(4) still included in GENERIC?
On 08/29/13 11:52, Warner Losh wrote: On Aug 29, 2013, at 3:15 AM, Kimmo Paasiala wrote: In reference to this FreeBSD forums post: http://forums.freebsd.org/showpost.php?p=231135postcount=4 Would it be a good time to remove those from GENERIC since the hardware they are for is becoming so seriously outdated? There's always an option to load those drivers as modules if needed. No. It is not a good time to remove them. They aren't as out-dated as you might think, and there's literally dozens of other devices in GENERIC that have even less use today... Warner Just thought I'd be a statistic and speak up to say that I am happily using the PCMCIA drivers on multiple 9.x/i386 machines, and plan to continue doing so through 10.x. -Boris ___ 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: Thinkpad CD-ROM hotplug with ATA_CAM
On 09/14/11 12:15, Andriy Gapon wrote: on 14/09/2011 18:11 Boris Kochergin said the following: camcontrol rescan all I think that this command may screw up communication between kernel and HDD from which the OS runs. It works under normal circumstances--I can run camcontrol rescan all on a system with ATA_CAM and the root filesystem isn't disturbed. Perhaps using a specific bus number would work better. Somewhat, but results are still undesirable. camcontrol rescan 1 (the CD-ROM is listed as being on scbus1) executes, stays in the cbwait state for 30 seconds, then the system locks up. camcontrol reset 1 has the same behavior as camcontrol rescan all in that the system locks up instantly. -Boris ___ 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
Thinkpad CD-ROM hotplug with ATA_CAM
Ahoy. I have some Thinkpad T40-T43s running -CURRENT (as recent as yesterday's sources) with ATA_CAM enabled. If I remove the CD-ROM and proceed to run camcontrol rescan all, the system hangs with the cursor still at the end of the the line. Is there a correct way of doing this, or does it just not work right now? Back in the old ATA days, I'd be able to detach the channel with atacontrol, remove the CD-ROM, and put it back without any trouble. -Boris ___ 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: why panic(9) ?
On 01/11/11 15:37, C. P. Ghost wrote: On Tue, Jan 11, 2011 at 9:32 PM, Xin LIdelp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/11/11 12:11, David DEMELIER wrote: Yes, why this function exists? There is no way to solve a problem without panic'ing? Is panic really needed? Imagine someone working on [...] Panic is used to stop the kernel in an aggressive way when data damage is detected and the damage is already beyond what the kernel can recover from. The kernel can and should be made more robust but no, I don't think we can totally eliminate panic(). Exactly. One area where the kernel should be made more robust is UFS with disappearing disks (e.g. USB mounted file systems, or, as recently happened here with a loose external SATA cable). Panicing here is REALLY annoying. ;-) Getting slightly off-topic here, but... there was progress made on this front a while ago. You can reliably detach at least USB storage with a mounted MSDOSFS or UFS filesystem without soft updates and not risk a system panic. There will be a panic if soft updates are enabled on UFS, however, at least as of my last test in 2010. -Boris Cheers, - -- Xin LIdelp...@delphij.net http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -cpghost. ___ 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: why panic(9) ?
On 01/11/11 15:11, David DEMELIER wrote: Hello, Hi. I'm just guessing why current BSD panic() when a problem occurs, all modern operating systems solve the problem instead of crashing suddently and corrupting all your data without saving your work. All modern operating systems? Maybe some niche ones, like the ones that run on Mars rovers, have made progress towards formal verification and are believed not to crash given correctly-functioning hardware. The latest versions of Windows, OS X, and Linux all panic. Yes, why this function exists? There is no way to solve a problem without panic'ing? Imagine you've got a machine with bad RAM. It corrupts a pointer in the kernel filesystem code. Imagine there is some code in the kernel filesystem code that checks whether a pointer points to memory belonging to the kernel filesystem code before dereferencing it, and the check failed. What should happen? Continued execution will, at best, lead to flamboyant failure of kernel subsystems or userspace programs, and, at worst, will silently destroy or modify data in memory or on your disk. (By the way, this actually happens.) Is panic really needed? Imagine someone working on something really important and his computer just panic, his work not saved everybody shout at him in the corporation. He lose his job, his wife, his dog, everything is wrong, just because of a panic() ! When I do kernel work, I keep my source code on an NFS share on a known-stable machine so that when the machine I'm working on inevitably crashes, I don't lose my code. Reliability is about more than software choices. There are other best practices to consider. Seriously, I really hate when I play some music that suddenly the music get stucked in a infinite loop, why ? I don't know because the panic does not core dump. But after some search I found that the panic was done because of conky. How the hell conky can panic FreeBSD? We are in 2011 ! I think even Window 2000 does not crash on a user-land software. Frustrating at it may be, there are things you can do, like compiling your kernel with DDB and performing online debugging. -Boris I'm guessing now, if minix panic when a bloated crappy software is running. I think Andrew is in the right way. ___ 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: symbol versioning on libgcc?
Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris ___ 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: symbol versioning on libgcc?
Alexander Kabaev wrote: On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? My interpretation of the question was whether libgcc used FreeBSD symbol versioning. If that wasn't it, then indeed, one has nothing to do with the other. -Boris ___ 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: QEMU/KVM Panic on USB Mount
Hans Petter Selasky wrote: On Friday 09 July 2010 19:12:59 Sean Bruno wrote: In order to come up with the most convoluted problem possible, I present to you screen shots of a panic from a FreeBSD VM running in QEMU emulation under RedHat's KVM infrastructure. I presented a perfectly functional USB partition from my host machine to the VM. Then I attempted to mount the partition from FreeBSD and it generated the panics located here: http://people.freebsd.org/~sbruno/usb_panic1.png http://people.freebsd.org/~sbruno/usb_panic2.png This is 100% reproducible. But not an emergency or anything. It might be that there is a conflict that both the VM and the OS is accessing / loading drivers on the same USB device. The panic seems not directly related to USB. --HPS I followed the code for a while and the cause of the panic appears to be that ffs_vgetf() in /usr/src/sys/ufs/ffs/ffs_vfsops.c fails in one of the several ways possible, causing in VFS_ROOT() in /usr/src/sys/kern/vfs_mount.c to return a non-zero value and resulting in the panic. I think the problem calls for someone with serious VFS chops. The I/O errors from the USB device are suspicious (in that they may cause the mount code to misbehave if they occur during its course). -Boris ___ 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: How to disable CLANG co build in buildworld?
Andreas Tobler wrote: Hello, how can I disable the build of CLANG in a buildworld? I have a sparc64 machine which is quite slow. And for my purpose I do not need CLANG etc. atm. Thanks for any pointer. Andreas Setting WITHOUT_CLANG=yes in /etc/src.conf seems to be the way: http://lists.freebsd.org/pipermail/svn-src-head/2010-June/017677.html -Boris ___ 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
