Re: RELENG_7/i386: ZFS constant panic on file system writes
On Fri, 3 Apr 2009, Dmitry Morozovsky wrote: DM> Pawel, DM> DM> could you please help me a bit with *very* unpleasant situation: one of my DM> servers with very large ZFS reboots on most write requests to one (largest, DM> which effectively prohibits recreating) ZFS file system with DM> DM> panic: avl_find() succeeded inside avl_add() Is there a way I can clear the directory in question? Even the latest -current panics when I try to access the directory containing this file. DM> DM> (kgdb) bt DM> #0 doadump () at pcpu.h:196 DM> #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 DM> #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. DM> ) at /usr/src/sys/kern/kern_shutdown.c:574 DM> #3 0xc0836a20 in avl_add (tree=Variable "tree" is not available. DM> ) at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 DM> #4 0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, DM> fatreader=1, zapp=0xfc6907f8) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 DM> #5 0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc DM> "daily.20080701.gz", integer_size=8, num_integers=1, buf=0xfc69083c) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 DM> #6 0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, DM> name=0xfc6908bc "daily.20080701.gz", zpp=0xfc690874, flag=Variable "flag" is DM> not available. DM> ) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 DM> #7 0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc DM> "daily.20080701.gz", vpp=0xfc690b5c) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 DM> #8 0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) DM> at DM> /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 DM> #9 0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at DM> vnode_if.c:153 DM> #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 DM> #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at DM> vnode_if.c:99 DM> #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 DM> #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 DM> #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088 0xbfbfd088 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xfc690c18) DM> at /usr/src/sys/kern/vfs_syscalls.c:2184 DM> #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at DM> /usr/src/sys/kern/vfs_syscalls.c:2167 DM> #16 0xc06d0288 in syscall (frame=0xfc690d38) at DM> /usr/src/sys/i386/i386/trap.c:1090 DM> #17 0xc06b5bc0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 DM> #18 0x0033 in ?? () DM> Previous frame inner to this frame (corrupt stack?) DM> DM> this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ DM> DM> Thanks in advance. DM> DM> -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ 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"
more automated fetch of ISO-IMAGES & ports
Hi stable@ people, Idea for a SOC or other development: Not all ftp sites carry betas (understandably), that raises an inefficiency of human & net resources also seen similarly on ports/ , eg: I tried to download 7.2-BETA to test, Not on local ftp://ftp2.de.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 ftp://ftp.de.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 Found manually on ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 but slow at 60 KB/s Faster @ 100K from USA ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 but I'd feel guilty loading main site & intercontinental band width. One could rustle up a ports/ entry to fetch ISO-IMAGES automatically from a list of nearest local national sites, using MASTER_SITE_BACKUP &/or MASTER_SITE_OVERRIDE, But does a pseudo port or tool exist already ? Choosing ftp site just by country is crude, (albeit better than global as once was), but if client is near national border, another country's adjacent city might be a nearer & faster server. Some servers for ports/ fetch are also incredibly slow, but fetch will hang in there trying, even if another site lower in the list might be nearer &/or faster. Perhaps some SOC student might like to develop some extension to fetch, or a new tool to intelligently save net bandwidth & human time (if not this year if SOC bids are in, then next) : Intelligently & automatically sniff fetch list to see where stuff is, measure the bandwidth, perhaps on a preliminary README, & automatically decide where to fetch from. & as 2nd stage, give up & try elsewhere if the server connection gets too bad. Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.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: RELENG_7/i386: ZFS constant panic on file system writes
On Tue, Apr 07, 2009 at 02:00:28PM +0400, Dmitry Morozovsky wrote: > On Fri, 3 Apr 2009, Dmitry Morozovsky wrote: > > DM> Pawel, > DM> > DM> could you please help me a bit with *very* unpleasant situation: one of > my > DM> servers with very large ZFS reboots on most write requests to one > (largest, > DM> which effectively prohibits recreating) ZFS file system with > DM> > DM> panic: avl_find() succeeded inside avl_add() > > Is there a way I can clear the directory in question? Even the latest > -current > panics when I try to access the directory containing this file. Could you try running 'zpool scrub' on this pool? Nothing better comes to my mind, it looks like some kind of internal inconsistency and hopefully scrub will be able to find it. Could you also show 'zpool status' output? -- Pawel Jakub Dawidek http://www.wheel.pl p...@freebsd.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpBHFdAoGWBK.pgp Description: PGP signature
Re: more automated fetch of ISO-IMAGES & ports
On 2009-4-7, at 14:21, Julian Stacey wrote: Perhaps some SOC student might like to develop some extension to fetch, or a new tool to intelligently save net bandwidth & human time (if not this year if SOC bids are in, then next) : Intelligently & automatically sniff fetch list to see where stuff is, measure the bandwidth, perhaps on a preliminary README, & automatically decide where to fetch from. & as 2nd stage, give up & try elsewhere if the server connection gets too bad. Use BitTorrent for all file distribution, it does all that. Yes, I'm half serious. Lars
Re: more automated fetch of ISO-IMAGES & ports
On 2009-4-7, at 15:59, Andrei Kolu wrote: What about this: # cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash # fastest_cvsup -c us,ee,ru,eu,uk,de,no,se RTT != throughput, and not all files are available via cvsup Lars
Re: more automated fetch of ISO-IMAGES & ports
Hi stable@ people, Ref my: > Found manually on > ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > but slow at 60 KB/s > Faster @ 100K from USA > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > but I'd feel guilty loading main site & intercontinental band width. Erwin Lansing emailed me off list: > ... Are you sure you hit the US mirror? ftp.freebsd.org is a DNS round > robin between a US and a danish mirror, so my guess would be that > if you'd have hit the danish one, it would have been faster. ... Thanks Erwin, You're right, nslookup: Name: ftp.freebsd.org Address: 87.51.34.132 Address: 204.152.184.73 For me in Munich Germany the Danish mirror 87.51.34.132 ftp.beastie.tdk.net. is 10 times faster than USA. 204.152.184.73 freebsd.isc.org. But I wouldn't want to load Denmark needlessly either, so look forward to reading follow up I see starting re. bitorrent & fastest_cvsup etc. Thanks all ! Cheers, Julian -- Julian Stacey: BSDUnixLinux C Prog Admin SysEng Consult Munich www.berklix.com Mail plain ASCII text. HTML & Base64 text are spam. www.asciiribbon.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: more automated fetch of ISO-IMAGES & ports
Lars Eggert wrote: On 2009-4-7, at 14:21, Julian Stacey wrote: Perhaps some SOC student might like to develop some extension to fetch, or a new tool to intelligently save net bandwidth & human time (if not this year if SOC bids are in, then next) : Intelligently & automatically sniff fetch list to see where stuff is, measure the bandwidth, perhaps on a preliminary README, & automatically decide where to fetch from. & as 2nd stage, give up & try elsewhere if the server connection gets too bad. Use BitTorrent for all file distribution, it does all that. Yes, I'm half serious. Lars What about this: # cd /usr/ports/sysutils/fastest_cvsup && make install clean && rehash # fastest_cvsup -c us,ee,ru,eu,uk,de,no,se ___ 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: more automated fetch of ISO-IMAGES & ports
On Tue, 7 Apr 2009, Julian Stacey wrote: Some servers for ports/ fetch are also incredibly slow, but fetch will hang in there trying, even if another site lower in the list might be nearer &/or faster. There is a tool called fastest_sites that uses round trip for the tcp hanshake wich is a little bit better than ping. I wrote about it here: http://www.arnold.se/chris/2008/11/how-to-speed-up-downloading-ports/ But the real solution is to do this the right waw. And we are a couple of people involved in making this happen. Notheing ready yet but be shure you will read all about it soon on a mailling list close to you... /Chris -- http://www.arnold.se/chris ___ 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: more automated fetch of ISO-IMAGES & ports
On Tue, 7 Apr 2009, Julian Stacey wrote: > Hi stable@ people, > Ref my: > > Found manually on > >ftp://ftp.uk.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > >but slow at 60 KB/s > > Faster @ 100K from USA > >ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/7.2 > >but I'd feel guilty loading main site & intercontinental band width. > > Erwin Lansing emailed me off list: > > ... Are you sure you hit the US mirror? ftp.freebsd.org is a DNS round > > robin between a US and a danish mirror, so my guess would be that > > if you'd have hit the danish one, it would have been faster. ... > > Thanks Erwin, You're right, nslookup: > Name: ftp.freebsd.org > Address: 87.51.34.132 > Address: 204.152.184.73 > For me in Munich Germany the Danish mirror > 87.51.34.132 ftp.beastie.tdk.net. > is 10 times faster than USA. > 204.152.184.73 freebsd.isc.org. > > But I wouldn't want to load Denmark needlessly either, so look > forward to reading follow up I see starting re. bitorrent & > fastest_cvsup etc. Thanks all ! http://www.mavetju.org/unix/freebsd-mirrors/ usually works for me .. doesn't show RTT or bandwidth directly, but Edwin might even share his secret recipe, offered enough $beer .. The 10 day score overview indeed shows .de mirrors improving yesterday from a not so hot score recently, and 7.2-BETA only on a few so far. cheers, Ian ___ 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: more automated fetch of ISO-IMAGES & ports
> From: Lars Eggert > Date: Tue, 7 Apr 2009 15:55:20 +0300 > Sender: owner-freebsd-sta...@freebsd.org > > On 2009-4-7, at 14:21, Julian Stacey wrote: > > Perhaps some SOC student might like to develop some extension to > > fetch, or a new tool to intelligently save net bandwidth & human > > time (if not this year if SOC bids are in, then next) : > > Intelligently & automatically sniff fetch list to see where > > stuff is, measure the bandwidth, perhaps on a preliminary > > README, & automatically decide where to fetch from. > > & as 2nd stage, give up & try elsewhere if the server > > connection gets too bad. > > Use BitTorrent for all file distribution, it does all that. Yes, I'm > half serious. Why only half? I have pulled FreeBSD ISOs via torrent and it was stunning to see the performance. The system I was loading it to had (at the time) only a fastE (100Mbps), but it loaded at a steady 90+ Mbps and spent a lot of time above 95M. Now that I am connected from that system at 1000M, I should see how it does. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: more automated fetch of ISO-IMAGES & ports
On 2009-4-7, at 17:55, Kevin Oberman wrote: Use BitTorrent for all file distribution, it does all that. Yes, I'm half serious. Why only half? I have pulled FreeBSD ISOs via torrent and it was stunning to see the performance. Half, because getting a BitTorrent infrastructure in place for the ports distfiles wold take a bit of effort. Lars The system I was loading it to had (at the time) only a fastE (100Mbps), but it loaded at a steady 90+ Mbps and spent a lot of time above 95M. Now that I am connected from that system at 1000M, I should see how it does. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
Re: more automated fetch of ISO-IMAGES & ports
BitTorrent is NOT always a good solution . I tried it on an approximately 4.5 Giga Bytes iso which came out to be unusable because - direct download is taken minimum 12 hours with a 1024 kilo bits per second down load speed , in average 18 hours from Turkey . - BitTorrent download is reaching in average to 45 hours due to 256 kilo bits up loads where my PC is also used as a server for down loaders to share my downloaded parts . I am not escaping to help to other people but to find a 45 hours continuous time without destructive voltage fluctuations and nearly dedicate a PC so much time is difficult . On Tue, Apr 7, 2009 at 8:55 AM, Lars Eggert wrote: > On 2009-4-7, at 14:21, Julian Stacey wrote: > >> Perhaps some SOC student might like to develop some extension to >> fetch, or a new tool to intelligently save net bandwidth & human >> time (if not this year if SOC bids are in, then next) : >>Intelligently & automatically sniff fetch list to see where >>stuff is, measure the bandwidth, perhaps on a preliminary >>README, & automatically decide where to fetch from. >>& as 2nd stage, give up & try elsewhere if the server >>connection gets too bad. >> > > Use BitTorrent for all file distribution, it does all that. Yes, I'm half > serious. > > Lars ___ 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: more automated fetch of ISO-IMAGES & ports
> Date: Tue, 7 Apr 2009 11:13:25 -0400 > From: Mehmet Erol Sanliturk > Sender: owner-freebsd-sta...@freebsd.org > > BitTorrent is NOT always a good solution . > > I tried it on an approximately 4.5 Giga Bytes iso which came out to be > unusable because > > - direct download is taken minimum 12 hours with a 1024 kilo bits per second > down load speed , > in average 18 hours from Turkey . > > - BitTorrent download is reaching in average to 45 hours due to 256 kilo > bits up loads where > my PC is also used as a server for down loaders to share my downloaded > parts . > > I am not escaping to help to other people but to find a 45 hours continuous > time without destructive voltage fluctuations and nearly dedicate a PC so > much time is difficult . No, bittorrent is should not replace conventional tranfers. It would be an additional way to distribute large data sets (like the DVD image). There are many cases, like this one, where it is not a good fit. That is true of most tools. Where it is a good fit, it works extremely well. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ 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: powerd broken
Robert Noland wrote: > On Sat, 2009-04-04 at 12:31 +0200, Dominic Fandrey wrote: >> Robert Noland wrote: >>> On Fri, 2009-04-03 at 11:43 +0200, Dominic Fandrey wrote: Alexander Motin wrote: > Dominic Fandrey wrote: >> I can rule out drm0 as the cause, because uhci0 is the only common >> presence in all occurrences of this problem. > You have other examples? If you mean "irq16: hdac0 uhci+" string, then > "+" there means "and some other devices", which in this case is probably > drm0. > > There were some drm related commits last time and there are also some > IRQ related problems were reported/patched in CURRENT recently. So I > would not ignore this possibility without additional testing. > Is there anything I can do, apart from turning off drm? This is really annoying (well, it eats a whole core while I'm compiling and it keeps the fans going, when the machine should be idle). Is there somehow I can generate useful information? Someone to send a kernel dump to? >>> Use a radeon? ;( >> Nay, I use an Intel GM965. >> >>> I've been working on the Intel vblank / irq issues. Every time I commit >>> something thinking that I have it resolved, it isn't. So I'm waiting on >>> hardware to arrive that will let me test this all more thoroughly. I do >>> have a patch that I think fixes most of the issues on Intel, but the ddx >>> driver is still doing some silly things that cause issues in some cases. >>> I *think* the only outstanding issue I have with Intel is if something >>> is rendering (synced to vblank or not) when the display goes into dpms >>> sleep, there isn't anything to block that app, so it renders as hard as >>> it can even though it isn't being displayed. In reality, this probably >>> isn't a huge issue, but running gears while the display is asleep keeps >>> the cpu at 100%, which isn't ideal. Normal apps that aren't trying to >>> draw as fast as they can, shouldn't cause an issue. >>> >>> The other issue with my current patches is that I had to change around a >>> fair amount of infrastructure code to try and fix Intel's brain damage, >>> so I have to finish fixing the rest of the drivers so they don't break. >>> I have Intel and radeon fixed, I just have to hit the more obscure >>> drivers. >>> >>> robert. >> So it appears all I've got to do is wait. Correct me if I'm wrong. > > You can set the tuneable hw.drm.msi=0 for now and see if that helps. I > haven't followed this whole thread, but the primary issue that people > were having is that interrupts would not work after a vt switch with > msi. So, it that isn't your issue, you may need to look elsewhere. That doesn't make any difference. Turning hardware acceleration helps, though. However I cannot play Quake that way. ___ 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"
SMART for mpt raid.
Hi, I have a mpt raid and want to run smart on the individual drives. But the examples in the config all seems linux-specific. Is there a way to get SMART-status for the drives in a mpt-raid? -- Peter Ankerstål pe...@pean.org http://www.pean.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: hald/geom(?) lock up
[redirected from -current] Seeing a similar locking issue on stable/7 as of April 5 now (I guess some pieces merged from -current caused that). 2009/2/10 pluknet : > Hi all. > > On recent -current after inserting a CD my system locks up in a few minutes. > Any commands I tried then lock on sysctl lock; i.e. ctrl+t returns: > load: 0.04 cmd: sudo 1008 [sysctl lock] 0.00u 0.00s 0% 312k > > FreeBSD 8.0-CURRENT #19: Tue Feb 10 00:24:21 UTC 2009 > > Captured ddb (partially transcribed as ddb capture does not return some data): > > db> show alllocks > > Process 924 (sshd) thread 0xc5d606c0 (100107) > exclusive sx so_rcv_sx ... uipc_sockbuf.c:148 > Process 890 (hald-addon-storage) thread 0xc5afd240 (100091) > exclusive sx GEOM topology ... geom_dev.c:171 > Process 880 (hald) thread 0xc5d60900 (100106) > exclusive sx sysctl lock ... kern_sysctl.c:1510 > Process 12 (intr) thread 0xc5663000 (100023) > exclusive sleep mutex Giant ... kbdmux.c:1044 > db> bt 890 > > Tracing pid 890 tid 100091 td 0xc5afd240 > sched_switch(c5afd240,0,104,18d,ae7e8399,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200 > sleepq_switch(c5afd240,0,c0805c50,26a,2,...) at sleepq_switch+0x15f > sleepq_timedwait(c089b424,0,c07f05e9,2,0,...) at sleepq_timedwait+0x6b > _sleep(c089b424,0,0,c07f05e9,1f4,...) at _sleep+0x329 > pause(c07f05e9,1f4,10,c5e170d0,c5986200,...) at pause+0x47 > acd_geom_access(c5986200,1,0,0,0,...) at acd_geom_access+0xeb > g_access(c5989340,1,0,0,2000,...) at g_access+0x20b > g_dev_open(c59a0500,1,2000,c5afd240,c052a7b4,...) at g_dev_open+0x104 > devfs_open(e7f1cacc,c5afd240,e7f1cba8,0,e7f1caf4,...) at devfs_open+0xe6 > VOP_OPEN_APV(c0847e80,e7f1cacc,c07fd022,c07fa9c9,c5decb84,...) at > VOP_OPEN_APV+0xa5 > vn_open_cred(e7f1cba8,e7f1cc5c,0,c5512900,c5de47a8,...) at vn_open_cred+0x429 > vn_open(e7f1cba8,e7f1cc5c,0,c5de47a8,3,...) at vn_open+0x33 > kern_openat(c5afd240,ff9c,bfbfe490,0,1,...) at kern_openat+0x110 > kern_open(c5afd240,bfbfe490,0,0,0,...) at kern_open+0x35 > open(c5afd240,e7f1ccf8,c,c0818fe7,c084b2d8,...) at open+0x30 > syscall(e7f1cd38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x281c5fd3, esp = > 0xbfbfe19c, ebp = 0xbfbfe1c8 --- > db> bt 880 > > Tracing pid 880 tid 100106 td 0xc5d60900 > sched_switch(c5d60900,0,104,18d,dc8c7829,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,4c,...) at mi_switch+0x200 > sleepq_switch(c5d60900,0,c0805c50,26a,0,...) at sleepq_switch+0x15f > sleepq_timedwait(c5c8e200,4c,c07f97cd,0,0,...) at sleepq_timedwait+0x6b > _sleep(c5c8e200,0,4c,c07f97cd,3e8,...) at _sleep+0x329 > g_waitfor_event(c0542cb0,c59847e0,2,0,0,...) at g_waitfor_event+0x9c > sysctl_kern_geom_conftxt(c08493c0,0,0,e7f72ba4,e7f72ba4,...) at > sysctl_kern_geom_conftxt+0x58 > sysctl_root(e7f72ba4,0,c0802669,5e6,c5d60900,...) at sysctl_root+0x199 > userland_sysctl(c5d60900,e7f72c10,3,0,bfbfe9c4,...) at userland_sysctl+0x115 > __sysctl(c5d60900,e7f72cf8,18,c08087f9,c084c550,...) at __sysctl+0x94 > syscall(e7f72d38) at syscall+0x2a3 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x28350b3f, esp = > 0xbfbfe8bc, ebp = 0xbfbfe8e8 --- > db> c > > [thread pid 12 tid 100023 ] > Stopped at kdb_enter+0x3a: movl$0,kdb_why > db> ps > > pid ppid pgrp uid state wmesg wchancmd > 1113 932 1113 1001 S+ sysctl l 0xc089b464 ls > 1042 1 1042 0 Ss select 0xc5e3aaa4 sshd > 981 884 880 0 S select 0xc5c950a4 initial thread > 932 868 932 1001 S+ wait 0xc5af7a90 bash > 929 928 929 1001 Ss+ ttyin0xc575e270 bash > 928 924 924 1001 S select 0xc5799624 sshd > 924 1 924 0 Ss sbwait 0xc5df7238 sshd > 890 884 880 0 S acdld0xc089b424 initial thread > 884 880 880 0 S select 0xc5989de4 initial thread > 883 1 883 0 Ss (threaded) console-kit-daemon > 100111 S waitvt 0xc0896f84 console-kit-daemon > 100125 S waitvt 0xc0896fbc console-kit-daemon > 100124 S waitvt 0xc0896fb8 console-kit-daemon > 100123 S waitvt 0xc0896fb4 console-kit-daemon > 100122 S waitvt 0xc0896fb0 console-kit-daemon > 100121 S waitvt 0xc0896fac console-kit-daemon > 100120 S waitvt 0xc0896fa8 console-kit-daemon > 100119 S waitvt 0xc0896fa4 console-kit-daemon > 100118 S waitvt 0xc0896fa0 console-kit-daemon > db> bt 1113 > > Tracing pid 1113 tid 100126 td 0xc5d5f6c0 > sched_switch(c5d5f6c0,0,104,18d,6d4b9014,...) at sched_switch+0x437 > mi_switch(104,0,c0805c50,1d2,0,...) at mi_switch+0x200 > sleepq_switch(c5d5f6c0,0,c0805c50,247,c089b464,...) at sleepq_switch+0x15f > sleepq_wait(c089b464,0,c0802757,3,0
FreeBSD and iSCSI for disks.
Some friends of mine are looking at the new "DroboPro", which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? -- Garance Alistair Drosehn= g...@gilead.netel.rpi.edu Senior Systems Programmer or g...@freebsd.org Rensselaer Polytechnic Instituteor dro...@rpi.edu ___ 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: lockmgr: locking against myself on 7.2-BEA1 (and gmirror dumpdev not working)
Hello. I have been able to reproduce this panic for a while now, and finally decided to build in debugging support for my kernel and obtain a proper panic, backtrace, etc as it's still happening with 7.2-BETA1 (FreeBSD pflog.net 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Tue Apr 7 16:03:17 EDT 2009 r...@pflog.net:/usr/obj/usr/src/sys/PFLOG_DEBUG amd64). The way I've found to reproduce this panic is to mount /usr/obj as tmpfs and repeatedly build world - it generally happens within 30 minutes, but with debugging enabled it took a bit longer to cause it. Here's the fstab entry for /usr/obj: tmpfs /usr/objtmpfs size=2147483648,rw 0 0 Here's the panic on the console when it happened: panic: lockmgr: locking against myself cpuid = 2 KDB: enter: panic [thread pid 61233 tid 100161 ] Stopped at kdb_enter_why+0x3d:movq$0,0x394136(%rip) db> Unfortunately, as mentioned in the subject, I am unable to get a savecore. After show alllocks and bt, I ran "call doadump", which appeared to work fine. However, after rebooting, there was no savecore in /var/crash and running savecore against /dev/mirror/gm1s1b states: # savecore /var/crash /dev/mirror/gm1s1b savecore: first and last dump headers disagree on /dev/mirror/gm1s1b savecore: unsaved dumps found but not saved If I use savecore -f, I get: # savecore -f /var/crash /dev/mirror/gm1s1b savecore: unable to force dump - bad magic savecore: no dumps found Which sounds to me like the swap slice's data was already clobbered. dumpdev appears to be set properly in rc.conf: dumpdev="/dev/mirror/gm1s1b" dumpdir="/var/crash" Here's the gm1 gmirror information, if that's pertinent: Geom name: gm1 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3971893092 Providers: 1. Name: mirror/gm1 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r5w5e6 Consumers: 1. Name: ad4 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 2996899963 2. Name: ad6 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 28724068 Here is a transcription of the output from show alllocks and then bt: show alllocks: Process 61346 (tsort) thread 0xff0008044000 (100084) exclusive sleep mutex vm page queue mutex r = 0 (0x80745e00) locked @ /usr/src/sys/vm/vm_object.c:684 exclusive sleep mutex vm page object (standard object) r = 0 (0xff00a5c34798) locked @ /usr/src/sys/vm/vm_object.c:460 exclusive sx user map r = 0 (0xff0006ccc0070) locked @ /usr/src/sys/vm/vm_map.c:2425 Process 61226 (sh) thread 0xff002ca1aa50 (100318) exclusive sx user map r = 0 (0xff002ca5b070) locked @ /usr/src/sys/vm/vm_map.c:3117 Process 61130 (tsort) thread 0xff002c710370 (100270) exclusive sx user map r = 0 (0xff0008049710) locked @ /usr/src/sys/vm/vm_map.c:3117 Process 89194 (sshd) thread 0xff002c4356e0 (100229) exclusive sx so_rcv_sx r = 0 (0xff000d8a6100) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 21453 (sshd) thread 0xff0018c336e0 (100307) exclusive sx so_rcv_sx r = 0 (0xff0008c113d0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 Process 11200 (pflogd) thread 0xff0005eb (100057) exclusive sx so_rcv_sx r = 0 (0xff00080e36a0) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 and bt: db> bt Tracing pid 61233 tid 100161 td 0xff00088c0a50 kdb_enter_why() at kdb_enter_why+0x3d panic() at panic+0x171 _lockmgr() at _lockmgr+0x861 VOP_LOCK1_AVP() at VOP_LOCK1_AVP+0x9b _vn_lock() at _vn_lock+0x8b vget() at vget+0x108 vm_object_reference() at vm_object_reference+0xbf kern_execve() at kern_execve+0x26a execve() at execve+0x38 syscall() at syscall+0x1d0 Xfast_syscall() at Xfast_syscall+0xab --- syscall (59, FreeBSD ELF64, execve), rip = 0x80091553c, rsp = 0x7fffdd28, rbp = 0x800b07b70 --- Hopefully this is enough information, as I don't have a dump obviously. If more information is needed, I'd prefer if I could fix the gmirror dumpdev issue first so I can have a coredump to use to get additional information without the tedious transcription from digital pictures! Please let me know if anything else is needed, or if there are ideas for how to fix the dumpdev issue for the gmirror. Thanks, Josh ___ 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: lockmgr: locking against myself on 7.2-BEA1 (and gmirror dumpdev not working)
> Unfortunately, as mentioned in the subject, I am unable to get a > savecore. After show alllocks and bt, I ran "call doadump", which > appeared to work fine. However, after rebooting, there was no savecore > in /var/crash and running savecore against /dev/mirror/gm1s1b states: I was able to reproduce the panic and this time, I booted single user mode and I was able to manually call savecore to get /var/crash/vmcore.0 So if there is any additional kgdb output needed, just say the word and I can get it now. Curious why /etc/rc.d/savecore didn't work on a normal reboot after the dump, but that's probably a topic for a separate mail thread. Thanks, Josh ___ 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 and iSCSI for disks.
Garance A Drosihn wrote: Some friends of mine are looking at the new "DroboPro", which makes a lot of disk space available via iSCSI (in addition to firewire 800), and they were wondering how well iSCSI works with FreeBSD. I haven't paid attention to iSCSI support. Is there anyone using it heavily for disk-storage under FreeBSD? Has there been much changed for iSCSI support in the 8.x branch, or is 7.x support working fine? I have some experience with "net/istgt" port and it looks solid compared to OpenBSD implementation "net/iscsi-target". Of course your milage may wary. net/istgt This is an iSCSI target, it serves iSCSI protocol and provides SCSI devices to the initiator (client). WWW:http://shell.peach.ne.jp/aoyama/ ___ 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"
