RE: zio_done panic on unadulterated FreeBSD Release 9.1
(kgdb) p/x *(struct vm_object *)0x81281580
$1 = {mtx = {lock_object = {lo_name = 0x80e54bbd,
lo_flags = 0x143, lo_data = 0x0, lo_witness = 0x0},
mtx_lock = 0xfe0006f44000}, object_list = {
tqe_next = 0x81281240, tqe_prev = 0x812814a0},
shadow_head = {lh_first = 0x0}, shadow_list = {le_next = 0x0,
le_prev = 0x0}, memq = {tqh_first = 0xfe00cfd3f880,
tqh_last = 0xfe00c9cac398}, root = 0xfe00cd733ab0,
size = 0x7ff, generation = 0x1, ref_count = 0x3f8, shadow_count = 0x0,
memattr = 0x6, type = 0x4, flags = 0x1000, pg_color = 0x0, pad1 = 0x0,
resident_page_count = 0x9b729, backing_object = 0x0,
backing_object_offset = 0x0, pager_object_list = {tqe_next = 0x0,
tqe_prev = 0x0}, rvq = {lh_first = 0xfe00c7dd2140}, cache = 0x0,
handle = 0x0, un_pager = {vnp = {vnp_size = 0x0, writemappings = 0x0},
devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}, ops = 0x0},
sgp = {sgp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {
swp_bcount = 0x0}}, cred = 0x0, charge = 0x0, paging_in_progress = 0x1}
(kgdb) p/x *(struct vm_page *)0xfe00cd733ab0
$2 = {pageq = {tqe_next = 0x0, tqe_prev = 0xfe00c7e7d678}, listq = {
tqe_next = 0xfe00cd733b28, tqe_prev = 0xfe00cd7331d8},
left = 0xfe00c9b31c38, right = 0xfe00cd735c70,
object = 0xfffb81281580, pindex = 0x7495a, phys_addr = 0xbe95a000, md = {
pv_list = {tqh_first = 0x0, tqh_last = 0xfe00cd733af8},
pat_mode = 0x6}, queue = 0xff, segind = 0x2, hold_count = 0x0,
order = 0xd, pool = 0x0, cow = 0x0, wire_count = 0x0, aflags = 0x0,
flags = 0x0, oflags = 0x4, act_count = 0x0, busy = 0x0, valid = 0xff,
dirty = 0x0}
(kgdb) list *vm_page_free_toq+0x45
0x80b506f5 is in vm_page_free_toq (/usr/src/sys/vm/vm_page.c:1878).
warning: Source file is more recent than executable.
1873
1874/*
1875 * If fictitious remove object association and
1876 * return, otherwise delay object association removal.
1877 */
1878if ((m->flags & PG_FICTITIOUS) != 0) {
1879return;
1880}
1881
1882m->valid = 0;
(kgdb)
-Original Message-
From: Konstantin Belousov [mailto:kostik...@gmail.com]
Sent: Wednesday, January 09, 2013 4:49 PM
To: Po-Li Soong
Cc: sta...@freebsd.org
Subject: Re: zio_done panic on unadulterated FreeBSD Release 9.1
On Wed, Jan 09, 2013 at 08:03:38PM +, Po-Li Soong wrote:
> Hi,
>
> My name is Po-Li Soong. I ran into a crash not long after installing the 9.1
> release on my home machine. I was performing a test run of file transfer with
> samba server running on the FreeBSD installation. The transfer rate was about
> 70-80 MB/sec. The core.txt is attached. If there are other crash dumps
> needed, please let me know.
>
> I first discussed this panic with Justin Gibbs, a coworker of mine at Spectra
> Logic. He referred me to this email address, suggesting that the information
> should be relevant to you. Thanks for the help.
>
> Regards,
>
> Po-Li Soong
>
> maestoso dumped core - see /var/crash/vmcore.0
>
> Sat Jan 5 19:53:24 MST 2013
>
> FreeBSD maestoso 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4
> 09:23:10 UTC 2012
> r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
>
> panic: page fault
>
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for details.
> This GDB was configured as "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
>
>
> Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01
> fault virtual address = 0xfffb812815d8
> fault code= supervisor read data, page not present
> instruction pointer = 0x20:0x80b50597
> stack pointer = 0x28:0xff80fa3bc8d0
> frame pointer = 0x28:0xff80fa3bc900
> code segment = base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 0 (zio_write_intr_5)
> trap number = 12
> panic: page fault
> cpuid = 3
> KDB: stack backtrace:
> #0 0x809208a6 at kdb_backtrace+0x66
> #1 0x808ea8be at panic+0x1ce
> #2 0x80bd8240 at trap_fatal+0x290
> #3 0x80bd857d at trap_pfault+0x1ed
> #4 0x80bd8b9e at trap+0x3ce
> #5 0x80bc315f at calltrap+0x8
> #6 0x80b506f5 at vm_page_free_toq+0x45
> #7 0x80b4f276 at vm_object_page_remove+0x196
> #8 0x80b46b06 at vm_map_delete+0x316
> #9 0x80b46c11 at vm_map_remove+0x51
> #10 0x80b3
Deleting the top-level ZFS file system (without affecting its children)
When I originally set up ZFS on my server, I used the topmost file system for the root file system. Last night, I used "zfs send" and "zfs recv" to create a new root file system named "zroot/root". Then, I adjusted the mount points in single-user mode. Based on my reading of the contents of src/sys/boot/zfs/ and src/sys/boot/i386/zfsboot/ (specifically the zfs_mount() and zfs_get_root() functions in zfsimpl.c), I ran "zpool set bootfs=zroot/root zroot". This should allow the boot program to find the new root file system. Now, I'd like to delete the old root file system and return its storage to the pool. Clearly, "rm -rf /oldroot/*" wouldn't return the space already allocated to the old root file system, but I don't want to run "zfs destroy zroot", as that will probably affect its children (the whole rest of the pool). At this point, I suspect that I'd have to re-create the pool to get the desired configuration. Is my understanding correct? Right now, the pool's datasets look something like the following: xenophon@cinep001bsdgw:~>zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 75.5G 143G 1.04G /oldroot zroot/root1.04G 143G 1.03G / zroot/usr 28.6G 143G 10.2G /usr (etc.) Best wishes, Matthew -- I FIGHT FOR THE USERS ___ 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: Deleting the top-level ZFS file system (without affecting its children)
On Fri, 11 Jan 2013 16:11:32 +0100, xenophon\+freebsd wrote: When I originally set up ZFS on my server, I used the topmost file system for the root file system. Last night, I used "zfs send" and "zfs recv" to create a new root file system named "zroot/root". Then, I adjusted the mount points in single-user mode. Based on my reading of the contents of src/sys/boot/zfs/ and src/sys/boot/i386/zfsboot/ (specifically the zfs_mount() and zfs_get_root() functions in zfsimpl.c), I ran "zpool set bootfs=zroot/root zroot". This should allow the boot program to find the new root file system. Now, I'd like to delete the old root file system and return its storage to the pool. Clearly, "rm -rf /oldroot/*" wouldn't return the space already allocated to the old root file system, but I don't want to run "zfs destroy zroot", as that will probably affect its children (the whole rest of the pool). At this point, I suspect that I'd have to re-create the pool to get the desired configuration. Is my understanding correct? Right now, the pool's datasets look something like the following: xenophon@cinep001bsdgw:~>zfs list NAME USED AVAIL REFER MOUNTPOINT zroot 75.5G 143G 1.04G /oldroot zroot/root1.04G 143G 1.03G / zroot/usr 28.6G 143G 10.2G /usr (etc.) Best wishes, Matthew Why would rm -rf /oldroot/* not return all the allocated space? I can only think of snapshots keeping the space allocated, but you can remove those too. Can you elaborate on that? Ronald. ___ 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: Some new hardware with 9.1 does not reboot easily
On 2013-01-07 18:06, Julian Stecklina wrote: > Thus spake Andriy Gapon : > >> on 29/11/2012 17:16 Willem Jan Withagen said the following: >>> Would that mean that the regular checkout of stable/9 contains enough >>> code to allow "painless" rebooting... >> >> Not yet... > > Has this been resolved? I still see a hang on reboot/shutdown on my box > (zfs root on USB thumb drive), but I am not sure if the problem is > related. Could very well be be. I have again the same problem as I reported before with the full and new 9.1 code. But did not have time yet to build a system te test with. My other 9.1 box is my ZFS only fileserver. And I do not want to fidle to much with it. A reboot work around that works for me: reboot -n shutdown -n now Of which the manual pages say: option should not be used. But I have not yet found bad effects. Perhaps becuase I only have ZFS fs-systems --WjW ___ 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"
csup to svn for 8-stable
I had an existing /usr/src/ tree from previous csup sessions. After a bit of reading, it looks like all I need to do are these two steps? pkg_add -r subversion svn co svn://svn.freebsd.org/base/stable/8 /usr/src Is it really that simple for a src update? I have been using portsnap for years for ports, so I can continue to do that. Brian ___ 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: csup to svn for 8-stable
On Fri, Jan 11, 2013 at 02:45:10PM -0800, Brian W. wrote: > I had an existing /usr/src/ tree from previous csup sessions. After a bit > of reading, it looks like all I need to do are these two steps? > > pkg_add -r subversion > svn co svn://svn.freebsd.org/base/stable/8 /usr/src > > Is it really that simple for a src update? Unless you have custom modifications in your source tree, I believe that you will find it simpler to remove it (or at least rename it) and use the above "svn co" to create a fresh new working copy. > I have been using portsnap for years for ports, so I can continue to do > that. That is my understanding, yes. > ... Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpm1H_AnykKf.pgp Description: PGP signature
Re: csup to svn for 8-stable
When I tried the first time, it only grabbed a few folders, a second try got me a conflict message. I then just whacked /usr/src and did the svn co again, successfully. Brian On Fri, Jan 11, 2013 at 2:48 PM, David Wolfskill wrote: > On Fri, Jan 11, 2013 at 02:45:10PM -0800, Brian W. wrote: > > I had an existing /usr/src/ tree from previous csup sessions. After a bit > > of reading, it looks like all I need to do are these two steps? > > > > pkg_add -r subversion > > svn co svn://svn.freebsd.org/base/stable/8 /usr/src > > > > Is it really that simple for a src update? > > Unless you have custom modifications in your source tree, I believe that > you will find it simpler to remove it (or at least rename it) and use > the above "svn co" to create a fresh new working copy. > > > I have been using portsnap for years for ports, so I can continue to do > > that. > > That is my understanding, yes. > > > ... > > Peace, > david > -- > David H. Wolfskill da...@catwhisker.org > Taliban: Evil men with guns afraid of truth from a 14-year old girl. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > ___ 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: csup to svn for 8-stable
On 01/11/2013 04:51 PM, Brian W. wrote: > When I tried the first time, it only grabbed a few folders, a second try > got me a conflict message. I then just whacked /usr/src and did the svn co > again, successfully. > > Brian And when you want to update, you can just type svn up /usr/src > > > On Fri, Jan 11, 2013 at 2:48 PM, David Wolfskill wrote: > >> On Fri, Jan 11, 2013 at 02:45:10PM -0800, Brian W. wrote: >>> I had an existing /usr/src/ tree from previous csup sessions. After a bit >>> of reading, it looks like all I need to do are these two steps? >>> >>> pkg_add -r subversion >>> svn co svn://svn.freebsd.org/base/stable/8 /usr/src >>> >>> Is it really that simple for a src update? >> >> Unless you have custom modifications in your source tree, I believe that >> you will find it simpler to remove it (or at least rename it) and use >> the above "svn co" to create a fresh new working copy. >> >>> I have been using portsnap for years for ports, so I can continue to do >>> that. >> >> That is my understanding, yes. >> >>> ... >> >> Peace, >> david >> -- >> David H. Wolfskill da...@catwhisker.org >> Taliban: Evil men with guns afraid of truth from a 14-year old girl. >> >> See http://www.catwhisker.org/~david/publickey.gpg for my public key. >> > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: zio_done panic on unadulterated FreeBSD Release 9.1
On Wed, 09 Jan 2013 15:03:38 -0500, Po-Li Soong wrote: Hi, My name is Po-Li Soong. I ran into a crash not long after installing the 9.1 release on my home machine. I was performing a test run of file transfer with samba server running on the FreeBSD installation. The transfer rate was about 70-80 MB/sec. The core.txt is attached. If there are other crash dumps needed, please let me know. I first discussed this panic with Justin Gibbs, a coworker of mine at Spectra Logic. He referred me to this email address, suggesting that the information should be relevant to you. Thanks for the help. Regards, Po-Li Soong I have this same kernel panic too, after a clean install of 9.1. Will be interesting to see where this goes, as I've had to result to 8.3-STABLE for now. -- Using Opera's mail client: http://www.opera.com/mail/ ___ 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: csup to svn for 8-stable
On Fri, 11 Jan 2013, Brian W. wrote: When I tried the first time, it only grabbed a few folders, a second try got me a conflict message. I then just whacked /usr/src and did the svn co again, successfully. An important difference is that if you modify a file in /usr/src, an svn update will not overwrite it but try to merge with new versions of the file from the repository. ___ 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"
