Re: FreeBSD 7 64 bits kernel crash debugging
On Thu, Jul 3, 2008 at 4:52 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Wed, Jul 2, 2008 at 12:50 PM, Fernando Apesteguía [EMAIL PROTECTED] wrote: Hi all, I'm experiencing several kernel crashes with the GENERIC kernel and with custom kernels as well. One of my MP3 players seems to be recognized, but if I disconnect it from the USB port (even without mounting the device), I got a kernel crash. I've tried to follow the instructions at http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html I have dumpdev and dumpdir properly set to my swap partition (ad0s2b) and to /var/crash. However, during the next boot, I got a message that indicates it is looking for a dump on such device but it couldn't find any. How can I track this error? Have you enabled at least KDB/DDB debugger support so you can look at a stack trace (t) and post this? This will at least give us/you some idea on what is crashing... No, running GENERIC kernel. Add minimally to your kernel build conf file: options DDB options KDB Rebuild, reboot, and test. I'm not sure why a crash dump is not working. Have you tried specifying your dump device in your kernel config file? Hi, First of all sorry for the delay, but my ISP is pissing me off since a couple of days and I don't have either telephone, nor Internet connection :S Anyway, I managed to recompile the kernel with debugging support. I provoked the panic and here is the trace: db t Tracing pid 2 tid 16 td 0xff0001096340 xpt_done() at xpt_done+0x54 cam_periph_runccb() at cam_periph_runccb+0x46 daprevent() at daprevent+0x80 daclose() at daclose+0x164 g_disk_access() at g_disk_access+0x107 g_access() at g_access+0x188 g_bsd_taste() at g_bsd_taste+0xdc g_new_provider_event() at g_new_provider_event+0x75 g_run_events() at g_run_events+0x1c7 g_event_procbody() at g_event_procbody+0x56 fork_exit() at fork_exit+0x11e fork_trampoline() at fork_trampoline()+0xe --- trap 0, rip = 0, rsp = 0xa0574d30, rbp = 0 --- The chain of events that leads to this panic is as follows: 1.- I plug the mp3 player in 2.- I see console messages about the device (size, transfer speed, etc). It is assigned the da0 device 3.- I list /dev and ther is no da0 (kernel still busy doing something?) 4.- After waiting some time (even minutes) I unplug the mp3 player and I got the crash. Thanks in advance. Let us know, -aps ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: massive interrupt storm
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sergey Babkin Sent: Monday, 7 July 2008 8:56 AM To: Murray Taylor Cc: freebsd-hackers@freebsd.org Subject: Re: massive interrupt storm Murray Taylor wrote: Hi all, We have just purchased some servers with a view to using them as firewalls within our WAN, and have discovered that they are suject to a massive interrupt storm on IRQ17. systat -v is showing 59000 - 63000 interrupts continuously on this IRQ, and 90%-98% Interrupt CPU usage One typical reason for interrupt storms is this: Some device has been initialized by BIOS and has indicated an interrupt but there is no driver in the OS to handle this interrupt. PCI allows sharing of the interrupts, i.e. multiple devices show their interrupts on the same IRQ line. The interrupt is signalled by level, i.e. if any device on this IRQ has an interrupt pending, it would pull the line low. OS has no way to tell which one, other than by trying all the drivers for the devices sitting on this line. Once the driver has found that its device is the one signalling interrupt, it services it, cleans the device state, and the device lets go of the IRQ line. The trouble starts when there is some device for which there is no driver. OS runs its interrupt handler, polls each driver, each of them says nope, not mine, teh interrupt handler exits and gets called again right away. The fix is to disable the unsupported devices in BIOS or at least collect them on some IRQ line that is not used by any supported devices. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] vmstat -i output interrupt total rate irq1: atkbd0 78 0 irq6: fdc0 3 0 irq16: uhci0 ehci0 3 0 irq17: mpt0 uhci1* 680341376 57301 irq21: bge011806 0 cpu0: timer 23737523 1999 Total 704090789 59301 Did you try to disable USB in BIOS? (yes, you don't have PS/2, but you can use SSH for testing) yes Also did you try to disable ACPI? yes I have attached the output from lspci and pciconf .. We have variously shutdown all USB in the bios, pulled the Raid daughter board, and still cant solve this storm. Currently looking for the SMB 'kill switch' .. And will also look into the SATA chips, but with not much hope (soldering iron anyone?) A point or two -- we get bge0 but not bge1 under FreeBSD, and FresBSD 4.11, 6.2 and 7.0 all exhibit the same problem. The box seems to work with knoppix, insofar as we DO get both NICs and dont seem to get the storm. This data (knoppix) is a bit flakey as it was late at night so we didnt look too hard after the NICs came up. mjt --- The information transmitted in this e-mail is for the exclusive use of the intended addressee and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of it, or the taking of any action in reliance upon this information by persons and/or entities other than the intended recipient is prohibited. If you received this in error, please inform the sender and/or addressee immediately and delete the material. E-mails may not be secure, may contain computer viruses and may be corrupted in transmission. Please carefully check this e-mail (and any attachment) accordingly. No warranties are given and no liability is accepted for any loss or damage caused by such matters. --- ### This e-mail message has been scanned for Viruses by Bytecraft ### Script started on Tue Jul 8 14:02:57 2008 gwfort27# lspci -bv 00:00.0 Host bridge: Intel Corporation Server DRAM Controller (rev 01) Subsystem: IBM Unknown device 0377 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information ? 00:01.0 PCI bridge: Intel Corporation Server Host-Primary PCI Express Bridge (rev 01) (prog-if 00 [Normal decode]) Flags: fast devsel Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [88] Subsystem: IBM Unknown device 0377 Capabilities: [80] Power Management version 3 Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable- Capabilities: [a0] Express Root Port (Slot+), MSI 00 00:1c.0 PCI bridge: Intel Corporation PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: fast devsel Bus: primary=00, secondary=08, subordinate=08, sec-latency=0 Capabilities: [40] Express Root Port (Slot+), MSI 00
Re: massive interrupt storm
On Tue, Jul 08, 2008 at 05:21:34PM +1000, Murray Taylor wrote: We have variously shutdown all USB in the bios, pulled the Raid daughter board, and still cant solve this storm. Have you tried disabling MSI and MSI-X in FreeBSD to see if it makes a difference? Set hw.pci.enable_msi=0 and hw.pci.enable_msix=0 in /boot/loader.conf and reboot. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Gábor Kövesdán wrote: Well, it seems you have missed the first nits of the discussion. GNU grep has some regression test, which doesn't pass completely itself either. :) I've mentioned here that I used those tests to find out what incompatible options are there. Unfortunately, I have to say that BSD grep won't pass all of those, because GNU allows some non-standard regexes, which are rejected by our libc-regex library, like for example (a|) is not standard because it has an empty subexpression. First, I tried to pre-edit such expression in the code. It was ugly enough but I thought: Ok, this code is pretty ugly, but compatibility is important, maybe we can later revise and/or change our regexp library and get rid of these snippets. Later, when Andrey pointed it out, I realized that my workarounds adressed those incompatibilities but didn't work completely, they broke compatibility at other places, thus I just removed them, because it was not that easy to fix. The version that I sent you for the portbuild test, doesn't have those workarounds. The regression test helped though to fix other compatibility issues, like return values. All of these trivial things are supposed to be compatible now, the only exceptions are the non-standard regexes. That's why I'm so curious about the results. If they are inacceptable, we can try to build BSD grep with the GNU regexp lib (it's in the tree, as Pedro F. Giffuni pointed it out). It doesn't work by just linking with that library, so it will need more work and investigation then, not speaking about that GNU regex should go one day... OK, yes I did miss the start of the thread, but I was trying to suggest that grep doesn't seem to be functional enough yet and this is a way to work on identifying what needs to be fixed. Could you please send me some logs of ports which build with GNU grep but not with BSD grep? That would help me to identify the problems and find out if those problems come from non-standard regexes or what's happening here? No, because every port build fails because egrep -v is failing to work properly in the management scripts :) I sent you mail about this already. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
Well, it seems you have missed the first nits of the discussion. GNU grep has some regression test, which doesn't pass completely itself either. :) I've mentioned here that I used those tests to find out what incompatible options are there. Unfortunately, I have to say that BSD grep won't pass all of those, because GNU allows some non-standard regexes, which are rejected by our libc-regex library, like for example (a|) is not standard because it has an empty subexpression. First, I tried to pre-edit such expression in the code. It was ugly enough but I thought: Ok, this code is pretty ugly, but compatibility is important, maybe we can later revise and/or change our regexp library and get rid of these snippets. Later, when Andrey pointed it out, I realized that my workarounds adressed those incompatibilities but didn't work completely, they broke compatibility at other places, thus I just removed them, because it was not that easy to fix. The version that I sent you for the portbuild test, doesn't have those workarounds. The regression test helped though to fix other compatibility issues, like return values. All of these trivial things are supposed to be compatible now, the only exceptions are the non-standard regexes. That's why I'm so curious about the results. If they are inacceptable, we can try to build BSD grep with the GNU regexp lib (it's in the tree, as Pedro F. Giffuni pointed it out). It doesn't work by just linking with that library, so it will need more work and investigation then, not speaking about that GNU regex should go one day... OK, yes I did miss the start of the thread, but I was trying to suggest that grep doesn't seem to be functional enough yet and this is a way to work on identifying what needs to be fixed. Could you please send me some logs of ports which build with GNU grep but not with BSD grep? That would help me to identify the problems and find out if those problems come from non-standard regexes or what's happening here? I've looked at our regex library and it is written by Henry Spencer. He has a slightly newer version, but he seems to be consequent and the implementation choices are the same, those non-standard regexes are still rejected by his library. I've also looked at PCRE, which was mentioned in this list. In fact, PCRE actually has a POSIX-compliant interface, but it's just the interface, the interpreted regexes are still Perl-like. -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Re: Sysinstall is still inadequate after all of these years
Freddie Cash wrote: The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. Actually, this is probably the easiest part (at least for UFS). The libdisk(3) library abstracts most of it out of the installer. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Sysinstall is still inadequate after all of these years
[EMAIL PROTECTED] wrote: Hear, hear! To be honest, this is the only bit about the current sysinstall that I really dislike: the fact that it can be used for post-installation configuration and package installation. This causes no end of trouble for newbies, who seem to view sysinstall as The One True System Admin Tool and try to use it for configuring/installing everything. Too many times, on various BSD forums, I've had to walk people through cleaning up /etc/rc.conf and showing them how to correctly install/configure things (using standard FreeBSD tools), since they used sysinstall for everything. That may be true, but sysinstall did help me do basic, essentical configuration of my very first installed system, and a few installs after that (until I learned about /etc/rc.conf et al). And I never regarded it as The One True Sysadmin Tool, because I did not use Linux distros, thus never got used to their ways. It's just that the simple configuration menu really helped me to get a useful system running in a few minutes (though menu items certainly could make use of more verbose descriptions). And then I could play with the working system and learn ways to configure it. So, IMHO, a basic curses system configuration utility is still needed, and should be run after sysinstall or it should tell the user how to run it (maybe in motd, or sysinstall itself?). Yes, I agree that such a tool is useful, but it does not belong in the installer. In fact, the BSD Installer framework can be used here also to separate the implementation details from the user interface. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: eeePC 900 with SSD reducing writes
Matthias Apitz wrote: I'd also like to get rid of 'lastlog' and 'wtmp' but even if the man page claims that they will not be created if they don't exist, they come up again and again; another candidate of not needed log is /var/log/Xorg.n.log ... You can get rid of an on-disk /var alltogether. Add these lines to /etc/rc.conf: varmfs=yes varsize=32m It will create a memory FS for /var of 32 MB (default). You could also mount some or all of your disk partitions read-only. That's what I do on my embedded FreeBSD-driven mp3 player (running from a CF card instead of hard disk), because it doesn't have to write anything anywhere. If you have any disk partitions that you mount read+write, be sure to enable soft-updates because it tends to reduce the number of physical write operations. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd FreeBSD is Yoda, Linux is Luke Skywalker -- Daniel C. Sobral ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Re: Sysinstall is still inadequate after all of these years
On Tue, Jul 08, 2008 at 05:53:45PM +0300, Mike Makonnen wrote: Freddie Cash wrote: The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. Actually, this is probably the easiest part (at least for UFS). The libdisk(3) library abstracts most of it out of the installer. ...except that libdisk(3) was supposed to be a temporary hack. I'd really suggest that something cleaner is to be written; libdisk(3) really is not the way to go. Have a look at the code and see for yourself. Regards, -- Rink P.W. Springer- http://rink.nu Anyway boys, this is America. Just because you get more votes doesn't mean you win. - Fox Mulder ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sysinstall is still inadequate after all of these years
On Jul 8, 2008, at 12:04 PM, Rink Springer wrote: On Tue, Jul 08, 2008 at 05:53:45PM +0300, Mike Makonnen wrote: Freddie Cash wrote: The tricky part will be getting the disk slicing, slice partitioning, and filesystem formatting to work reliably, with all the power of FreeBSD's GEOM modules, and ZFS. Actually, this is probably the easiest part (at least for UFS). The libdisk(3) library abstracts most of it out of the installer. ...except that libdisk(3) was supposed to be a temporary hack. I'd really suggest that something cleaner is to be written; libdisk(3) really is not the way to go. Have a look at the code and see for yourself. Yes, libdisk is bad. GEOM_PART has been designed for use by installers. It can be interfaced faily easily. See gpart(8) for example. FYI, -- Marcel Moolenaar [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Glaring 64 bit omission
I was just following up to a post in the forms nvidia supports regarding the graphics cards and FreeBSD when it struck me... Possibly one of the most important glaring omissions to the current FreeBSD platform and it's associated desktop projects is the lack of an nvidia 3D driver. Now I do follow the various forums and mailing lists sufficiently to be quite aware of the requests that nvidia has made for the FreeBSD kernel, the latest reported status on these items and the discussions about these items. I am even somewhat familliar with the efforts for open source drivers on both nvidia (barely supporting 2D at this point) and 3D drivers on other types of hardware (Intel and AMD) In the other forum, I commented that in all my reading, I had not come across someone saying that either a) the nvidia requests seemed unneccary or even b) that the nvidia requests served only the interests of nvida or some narrow (possibly bad) design of hardware. Now... the kernel modifications seem rather major to my untrained eye... something that seems highly unlikely to be considered for MFC. That being the case, it's already too late to consider nvidia cards working on AMD-64 in 7.x. _That_ being said, it seems that these kernel items should be on a priority list for 8.0 (and possibly even delaying 8.0 until we can achieve them so that 64bit nvidia support (arriving in -STABLE) is not delayed another year or two). Although AMD64 is a new platform, it was a platform born out of desperation. There's good evidence for this position in the amount of sheer crow Intel had to consume by supporting the architecture. I multi-boot my laptop to take advantage of it's DUAL-8800M video cards, but I also spend much of my time in amd64 mode because I find i386 too restrictive (for ZFS, for application size, for amount of supported RAM, etc.). In fact, running ZFS in 32 bit mode seems to run the system out of resources required to run 3D application (although there is talk on the FreeBSD lists that future ZFS patches may mitigate this behaviour --- but the fact seems to remain that both ZFS and nvidia require gobs of kernel resources --- which in turn both point to 64 bit OS). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Glaring 64 bit omission
On Tue, 8 Jul 2008 18:21:27 -0400 Zaphod Beeblebrox [EMAIL PROTECTED] wrote: I was just following up to a post in the forms nvidia supports regarding the graphics cards and FreeBSD when it struck me... Rather late Possibly one of the most important glaring omissions to the current FreeBSD platform and it's associated desktop projects is the lack of an nvidia 3D driver. It's been this way for quite a while. _That_ being said, it seems that these kernel items should be on a priority list for 8.0 (and possibly even delaying 8.0 until we can achieve them so that 64bit nvidia support (arriving in -STABLE) is not delayed another year or two). I'm sure it's on quite a few people's priority lists. Unfortunately for them (yup, them - I don't do 3d on my desktop) none of them appear to be on the important list of people regarding this issue: the list of people with both the time and skills needed to deal with these kernel items. Which is the root of the problem: FreeBSD is a volunteer effort. There's not a lot of incentive to fix a problem that doesn't affect you directly (and the FreeBSD folks are to be congratulated for how well they do on such issues in general!) - and as you point out, this is a rather deep problem. Pointing out that this issue is N years old and hasn't been addressed isn't constructive - everyone who could deal with it certainly knows about it by now. That said, since you believe this should be a priority, and have listed how it affects you personally, what have you done that *is* constructive? The obvious ones would be submitting patches that seem to move things in the right direction, or establishing a bounty for such patches. Done either of those? Something I overlooked? mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re: Sysinstall is still inadequate after all of these years
On Mon, Jul 07, 2008 at 11:55:41AM -0700, Freddie Cash wrote: IMO, the installer should allow you to partition the disk(s), format the partition(s), install the OS, configure a user, and reboot the system. Anything beyond that should be handled by the OS tools, from within the installed and running OS. It already does all of that, but why reboot right away? The first thing I do while the system is installing is run csup(1) to get the latest source, build and install world/kernel, and build all my ports. I also setup my gmirror and do all my configuration. The only reason I reboot is to use the latest kernel and mount from the mirror. I'd like to see other OSes do all of that. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
