FreeBSD 9.1 occasional kernel panic
Hi, recently I've switched from 8.3 to 9.1 on my home box and are quite pleased but occasionally I get a kernel panic like this: Feb 5 19:55:45 magni kernel: /dev: got error 6 while accessing filesystem Feb 5 19:55:45 magni kernel: panic: softdep_deallocate_dependencies: unrecovered I/O error Feb 5 19:55:45 magni kernel: cpuid = 1 Feb 5 19:55:45 magni kernel: KDB: stack backtrace: Feb 5 19:55:45 magni kernel: #0 0x809208a6 at kdb_backtrace+0x66 Feb 5 19:55:45 magni kernel: #1 0x808ea8be at panic+0x1ce Feb 5 19:55:45 magni kernel: #2 0x80b08d30 at clear_remove+0 Feb 5 19:55:45 magni kernel: #3 0x80966cd0 at brelse+0x60 Feb 5 19:55:45 magni kernel: #4 0x8096a14c at bufwrite+0xfc Feb 5 19:55:45 magni kernel: #5 0x80b0bd47 at softdep_process_journal+0x867 Feb 5 19:55:45 magni kernel: #6 0x80b0bf0a at jwait+0x9a Feb 5 19:55:45 magni kernel: #7 0x80b0c2b0 at flush_deplist+0x80 Feb 5 19:55:45 magni kernel: #8 0x80b0d531 at softdep_sync_metadata+0x1b1 Feb 5 19:55:45 magni kernel: #9 0x80b2236b at ffs_syncvnode+0x44b Feb 5 19:55:45 magni kernel: #10 0x80b22f91 at ffs_fsync+0x41 Feb 5 19:55:45 magni kernel: #11 0x8098c600 at sys_fsync+0x160 Feb 5 19:55:45 magni kernel: #12 0x80bd7ae6 at amd64_syscall+0x546 Feb 5 19:55:45 magni kernel: #13 0x80bc3447 at Xfast_syscall+0xf7 It does not happen very often but when it happens it mostly happens several times in a row. When I'm booting into single user while within such a series I seem to be able to reproduce the panic. If I mount my partitions one at a time the panic occurs several seconds after I mount my geli encrypted home partition. System specs: Gigabyte GA-EP35-DS3P Intel Core 2 Duo E8500 4 GB DDR2-800 3 HDDs (2x SATA, 1 SATA (Intel SSD)) System is installed on the SSD. Any ideas where this could be originating from? Regards, Jens -- 06. Hornung 2013, 09:20 Homepage : http://www.jan0sch.de Why don't you fix your little problem... and light this candle? -- Alan Shepard, the first American into space, Gemini program pgpmGegHGhFRN.pgp Description: PGP signature
Re: problems with the mfi
On Tuesday, February 05, 2013 3:48:28 am Daniel Braniss wrote: after rebooting I get very often: ... mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 659 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 689 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 719 SECONDS ... another reboot usualy fixes this. Does it have the latest firmware? it happened on several boxes, this one just arrived a week ago, and I will check, but most probably has the latest firmaware. cheers danny -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problems with the mfi
- Original Message - From: John Baldwin j...@freebsd.org On Tuesday, February 05, 2013 3:48:28 am Daniel Braniss wrote: after rebooting I get very often: ... mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 659 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 689 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 719 SECONDS ... another reboot usualy fixes this. Does it have the latest firmware? Be aware that the current code for mfi timeout's never abort so if you get a command stuck it will moan forever. This is one of the issues fixed in a patch that's in testing. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: So I whip out a FTDI-based multiport Serial USB Adapter....
On Mon, Feb 4, 2013 at 10:05 PM, CeDeROM cede...@tlen.pl wrote: I also want to use my KT-LINK multipurpose low-level embedded access multitool based on FT2232H with RS232 port and I was worried there is no driver - right now I will add the PID and recompile sources to see if it works - happy to catch this thread :-) Glad to announce I made my KT-LINK RS232/JTAG/SWD/* interface working on FreeBSD with just a little driver modification and kernel/modules rebuild - I will send patches soon, just need to test how it works with both RS2232 and JTAG running if there are no glitches :-) Best regards :-) Tomek Cedro -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problems with the mfi
- Original Message - From: John Baldwin j...@freebsd.org On Tuesday, February 05, 2013 3:48:28 am Daniel Braniss wrote: after rebooting I get very often: ... mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 659 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 689 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 719 SECONDS ... another reboot usualy fixes this. Does it have the latest firmware? Be aware that the current code for mfi timeout's never abort so if you get a command stuck it will moan forever. This is one of the issues fixed in a patch that's in testing. Regards Steve i know :-), I caught this one because the machine was not rebooting. can you shed some light as to what command timed out? cheers, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
Em 06/02/13 04:24, Mikhail T. escreveu: On 05.02.2013 23:38, Mikhail T. wrote: What happened between 6.x and 7.x? Ok, what happened is that device cpufreq is now in GENERIC and the ichss0 along with it. Setting set hint.ichss.0.disabled=1 on the loader prompt allows me to boot -- both my own kernel as well as the 9.1-RELEASE from CD. Solved... Annoying beyond belief, but solved. Now, if only I could figure out, why my network card (3COM's 3C556 Mini PCI) is not seen by the 9.1... It was working perfectly fine with 6.3 -- and still works with the FreeSBIE-2.0.1 Hi, 3c556 is supported by xl driver but xl driver need device miibus in kernel. http://www.freebsd.org/releases/9.1R/hardware.html The xl(4) http://www.FreeBSD.org/cgi/man.cgi?query=xlsektion=4manpath=FreeBSD+9.1-RELEASE driver supports the following hardware: * 3Com 3c900-TPO * 3Com 3c900-COMBO * 3Com 3c905-TX * 3Com 3c905-T4 * 3Com 3c900B-TPO * 3Com 3c900B-TPC * 3Com 3c900B-FL * 3Com 3c900B-COMBO * 3Com 3c905B-T4 * 3Com 3c905B-TX * 3Com 3c905B-FX * 3Com 3c905B-COMBO * 3Com 3c905C-TX * 3Com 3c980, 3c980B, and 3c980C server adapters * 3Com 3cSOHO100-TX OfficeConnect adapters * 3Com 3c450 HomeConnect adapters * 3Com 3c555, 3c556 and 3c556B mini-PCI adapters * 3Com 3C3SH573BT, 3C575TX, 3CCFE575BT, 3CXFE575BT, 3CCFE575CT, 3CXFE575CT, 3CCFEM656, 3CCFEM656B, and 3CCFEM656C, 3CXFEM656, 3CXFEM656B, and 3CXFEM656C CardBus adapters * 3Com 3c905-TX, 3c905B-TX 3c905C-TX, 3c920B-EMB, and 3c920B-EMB-WNM embedded adapters best regards, Gondim ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
pkg can't access pkgbeta.freebsd.org
Hi, On freshly installed FreeBSD-9.1-Release amd64 (from ISO) I am trying to migrate to new generation of packages: arch1% sudo pkg The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg please wait pkg: Error fetching http://pkgbeta.FreeBSD.org/freebsd:9:x86:64/latest/Latest/pkg.txz: No route to host arch1% arch1% traceroute pkgbeta.freebsd.org traceroute to bwwwdyn.freebsd.org (69.147.83.39), 64 hops max, 52 byte packets 1 172.16.30.1 (172.16.30.1) 1.215 ms 1.106 ms 1.107 ms 2 192.168.0.99 (192.168.0.99) 2.337 ms 2.474 ms 1.933 ms 3 pw-gw-gi3-0-558.warman.nask.pl (194.181.61.225) 3.978 ms 5.550 ms 4.799 ms 4 172.27.27.2 (172.27.27.2) 5.524 ms 5.292 ms 6.841 ms 5 frankfurt-gw-ae1-100.core.nask.pl (195.187.255.183) 29.989 ms 39.843 ms 28.430 ms 6 ge-1-3-0.pat2.dee.yahoo.com (80.81.193.115) 28.565 ms 28.384 ms 28.221 ms 7 as-1.pat2.dcp.yahoo.com (66.196.65.129) 119.239 ms 119.011 ms 118.605 ms 8 as-0.pat2.da3.yahoo.com (216.115.101.155) 193.173 ms 198.485 ms ae-7.pat2.che.yahoo.com (216.115.100.137) 224.062 ms 9 ae-6.pat1.dnx.yahoo.com (216.115.96.207) 191.784 ms as-1.pat2.sjc.yahoo.com (216.115.101.151) 194.342 ms ae-5.pat2.dnx.yahoo.com (216.115.96.55) 186.775 ms 10 ae-7.pat1.sjc.yahoo.com (216.115.101.149) 189.467 ms ae-7.pat1.pao.yahoo.com (216.115.101.128) 183.305 ms ae-7.pat1.sjc.yahoo.com (216.115.101.149) 192.312 ms 11 ae-0-d141.msr1.sp1.yahoo.com (216.115.107.51) 186.679 ms ae-1-d170.msr2.sp1.yahoo.com (216.115.107.85) 221.705 ms ae-1-d160.msr1.sp1.yahoo.com (216.115.107.61) 185.266 ms 12 * gi-1-47.bas-b1.sp1.yahoo.com (209.131.32.45) 187.202 ms gi-1-33.bas-b2.sp1.yahoo.com (98.136.16.33) 184.560 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * *^C arch1% ping pkgbeta.freebsd.org PING bwwwdyn.freebsd.org (69.147.83.39): 56 data bytes and no answer... Regards, -- Marek Salwerowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: problems with the mfi
- Original Message - From: Daniel Braniss da...@cs.huji.ac.il On Tuesday, February 05, 2013 3:48:28 am Daniel Braniss wrote: after rebooting I get very often: ... mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 659 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 689 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 719 SECONDS ... another reboot usualy fixes this. Does it have the latest firmware? Be aware that the current code for mfi timeout's never abort so if you get a command stuck it will moan forever. This is one of the issues fixed in a patch that's in testing. i know :-), I caught this one because the machine was not rebooting. can you shed some light as to what command timed out? Unfortunately not it was a generic issue any command which timeout would get stuck for ever. What FreeBSD version are using and what controller are you using? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
on 06/02/2013 08:40 Mikhail T. said the following: I struggle to understand, how a less seasoned user could be expected to figure these two issues out... Nobody expects that. These two bugs are just bugs, there is no drama. People change code, something gets broken for some very rarely used hardware, it goes unnoticed. Then someone notices, reports. From that point, all depends on that someone and on the developers. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 occasional kernel panic
on 06/02/2013 10:29 Jens Jahnke said the following: Hi, recently I've switched from 8.3 to 9.1 on my home box and are quite pleased but occasionally I get a kernel panic like this: Feb 5 19:55:45 magni kernel: /dev: got error 6 while accessing filesystem Feb 5 19:55:45 magni kernel: panic: softdep_deallocate_dependencies: unrecovered I/O error Feb 5 19:55:45 magni kernel: cpuid = 1 Feb 5 19:55:45 magni kernel: KDB: stack backtrace: Feb 5 19:55:45 magni kernel: #0 0x809208a6 at kdb_backtrace+0x66 Feb 5 19:55:45 magni kernel: #1 0x808ea8be at panic+0x1ce Feb 5 19:55:45 magni kernel: #2 0x80b08d30 at clear_remove+0 Feb 5 19:55:45 magni kernel: #3 0x80966cd0 at brelse+0x60 Feb 5 19:55:45 magni kernel: #4 0x8096a14c at bufwrite+0xfc Feb 5 19:55:45 magni kernel: #5 0x80b0bd47 at softdep_process_journal+0x867 Feb 5 19:55:45 magni kernel: #6 0x80b0bf0a at jwait+0x9a Feb 5 19:55:45 magni kernel: #7 0x80b0c2b0 at flush_deplist+0x80 Feb 5 19:55:45 magni kernel: #8 0x80b0d531 at softdep_sync_metadata+0x1b1 Feb 5 19:55:45 magni kernel: #9 0x80b2236b at ffs_syncvnode+0x44b Feb 5 19:55:45 magni kernel: #10 0x80b22f91 at ffs_fsync+0x41 Feb 5 19:55:45 magni kernel: #11 0x8098c600 at sys_fsync+0x160 Feb 5 19:55:45 magni kernel: #12 0x80bd7ae6 at amd64_syscall+0x546 Feb 5 19:55:45 magni kernel: #13 0x80bc3447 at Xfast_syscall+0xf7 It does not happen very often but when it happens it mostly happens several times in a row. When I'm booting into single user while within such a series I seem to be able to reproduce the panic. If I mount my partitions one at a time the panic occurs several seconds after I mount my geli encrypted home partition. System specs: Gigabyte GA-EP35-DS3P Intel Core 2 Duo E8500 4 GB DDR2-800 3 HDDs (2x SATA, 1 SATA (Intel SSD)) System is installed on the SSD. Any ideas where this could be originating from? error 6 is ENXIO, which usually corresponds to a disappearing device or some such. Do you get anything in logs (or other objective experience) that could look like that? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pkg can't access pkgbeta.freebsd.org
: in the URL instead of / , possibly ? I find it strange that there should be : in the URL, it is only acceptable when denoting the destination port to connect to. Try replacing them with slashes. -- Sent from my [insert random phone here] On 6 Feb 2013, at 12:59, Marek Salwerowicz marek_...@wp.pl wrote: Hi, On freshly installed FreeBSD-9.1-Release amd64 (from ISO) I am trying to migrate to new generation of packages: arch1% sudo pkg The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg please wait pkg: Error fetching http://pkgbeta.FreeBSD.org/freebsd:9:x86:64/latest/Latest/pkg.txz: No route to host arch1% arch1% traceroute pkgbeta.freebsd.org traceroute to bwwwdyn.freebsd.org (69.147.83.39), 64 hops max, 52 byte packets 1 172.16.30.1 (172.16.30.1) 1.215 ms 1.106 ms 1.107 ms 2 192.168.0.99 (192.168.0.99) 2.337 ms 2.474 ms 1.933 ms 3 pw-gw-gi3-0-558.warman.nask.pl (194.181.61.225) 3.978 ms 5.550 ms 4.799 ms 4 172.27.27.2 (172.27.27.2) 5.524 ms 5.292 ms 6.841 ms 5 frankfurt-gw-ae1-100.core.nask.pl (195.187.255.183) 29.989 ms 39.843 ms 28.430 ms 6 ge-1-3-0.pat2.dee.yahoo.com (80.81.193.115) 28.565 ms 28.384 ms 28.221 ms 7 as-1.pat2.dcp.yahoo.com (66.196.65.129) 119.239 ms 119.011 ms 118.605 ms 8 as-0.pat2.da3.yahoo.com (216.115.101.155) 193.173 ms 198.485 ms ae-7.pat2.che.yahoo.com (216.115.100.137) 224.062 ms 9 ae-6.pat1.dnx.yahoo.com (216.115.96.207) 191.784 ms as-1.pat2.sjc.yahoo.com (216.115.101.151) 194.342 ms ae-5.pat2.dnx.yahoo.com (216.115.96.55) 186.775 ms 10 ae-7.pat1.sjc.yahoo.com (216.115.101.149) 189.467 ms ae-7.pat1.pao.yahoo.com (216.115.101.128) 183.305 ms ae-7.pat1.sjc.yahoo.com (216.115.101.149) 192.312 ms 11 ae-0-d141.msr1.sp1.yahoo.com (216.115.107.51) 186.679 ms ae-1-d170.msr2.sp1.yahoo.com (216.115.107.85) 221.705 ms ae-1-d160.msr1.sp1.yahoo.com (216.115.107.61) 185.266 ms 12 * gi-1-47.bas-b1.sp1.yahoo.com (209.131.32.45) 187.202 ms gi-1-33.bas-b2.sp1.yahoo.com (98.136.16.33) 184.560 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * *^C arch1% ping pkgbeta.freebsd.org PING bwwwdyn.freebsd.org (69.147.83.39): 56 data bytes and no answer... Regards, -- Marek Salwerowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD 9.1 occasional kernel panic
On Wed, 06 Feb 2013 14:40:47 +0200 Andriy Gapon a...@freebsd.org wrote: AG error 6 is ENXIO, which usually corresponds to a disappearing AG device or some such. Do you get anything in logs (or other AG objective experience) that could look like that? Nothing found so far. System ran stable for the last 18 hours through. I'll look if the error occurs again. Regards, Jens -- 06. Hornung 2013, 14:00 Homepage : http://www.jan0sch.de Virtual means never knowing where your next byte is coming from. pgp4JRNVIrc8s.pgp Description: PGP signature
Re: problems with the mfi
- Original Message - From: Daniel Braniss da...@cs.huji.ac.il On Tuesday, February 05, 2013 3:48:28 am Daniel Braniss wrote: after rebooting I get very often: ... mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 659 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 689 SECONDS mfi0: COMMAND 0xff800132d990 TIMEOUT AFTER 719 SECONDS ... another reboot usualy fixes this. Does it have the latest firmware? Be aware that the current code for mfi timeout's never abort so if you get a command stuck it will moan forever. This is one of the issues fixed in a patch that's in testing. i know :-), I caught this one because the machine was not rebooting. can you shed some light as to what command timed out? Unfortunately not it was a generic issue any command which timeout would get stuck for ever. What FreeBSD version are using and what controller are you using? freebsd-9.1-stable as of last Friday the last one that did this is: mfi1: Dell PERC H810 Adapter port 0xdc00-0xdcff mem 0xd4ffc000-0xd4ff,0xd4f8-0xd4fb irq 66 at device 0.0 on pci65 but I saw this on older PERCs too. cheers, danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD-9.1 would not boot on pentium3 laptop
On 06.02.2013 02:13, YongHyeon PYUN wrote: Disabling Wake on LAN in the BIOS solved this problem. Now xl0 is seen and functional. Solved. Because I added WOL support xl(4) in the past I'm interested in knowing whether that change broke your controller when BIOS enables WOL. I can not reproduce this -- after enabling WOL in BIOS, both kernels (mine and 9.1-R GENERIC) still see xl0 now. Maybe, it is a BIOS issue -- I'm using Lattitude's BIOS version A02, but the last update from Dell before they stopped supporting the laptop is A23. Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: So I whip out a FTDI-based multiport Serial USB Adapter.... [SB QUAR: Tue Feb 5 10:15:47 2013]
On 2/5/2013 11:25 AM, CeDeROM wrote: On Tue, Feb 5, 2013 at 6:09 PM, Karl Denninger k...@denninger.net wrote: The FTDI adapter has the provision for an external power supply (+5V) but it does not require it unless you're running off an unpowered bus, which is not normally the case. 500ma is quite a bit of available energy. Karl, can you please use external power supply to power up the adapter - with and without the additional devices step by step - this way we will eliminate one of the possible causes :-) That's pretty-clearly not the problem -- I have removed the KVM from the system and added a couple other USB devices, including switching the UPS attached to it from serial communication to USB, and it's fine. Whatever is going on here it's KVM-related, not the FTDI box. That's an interesting issue all on its own but one that may be rather difficult to solve -- let's toss this thread and I'll start a new one when I can start chasing the KVM issue -- that's one that's not good as well, but I will check across OS revisions and see if it's limited to 9.x or whether it shows up on other, older releases as well first. -- -- Karl Denninger /The Market Ticker ®/ http://market-ticker.org Cuda Systems LLC ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Panic at shutdown
Hello there, I recently had a panic at shutdown in 9.1-STABLE, there's the backtrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: 118. 118Feb 5 23:30:31 Melon syslogd: exiting on signal 15 5wlan0: link state changed to DOWN 5lagg0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...7 1 1 0 done All buffers synced. ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-443) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.SMAB] (Node 0xfe00017edc08), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.GFXZ._TMP] (Node 0xfe00017d3280), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed type [Reference], found [Integer] 0xfe0001807678 (20110527/exresop-116) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.INTM] (Node 0xfe00017d4168), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.DTSZ._TMP] (Node 0xfe00017d4500), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.GTTP] (Node 0xfe00017d6050), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.CPUZ._TMP] (Node 0xfe00017d41e0), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.GTTP] (Node 0xfe00017d6050), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.SKNZ._TMP] (Node 0xfe00017d8258), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.GTTP] (Node 0xfe00017d6050), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.BATZ._TMP] (Node 0xfe00017d8118), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed type [Reference], found [Integer] 0xfe0001807678 (20110527/exresop-116) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.KRFS] (Node 0xfe00017e71e0), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.GRFS] (Node 0xfe00017f37f8), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.FDTZ._TMP] (Node 0xfe00017d8078), AE_AML_OPERAND_TYPE (20110527/psparse-560) Uptime: 2h1m59s ACPI Error: Needed type [Reference], found [Integer] 0xfe0001807678 (20110527/exresop-116) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.DGFX._DOS] (Node 0xfe00017d9528), AE_AML_OPERAND_TYPE (20110527/psparse-560) can't evaluate \_SB_.PCI0.PEGP.DGFX._DOS - AE_AML_OPERAND_TYPE usbus0: Controller shutdown uhub0: at usbus0, port 1, addr 1 (disconnected) ugen0.2: Broadcom Corp at usbus0 (disconnected) ubt0: at uhub0, port 1, addr 2 (disconnected) usbus0: Controller shutdown complete usbus1: Controller shutdown uhub1: at usbus1, port 1, addr 1 (disconnected) usbus1: Controller shutdown complete usbus2: Controller shutdown uhub2: at usbus2, port 1, addr 1 (disconnected) usbus2: Controller shutdown complete usbus3: Controller shutdown uhub3: at usbus3, port 1, addr 1 (disconnected) ugen3.2: Chicony Electronics Co., Ltd. at usbus3 (disconnected) usbus3: Controller shutdown complete usbus4: Controller shutdown uhub4: at usbus4, port 1, addr 1
Re: problems with the mfi
- Original Message - From: Daniel Braniss da...@cs.huji.ac.il Unfortunately not it was a generic issue any command which timeout would get stuck for ever. What FreeBSD version are using and what controller are you using? freebsd-9.1-stable as of last Friday the last one that did this is: mfi1: Dell PERC H810 Adapter port 0xdc00-0xdcff mem 0xd4ffc000-0xd4ff,0xd4f8-0xd4fb irq 66 at device 0.0 on pci65 but I saw this on older PERCs too. I've got a set of patches which should definitely stop the continuous moaning, but also may prevent the issue as it has significant fixes for tbolt cards which the H810 is. Would you would like try them? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Panic at shutdown
On 06/02/2013 16:31, David Demelier wrote: Hello there, I recently had a panic at shutdown in 9.1-STABLE, there's the backtrace: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: 118. 118Feb 5 23:30:31 Melon syslogd: exiting on signal 15 5wlan0: link state changed to DOWN 5lagg0: link state changed to DOWN Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...7 1 1 0 done All buffers synced. ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-443) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.SMAB] (Node 0xfe00017edc08), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.GFXZ._TMP] (Node 0xfe00017d3280), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed type [Reference], found [Integer] 0xfe0001807678 (20110527/exresop-116) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.INTM] (Node 0xfe00017d4168), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.DTSZ._TMP] (Node 0xfe00017d4500), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.GTTP] (Node 0xfe00017d6050), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.CPUZ._TMP] (Node 0xfe00017d41e0), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.GTTP] (Node 0xfe00017d6050), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.SKNZ._TMP] (Node 0xfe00017d8258), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed [Integer/String/Buffer], found [Reference] 0xfe0001807678 (20110527/exresop-533) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_TZ_.GTTP] (Node 0xfe00017d6050), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.BATZ._TMP] (Node 0xfe00017d8118), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Needed type [Reference], found [Integer] 0xfe0001807678 (20110527/exresop-116) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.LPCB.EC0_.KRFS] (Node 0xfe00017e71e0), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_SB_.GRFS] (Node 0xfe00017f37f8), AE_AML_OPERAND_TYPE (20110527/psparse-560) ACPI Error: Method parse/execution failed [\_TZ_.FDTZ._TMP] (Node 0xfe00017d8078), AE_AML_OPERAND_TYPE (20110527/psparse-560) Uptime: 2h1m59s ACPI Error: Needed type [Reference], found [Integer] 0xfe0001807678 (20110527/exresop-116) ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for [OpcodeName unavailable] (20110527/dswexec-498) ACPI Error: Method parse/execution failed [\_SB_.PCI0.PEGP.DGFX._DOS] (Node 0xfe00017d9528), AE_AML_OPERAND_TYPE (20110527/psparse-560) can't evaluate \_SB_.PCI0.PEGP.DGFX._DOS - AE_AML_OPERAND_TYPE usbus0: Controller shutdown uhub0: at usbus0, port 1, addr 1 (disconnected) ugen0.2: Broadcom Corp at usbus0 (disconnected) ubt0: at uhub0, port 1, addr 2 (disconnected) usbus0: Controller shutdown complete usbus1: Controller shutdown uhub1: at usbus1, port 1, addr 1 (disconnected) usbus1: Controller shutdown complete usbus2: Controller shutdown uhub2: at usbus2, port 1, addr 1 (disconnected) usbus2: Controller shutdown complete usbus3: Controller shutdown uhub3: at usbus3, port 1, addr 1 (disconnected) ugen3.2: Chicony Electronics
I/O hanging while hosting Postgres database
I'm seeing a condition on FreeBSD 9.1 (built October 24th) where I/O seems to hang on any local zpools after several hours of hosting a large-ish Postgres database. The database occupies about 14TB of a 38TB zpool with a single SSD ZIL. The OS is on a ZFS boot disk. The system also has 24GB of physical memory. Smartmon tools reports no errors on any disks attached to the system, and IPMI reports all temperatures, CPU voltages, and fan speeds are normal. The database has been gradually increasing in size since it was first deployed on FreeBSD 9.1 this fall. There were no problems until last night, when the database became unresponsive. Attempts to interact with the shell would block (specifically, any interaction with the disk), and no error messages were logged to the console. I restarted the system at that time, and brought the database back up. Everything seemed normal until this morning, where the database had become unresponsive again. Fortunately, I was able to grab some system statistics before the shell and console went AWOL. The only finding that I thought was suspicious were the kmem_map numbers: vm.kmem_map_free: 655360 vm.kmem_map_size: 17141383168 It's something like 0.004% free. I haven't been able to find much documentation on what to expect here, but I don't see anything like that for other databases that I've monitored. It is possible that kmem_map can become exhausted without generating a kernel panic? Could it be indicative of severe memory fragmentation? - .Dustin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
