Re: sysctl filesystem ?
On Jun 26, 2012 7:07 AM, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysctl filesystem ?
On Tue, 26 Jun 2012, Chris Rees wrote: as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. One of the problems we've encounted with synthetic file systems is that off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but not unreasonable) assumptions about the statistic content of files. This comes up frequently with procfs-like systems where the size of, say, memory map data can be considerably larger than the perhaps 128-byte, 256-byte, or even 8k buffers that might exist in a stock file access tool. Unless we change all of those tools to use buffers much bigger than they currently do, which even suggets changing the C library buffer to defaults for FILE *, that places an onus on the file system to provide persisting snapshots of data until it's sure that a user process is done -- e.g., over many system calls. sysctl is not immune to the requirement of atomicity, but it has explicit control over it: sysctl is a single system call, rather than an unbounded open-read-seek-repeat-etc cycle, and has been carefully crafted to provide this and other MIB-like properties, such as a basic data type model so that command line tools know how to render content rather than having to guess and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better match for accessing this sort of monitoring and control data than the POSIX file API, and would recommend against trying to move to a sysctl file system. Robert ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.
pgpcAmL5mkan1.pgp
Description: PGP signature
Re: sysctl filesystem ?
as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. actually - i don't know since over 5 years what linux do. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: sysctl filesystem ?
as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[CFC/CFT] large changes in the loader(8) code
Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff What i already did: 1. The partition tables handling now is machine independent, and it is compatible with the kernel's GEOM_PART implementation. There is new API for disk drivers in the loader to get information about partitions and tables: common/Makefile.inc common/part.c common/part.h 2. The similar and general code from the disk drivers merged in the disk.c: common/disk.c common/disk.h i386/libi386/libi386.h i386/libi386/biosdisk.c userboot/test/test.c userboot/userboot/userboot_disk.c userboot/userboot.h 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. 6. I have changed userboot interface. I guess there is none consumers except the one test program. But if it isn't that, i can make it compatible. Any comments are welcome. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. Just a quick note here. At some point when I was adding GPT attributes to allow for test starts I greatly improved, at least parts of, the GPT implementation. I did implement support for both CRC checksum verification and fallback to backup GPT header when primary is broken. And the code is still in sys/boot/common/gpt.c. So my question would be what do you mean by this sentence? So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff What i already did: 1. The partition tables handling now is machine independent, and it is compatible with the kernel's GEOM_PART implementation. There is new API for disk drivers in the loader to get information about partitions and tables: common/Makefile.inc common/part.c common/part.h 2. The similar and general code from the disk drivers merged in the disk.c: common/disk.c common/disk.h i386/libi386/libi386.h i386/libi386/biosdisk.c userboot/test/test.c userboot/userboot/userboot_disk.c userboot/userboot.h 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. 6. I have changed userboot interface. I guess there is none consumers except the one test program. But if it isn't that, i can make it compatible. Any comments are welcome. -- WBR, Andrey V. Elsukov -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpWMg9tnH9tN.pgp Description: PGP signature
Re: sysctl filesystem ?
and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better me too. i REALLY appreciate the way FreeBSD do this. pseudo-filesystems are sometimes good but making them default method is bad. Current way is simple. Or actually - less complicated as i think for example - XML in system output is not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. Just a quick note here. At some point when I was adding GPT attributes to allow for test starts I greatly improved, at least parts of, the GPT implementation. I did implement support for both CRC checksum verification and fallback to backup GPT header when primary is broken. And the code is still in sys/boot/common/gpt.c. So my question would be what do you mean by this sentence? Yes, gptboot does that, but the loader/zfsloader doesn't. So there might be a situation when gptboot does boot, but loader(8) can't. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On Tue, Jun 26, 2012 at 06:01:26PM +0400, Andrey V. Elsukov wrote: On 26.06.2012 16:57, Pawel Jakub Dawidek wrote: On Tue, Jun 26, 2012 at 04:50:36PM +0400, Andrey V. Elsukov wrote: Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. Just a quick note here. At some point when I was adding GPT attributes to allow for test starts I greatly improved, at least parts of, the GPT implementation. I did implement support for both CRC checksum verification and fallback to backup GPT header when primary is broken. And the code is still in sys/boot/common/gpt.c. So my question would be what do you mean by this sentence? Yes, gptboot does that, but the loader/zfsloader doesn't. So there might be a situation when gptboot does boot, but loader(8) can't. I see. I don't know if I'll find time for a proper review, but it is really great that you are working on cleaning up this huge mess. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgp62kXgtS21u.pgp Description: PGP signature
Re: sysctl filesystem ?
On Tue, Jun 26, 2012 at 1:59 AM, Robert Watson rwat...@freebsd.org wrote: On Tue, 26 Jun 2012, Chris Rees wrote: as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. One of the problems we've encounted with synthetic file systems is that off-the-shelf file system tools (e.g., cp, dd, cat) make simplistic (but not unreasonable) assumptions about the statistic content of files. This comes up frequently with procfs-like systems where the size of, say, memory map data can be considerably larger than the perhaps 128-byte, 256-byte, or even 8k buffers that might exist in a stock file access tool. Unless we change all of those tools to use buffers much bigger than they currently do, which even suggets changing the C library buffer to defaults for FILE *, that places an onus on the file system to provide persisting snapshots of data until it's sure that a user process is done -- e.g., over many system calls. sysctl is not immune to the requirement of atomicity, but it has explicit control over it: sysctl is a single system call, rather than an unbounded open-read-seek-repeat-etc cycle, and has been carefully crafted to provide this and other MIB-like properties, such as a basic data type model so that command line tools know how to render content rather than having to guess and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better match for accessing this sort of monitoring and control data than the POSIX file API, and would recommend against trying to move to a sysctl file system. While I understand the problems you allude to, the sysctl(8) binary can protect itself from them. IMO the biggest problem with sysctls not being files is that it makes no sense from the core UNIX philosophy that everything is a file. Sockets and pipes and character devices and even unseekable things like stdout are files; why aren't these other objects that allow read, write, and have their own namespace? Cheers, matthew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Removing an SDHC card causes a kernel panic on -current
As follows, in g_disk_providergone, a NULL pointer reference?: imb@toshi:/home/imb sudo less /var/crash/core.txt.4 toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 Tue Jun 26 08:59:01 EDT 2012 FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r237599M: Tue Jun 26 07:52:01 EDT 2012 i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault [ .. ] Unread portion of the kernel message buffer: sdhci0-slot0: Card removed mmc0: detached Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc070a4bc stack pointer = 0x28:0xc6fb7c54 frame pointer = 0x28:0xc6fb7c54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (g_event) trap number = 12 panic: page fault cpuid = 1 Uptime: 7m8s Physical memory: 3045 MB Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc07ae76c in kern_reboot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:449 #2 0xc07aee41 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:637 #3 0xc0af13d1 in trap_fatal (frame=0xc6fb7c14, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1022 #4 0xc0af16a8 in trap_pfault (frame=0xc6fb7c14, usermode=0, eva=0) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:936 #5 0xc0af29ef in trap (frame=0xc6fb7c14) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:546 #6 0xc0adcbdc in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:169 #7 0xc070a4bc in g_disk_providergone (pp=0xcb33ab80) at /usr/home/imb/svn/head/sys/geom/geom_disk.c:505 #8 0xc070f8ba in g_destroy_provider (pp=0xcb33ab80) at /usr/home/imb/svn/head/sys/geom/geom_subr.c:643 #9 0xc070fb6e in g_wither_washer () at /usr/home/imb/svn/head/sys/geom/geom_subr.c:462 #10 0xc070cb62 in g_run_events () at /usr/home/imb/svn/head/sys/geom/geom_event.c:289 #11 0xc077bd8b in fork_exit (callout=0xc070de54 g_event_procbody, arg=0x0, frame=0xc6fb7d08) at /usr/home/imb/svn/head/sys/kern/kern_fork.c:995 #12 0xc0adcc84 in fork_trampoline () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:276 (kgdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] llquantize for FreeBSD's dtrace
On 6/23/12 11:09 AM, Pedro Giffuni wrote: --- Sab 23/6/12, Fabian Keil freebsd-lis...@fabiankeil.de ha scritto: ... My suggestion would be to instead try using the test scripts in cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize/ err.D_LLQUANT_FACTORSMALL.d (for example) has @ = llquantize(0, 1, 0, 10, 10); The problem appears to be unrelated to the syntax change: fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize $sudo dtrace -s err.D_LLQUANT_FACTORSMALL.d Assertion failed: (!(arg (UINT16_MAX args[i].shift))), file It's a different assertion. Probably some difference between Solaris and BSD. this is very useful, thanks! Try this, change the assert on line 1429 in file dt_cc.c from: assert(!(arg (UINT16_MAX args[i].shift))); to assert(!(arg ((uint64_t)UINT16_MAX args[i].shift))); Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] llquantize for FreeBSD's dtrace
--- Mar 26/6/12, Mark Peek m...@freebsd.org ha scritto: It's a different assertion. Probably some difference between Solaris and BSD. this is very useful, thanks! Try this, change the assert on line 1429 in file dt_cc.c from: assert(!(arg (UINT16_MAX args[i].shift))); to assert(!(arg ((uint64_t)UINT16_MAX args[i].shift))); This certainly looks correct. Thanks Mark ! I updated the patch: http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize cheers, Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFT] llquantize for FreeBSD's dtrace
Pedro Giffuni p...@freebsd.org wrote: --- Mar 26/6/12, Mark Peek m...@freebsd.org ha scritto: Try this, change the assert on line 1429 in file dt_cc.c from: assert(!(arg (UINT16_MAX args[i].shift))); to assert(!(arg ((uint64_t)UINT16_MAX args[i].shift))); This certainly looks correct. Thanks Mark ! I updated the patch: http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize Thanks a lot. Seems to work for me: fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize $for t in tst.*.d; do sudo dtrace -s $t $t.myout; diff $t.out $t.myout echo success for $t; done success for tst.bases.d success for tst.basic.d success for tst.negorder.d success for tst.negvalue.d success for tst.normal.d success for tst.range.d success for tst.steps.d success for tst.trunc.d fk@r500 /usr/src/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/llquantize $for t in err.*.d; do sudo dtrace -s $t dtrace: failed to compile script err.D_LLQUANT_FACTOREVEN.nodivide.d: line 28: llquantize( ) factor (argument #1) must evenly divide the number of steps per magnitude (argument #4), and the number of steps per magnitude must evenly divide a power of the factor dtrace: failed to compile script err.D_LLQUANT_FACTOREVEN.notfactor.d: line 28: llquantize( ) factor (argument #1) must evenly divide the number of steps per magnitude (argument #4), and the number of steps per magnitude must evenly divide a power of the factor dtrace: failed to compile script err.D_LLQUANT_FACTORMATCH.d: line 29: llquantize( ) factor (argument #1) doesn't match previous declaration: expected 10, found 3 dtrace: failed to compile script err.D_LLQUANT_FACTORNSTEPS.d: line 28: llquantize( ) factor (argument #1) must be less than or equal to the number of linear steps per magnitude (argument #4) dtrace: failed to compile script err.D_LLQUANT_FACTORSMALL.d: line 28: llquantize( ) factor (argument #1) must be two or more dtrace: failed to compile script err.D_LLQUANT_FACTORTYPE.d: line 29: llquantize( ) argument #1 (factor) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_FACTORVAL.d: line 28: llquantize( ) argument #1 (factor) must be an unsigned 16-bit quantity dtrace: failed to compile script err.D_LLQUANT_HIGHMATCH.d: line 29: llquantize( ) high magnitude (argument #3) doesn't match previous declaration: expected 10, found 11 dtrace: failed to compile script err.D_LLQUANT_HIGHTYPE.d: line 29: llquantize( ) argument #3 (high magnitude) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_HIGHVAL.d: line 28: llquantize( ) argument #3 (high magnitude) must be an unsigned 16-bit quantity dtrace: failed to compile script err.D_LLQUANT_LOWMATCH.d: line 29: llquantize( ) low magnitude (argument #2) doesn't match previous declaration: expected 0, found 1 dtrace: failed to compile script err.D_LLQUANT_LOWTYPE.d: line 29: llquantize( ) argument #2 (low magnitude) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_LOWVAL.d: line 28: llquantize( ) argument #2 (low magnitude) must be an unsigned 16-bit quantity dtrace: failed to compile script err.D_LLQUANT_MAGRANGE.d: line 28: llquantize( ) high magnitude (argument #3) must be greater than low magnitude (argument #2) dtrace: failed to compile script err.D_LLQUANT_MAGTOOBIG.d: line 28: llquantize( ) factor (10) raised to power of high magnitude (100) overflows 64-bits dtrace: failed to compile script err.D_LLQUANT_NSTEPMATCH.d: line 29: llquantize( ) linear steps per magnitude (argument #4) doesn't match previous declaration: expected 10, found 100 dtrace: failed to compile script err.D_LLQUANT_NSTEPTYPE.d: line 29: llquantize( ) argument #4 (linear steps per magnitude) must be an integer constant dtrace: failed to compile script err.D_LLQUANT_NSTEPVAL.d: line 28: llquantize( ) argument #4 (linear steps per magnitude) must be an unsigned 16-bit quantity Fabian signature.asc Description: PGP signature
Re: [RFT] llquantize for FreeBSD's dtrace
--- Mar 26/6/12, Fabian Keil freebsd-lis...@fabiankeil.de ha scritto: Pedro Giffuni p...@freebsd.org wrote: --- Mar 26/6/12, Mark Peek m...@freebsd.org ha scritto: Try this, change the assert on line 1429 in file dt_cc.c from: assert(!(arg (UINT16_MAX args[i].shift))); to assert(!(arg ((uint64_t)UINT16_MAX args[i].shift))); This certainly looks correct. Thanks Mark ! I updated the patch: http://people.freebsd.org/~pfg/patches/patch-dtrace-llquantize Thanks a lot. Seems to work for me: Nice! I don't use Dtrace though ... so I'll ask: Any objections against committing it? :). Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Tuesday, June 26, 2012 8:50:36 am Andrey V. Elsukov wrote: Hi All, Some time ago i have started reading the code in the sys/boot. Especially i'm interested in the partition tables handling. I found several problems: 1. There are several copies of the same code in the libi386/biosdisk.c and common/disk.c, and partially libpc98/biosdisk.c. 2. ZFS probing is very slow, because the ZFS code doesn't know how many disks and partitions the system has: http://www.freebsd.org/cgi/query-pr.cgi?pr=148296 http://www.freebsd.org/cgi/query-pr.cgi?pr=161897 3. The GPT support doesn't check CRC and even doesn't know anything about the secondary GPT header/table. So, i have created the branch and committed the changes: http://svnweb.freebsd.org/base/user/ae/bootcode/ The patch is here: http://people.freebsd.org/~ae/boot.diff What i already did: 1. The partition tables handling now is machine independent, and it is compatible with the kernel's GEOM_PART implementation. There is new API for disk drivers in the loader to get information about partitions and tables: common/Makefile.inc common/part.c common/part.h 2. The similar and general code from the disk drivers merged in the disk.c: common/disk.c common/disk.h i386/libi386/libi386.h i386/libi386/biosdisk.c userboot/test/test.c userboot/userboot/userboot_disk.c userboot/userboot.h 3. ZFS code now uses new API and probing on the systems with many disks should be greatly increased: zfs/zfs.c i386/loader/main.c 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. 6. I have changed userboot interface. I guess there is none consumers except the one test program. But if it isn't that, i can make it compatible. One other consumer is in the bhyve branch. I think the 'kload' patches also use it. However, they can probably be adapted easily. [ Note, I haven't done a detailed review of the patch at all yet. ] -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... [...] It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. In other words, IMHO, our problem is that FreeBSD's boot code doesn't recognize/support gmirror's metadata. What Andrey is proposing is to recognize the metadata and act accordingly - in case of a gmirror we simply need to skip it. In the future we will have the same problem with graid - until we add support for it to the boot code, we won't be able to boot from it. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpxIGC3e4HIp.pgp Description: PGP signature
xzexe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Here is a small utility that uses xz(1) instead of gzip(1) for compressing executable, derived from the base system gzexe(1). http://people.freebsd.org/~delphij/misc/xzexe There is no plan at this time to put this into base system or a port unless people thinks it's useful. Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBCAAGBQJP6issAAoJEG80Jeu8UPuzU14H/3rI6g8FJc+fFaW88LHc5Iwr psAzBWh/TFlyRvtcN6FmiCCTFy9nxi07P8hqd902Qa9yxRbKItD02hGehZCw/czM d5fHq5SXF2pJxZznae/TU4xrrZd3niCFJNQReO/bw5a6IooTgW26d6JaBrjGpUf2 eTLcVEzY6MS9DacUnHiwQAdWRdRIxr6ropBlKEIpkbvwNED+BAt9JOkjDP1YrZe5 M+gfzbEU3Lx+X1UBLmtah7zEF+Fwq89Y32KERrcadCvEOP0jqGrDM+njnq8eqk8a QK9wgxwg+SZLBGbYkVVtZEgIWKldxOBxEDwosizlrPPIJWbpOssc1k9lLsTlZ9U= =kl8S -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Tue, Jun 26, 2012 at 2:23 PM, Pawel Jakub Dawidek p...@freebsd.org wrote: On Tue, Jun 26, 2012 at 01:37:11PM -0400, John Baldwin wrote: 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. [...] My interpretation is different: The way to verify if the header is valid is to check its checksum, not to check if the backup header location in the primary header points at the last LBA. Of course if primary header's checksum is incorrect it is hard to trust that the backup header location is correct. And we need the backup header when the primary header is invalid... [...] It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. I don't think so. Most common case is to configure partitions on top of a mirror. Mirroring partitions is less common. Mostly because of hardware RAIDs being popular. You don't expect hardware RAID vendor to mirror partitions. Partition editors for other OS's won't work, but only because they don't support gmirror. If they wouldn't recognize and support some hardware (or pseudo-hardware) RAIDs there will be the same problem. In other words, IMHO, our problem is that FreeBSD's boot code doesn't recognize/support gmirror's metadata. What Andrey is proposing is to recognize the metadata and act accordingly - in case of a gmirror we simply need to skip it. In the future we will have the same problem with graid - until we add support for it to the boot code, we won't be able to boot from it. Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixed. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On Tue, Jun 26, 2012 at 02:41:31PM -0700, Kevin Oberman wrote: Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. I think this is an issue that will continue to bite users unless it is fixed. I don't really see how dedicating a partition for metadata can work or is good idea, sorry. As for sharing disk with other OS. If you share the disk with OS that doesn't support gmirror, you shouldn't use gmirror in the first place. You probably want to use only formats that are recognized by all your OSes. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgprySQFgONfF.pgp Description: PGP signature
Re: Removing an SDHC card causes a kernel panic on -current
On Tue, 26 Jun 2012, Michael Butler wrote: As follows, in g_disk_providergone, a NULL pointer reference?: g_disk_providergone() is new in r237518 (by ken); ken cc'd. -Ben Kaduk imb@toshi:/home/imb sudo less /var/crash/core.txt.4 toshi.auburn.protected-networks.net dumped core - see /var/crash/vmcore.4 Tue Jun 26 08:59:01 EDT 2012 FreeBSD toshi.auburn.protected-networks.net 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r237599M: Tue Jun 26 07:52:01 EDT 2012 i...@toshi.auburn.protected-networks.net:/usr/obj/usr/home/imb/svn/head/sys/TOSHI i386 panic: page fault [ .. ] Unread portion of the kernel message buffer: sdhci0-slot0: Card removed mmc0: detached Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x20:0xc070a4bc stack pointer = 0x28:0xc6fb7c54 frame pointer = 0x28:0xc6fb7c54 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (g_event) trap number = 12 panic: page fault cpuid = 1 Uptime: 7m8s Physical memory: 3045 MB Dumping 265 MB: 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/modules/vboxdrv.ko...done. Loaded symbols for /boot/modules/vboxdrv.ko Reading symbols from /boot/modules/cuse4bsd.ko...done. Loaded symbols for /boot/modules/cuse4bsd.ko Reading symbols from /boot/modules/vboxnetflt.ko...done. Loaded symbols for /boot/modules/vboxnetflt.ko Reading symbols from /boot/modules/vboxnetadp.ko...done. Loaded symbols for /boot/modules/vboxnetadp.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc07ae76c in kern_reboot (howto=260) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:449 #2 0xc07aee41 in panic (fmt=0x104 Address 0x104 out of bounds) at /usr/home/imb/svn/head/sys/kern/kern_shutdown.c:637 #3 0xc0af13d1 in trap_fatal (frame=0xc6fb7c14, eva=40) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:1022 #4 0xc0af16a8 in trap_pfault (frame=0xc6fb7c14, usermode=0, eva=0) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:936 #5 0xc0af29ef in trap (frame=0xc6fb7c14) at /usr/home/imb/svn/head/sys/i386/i386/trap.c:546 #6 0xc0adcbdc in calltrap () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:169 #7 0xc070a4bc in g_disk_providergone (pp=0xcb33ab80) at /usr/home/imb/svn/head/sys/geom/geom_disk.c:505 #8 0xc070f8ba in g_destroy_provider (pp=0xcb33ab80) at /usr/home/imb/svn/head/sys/geom/geom_subr.c:643 #9 0xc070fb6e in g_wither_washer () at /usr/home/imb/svn/head/sys/geom/geom_subr.c:462 #10 0xc070cb62 in g_run_events () at /usr/home/imb/svn/head/sys/geom/geom_event.c:289 #11 0xc077bd8b in fork_exit (callout=0xc070de54 g_event_procbody, arg=0x0, frame=0xc6fb7d08) at /usr/home/imb/svn/head/sys/kern/kern_fork.c:995 #12 0xc0adcc84 in fork_trampoline () at /usr/home/imb/svn/head/sys/i386/i386/exception.s:276 (kgdb) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
Hi Bruce, On Jun 24, 2012, at 5:14 PM, Bruce Cran wrote: On 21/06/2012 00:40, Devin Teske wrote: If you have the time and/or energy, please test and report any issues that you experience. I've noticed a few typos and other minor issues: In bsdconfig(8): Contains a link to itself under SEE ALSO. bsdconfig takes a commands as an argument - should be command. Fixed. bsdconfig mouse: Typo se Configuration menu. Please Specify the mouse daemon flags - don't need upper-case S. Fixed. bsdconfig hostname: The example should probably be in the example.com domain. Replaced with full.example.com bsdconfig netdev: Select a TCP/IP network interface to configure doesn't need TCP/IP. Done. bsdconfig nameservers: Please enter the new TCP/IP address of the DNS nameserver should just be IP address. TCP/IP is being used where just IP was needed in other places too. Done. 'bsdconfig command -h' doesn't always work: Enough people complained about this, that… it too is fixed (though I argue that there's absolutely nothing wrong with having -h be invalid to getopts -- the end result is the same with exception to the illegal option -h extra-line of output that everybody seems to complain about. Also mind you, that much of the FreeBSD Operating System suffers from this bug bsdconfig hostname -h Illegal option -h Like tzsetup -h and many others that are this way. I just can't win (inconsistencies everywhere in the system w/respect to this). -- Devin P.S. Fixes are in the up-coming 0.7.3 PORTVERSION of sysutils/bsdconfig. _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627 address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx, NULL,
NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Removing an SDHC card causes a kernel panic on -current
On Tue, Jun 26, 2012 at 19:41:07 -0400, Benjamin Kaduk wrote: On Tue, 26 Jun 2012, Michael Butler wrote: As follows, in g_disk_providergone, a NULL pointer reference?: g_disk_providergone() is new in r237518 (by ken); ken cc'd. Can you try the attached patch to sys/geom/geom_disk.c? Also, do you have full dmesg information for when the panic happened? It looks like disk_destroy() has already been called in this case, and I suppose that's likely to happen for any of the users of the GEOM disk class that haven't been updated with the reference count changes I made in da(4). (i.e. all of the rest of them.) Let me know whether this works for you. Thanks, Ken -- Kenneth Merry k...@freebsd.org //depot/users/kenm/FreeBSD-test2/sys/geom/geom_disk.c#7 - /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/geom/geom_disk.c *** /tmp/tmp.75357.20 Tue Jun 26 20:25:44 2012 --- /usr/home/kenm/perforce4/kenm/FreeBSD-test2/sys/geom/geom_disk.cTue Jun 26 20:25:29 2012 *** *** 502,507 --- 502,515 struct g_disk_softc *sc; sc = (struct g_disk_softc *)pp-geom-softc; + + /* +* If the softc is already NULL, then we've probably been through +* g_disk_destroy already; there is nothing for us to do anyway. +*/ + if (sc == NULL) + return; + dp = sc-dp; if (dp-d_gone != NULL) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
On 26.06.2012 21:37, John Baldwin wrote: 4. The gptboot now searches the backup GPT header in the previous sectors, when it finds the GEOM:: signature in the last sector. PMBR code also tries to do the same: common/gpt.c i386/pmbr/pmbr.s GPT really wants the backup header at the last LBA. I know you can set it, but I've interpreted that as a way to see if the primary header is correct or not. It seems to me that GPT tables created in this fashion (inside a GEOM provider) will not work properly with partition editors for other OS's. I'm hesitant to encourage the use of this as I do think putting GPT inside of a gmirror violates the GPT spec. The standard says: The following test must be performed to determine if a GPT is valid: • Check the Signature • Check the Header CRC • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table • Check the CRC of the GUID Partition Entry Array If the GPT is the primary table, stored at LBA 1: • Check the AlternateLBA to see if it is a valid GPT If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a valid GPT Header and point to a valid GPT Partition Entry Array. For the FreeBSD an each GEOM provider can be treated as disk device. So, i don't see anything criminal if we will add some quirks in the our loader for the better supporting of our technologies. If a user wants modify GPT in the disk editor from the another OS, he can do it, and it should work. The result depends only from the partition editor, it might overwrite the last sector and might don't. 5. Also the pmbr image now contains one fake partition record. When several first sectors are damaged the kernel can't detect GPT (see RECOVERING section in the gpart(8)). We can restore PMBR with dd(1) command, but the old pmbr image has an empty partition table and loader doesn't able to boot from GPT, when there is no partition record in the PMBR. Now it will be able. When pmbr is installed via 'gpart bootcode' command, the kernel correctly modifies this partition record. So, this is only for the first rescue step. As I said earlier, I do not think this is appropriate and that instead gpart should have an appropriate 'recover' command to install just the pmbr on a disk and also create a correct entry in the MBR if needed while doing so. gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. It only sends control requests to the kernel. If GPT is not detected, there is no geom objects to manage. And we can't write bootcode with gpart(8). I think that adding such functions to the gpart(8) is not good. Maybe, the boot0cfg is the better tool for that. Also we still haven't any tool to install zfsboot. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Re: [CFC/CFT] large changes in the loader(8) code
On 27.06.2012 1:41, Kevin Oberman wrote: Long ago I saw a proposal to create a dedicated partition on GPT to hold the metadata. With the large number of partitions available on GPT, tying up one just for GEOM seems like a low price and it moves the device GEOM out of the realm of FreeBSD unique and subject to serious issues when/if a disk is shared with some other OS. I have seen little comment on this and have never seen any argument that that it could not work. When you share some disk with another OS, it seems that much serious issue will be when other OS did some changes in your mirror without you knowing. I know about successful sharing of the disk between Windows and FreeBSD via graid on the Intel pseudo raid. Just use compatible technologies. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
Panic on current from yesterday during boot
Hi, I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. The panic regards /usr/src/sys/vm/uma_core/c line 2040. The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. How could I help you there? I would need some hand holding there as I am travelling at the moment and have only this machine with me without much documentation available. Moving back to this FreeBSD X220.ovitrap.com 10.0-CURRENT FreeBSD 10.0-CURRENT #4: Thu Jun 21 14:29:15 WIT 2012 solves the problem for me. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic's in 10-CURRENT r235646 in VMware
El día Saturday, June 16, 2012 a las 08:11:40AM -0400, John Baldwin escribió: On Saturday, June 16, 2012 04:51:06 AM Matthias Apitz wrote: El día Friday, June 15, 2012 a las 08:18:22AM -0400, John Baldwin escribió: the panic says: mutex page lock not owned at /usr/src/sys/vm/vm_page.c:2060 I have a screen shoot here: http://www.unixarea.de/aurora-panic.gif Installed and started (via rc.conf) is the port open-vm-tools-425873,1; Thx matthias Can you get a stack trace? The attached patch file (to be replaced in open-vm-tools/files/patch-vmmemctl-os.c) solved the problem for me; thanks, John matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11 | UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2 | FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Panic on current from yesterday during boot
On Wed, Jun 27, 2012 at 9:06 AM, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, I am getting a panix when I boot a newly compiled system with sources downloaded yesterday. The panic was still there with the sources from three days ago. The panic regards /usr/src/sys/vm/uma_core/c line 2040. The machine is a Lenovo X220. I do not expect anything specific loaded yet as I load the Intel KMS module manually after the system is up and running on the console. confirm faced with the same error FreeBSD X220 10.0-CURRENT FreeBSD 10.0-CURRENT #2 r237565 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Tmpfs panic in -current
Kevin Lo wrote:
Konstantin Belousov wrote:
On Tue, Jun 26, 2012 at 12:38:25PM +0800, Kevin Lo wrote:
Konstantin Belousov wrote:
On Mon, Jun 25, 2012 at 10:03:28AM +0800, Kevin Lo wrote:
I've observed a panic in recent -current several times but I only
have a picture of the backtrace:
http://people.freebsd.org/~kevlo/panic_tmpfs.jpg
Does this look at all familiar to anyone?
Can you look up the line corresponding to tmpfs_reg_resize + 0x627
address
in your kernel ?
Sure.
The screenshot looks strange. The instruction on which the kernel
trapped
is int 0x28 which should not appear in the compiled code.
# gdb tmpfs.ko
(gdb) l *tmpfs_reg_resize+0x627
0xbf37 is in tmpfs_reg_resize
(/usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c:1005).
1000in /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_subr.c
In tmpfs_subr.c:
999 if (m != NULL) {
1000 if ((m-oflags VPO_BUSY) != 0 ||
1001 m-busy != 0) {
1002 vm_page_sleep(m, tmfssz);
1003 goto retry;
1004 }
1005 MPASS(m-valid == VM_PAGE_BITS_ALL);
1006 } else if (vm_pager_has_page(uobj, idx,
NULL, NU
LL)) {
Hm, can you get a core and
- obtain backtrace in kgdb;
- print the *m content for the page that triggered the assertion ?
The only possible 'new size' value for the truncation from open(2) is zero,
so I do not understand why the asserted block was executed at all.
Thanks for looking into it. Unfortunately I can't get a crash dump
due to lack of disk space and memory.
I triggered the KASSERT on a different machine in the last hour.
panic: Assertion (vp) !=NULL (vp)-v_data != NULL failed at
@/fs/tmpfs/tmpfs.h:527
The bad news is my coworker rebooted that machine after panic :-(
Kevin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] sysutils/bsdconfig: Replacement for sysinstall(8) post-install configuration abilities
On 27/06/2012 02:11, Devin Teske wrote: Like tzsetup -h and many others that are this way. I just can't win (inconsistencies everywhere in the system w/respect to this). Not at all: bsdconfig claims to support -h whereas tzsetup doesn't: SYNOPSIS tzsetup [-nrs] [-C chroot_directory] [zoneinfo_file | zoneinfo_name] SYNOPSIS bsdconfig [-h] bsdconfig command [-h] bsdconfig [OPTIONS] [command [OPTIONS]] -- Bruce Cran ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFC/CFT] large changes in the loader(8) code
on 27/06/2012 07:50 Andrey V. Elsukov said the following: Also we still haven't any tool to install zfsboot. Yeah, I think it would be nice if ZFS provided some interface (ioctl?) to properly write stuff to its special areas. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
