Re: GEOM label tasting of windows disk hangs on 8.1
On Wed, Aug 11, 2010 at 23:29, Bengt Ahlgren wrote: > Marius Nünnerich writes: > >> On Wed, Aug 11, 2010 at 14:11, Bengt Ahlgren wrote: >>> Hi! >>> >>> When I was trying to install 8.1-REL from the dvd install media on a >>> ThinkPad X40 that has the original Windows XP partitions on its disk, >>> the geom label tasting seems to hang with the disk activity light on. >>> I just submitted this PR: >>> >>> http://www.freebsd.org/cgi/query-pr.cgi?pr=149523 >>> >>> 7.3-REL works just fine. >>> >>> Is this a known issue? >>> >>> I assume that wiping the mbr will fix it, but I will defer that if >>> additional debugging is needed. >> >> Could you please send a hexdump of the first sector of that device? > > Certainly: > > eb 0e 03 1e 01 00 90 02 00 00 00 00 00 00 4e 50 |..NP| > 0010 fa 33 c0 bc 00 7a 8e d0 50 07 50 1f fb fc bf 00 |.3...z..P.P.| > 0020 08 be 00 7c b9 00 01 f3 a5 ea 2e 08 00 00 32 ed |...|..2.| > 0030 bb 00 06 be 02 08 8a 0c b8 01 02 ba 80 00 cd 13 || > 0040 b9 05 00 bb 00 14 51 8b f1 32 ed 8a 8c ff 05 81 |..Q..2..| > 0050 eb 00 02 b8 01 02 ba 80 00 cd 13 59 e2 e8 b3 00 |...Y| > 0060 be 99 05 88 1c be 98 05 88 1c be 97 05 88 1c eb || > 0070 0a b3 01 be 98 05 88 1c e9 9d 00 e8 36 00 3c 01 |6.<.| > 0080 74 ef e8 5c 00 3c 01 74 e8 e8 db 04 be 22 06 80 |t..\.<.t."..| > 0090 3c 00 0f 84 b3 02 80 3c 01 0f 84 63 01 80 3c 02 |<..<...c..<.| > 00a0 0f 84 86 01 be 05 08 0a 04 88 04 b1 01 bb 00 08 || > 00b0 e8 db 00 c3 be 00 06 e8 17 00 be 23 06 80 3c 00 |...#..<.| > 00c0 74 0c 3c 00 74 08 b0 02 e8 d9 ff b0 01 c3 b0 00 |t.<.t...| > 00d0 c3 4e 32 c0 b9 00 02 8b d9 8a 10 32 c2 e2 f8 46 |.N22...F| > 00e0 c3 b9 01 00 51 b8 00 02 f7 e1 05 00 08 8b f0 e8 |Q...| > 00f0 df ff 5e 56 8a 8c 05 06 80 f9 00 74 17 38 c1 75 |..^V...t.8.u| > 0100 0a 59 41 51 83 f9 06 74 0b 75 da 59 b0 01 e8 93 |.YAQ...t.u.Y| > 0110 ff b0 01 c3 59 b0 00 c3 32 ed be 07 08 8a 0c b8 |Y...2...| > 0120 01 02 bb 00 7c ba 80 00 cd 13 8b f3 e8 a2 ff be ||...| > 0130 06 08 8a 24 80 fc 00 74 30 38 c4 74 2c b0 08 e8 |...$...t08.t,...| > 0140 62 ff be af 07 e8 f0 01 be 0e 06 32 ed 8a 0c 80 |b..2| > 0150 c1 01 51 b9 80 3e e8 22 00 59 e2 f6 be 98 05 80 |..Q..>.".Y..| > 0160 3c 01 74 03 e8 99 00 cd 18 be be 09 bf be 7d b9 |<.t...}.| > 0170 20 00 f3 a5 eb 00 ea 00 7c 00 00 50 e4 61 24 10 | ...|..P.a$.| > 0180 8a e0 e4 61 24 10 38 e0 74 f8 e2 f4 58 c3 32 ed |...a$.8.t...X.2.| > 0190 b8 01 03 ba 80 00 cd 13 c3 be 05 06 8a 04 24 0c |..$.| > 01a0 c0 e8 02 c3 be 22 06 88 0c e8 6a 01 c3 00 00 00 |."j.| > 01b0 00 00 00 00 00 00 00 00 cd cc cd cc 00 00 80 01 || > 01c0 01 00 0c ef ff ff 3f 00 00 00 31 0c 25 04 00 00 |..?...1.%...| > 01d0 c1 ff 12 ef ff ff 70 0c 25 04 90 46 83 00 00 00 |..p.%..F| > 01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| > 0200 Hmm, sorry, wrong idea. I wanted to look at the label names itself. But they are part of the FAT label inside the partitions, not part of the first sector. I have no idea how to obtain them. ___ 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: GEOM label tasting of windows disk hangs on 8.1
On Wed, Aug 11, 2010 at 14:11, Bengt Ahlgren wrote: > Hi! > > When I was trying to install 8.1-REL from the dvd install media on a > ThinkPad X40 that has the original Windows XP partitions on its disk, > the geom label tasting seems to hang with the disk activity light on. > I just submitted this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=149523 > > 7.3-REL works just fine. > > Is this a known issue? > > I assume that wiping the mbr will fix it, but I will defer that if > additional debugging is needed. Could you please send a hexdump of the first sector of that device? ___ 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: zpool vdev vs. glabel
2010/2/10 Gerrit Kühn : > On Tue, 9 Feb 2010 13:27:21 -0700 Elliot Finley > wrote about Re: zpool vdev vs. glabel: > > EF> I ran into this same problem. you need to clean the beginning and end > EF> of your disk off before glabeling and adding it to your pool. clean > EF> with dd if=/dev/zero... > > Hm, I think I did that (at least for the beginning part). > Maybe I was not quite clear what I did below: I removed and re-attached > the *same* disk which was labelled with glabel and running fine brefore. > The label was there when I inserted it back, but zfs went for the da > device node anyway. > If I see this problem again, I will try to wipe the complete disk before > re-inserting it. It seems there is some kind of race condition with zfs either picking up the disk itself or the label device for the same disk. I guess it's which ever it probes first. I wrote the GPT part of glabel for using it in situations like this, I had not a single report of this kind of problem with the gpt labels. Maybe you can try them too? My zpool looks like this: % zpool status pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/wd1 ONLINE 0 0 0 gpt/wd2 ONLINE 0 0 0 gpt/wd3 ONLINE 0 0 0 gpt/wd4 ONLINE 0 0 0 gpt/wd5 ONLINE 0 0 0 errors: No known data errors I already physically reordered the devices a few times and it always worked out correctly. ___ 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: lock order reversals in RELENG_8
On Thu, Dec 31, 2009 at 12:10, Pete French wrote: > am still trying to get the machine which ocks up to lock up > when I have DDb, KDB and WITNESS in the ernel. It's not locked yet > but I have got the following in dmesg... > > lock order reversal: > 1st 0xff8052321e50 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2559 > 2nd 0xff000384a800 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2c > witness_checkorder() at witness_checkorder+0x66f > _sx_xlock() at _sx_xlock+0x35 > ufsdirhash_acquire() at ufsdirhash_acquire+0x33 > ufsdirhash_remove() at ufsdirhash_remove+0x18 > ufs_dirremove() at ufs_dirremove+0x161 > ufs_remove() at ufs_remove+0x92 > VOP_REMOVE_APV() at VOP_REMOVE_APV+0x34 > kern_unlinkat() at kern_unlinkat+0x252 > syscall() at syscall+0x19d > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (10, FreeBSD ELF64, unlink), rip = 0x80072a28c, rsp = > 0x7fffe418, rbp = 0x7fffef6e --- > lock order reversal: > 1st 0xff003e230d80 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1058 > 2nd 0xff003e2307f8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2083 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2c > witness_checkorder() at witness_checkorder+0x66f > __lockmgr_args() at __lockmgr_args+0x475 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x46 > _vn_lock() at _vn_lock+0x47 > vget() at vget+0x56 > devfs_allocv() at devfs_allocv+0x103 > devfs_root() at devfs_root+0x48 > vfs_donmount() at vfs_donmount+0xf43 > nmount() at nmount+0x63 > syscall() at syscall+0x19d > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007b062c, rsp = > 0x7fffdd28, rbp = 0x > I think this is LOR #261 and therefore harmless. http://sources.zabbadoz.net/freebsd/lor.html ___ 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: Most files in subversion stable/8/sys touched by bms
On Tue, Dec 29, 2009 at 20:41, Michal Varga wrote: > On Tue, Dec 29, 2009 at 7:37 PM, Oliver Fromme wrote: >> By the way, here is another little tool that can be used to >> watch changes in 8-stable conveniently: >> >> http://www.secnetix.de/olli/FreeBSD/svnews/?p=stable/8/sys >> > Thank you for mentioning this, this is a great tool for everyone to > have around (instantly bookmarked). > > I'd have one question to ask - would you consider adding one more > piece of information to the output, namely "age" of the commit? So > that > > 17:38:50 - r201208 > by rwatson > > would look like: > > 17:38:50 - r201208 (17 hours, 30 minutes old) > by rwatson > > or > > 17:38:50 - r201208 (3 days, 15 hours old) > by rwatson > > etc. > > Little extra like this makes tracking down some specific changes > easier, or makes some quick point of reference where you left the last > time, etc. I guess you get the idea.. It's not exactly critical, just > would be handy to see there, if possible :) I would prefer the name of the timezone. ___ 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: MTRR failure revisited (nVidia) 8-STABLE/RELEASE
On Sat, Dec 12, 2009 at 12:47, Chris H wrote: > Greetings, > I brought this same error to the list back in May 2009. > Under: failed to set mtrr: invalid argument. > Well, I'm back using the same card: > GeForce4 MX 440-SE - VideoRam 65536 - BusID PCI:1:3:0. > The driver is different, I'm using: nvidia-driver-96.43.13 out of ports on a > custom 8-STABLE kernel. Xorg starts up, and produces a desktop. But it's > "dog slow", and the nvidia driver emits the following error: > NVIDIA: failed to set MTRR 0xf000, 0M (write-combining) > several times. I understand John Baldwin provided some "invaluable" help some > time ago: > http://lists.freebsd.org/pipermail/freebsd-hackers/2006-June/016995.html > and I was wondering if anyone has gained any further "insight" with these > cards, > and how to better "interface" them in BSD. Last I spoke on the topic, I was > informed that the memory was basically "untouchable" - or perhaps in other > words; > can't be manipulated. Has this changed? Surely someone else has had to deal > with > this besides me. It seems crazy to spend a "boat load" of $$ on these high > performers, and not be able to use them on a high performing OS - no? :) > Sure, the one I'm working with now is "legacy". But I have 3 near new, top of > their line cards, and thus far it appears that if I ever hope to use them, > I'll > be forced to... hack, choke.. spin up a WIN CD. :( > > Thank you for all your time, consideration, and insight. FreeBSD as of 8.0-RELEASE supports PAT which obsoletes MTRR. It was a requirement for the nvidia amd64 blob. So in the future it should all work fine if you have at least a card which is supported by the newest nvidia driver. ___ 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 8.0 system freeze
On Wed, Dec 2, 2009 at 17:22, Peter Pieczora wrote: > Hi, > > I recently upgraded from 7.2-STABLE to 8.0-RELEASE, and I'm encountering > frequent system freezes (hang ups), which end in a reboot. > > There is no indication of any panic, no messages are generated and no core > dump files (sysctl kern.coredump=1). > > System runs on IBM T43 with intel wireless chipset, iwi modules are loaded > during boot via /boot/loader.conf. > > legal.intel_iwi.license_ack=1 > if_iwi_load="YES" > wlan_load="YES" > firmware_load="YES" > iwi_bss_load="YES" > iwi_ibss_load="YES" > iwi_monitor_load="YES > > Typically msg. look something like that or similar (iwi0 line gets repeated > twice or 3 times): > > Dec 1 22:02:12 local kernel: wlan0: link state changed to DOWN > Dec 1 22:02:19 local kernel: wlan0: link state changed to UP > Dec 1 22:02:19 local kernel: iwi0: need multicast update callback > Dec 1 22:02:30 local kernel: wlan0: link state changed to DOWN > Dec 1 22:04:14 local syslogd: kernel boot file is /boot/kernel/kernel > > Is anyone else seeing this? > > ATM I am at work using bge0 interface and system runs without freezing so far. > Could this situation be attributed to iwi driver or maybe wlandev? I see similar behaviour. stable/8 before the release worked normal. Since a few days I have apps segfaulting frequently (firefox, pidgin, mplayer, ...) and have freezes. I configured Kernel debugging and added a dumpdev but had no luck in getting a dump so far only freezes. I let the system run frozen for more then five minutes to see if it's just dumping in the background (I think one cannot see that while in X). One time the system froze while loading vboxdrv, another time when I started mplayer. But it happens on other occasions too. ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Fri, Nov 20, 2009 at 23:20, Daniel O'Connor wrote: > On Sat, 21 Nov 2009, Marius Nünnerich wrote: >> On Fri, Nov 20, 2009 at 14:27, Daniel O'Connor > wrote: >> > On Fri, 20 Nov 2009, Marius Nünnerich wrote: >> >> > Actually that is an interesting point, the swap partitions don't >> >> > have an entry in /dev/gptid, although perhaps that is because >> >> > glabel has grabbed that node. >> >> >> >> If I remember correctly nodes vanish when another name for the >> >> same device is opened. Maybe this happens for the other gpt labels >> >> too? >> > >> > Hmm, but I have gptid ones corresponding to my ZFS partitions.. It >> > seems like a bug. >> >> Maybe. Could you paste kern.geom.confdot, kern.geom.confxml and mount >> output to pastie.org or the like. > > I've attached it.. Hmm, I do not see whats wrong here. ZFS already opened the devices and I see no /dev/gpt/* entries. Maybe there is some bug with handling the long gptid names. Maybe you try to detach ZFSfrom the devices, give everything a short gpt label and try to use that. ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Fri, Nov 20, 2009 at 14:27, Daniel O'Connor wrote: > On Fri, 20 Nov 2009, Marius Nünnerich wrote: >> > Actually that is an interesting point, the swap partitions don't >> > have an entry in /dev/gptid, although perhaps that is because >> > glabel has grabbed that node. >> >> If I remember correctly nodes vanish when another name for the same >> device is opened. Maybe this happens for the other gpt labels too? > > Hmm, but I have gptid ones corresponding to my ZFS partitions.. It seems > like a bug. Maybe. Could you paste kern.geom.confdot, kern.geom.confxml and mount output to pastie.org or the like. ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Fri, Nov 20, 2009 at 13:32, Daniel O'Connor wrote: > On Fri, 20 Nov 2009, Marius Nünnerich wrote: >> > Maybe the UUID label got their first so it won't have an alias >> > (although the UUID is an alias for /dev/ad4p2..) >> >> Maybe that's been asked already but what version are you using? >> Does glabel work at all? > > 8.0-RC1 > > glabel works fine, I use it for swap. > > Actually that is an interesting point, the swap partitions don't have an > entry in /dev/gptid, although perhaps that is because glabel has > grabbed that node. If I remember correctly nodes vanish when another name for the same device is opened. Maybe this happens for the other gpt labels too? ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Fri, Nov 20, 2009 at 01:48, Daniel O'Connor wrote: > On Thu, 19 Nov 2009, Tom Evans wrote: >> On Thu, Nov 19, 2009 at 12:35 PM, Daniel O'Connor > wrote: >> > On Thu, 19 Nov 2009, Marius Nünnerich wrote: >> > > > operator 0, 164 Oct 21 15:34 >> > > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc >> > > >> > > Have you tried naming the GPT partitions and using /dev/gpt/* ? >> > >> > Nope, how would I do that? >> > >> > I'd be surprised if it worked TBH.. >> >> Use the -l flag to gpart when creating the partitions. I'm not sure >> if there is a way to label them after the fact. I found it led to a >> much more descriptive/reliable pool, as I can plug the disks in >> anywhere and get the same results: > > Descriptive yes, reliable no (IMO :) > > UUIDs should always be more reliable so long as the "UU" part of their > name holds true :) > > No reason you couldn't have both thought. > >> pool: tank >> state: ONLINE >> scrub: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> tank ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> gpt/samsung15-1 ONLINE 0 0 0 >> gpt/samsung15-2 ONLINE 0 0 0 >> gpt/samsung15-3 ONLINE 0 0 0 >> gpt/samsung15-4 ONLINE 0 0 0 >> gpt/seagate15-1 ONLINE 0 0 0 >> gpt/seagate15-2 ONLINE 0 0 0 >> >> I use the geom name 'gpt/foo' when referring to the disks in zpool. >> All works perfectly. > > Hmm I did.. > [midget 11:13] ~ >sudo gpart modify -i 2 -l "Midget-ZFS-1" ad4 > ad4p2 modified > [midget 11:15] ~ >sudo gpart show -l ad4 > => 34 1953525101 ad4 GPT (932G) > 34 8388608 1 (null) (4.0G) > 8388642 1944059904 2 Midget-ZFS-1 (927G) > 1952448546 1076589 - free - (526M) > > but I get no /dev/gpt directory.. > [midget 11:14] ~ >ls -la /dev/gpt > ls: /dev/gpt: No such file or directory > > Maybe the UUID label got their first so it won't have an alias (although > the UUID is an alias for /dev/ad4p2..) Maybe that's been asked already but what version are you using? Does glabel work at all? ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Thu, Nov 19, 2009 at 13:44, Tom Evans wrote: > On Thu, Nov 19, 2009 at 12:35 PM, Daniel O'Connor > wrote: >> >> On Thu, 19 Nov 2009, Marius Nünnerich wrote: >> > > operator 0, 164 Oct 21 15:34 >> > > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc >> > >> > Have you tried naming the GPT partitions and using /dev/gpt/* ? >> >> Nope, how would I do that? >> >> I'd be surprised if it worked TBH.. >> > > Use the -l flag to gpart when creating the partitions. I'm not sure if there > is a way to label them after the fact. I found it led to a much more > descriptive/reliable pool, as I can plug the disks in anywhere and get the > same results: > > pool: tank > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > tank ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > gpt/samsung15-1 ONLINE 0 0 0 > gpt/samsung15-2 ONLINE 0 0 0 > gpt/samsung15-3 ONLINE 0 0 0 > gpt/samsung15-4 ONLINE 0 0 0 > gpt/seagate15-1 ONLINE 0 0 0 > gpt/seagate15-2 ONLINE 0 0 0 > > I use the geom name 'gpt/foo' when referring to the disks in zpool. All > works perfectly. > I never tried it but maybe gpart modify -l works too. ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Thu, Nov 19, 2009 at 01:53, Daniel O'Connor wrote: > On Sun, 15 Nov 2009, Daniel O'Connor wrote: >> > There's no need to detach anything. >> >> I'll try it when I get home and see how it goes. > > Unfortunately I get.. > > [midget 11:20] ~ >sudo zpool replace tank ad4p2 > gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > cannot use '/dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc': must be a GEOM > provider or regular file > [midget 11:20] ~ >ll /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > crw-r- 1 root operator 0, 164 Oct 21 15:34 > /dev/gptid/6866d8b0-a8ac-11de-8e07-00241dd192cc > Have you tried naming the GPT partitions and using /dev/gpt/* ? ___ 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: whats best pracfive for ZFS on a whole disc these days ?
On Wed, Nov 18, 2009 at 23:15, Daniel O'Connor wrote: > On Sun, 15 Nov 2009, Daniel O'Connor wrote: >> > There's no need to detach anything. >> >> I'll try it when I get home and see how it goes. > > How can I show what partition has what UUID? > > gpart list and gpart show do not say.. > > I suspect if I booted verbose glabel would say but that is a bit > annoying :) % sysctl -b kern.geom.confdot | dot -Tpng > foo.png % pkg_which /usr/local/bin/dot graphviz-2.24.0_1 ___ 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: KVM tips for bsd as guest?
On Thu, Nov 12, 2009 at 22:42, Rudy wrote: > > Downloaded iso, but qemu barfs when trying to install --- loads kernel but > panics during boot of 7.2 ( and 8.0-rc3) install ISOs. I am trying to set > up a bsd guest ... Host OS is debian. > > Virtualbox installed no problem. > > I am looking for a general how-to if there is one out there( tried searching > didn't find it). What about sending the kernel panic message (with backtrace)? ___ 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: Funny bug in zfs-snapshot-mgmt
On Sun, Nov 1, 2009 at 20:07, Adam Stylinski wrote: > So I'm not entirely sure which mailing list to post this to in order to > inform the port/package maintainer, and this bug may already be fixed, as > I'm using a package from 7.2-release, but I found a pretty interesting bug. > I live in one of the regions of the US that actually are affected by > Daylight Savings Time, and cron appears to have informed me when naming a > snapshot that there is a duplicate (for obvious reasons): > > cannot create snapshot 'share/dadsh...@auto-2009-11- > 01_01.00': dataset already exists > no snapshots were created > > Perhaps there is a way to use the tzdata distributed with freebsd to rename > this snapshot? > ___ > 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" > Hi, I'm the current maintainer. This bug is not fixed. The simplest solution would be to use UTC times. Another to add the current timezone to the snapshot name. Both not really satisfying. I would just live on with that on mail per year until the nuisance of DST is finally removed from our lives ;) - Marius ___ 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: ale0 gets no carrier
On Thu, Oct 22, 2009 at 21:38, Pyun YongHyeon wrote: > On Thu, Oct 22, 2009 at 09:18:15PM +0200, Milan Obuch wrote: >> On Thursday 22 October 2009 21:05:39 Mike Tancsa wrote: >> > At 02:22 PM 10/22/2009, Marius N?nnerich wrote: >> > >Hi Pyun, all, >> > > >> > >today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros >> > > nic: a...@pci0:2:0:0: class=0x02 card=0x831c1043 >> > > chip=0x10261969 rev=0xb0 hdr=0x00 >> > > vendor = 'Attansic (Now owned by Atheros)' >> > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' >> > > class = network >> > > subclass = ethernet >> > > >> > >ale0: flags=8802 metric 0 mtu 1500 >> > > >> > >options=319a> > >_MAGIC> ether 00:24:8c:a4:0a:b3 >> > > media: Ethernet autoselect (none) >> > > status: no carrier >> > > >> > >The nic gets no carrier at all. I tried against two known-working nics >> > >with a cross-over cable and against a dsl-modem. >> > >Any idea what to try? Will happily test patches. >> > >> > Did you try and give it an IP address so that its >> > "UP" ? Some nics dont seem to have carrier until >> > you put it in UP state with an IP. Try something simple like >> > ifconfig ale0 192.168.255.254/30 >> > >> >> In my case >> >> a...@pci0:2:0:0: class=0x02 card=0x831c1043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> vendor = 'Attansic (Now owned by Atheros)' >> device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' >> class = network >> subclass = ethernet >> >> (exactly the same, as I can see) when configuring interface manually, I need >> to do 'ifconfig ale0 up' before I can successfully acquire IP with 'dhclient >> ale0'. Everything works normally with 'ifconfig_ale0="DHCP"' line >> in /etc/rc.conf. >> > > This is intended behavior as establishing a link requires > negotiation with link-partner and the link state could be changed > after the negotiation. So showing (fake/incorrect) link state > before UPing the interface wouldn't be correct behavior. Ok, sounds plausible. It's just that every other nic I have had worked the other 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"
Re: i am desperate over some GPT tables
On Wed, Oct 21, 2009 at 14:11, Kris Weston wrote: > been looking for months now, trawled google no help, i just dont understand. > do you need a GPT table with zfs ? > i have a pentium D 3ghz (running 64bit stable 7.2) and i cant seem to import > my zpool into it > exported fine on solaris , its definitely the same version (v13) > but when i import into zfs it says GPT tables corrupt ? > why ? and what does this mean ? > please help me. please. Could you provide some more data? What is the error message for example? From the zpool command and maybe what geom says about the GPT in dmesg. ___ 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: ale0 gets no carrier
On Thu, Oct 22, 2009 at 21:05, Mike Tancsa wrote: > At 02:22 PM 10/22/2009, Marius Nünnerich wrote: >> >> Hi Pyun, all, >> >> today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros >> nic: >> a...@pci0:2:0:0: class=0x02 card=0x831c1043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> vendor = 'Attansic (Now owned by Atheros)' >> device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' >> class = network >> subclass = ethernet >> >> ale0: flags=8802 metric 0 mtu 1500 >> >> >> options=319a >> ether 00:24:8c:a4:0a:b3 >> media: Ethernet autoselect (none) >> status: no carrier >> >> The nic gets no carrier at all. I tried against two known-working nics >> with a cross-over cable and against a dsl-modem. >> Any idea what to try? Will happily test patches. > > > Did you try and give it an IP address so that its "UP" ? Some nics dont seem > to have carrier until you put it in UP state with an IP. Try something > simple like > ifconfig ale0 192.168.255.254/30 > > ---Mike Wow! Good idea, that did work! Thanks Marius ___ 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: ale0 gets no carrier
On Thu, Oct 22, 2009 at 20:36, Pyun YongHyeon wrote: > On Thu, Oct 22, 2009 at 08:22:50PM +0200, Marius N?nnerich wrote: >> Hi Pyun, all, >> >> today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros >> nic: >> a...@pci0:2:0:0: class=0x02 card=0x831c1043 chip=0x10261969 >> rev=0xb0 hdr=0x00 >> vendor = 'Attansic (Now owned by Atheros)' >> device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' >> class = network >> subclass = ethernet >> >> ale0: flags=8802 metric 0 mtu 1500 >> >> options=319a >> ether 00:24:8c:a4:0a:b3 >> media: Ethernet autoselect (none) >> status: no carrier >> >> The nic gets no carrier at all. I tried against two known-working nics >> with a cross-over cable and against a dsl-modem. >> Any idea what to try? Will happily test patches. >> > > Would you show me dmesg output related with ale(4)/atphy(4)? > Also show me the output "devinfo -rv | grep phy". Sure: % dmesg|grep ale ale0: port 0xdc00-0xdc7f mem 0xfbec-0xfbef irq 18 at device 0.0 on pci2 ale0: 960 Tx FIFO, 1024 Rx FIFO ale0: Using 1 MSI messages. miibus0: on ale0 ale0: Ethernet address: 00:24:8c:a4:0a:b3 ale0: [FILTER] ale0: link state changed to DOWN % dmesg|grep atphy atphy0: PHY 0 on miibus0 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto % devinfo -rv | grep phy atphy0 pnpinfo oui=0x1374 model=0x1 rev=0x9 at phyno=0 ip1000phy0 pnpinfo oui=0x90c3 model=0x8 rev=0x0 at phyno=24 It is a GENERIC kernel. ___ 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"
ale0 gets no carrier
Hi Pyun, all, today I installed FreeBSD 8-STABLE r198366 on a new Box. It has a Atheros nic: a...@pci0:2:0:0:class=0x02 card=0x831c1043 chip=0x10261969 rev=0xb0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)' device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' class = network subclass = ethernet ale0: flags=8802 metric 0 mtu 1500 options=319a ether 00:24:8c:a4:0a:b3 media: Ethernet autoselect (none) status: no carrier The nic gets no carrier at all. I tried against two known-working nics with a cross-over cable and against a dsl-modem. Any idea what to try? Will happily test patches. - Marius ___ 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: Booting FreeBSD 8.0-RC1 from usb stick
On Tue, Sep 29, 2009 at 16:03, Gavin Atkinson wrote: > On Tue, 2009-09-29 at 14:40 +0200, Marius Nünnerich wrote: >> 2009/9/29 Andrey V. Elsukov : >> > Marius Nu"nnerich wrote: >> >> >> >> Explicitly setting the root partition >> >> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not >> >> help either: Again, the system knows which partition it should mount >> >> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set >> >> too). >> > >> > It's known problem and we are waiting for fix. There is a race between >> > USB and CAM/SCSI subsystems. >> >> OK, thank you! Is there a PR open for this? > > I think your problem is probably usb/138798. Thanks! I hoped there would be some quick fix like putting some DELAY into CAM or usb to go ahead for now but it isn't. Anyone has an idea for where to put this or a patch to try? I suppose usb should finish before CAM comes along? ___ 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: Booting FreeBSD 8.0-RC1 from usb stick
2009/9/29 Andrey V. Elsukov : > Marius Nu"nnerich wrote: >> >> Explicitly setting the root partition >> (vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not >> help either: Again, the system knows which partition it should mount >> to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set >> too). > > It's known problem and we are waiting for fix. There is a race between > USB and CAM/SCSI subsystems. OK, thank you! Is there a PR open for this? ___ 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"
Booting FreeBSD 8.0-RC1 from usb stick
Hi all,
FreeBSD 8.0-RC1 was installed onto hard disk. The root filesystem was
transferred to a usb memory stick via
#pwd
/
# find -print . -x | cpio -pdm /mnt/usbstick
The fstab on the stick was modified such that "/" was to be mounted
from /dev/da0s1a, the ufs fs on the usb stick.
This had proven to work perfectly with 7.2.
In 8.0-RC1, however, this approach fails. After booting the kernel,
the system does not automatically mount the "/" partition. Instead, it
asks for a partition to mount to "/", and when exactly the same
location is entered ("ufs:/dev/da0s1a"), it mounts this partition and
works perfectly.
Explicitly setting the root partition
(vfs.root.mountfrom="ufs:/dev/da0s1a") in /boot/loader.conf does not
help either: Again, the system knows which partition it should mount
to "/", but it fails to do so. (vfs.root.mountfrom.options=rw was set
too).
Any ideas?
Marius
___
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: Zpool on raw disk and weird GEOM complaint
On Mon, Jun 29, 2009 at 16:50, Patrick M. Hausen wrote: > Hi! > > On Mon, Jun 29, 2009 at 04:41:14PM +0200, Marius Nünnerich wrote: >> OK, there is the GPT signature which reads "EFI PART" at offset 0x200. >> What was on the disk before? > > Nothing. Factory new. > >> I think it should look different. There is a document from sun which >> explains the ZFS ondisk format and and I don't remember it to look >> like a MBR and GPT ;) Sorry, I don't have the time right now to dig >> through it. > > As I found with Google, ZFS does put a EFI/GPT label on the > disk if you give it an entire disk as a vdev. Looks like > it's not understood by GEOM_PART_GPT. Hmm, it's rather stupid to put a GPT entry in the second sector but not the corresponding one in the last sector. So our GPT implementation has the right to think this GPT is broken. As far as I understand the ondisk spec from sun there is no space for the corresponding one in the last sector (it's part of the uberblock array). I just checked my ZFS mirror it has all zeros in the first few sectors on both disks. It was created with zfs version 6 in freebsd. ___ 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: Zpool on raw disk and weird GEOM complaint
On Mon, Jun 29, 2009 at 16:41, Marius Nünnerich wrote: > On Mon, Jun 29, 2009 at 16:14, Patrick M. Hausen wrote: >> Hi! >> >> On Mon, Jun 29, 2009 at 03:38:51PM +0200, Marius Nünnerich wrote: >> >>> I'm sorry, it should have said: >>> dd if=/dev/da0 count=4 | hd >> >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff >> || >> 01c0 ff ff ee ff ff ff 01 00 00 00 ff ff ff ff 00 00 >> || >> 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa >> |..U.| >> 0200 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI >> PART\...| >> 0210 2d e8 5e 91 00 00 00 00 01 00 00 00 00 00 00 00 >> |-.^.| >> 0220 ff ff 3f d1 01 00 00 00 22 00 00 00 00 00 00 00 >> |..?."...| >> 0230 de ff 3f d1 01 00 00 00 47 b5 79 82 96 d5 dc 11 >> |..?.G.y.| >> 0240 be 97 00 0a e4 85 78 5e 02 00 00 00 00 00 00 00 >> |..x^| >> 0250 80 00 00 00 80 00 00 00 3e 0b 98 53 00 00 00 00 >> |>..S| >> 0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0400 b6 7c 6e 51 cf 6e d6 11 8f f8 00 02 2d 09 71 2b >> |.|nQ.n..-.q+| >> 0410 16 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |..y...x^| >> 0420 22 00 00 00 00 00 00 00 de ff 3f d1 01 00 00 00 >> |".?.| >> 0430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0490 26 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |&.y...x^| >> 04a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0510 37 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |7.y...x^| >> 0520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0590 48 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |H.y...x^| >> 05a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0610 59 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |Y.y...x^| >> 0620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0690 6a b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |j.y...x^| >> 06a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0710 7a b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |z.y...x^| >> 0720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || >> * >> 0790 8b b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e >> |..y...x^| >> 07a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> || > > OK, there is the GPT signature which reads "EFI PART" at offset 0x200. > What was on the disk before? > I think it should look different. There is a document from sun which > explains the ZFS ondisk format and and I don't remember it to look > like a MBR and GPT ;) Sorry, I don't have the time right now to dig > through it. Found it quickly. Here is the document: http://opensolaris.org/os/community/zfs/docs/ondiskformat0822.pdf See section 1.3.1. ZFS is not cleaning the first 8KB of the raw device so GEOM_PART will taste it and it looks like a broken GPT to it. For future constructions of zpool's one should zero the first few sectors of a device. For your specific I would make a tested backup and then zero the first 1KB of da0. But beware that it's dangerous! Don't blame me if you lose data or hair! ___ 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: Zpool on raw disk and weird GEOM complaint
On Mon, Jun 29, 2009 at 16:14, Patrick M. Hausen wrote: > Hi! > > On Mon, Jun 29, 2009 at 03:38:51PM +0200, Marius Nünnerich wrote: > >> I'm sorry, it should have said: >> dd if=/dev/da0 count=4 | hd > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff || > 01c0 ff ff ee ff ff ff 01 00 00 00 ff ff ff ff 00 00 || > 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| > 0200 45 46 49 20 50 41 52 54 00 00 01 00 5c 00 00 00 |EFI PART\...| > 0210 2d e8 5e 91 00 00 00 00 01 00 00 00 00 00 00 00 |-.^.| > 0220 ff ff 3f d1 01 00 00 00 22 00 00 00 00 00 00 00 |..?."...| > 0230 de ff 3f d1 01 00 00 00 47 b5 79 82 96 d5 dc 11 |..?.G.y.| > 0240 be 97 00 0a e4 85 78 5e 02 00 00 00 00 00 00 00 |..x^| > 0250 80 00 00 00 80 00 00 00 3e 0b 98 53 00 00 00 00 |>..S| > 0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0400 b6 7c 6e 51 cf 6e d6 11 8f f8 00 02 2d 09 71 2b |.|nQ.n..-.q+| > 0410 16 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |..y...x^| > 0420 22 00 00 00 00 00 00 00 de ff 3f d1 01 00 00 00 |".?.| > 0430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0490 26 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |&.y...x^| > 04a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0510 37 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |7.y...x^| > 0520 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0590 48 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |H.y...x^| > 05a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0610 59 b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |Y.y...x^| > 0620 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0690 6a b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |j.y...x^| > 06a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0710 7a b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |z.y...x^| > 0720 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 0790 8b b6 79 82 96 d5 dc 11 be 97 00 0a e4 85 78 5e |..y...x^| > 07a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || OK, there is the GPT signature which reads "EFI PART" at offset 0x200. What was on the disk before? I think it should look different. There is a document from sun which explains the ZFS ondisk format and and I don't remember it to look like a MBR and GPT ;) Sorry, I don't have the time right now to dig through it. ___ 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: Zpool on raw disk and weird GEOM complaint
On Mon, Jun 29, 2009 at 13:46, Patrick M. Hausen wrote: > Hi, > > On Mon, Jun 29, 2009 at 01:11:16PM +0200, Marius Nünnerich wrote: > >> > GEOM: da0: corrupt or invalid GPT detected. >> > GEOM: da0: GPT rejected -- may not be recoverable. > >> could you post the output of >> dd if=/dev/da0 count=1 | hd > > 512 bytes transferred in 0.038030 secs (13463 bytes/sec) > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff || > 01c0 ff ff ee ff ff ff 01 00 00 00 ff ff ff ff 00 00 || > 01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || > * > 01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..U.| > 0200 I'm sorry, it should have said: dd if=/dev/da0 count=4 | hd ___ 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: Zpool on raw disk and weird GEOM complaint
On Mon, Jun 29, 2009 at 11:43, Patrick M. Hausen wrote: > Hi, all, > > I have a system with 12 S-ATA disks attached that I set up > as a raidz2: > > %zpool status zfs > pool: zfs > state: ONLINE > scrub: scrub in progress for 0h5m, 7.56% done, 1h3m to go > config: > > NAME STATE READ WRITE CKSUM > zfs ONLINE 0 0 0 > raidz2 ONLINE 0 0 0 > da0 ONLINE 0 0 0 > da1 ONLINE 0 0 0 > da2 ONLINE 0 0 0 > da3 ONLINE 0 0 0 > da4 ONLINE 0 0 0 > da5 ONLINE 0 0 0 > da6 ONLINE 0 0 0 > da7 ONLINE 0 0 0 > da8 ONLINE 0 0 0 > da9 ONLINE 0 0 0 > da10 ONLINE 0 0 0 > da11 ONLINE 0 0 0 > > errors: No known data errors > > We are currently tweaking kernel memory a bit but the on disk > data and the hardware seem to be just fine. > > 7-STABLE, amd64, 4 GB of RAM. > > A couple of days ago, at each boot we saw this error message: > > GEOM: da0: corrupt or invalid GPT detected. > GEOM: da0: GPT rejected -- may not be recoverable. > > > There should not be any partition, MBR or GPT on the disks, > I created the zpool on the raw devices. > > So I figure: > > Somehow zfs wrote some data to da0 that somewhat resembles a > GPT partition table, so GEOM gets confused at boot time. > > Question is: can somebody confirm my guess? If yes should I > just ignore the message, can it be disabled somehow (compile > kernel without GPT?) or should zpools be created on slices instead > of disks? Hi, could you post the output of dd if=/dev/da0 count=1 | hd ___ 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 Thu, Apr 2, 2009 at 22:32, Dmitry Morozovsky wrote: > Pawel, > > could you please help me a bit with *very* unpleasant situation: one of my > servers with very large ZFS reboots on most write requests to one (largest, > which effectively prohibits recreating) ZFS file system with > > panic: avl_find() succeeded inside avl_add() > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc0533227 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc0533535 in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc0836a20 in avl_add (tree=Variable "tree" is not available. > ) at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/common/avl/avl.c:635 > #4 0xc088c39f in zap_lockdir (os=0xc555a590, obj=6108, tx=0x0, lti=RW_READER, > fatreader=1, zapp=0xfc6907f8) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:231 > #5 0xc088cc0f in zap_lookup (os=0xc555a590, zapobj=6108, name=0xfc6908bc > "daily.20080701.gz", integer_size=8, num_integers=1, buf=0xfc69083c) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c:509 > #6 0xc089e25d in zfs_dirent_lock (dlpp=0xfc690878, dzp=0xc709f570, > name=0xfc6908bc "daily.20080701.gz", zpp=0xfc690874, flag=Variable "flag" is > not available. > ) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:173 > #7 0xc089e43e in zfs_dirlook (dzp=0xc709f570, name=0xfc6908bc > "daily.20080701.gz", vpp=0xfc690b5c) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_dir.c:271 > #8 0xc08a8653 in zfs_freebsd_lookup (ap=0xfc690a00) > at > /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1080 > #9 0xc06dab42 in VOP_CACHEDLOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a00) at > vnode_if.c:153 > #10 0xc05a402c in vfs_cache_lookup (ap=0xfc690a84) at vnode_if.h:83 > #11 0xc06dc816 in VOP_LOOKUP_APV (vop=0xc08ba7e0, a=0xfc690a84) at > vnode_if.c:99 > #12 0xc05aa681 in lookup (ndp=0xfc690b48) at vnode_if.h:57 > #13 0xc05ab308 in namei (ndp=0xfc690b48) at /usr/src/sys/kern/vfs_lookup.c:215 > #14 0xc05ba07f in kern_lstat (td=0xc5186af0, path=0xbfbfd088 0xbfbfd088 out of bounds>, pathseg=UIO_USERSPACE, sbp=0xfc690c18) > at /usr/src/sys/kern/vfs_syscalls.c:2184 > #15 0xc05ba22f in lstat (td=0xc5186af0, uap=0xfc690cfc) at > /usr/src/sys/kern/vfs_syscalls.c:2167 > #16 0xc06d0288 in syscall (frame=0xfc690d38) at > /usr/src/sys/i386/i386/trap.c:1090 > #17 0xc06b5bc0 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:255 > #18 0x0033 in ?? () > Previous frame inner to this frame (corrupt stack?) > > this is fresh RELENG_7/i386 with (I suppose, unrelated) patch to ata from mav@ > > Thanks in advance. Hi Dmitry, I think the line numbers are misleading, see: http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs/zap_micro.c?v=FREEBSD7;im=bigexcerpts#L262 Could you build a kernel with -O1 or -O0 perhaps that will help. I have no other clue about your situation except maybe try 8-current? - Marius ___ 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: Kernel not mounting root
On Sun, Dec 21, 2008 at 10:54 AM, Dominic Fandrey wrote: > Marius Nünnerich wrote: >> Hi all, >> >> I did cvsup to 7-STABLE yesterday, build, installed and booted a new >> kernel then buildworld. >> Then I noticed that my PS/2 keyboard is not working at the loader menu >> so I booted multiuser and did the make installworld part from there. >> Then I tried to reboot but now it hangs after the line >> Trying to mount root from ufs:/dev/ad4s1a >> >> It sits there for at least 10min. I tried so far: >> - Installing 7.1-beta2 on another hd and booting it, it works. >> - Copied that kernel to the old hd >> - Moved kernel.old to kernel >> - fsck everything >> - mounted everything from the old hd under /mnt, chroot into that, >> installworld >> >> Anyone else seeing this or has an idea what to do next? >> >> Kind regards >> Marius > > I encountered something similar with RC-1, yesterday. The installer entered > the devices ad4s4a till ad4s4f instead of ad4s3a till ad4s3f into the fstab > file. That is different ad4s1a would be the right partition in my case. ___ 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"
Kernel not mounting root
Hi all, I did cvsup to 7-STABLE yesterday, build, installed and booted a new kernel then buildworld. Then I noticed that my PS/2 keyboard is not working at the loader menu so I booted multiuser and did the make installworld part from there. Then I tried to reboot but now it hangs after the line Trying to mount root from ufs:/dev/ad4s1a It sits there for at least 10min. I tried so far: - Installing 7.1-beta2 on another hd and booting it, it works. - Copied that kernel to the old hd - Moved kernel.old to kernel - fsck everything - mounted everything from the old hd under /mnt, chroot into that, installworld Anyone else seeing this or has an idea what to do next? Kind regards Marius ___ 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: Weird truss output
On Wed, Dec 3, 2008 at 6:08 PM, Dan Nelson <[EMAIL PROTECTED]> wrote: > In the last episode (Dec 03), Vlad GALU said: >> On Wed, Dec 3, 2008 at 5:23 PM, Dan Nelson <[EMAIL PROTECTED]> wrote: >> > In the last episode (Dec 03), Vlad GALU said: >> >> I'm running a statically linked binary, which I've built inside a >> >> jail. The jail's libc & co are in sync with the host's. Truss then >> >> shows this: >> >> >> >> -- cut here -- >> >> -- UNKNOWN SYSCALL 1048532 -- >> >> -- UNKNOWN SYSCALL 1048532 -- >> > >> > Is this a threaded app that you attached truss to after it was >> > started? The method that truss uses to catch syscall enter/exit >> > events doesn't indicate whether the event is an enter or an exit, >> > so if you attach while a syscall is active, truss handles the exit >> > event as if it were a syscall entry event, and never gets back in >> > synch. It gets worse with threaded apps because each thread is >> > another chance to get out of synch. Try this patch: >> >> You were right, this application was indeed threaded. The messages >> still occur, although at a slightly lower rate. One other thing >> that's not particularly helpful is this: >> >> -- cut here-- >> read(1074283119,"\M-Ry\^A\0",7356800)= 4 (0x4) >> -- and here -- >> >> I obviously don't have that many descriptors in my process. I can >> live with the malformed message, but it's a PITA not to know which fd >> the read was actually made from :( > > It looks like there's some other problem where truss either drops a > syscall event, or puts some status fields into the wrong thread's > structure. It seems to happen when two threads call blocking syscalls, > and when they return, truss gets confused as to which thread called > which syscall. The read syscall is probably still pending, and you're > getting the arguments of the syscall that returned, printed as if it > was the read syscall. When the read call completes, you'll probably > get an --UNKNOWN SYSCALL-- line, or another mismatched syscall output > line. > > An alternative it to use ktrace/kdump to trace the process; it's more > cumbersome to use, but doesn't have problems with threaded processes. Maybe DTrace will help you but I don't know if there is enough ported yet. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: virtual machines
Hi, emulators/qemu could do the job for you :) cheers Marius pgpBP1HkSlCmI.pgp Description: PGP signature
Re: USB Mouse not working
On Tue, 22 Mar 2005 01:46:19 + Ian Dowse <[EMAIL PROTECTED]> wrote: > > I'm not sure I do either :-) On a mouse I tried here I got very > different information than that: > > Report descriptor: > Collection page=Generic_Desktop usage=Mouse > Collection page=Generic_Desktop usage=Pointer > Input size=1 count=1 page=Button usage=Button_1, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_2, logical range 0..1 > Input size=1 count=1 page=Button usage=Button_3, logical range 0..1 > Input size=8 count=1 page=Generic_Desktop usage=X, logical range -127..127 > Input size=8 count=1 page=Generic_Desktop usage=Y, logical range -127..127 > Input size=8 count=1 page=Generic_Desktop usage=Wheel, logical range -127..127 > End collection > Feature size=1 count=1 page=Generic_Desktop usage=Motion_Wakeup, logical range 0..1 > End collection > Total input size 4 bytes > Total output size 0 bytes > Total feature size 0 bytes > > But I don't know enough about how this is supposed to work to make > sense of the difference. I got similar output, when I plug in that mouse with hw.usb.ums.debug=99: ums0: Device USB Device, rev 1.10/0.01, addr 2, iclass 3/1 ums_attach: bLength=7 bDescriptorType=5 bEndpointAddress=2-in bmAttributes=3 wMa xPacketSize=5 bInterval=10 ums0: 5 buttons and Z dir and a TILT dir. ums_attach: sc=0xc1a14000 ums_attach: X 8/8 ums_attach: Y 16/8 ums_attach: Z 24/8 ums_attach: B1 0/1 ums_attach: B2 1/1 ums_attach: B3 2/1 ums_attach: B4 3/1 ums_attach: B5 4/1 ums_attach: size=9, id=3 The TILT dir is caused by the hardcoded sc->flags |= UMS_T; Has anyone an idea what to do next? I suppose I can't do anything in ums.c, as it gets the (to few) data from another file. thanks Marius pgp35SOojs6cE.pgp Description: PGP signature
Re: USB Mouse not working
On Mon, 21 Mar 2005 00:33:00 + Ian Dowse <[EMAIL PROTECTED]> wrote: > I think page 61 is just an example of one possible report descriptor > for a mouse. Could you follow the instructions below to get the > report descriptor for your mouse and post it to the list? > > o Remove the `ums' device from your kernel config, but leave in >the `uhid' device (if you're using modules, just unload ums and >make sure uhid is loaded). > > o Plug in the mouse > > o Check dmesg for the correct uhid device, e.g. you should see >something like: > > uhid0: Logitech USB Mouse, rev 1.10/4.10, addr 2, iclass 3/1 > > o Run this command > > usbhidctl -f /dev/uhid0 -ra > # dmesg|grep uhid uhid0: Device USB Device, rev 1.10/0.01, addr 2, iclass 3/1 Thats the mouse, because it's the only USB device plugged-in at the moment (with ukbd0). # usbhidctl -f /dev/uhid0 -ra Report descriptor: Total input size 0 bytes Total output size 4 bytes Total feature size 1 bytes usbhidctl: device does not support immediate mode, only changes reported. Hmm, don't know what to do with this information :) Thanks, Marius pgpaYSeGs5EG5.pgp Description: PGP signature
Re: USB Mouse not working
On Sun, 20 Mar 2005 19:29:18 + Ian Dowse <[EMAIL PROTECTED]> wrote: > BTW, before adding more workarounds here it would be worth reading: > > http://www.usb.org/developers/devclass_docs/HID1_11.pdf > > I don't know if this is true, but I suspect the main problem is > that we are simply ignoring the information in the report descriptor > that says how to interpret the data coming from the mouse. Can > somebody check if this is the case, or if these mice really need > special case workarounds? I didn't read the whole document, but as far as I understand the table on the bottom of page 61 (of the document, not the pdf-file) it is clear how the data should be interpreted, and that my mouse (like the intellimouse) is not conforming to this standard. But the interpretation of the data isn't really the problem, the problem are the three points described in my last two mails. Anyway, thanks for your time. Marius pgpvNAYXd2033.pgp Description: PGP signature
Re: USB Mouse not working
On Sun, 20 Mar 2005 13:39:59 -0500
Anish Mistry <[EMAIL PROTECTED]> wrote:
> Is the code setting the UMS_T flags? If not, then force it in after
> the detection routine section:
> /* The Microsoft Wireless Intellimouse 2.0 reports it's wheel
>* using 0x0048 (i've called it HUG_TWHEEL) and seems to expect
>* you to know that the byte after the wheel is the tilt axis.
>* There are no other HID axis descriptors other than X,Y and
>* TWHEEL */
> if (hid_locate(desc, size, HID_USAGE2(HUP_GENERIC_DESKTOP,
> HUG_TWHEEL),
> hid_input, &sc->sc_loc_t, &flags)) {
> sc->sc_loc_t.pos = sc->sc_loc_t.pos + 8;
> sc->flags |= UMS_T;
> }
> sc->flags |= UMS_T; /* <--- Add this to force MS Intellimouse Mode */
No, it isn't set by the code itself. I tried what you suggested, I get
the same results as before:
- jerky movement
- need to scroll the mousewheel two positions to get one event
- button pressing isn't recognized if the mouse isn't moving
If I plug the mouse into the PS/2 connector it works as I
expect. But thats not an option :(
Anyhow, thank you very much for your suggestions.
Marius
pgpBNxDjcXTQZ.pgp
Description: PGP signature
USB Mouse not working
Hi,
I recently purchased a cheap USB mouse/keyboard combination. If I plug
it in /dev/ums0 is created, I also can run moused -p /dev/ums0, but the
mouse will not move.
I upgraded to a recent -STABLE, so ums.c is version 1.70.2.2.
I compiled a kernel with options USB_DEBUG and set
hw.usb.ums.debug=.
With cat /dev/ums0 > /dev/null I can see the Debug Info on the console:
ums_intr: sc=0x19d5c00 status=13
ums_intr: data = 01 00 00 00 00 01
ums_intr: status=13
It seems that this mouse sends 1 extra byte before the usual data, just
like the MS Wireless Intellimouse 2.0, because data is like:
01 BUTTON X Y Z 01
But seems like ums_intr() returns on line 467, so I tried this:
--- /sys/dev/usb/ums.c Sun Mar 20 14:54:14 2005
+++ /root/ums.c Sun Mar 20 14:54:04 2005
@@ -456,7 +456,7 @@
* Currently it's the only user of UMS_T so use it as an identifier.
* We probably should switch to some more official quirk.
*/
- if (sc->flags & UMS_T) {
+/* if (sc->flags & UMS_T) {
if (sc->sc_iid) {
if (*ibuf++ == 0x02)
return;
@@ -468,9 +468,11 @@
}
}
+*/ *ibuf++;
It sort of works. If I run moused -p /dev/ums0 I can actually use that
mouse, BUT it moves jerky, I have to move the wheel two positions
to get one and when a button is pressed when the mouse stands still it
is not recognized. The mouse _must_ move for the button to get noticed.
Has anyone an idea what to try next?
Any help would be greatly appreciated!
Marius
pgpSeUZfsyEt5.pgp
Description: PGP signature
