Sell Cisco Systems equipment items
Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, .. NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, .. WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, .. CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, .. MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, and so on. ¡¡ Regards Helen.Zhou www.nstnetwork.com MSN: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] AOL helenxuezhou Icq 320-880-606 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Sell Cisco Systems equipment items
Hello: We are specialized in new network products, including switch, firewall, router, GBIC,SFP,WIC,cables etc... We provide high quality products and the most reasonable price with professional services to our customers. So if you are interested in any of our products, please contact with me,we will try our best for you,thanks! example of the products: CWDM-SFP-1G 39dB (Ultra long-haul)--1510nm,1530nm,1550nm,1570nm,1590nm,1610nm WS-G5483, WS-G5487, WS-G5484, WS-G5486, GLC-SX-MM, GLC-LH-SM, GLC-ZX-SM, GLC-T, .. NM-2FE2W-T1, NM-2FE2W-E1, NM-2FE2W-V2, WIC-1T, WIC-2T, WIC-2A/S, WIC-1B/ST, WIC-1ENET, VWIC-1MFT-T1, VWIC-1MFT-E1, VWIC-2MFT-T1, VWIC-2MFT-E1, VWIC-1MFT-G703, VWIC-2MFT-G703, VWIC-1MFT-T1-DI, VWIC-2MFT-T1-DI, NM-1E, NM-4E, .. WS-C2950-24, WS-C2950T-24, WS-C2950G-24-EI, WS-C2950G-48-EI, .. CONSOLE CABLE, CAB-STACK-1M/3M, CAB-V35MT, CAB-V35FC, CAB-SS-V.35MT, CAB-SS-V.35FC, CAB-SS-232MT, CAB-SS-232FC, CAB-232MT, CAB-232FC, CAB-SS-X21MT, CAB-SS-X21FC, CAB-X21MT, .. MEM-npe400-512MB, MEM-3660-128mb, MEM2600-32D, MEM2600-16FS, MEM2600XM-64D, MEM-S1-128MB, MEM-S2-256MB, MEM-S2-512MB, MEM-MSFC-128MB, MEM2801-256D, MEM3800-256D, MEM3800-512, MEM3745-256D, MEM1841-256D, MEM180X-256D, WS-X6K-MSFC2-KIT, and so on. ¡¡ Regards Helen.Zhou www.nstnetwork.com MSN: [EMAIL PROTECTED] Email: [EMAIL PROTECTED] AOL helenxuezhou Icq 320-880-606 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
Karl Denninger wrote: On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: On Mon, Jun 16, 2008 at 08:20:53PM -0500, Karl Denninger wrote: On Thu, May 08, 2008 at 10:30:01AM +0100, Pete French wrote: I assume SCSI is the best path forward (either SA/SCSI or traditional) but have been out of the loop on the card(s) that work properly for a good long while. HP P400 cards are PCI express and SAS - they work very well under FreeBSD. I've also used the cheaper E200 and that appears to be fine too, though I havent run it for as long as the 400's. http://h18004.www1.hp.com/products/servers/proliantstorage/arraycontrollers/smartarrayp400/index.html -pete. Following upon my own stuff, I just laid hands on a Quad-Xeon machine with an Intel SRCSAS18E card in it, and well, the only way I can describe it is oh my GOD! Ok, another followup! Is there a mangement interface program for the mfi driver somewhere? I rooted around in ports but didn't find one, nor on the base system. The Linux ones want to talk to the amr driver which is the older LSI Logic MegaRAID boards, not the newer ones that the mfi driver talks to. No management tool = el-sucko, because you can't rebuild a failed disk or even shut the alarm on the board off! Its sysutils/linux-megacli. Nope. It builds and installs but doesn't work (already tried this one.) Attempting to ask it for the number of boards returns 0. This may have something to do with changes made to the device structure(s) in FreeBSD-7 (I don't have a 6 machine to test on any more) but it definitely does not function. It works fine for me on very recent 7-STABLE. megacli -CfgDsply -a0 == Adapter: 0 Product Name: PERC 5/i Integrated Memory: 256MB BBU: Present Serial No: 12345 == -cut- megacli -AdpAllInfo -aALL also works without a problem. 7.0-STABLE-200805 FreeBSD 7.0-STABLE-200805 #0: Sun May 11 11:55:15 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? Though I think there is a small bug in the port (maintainer CCed) It wants compat.linux.osrelease=2.6.12, but I think it should be compat.linux.osrelease=2.6.16 ? Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 I think you are confusing mega-cli with megamgr (which is the one that work with amr driver) -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output
On Sunday 15 June 2008 07:23:19 am Stef Walter wrote: I've been trying to track down a deadlock on some newish production servers running FreeBSD 6.3-RELEASE-p2. The deadlock occurs on a specific (although mundane) hardware configuration, and each of several servers running this hardware deadlock about once per week. Although I suspect that this is not hardware related, from a (naive) perusal of the attached stack traces. Forgive me if my interpretation of this is all wrong, but I'm pretty desperate for help. So here's my basic understanding of the deadlock: These processes seem to be waiting on the page queue mutex: sendmail (in vm_mmap vm_map_find vm_map_insert vm_map_pmap_enter) bsnmpd (in malloc, uma_large_malloc page_alloc kmem_malloc) httpd (in trap trap_pfault vm_fault) [g_up] (in g_vfs_done bufdone) The page queue mutex is held by rsync process: rsync (in trap trap_pfault vm_fault pmap_enter) Rsync kernel process (in pmap_enter) was interrupted while holding the page queue lock? Giant is enabled in loader.conf due to the needs of the pf firewall when dealing with user credentials lookups. I do not believe that Giant plays into this deadlock. Kernel config attached. Any and all help or info is welcome. Thanks in advance. Try this change: jhb 2007-10-27 22:07:40 UTC FreeBSD src repository Modified files: sys/kern sched_4bsd.c Log: Change the roundrobin implementation in the 4BSD scheduler to trigger a userland preemption directly from hardclock() via sched_clock() when a thread uses up a full quantum instead of using a periodic timeout to cause a userland preemption every so often. This fixes a potential deadlock when IPI_PREEMPTION isn't enabled where softclock blocks on a lock held by a thread pinned or bound to another CPU. The current thread on that CPU will never be preempted while softclock is blocked. Note that ULE already drives its round-robin userland preemption from sched_clock() as well and always enables IPI_PREEMPT. MFC after: 1 week Revision ChangesPath 1.108 +8 -29 src/sys/kern/sched_4bsd.c We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD when softclock() (swi4: clock) blocks on a lock like Giant. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
Hi, On 18 Jun 2008, at 12:29, Stefan Lambrev wrote: Did you follow all steps from ports/sysutils/linux-megacli/pkg- message ? Though I think there is a small bug in the port (maintainer CCed) It wants compat.linux.osrelease=2.6.12, but I think it should be compat.linux.osrelease=2.6.16 ? Last time I checked it was still 2.6.12. it still is set to that value on our 2950's (running 6.2 and linux_base-fc-4_9) Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 I think you are confusing mega-cli with megamgr (which is the one that work with amr driver) People should only realise that they are running a linux binary under emulation in order to manage their mission critical servers. It is a thing you might not like. Regards, Ruben ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
On Wed, Jun 18, 2008 at 01:29:56PM +0300, Stefan Lambrev wrote: Karl Denninger wrote: On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: Intel SRCSAS18E card in it, and well, the only way I can describe it is oh my GOD! Ok, another followup! Is there a mangement interface program for the mfi driver somewhere? I rooted around in ports but didn't find one, nor on the base system. The Linux ones want to talk to the amr driver which is the older LSI Logic MegaRAID boards, not the newer ones that the mfi driver talks to. No management tool = el-sucko, because you can't rebuild a failed disk or even shut the alarm on the board off! Its sysutils/linux-megacli. Nope. It builds and installs but doesn't work (already tried this one.) Attempting to ask it for the number of boards returns 0. This may have something to do with changes made to the device structure(s) in FreeBSD-7 (I don't have a 6 machine to test on any more) but it definitely does not function. It works fine for me on very recent 7-STABLE. megacli -CfgDsply -a0 == Adapter: 0 Product Name: PERC 5/i Integrated Memory: 256MB BBU: Present Serial No: 12345 == -cut- megacli -AdpAllInfo -aALL also works without a problem. 7.0-STABLE-200805 FreeBSD 7.0-STABLE-200805 #0: Sun May 11 11:55:15 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? Though I think there is a small bug in the port (maintainer CCed) It wants compat.linux.osrelease=2.6.12, but I think it should be compat.linux.osrelease=2.6.16 ? Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 I think you are confusing mega-cli with megamgr (which is the one that work with amr driver) dbms# megacli -CfgDsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# But the card is definitely there; this is what it last logged when I manually yanked one of the mirrored drives, then shut down and told it to rebuild from the GUI before boot and let it go on its way: mfi0: 501 - PD 10(e252/s1) progress 99% seconds 7017s: Rebuild progress on PD 0a(e0xfc/s1) is 98.94%(7017s) mfi0: 502 - PD 10(e252/s1) progress 100% seconds 7158s: Rebuild progress on PD 0a(e0xfc/s1) is 99.94%(7158s) mfi0: 503 - PD 10(e252/s1) event: Rebuild complete on PD 0a(e0xfc/s1) mfi0: 504 - VD 00/0 state prior 2 new 3: State change on VD 00/0 from DEGRADED(2) to OPTIMAL(3) mfi0: 505 - VD 00/0 event: VD 00/0 is now OPTIMAL mfi0: 506 - PD 10(e252/s1) state prior 20 new 24: State change on PD 0a(e0xfc/s1) from REBUILD(14) to ONLINE(18) Oook! So we have a card that the driver is perfectly happy with, but the management interface can't find. Note that this is the Intel board; I grabbed the Intel version of the software for Linux (which appears to be essentially the same code but under Intel's name), set the branding so the Linux emulator would play nice, and got the same thing: dbms# ./CmdTool2 -Cfgdsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# H... this is on a new machine that I loaded 7-RELEASE on and then grabbed the CVS tree and pulled a -rRELENG_7 on and rebuilt. Let me dig around a bit. I wonder if I got a funny in here... looking at kernel versions, it appears I might. If so, that's going to be an interesting problem (as in how did that happen?) to figure out. uname -v is returning: FreeBSD 7.0-CURRENT-200608 #0: Mon Jun 16 20:54:25 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC How'd that happen with the tag RELENG_7 in the tag? (and yes, it IS in there in the CVS directory in the Tag file) -- Karl Denninger [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
Hi, Ruben van Staveren wrote: Hi, On 18 Jun 2008, at 12:29, Stefan Lambrev wrote: Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? Though I think there is a small bug in the port (maintainer CCed) It wants compat.linux.osrelease=2.6.12, but I think it should be compat.linux.osrelease=2.6.16 ? Last time I checked it was still 2.6.12. it still is set to that value on our 2950's (running 6.2 and linux_base-fc-4_9) I never saw 2.6.12 in documentation, but you may be right. Tough in ports/UPDATING only 2.6.16 is mention. http://blogs.freebsdish.org/netchild/category/freebsd/linuxolator/ speaks also only for 2.6.16 :) Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 I think you are confusing mega-cli with megamgr (which is the one that work with amr driver) People should only realise that they are running a linux binary under emulation in order to manage their mission critical servers. It is a thing you might not like. It has been always this way with lsi ? Actually the difference now is that we are forced to use tools under beta/experimental linuxolator ;) Regards, Ruben -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
Hi Karl, Karl Denninger wrote: On Wed, Jun 18, 2008 at 01:29:56PM +0300, Stefan Lambrev wrote: Karl Denninger wrote: On Tue, Jun 17, 2008 at 10:05:31PM -0700, Andrew Thompson wrote: On Tue, Jun 17, 2008 at 11:15:30PM -0500, Karl Denninger wrote: Intel SRCSAS18E card in it, and well, the only way I can describe it is oh my GOD! Ok, another followup! Is there a mangement interface program for the mfi driver somewhere? I rooted around in ports but didn't find one, nor on the base system. The Linux ones want to talk to the amr driver which is the older LSI Logic MegaRAID boards, not the newer ones that the mfi driver talks to. No management tool = el-sucko, because you can't rebuild a failed disk or even shut the alarm on the board off! Its sysutils/linux-megacli. Nope. It builds and installs but doesn't work (already tried this one.) Attempting to ask it for the number of boards returns 0. This may have something to do with changes made to the device structure(s) in FreeBSD-7 (I don't have a 6 machine to test on any more) but it definitely does not function. It works fine for me on very recent 7-STABLE. megacli -CfgDsply -a0 == Adapter: 0 Product Name: PERC 5/i Integrated Memory: 256MB BBU: Present Serial No: 12345 == -cut- megacli -AdpAllInfo -aALL also works without a problem. 7.0-STABLE-200805 FreeBSD 7.0-STABLE-200805 #0: Sun May 11 11:55:15 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 Did you follow all steps from ports/sysutils/linux-megacli/pkg-message ? Though I think there is a small bug in the port (maintainer CCed) It wants compat.linux.osrelease=2.6.12, but I think it should be compat.linux.osrelease=2.6.16 ? Just for reference I installed it with OVERRIDE_LINUX_BASE_PORT=f8 I think you are confusing mega-cli with megamgr (which is the one that work with amr driver) dbms# megacli -CfgDsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# Sorry if you already answer this and I missed it, but do you have mfi_linux, linprocfs, linsysfs loaded as modules (or build in kernel)? Also do you have mounted: linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) If this is done I'm really out of ideas. But the card is definitely there; this is what it last logged when I manually yanked one of the mirrored drives, then shut down and told it to rebuild from the GUI before boot and let it go on its way: mfi0: 501 - PD 10(e252/s1) progress 99% seconds 7017s: Rebuild progress on PD 0a(e0xfc/s1) is 98.94%(7017s) mfi0: 502 - PD 10(e252/s1) progress 100% seconds 7158s: Rebuild progress on PD 0a(e0xfc/s1) is 99.94%(7158s) mfi0: 503 - PD 10(e252/s1) event: Rebuild complete on PD 0a(e0xfc/s1) mfi0: 504 - VD 00/0 state prior 2 new 3: State change on VD 00/0 from DEGRADED(2) to OPTIMAL(3) mfi0: 505 - VD 00/0 event: VD 00/0 is now OPTIMAL mfi0: 506 - PD 10(e252/s1) state prior 20 new 24: State change on PD 0a(e0xfc/s1) from REBUILD(14) to ONLINE(18) Oook! So we have a card that the driver is perfectly happy with, but the management interface can't find. Note that this is the Intel board; I grabbed the Intel version of the software for Linux (which appears to be essentially the same code but under Intel's name), set the branding so the Linux emulator would play nice, and got the same thing: dbms# ./CmdTool2 -Cfgdsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# H... this is on a new machine that I loaded 7-RELEASE on and then grabbed the CVS tree and pulled a -rRELENG_7 on and rebuilt. Let me dig around a bit. I wonder if I got a funny in here... looking at kernel versions, it appears I might. If so, that's going to be an interesting problem (as in how did that happen?) to figure out. uname -v is returning: FreeBSD 7.0-CURRENT-200608 #0: Mon Jun 16 20:54:25 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC How'd that happen with the tag RELENG_7 in the tag? (and yes, it IS in there in the CVS directory in the Tag file) -- Karl Denninger [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
On 18 Jun 2008, at 16:07, Stefan Lambrev wrote: Last time I checked it was still 2.6.12. it still is set to that value on our 2950's (running 6.2 and linux_base-fc-4_9) I never saw 2.6.12 in documentation, but you may be right. Tough in ports/UPDATING only 2.6.16 is mention. http://blogs.freebsdish.org/netchild/category/freebsd/linuxolator/ speaks also only for 2.6.16 :) I got this from reading the commit message of r1.5 of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/mfi.c I don't know what the change set between 2.6.12 and 2.6.16 is regarding the linuxolator. As I see it the difference should only in more syscalls being supported. So if megacli has enough to get going on by setting it to just 2.6.12 it should not have a requirement for 2.6.16. Correct me if I am wrong (and I'll fix the instructions in the port) Of course, if you think mfi(4) should support your board csup up to the latest stable and see whether it works. Also run through /usr/ local/sbin/megacli instead of /usr/local/libexec/MegaCli as it will perform some sanity checks. People should only realise that they are running a linux binary under emulation in order to manage their mission critical servers. It is a thing you might not like. It has been always this way with lsi ? Actually the difference now is that we are forced to use tools under beta/experimental linuxolator ;) Sad but true. But I managed with ease to replace a hot spare not that long ago. You might want to have a peek at the cheat sheet hosted at http://tools.rapidsoft.de/perc/ Cheers, Ruben PGP.sig Description: This is a digitally signed message part
Re: Management interface for cards powered by the mfi driver?
Hi Ruben, Ruben van Staveren wrote: On 18 Jun 2008, at 16:07, Stefan Lambrev wrote: Last time I checked it was still 2.6.12. it still is set to that value on our 2950's (running 6.2 and linux_base-fc-4_9) I never saw 2.6.12 in documentation, but you may be right. Tough in ports/UPDATING only 2.6.16 is mention. http://blogs.freebsdish.org/netchild/category/freebsd/linuxolator/ speaks also only for 2.6.16 :) I got this from reading the commit message of r1.5 of http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/mfi/mfi.c I don't know what the change set between 2.6.12 and 2.6.16 is regarding the linuxolator. As I see it the difference should only in more syscalls being supported. So if megacli has enough to get going on by setting it to just 2.6.12 it should not have a requirement for 2.6.16. Correct me if I am wrong (and I'll fix the instructions in the port) Yes that's correct, so the sanity check should be = 2.6.12, not just equal to 2.6.12? Of course, if you think mfi(4) should support your board csup up to the latest stable and see whether it works. Also run through /usr/local/sbin/megacli instead of /usr/local/libexec/MegaCli as it will perform some sanity checks. I do not have problems with mfi and megacli ;) It's the OP who have them. People should only realise that they are running a linux binary under emulation in order to manage their mission critical servers. It is a thing you might not like. It has been always this way with lsi ? Actually the difference now is that we are forced to use tools under beta/experimental linuxolator ;) Sad but true. But I managed with ease to replace a hot spare not that long ago. You might want to have a peek at the cheat sheet hosted at http://tools.rapidsoft.de/perc/ nice site :) Cheers, Ruben -- Best Wishes, Stefan Lambrev ICQ# 24134177 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
dbms# ./CmdTool2 -Cfgdsply -a0 Failed to get ControllerId List. Failed to get CpController object. dbms# H... this is on a new machine that I loaded 7-RELEASE on and then grabbed the CVS tree and pulled a -rRELENG_7 on and rebuilt. Let me dig around a bit. I wonder if I got a funny in here... looking at kernel versions, it appears I might. If so, that's going to be an interesting problem (as in how did that happen?) to figure out. uname -v is returning: FreeBSD 7.0-CURRENT-200608 #0: Mon Jun 16 20:54:25 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC How'd that happen with the tag RELENG_7 in the tag? (and yes, it IS in there in the CVS directory in the Tag file) -- Karl Denninger [EMAIL PROTECTED] Ok, wiped the src tree, re-cvs'd out the RELENG_7, rebuild world and kernel and reinstalled (nice fast machine eh?) Anyway, no change: dbms# uname -v FreeBSD 7.0-STABLE #1: Wed Jun 18 14:43:29 CDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC dbms# megacli -adpCount Controller Count: 0. dbms# megacli -Cfgdsply -a0 Failed to get ControllerId List. Failed to get CpController object. Still no joy dbms# kldstat Id Refs AddressSize Name 1 17 0xc040 943140 kernel 21 0xc0d44000 6a2c4acpi.ko 31 0xc5534000 7000 linprocfs.ko 43 0xc553b000 22000linux.ko 51 0xc5585000 3000 linsysfs.ko 61 0xc7a34000 3000 daemon_saver.ko 71 0xc7c2d000 2000 mfi_linux.ko Says I got the proper KLDs loaded. dbms# mount /dev/mfid0s1a on / (ufs, local, soft-updates) devfs on /dev (devfs, local) /dev/mfid0s1e on /dbms (ufs, local, soft-updates) /dev/mfid0s1d on /usr (ufs, local, soft-updates) linprocfs on /usr/compat/linux/proc (linprocfs, local) linsysfs on /usr/compat/linux/sys (linsysfs, local) The two linux look-sees are there. So it looks like all the pre-reqs are there, but it still doesn't work. Here's the ID on the card and volume: mfi0: 524 (267116948s/0x0020/0) - Adapter ticks 267116948 elapsed 61s: Time established as 06/18/08 15:09:08; (61 seconds since power on) mfid0: MFI Logical Disk on mfi0 mfid0: 237464MB (486326272 sectors) RAID volume '' is optimal What am I missing? -- Karl Denninger [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR on sleepqueue chain locks, Was: LOR sleepq/scrlock
On Friday 09 May 2008 10:53:15 pm Aristedes Maniatis wrote: On 23/04/2008, at 3:34 AM, John Baldwin wrote: The real problem at the bottom of the screen though is a real issue. It's a LOR of two different sleepqueue chain locks. The problem is that when setrunnable() encounters a swapped out thread it tries to wakeup proc0, but if proc0 is asleep (which is typical) then its thread lock is a sleep queue chain lock, so waking up a swapped out thread from wakeup() will usually trigger this LOR. I think the best fix is to not have setrunnable() kick proc0 directly. Perhaps setrunnable() should return an int and return true if proc0 needs to be awakened and false otherwise. Then the the sleepq code (b/c only sleeping threads can be swapped out anyway) can return that value from sleepq_resume_thread() and can call kick_proc0() directly once it has dropped all of its own locks. -- John Baldwin The way you describe it, it almost sounds like this LOR should be happening for everyone, all the time. To try and eliminate the factors which trigger it for us, we tried the following: removed PAE from kernel, disabled PF. Neither of these things made any difference and the error is fairly quickly reproducible (within a couple of hours running various things to load the machine). The one thing we did not test yet is removing ZFS from the picture. Note also that this box ran for years and years on FreeBSD 4.x without a hiccup (non PAE, ipfw instead of pf and no ZFS of course). There are two things. 1) Most people who run witness (that I know of) don't run it on spinlocks because of the overhead, so LORs of spin locks are less well-reported than LORs of other locks (mutexes, rwlocks, etc.). 2) You have to have enough load on the box to swap out active processes to get into this situation. Between those I think that is why this is not more widely reported. Hi John, Thanks for your efforts so far to track this LOR down. I've been keeping an eye on cvs logs, but haven't seen anything which looks like a patch for this. * is this still outstanding? * or will it be addressed soon? * if not, should I create a PR so that it doesn't get forgotten? * in our case, although we can trigger it quickly with some load, the problem occurs (and causes a complete machine lock) even under 10% load. Not sure if the combination of PAE/ZFS/SCHED ULE exacerbates that in any way compared to a 'standard' build. Try http://www.FreeBSD.org/~jhb/patches/sleepq.patch -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
arl(4) MPSAFE patch -- test or driver will be removed!
I have a patch to make arl(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/arl.patch -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
cnw(4) MPSAFE patch -- test or driver will be removed!
I have a patch to make cnw(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/cnw.patch -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sbni(4) MPSAFE patch -- test or driver will be removed!
I have a patch to make sbni(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/sbni.patch -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sbsh(4) MPSAFE patch -- test or driver will be removed!
I have a patch to make sbsh(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/sbsh.patch This driver has very dubious behavior in that it sleeps in lots of places when it shouldn't. I doubt it works properly even with Giant. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
snc(4) MPSAFE patch -- test or driver will be removed!
I have a patch to make snc(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/snc.patch Note that this patch is relative to some cleanups done in HEAD a while ago. You should be able to just grab the snc(4) files from HEAD and apply the patch to test this on 6.x or 7.x. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
oltr(4) MPSAFE patch -- test or driver will be removed!
I have a patch to make oltr(4) MPSAFE. However, I am unable to test it. If no one is able to test patches for this driver, it will be removed. I posted the patch to current@ several weeks ago. If I do not hear anything within a week I will remove the driver from HEAD (and thus 8.0). http://www.FreeBSD.org/~jhb/patches/oltr.patch -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 deadlock (vm_map?) with DDB output
John Baldwin wrote: Try this change: jhb 2007-10-27 22:07:40 UTC snip We use it at work on 6.x. W/o this fix, round-robin stops working on 4BSD when softclock() (swi4: clock) blocks on a lock like Giant. Awesome. Thanks. That looks like it'll do the trick. I'll deploy it and keep the list posted. Stef ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Management interface for cards powered by the mfi driver?
Karl Denninger writes: [snip] | Ok, wiped the src tree, re-cvs'd out the RELENG_7, rebuild world and kernel | and reinstalled (nice fast machine eh?) Not needed since FreeBSD 6.2 if I recall right. Forget if I got it in 6.1. | Anyway, no change: | | dbms# uname -v | FreeBSD 7.0-STABLE #1: Wed Jun 18 14:43:29 CDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC | | dbms# megacli -adpCount | | Controller Count: 0. | | dbms# megacli -Cfgdsply -a0 | | Failed to get ControllerId List. | Failed to get CpController object. | | Still no joy | | dbms# kldstat | Id Refs AddressSize Name | 1 17 0xc040 943140 kernel | 21 0xc0d44000 6a2c4acpi.ko | 31 0xc5534000 7000 linprocfs.ko | 43 0xc553b000 22000linux.ko | 51 0xc5585000 3000 linsysfs.ko | 61 0xc7a34000 3000 daemon_saver.ko | 71 0xc7c2d000 2000 mfi_linux.ko | | Says I got the proper KLDs loaded. | | dbms# mount | /dev/mfid0s1a on / (ufs, local, soft-updates) | devfs on /dev (devfs, local) | /dev/mfid0s1e on /dbms (ufs, local, soft-updates) | /dev/mfid0s1d on /usr (ufs, local, soft-updates) | linprocfs on /usr/compat/linux/proc (linprocfs, local) | linsysfs on /usr/compat/linux/sys (linsysfs, local) | | The two linux look-sees are there. | | So it looks like all the pre-reqs are there, but it still doesn't work. | | Here's the ID on the card and volume: | | mfi0: 524 (267116948s/0x0020/0) - Adapter ticks 267116948 elapsed 61s: Time established as 06/18/08 15:09:08; (61 seconds since power on) | mfid0: MFI Logical Disk on mfi0 | mfid0: 237464MB (486326272 sectors) RAID volume '' is optimal | | What am I missing? The linux version sysctl is? Also I think you need to make sure mfi_linux.ko is loaded before linuxsys.ko mounts so you get the emulation hooks. Verify that via: head /compat/linux/sys/class/scsi_host/*/proc_name results in one saying: megaraid_sas or it won't think it is there. The count is good to see if your file system linux version sysctl stuff is in the right state. Once it detects it, then the ioctl should work. 6-stable, 7-stable and -current all have the latest stuff to support all of the ioctl stuff as Linux does for MegaCli. MegaCli does various things to try to find the card in Linux that is really strange IMHO. For FreeBSD it doesn't have to be that complicated. They unfortunately, have not released a FreeBSD MegaCli which they could ... Doug A. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
