Bug 84102
| Summary: | FreeBSD 6.0 BETA 1 install Panic's in VMWARE Workstation 5.0.0 build-13124 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Russell J. Yount <rjy> | ||||
| Component: | kern | Assignee: | George V. Neville-Neil <gnn> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | ||||||
| Priority: | Normal | ||||||
| Version: | Unspecified | ||||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| Attachments: |
|
||||||
I see this too: Vmware 3.2.1, FreeBSD 6.0 Beta 2. Full stack trace: panic: Duplicate free of item 0xc1b0c4a4 from zone 0xc143f000(g_bio) cpuid = 0 KDB: enter: panic [thread pid 3 tid 100021 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 3 tid 100021 td 0xc1833300 kdb_enter(c0856274) at kdb_enter+0x2b panic(c0870cfb,c1b0c4a4,c143f000,c0850ced,c0870cdf) at panic+0x127 uma_dbg_free(c143f000,0,c1b0c4a4) at uma_dbg_free+0x110 uma_zfree_arg(c143f000,c1b0c4a4,0) at uma_zfree_arg+0x66 g_destroy_bio(c1b0c4a4) at g_destroy_bio+0x13 g_vfs_done(c1b0c4a4) at g_vfs_done+0x5a biodone(c1b0c4a4,ca0bccc4,0,c0850cb0,1e4) at biodone+0x57 g_io_schedule_up(c1833300) at g_io_schedule_up+0xb5 g_up_procbody(0,ca0bcd38,0,c05fed08,0) at g_up_procbody+0x5a fork_exit(c05fed08,0,ca0bcd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xca0bcd6c, ebp = 0 --- Responsible Changed From-To: freebsd-bugs->gnn gnn@ want to take a look at this one. I'm also seeing the same panic and stack trace under VMware Workstation 5. I can probably provide remote access to a machine (remote desktop, VNC?) if that would aid in debugging... I found this happens during heavy reads from a cd9660 file system, eg. reading the ports.tgz file from a release ISO will panic it. A workaround I used for the BSD Installer images is to remove PREEMPTION from the kernel, see http://perforce.freebsd.org/chv.cgi?CH=81383. Text and patch from mail I just sent to -current. I'd be interested to know if this fixes the reported issue. > acd_geom_start() implements request limiting by breaking up a large > request in the passed bio into a sequence of smaller ones. As each > request is created, acd_strategy is invoked to start the IO. > > However, I think this IO can complete while still issuing the child > requests, leading to the parent being retired early. (ie, when a child > operation completes, it checks if its the last operation to complete, > and, if so, retires the parent: see g_std_done.) > > The attached patch makes my qemu box much more reliable (I could crash > a qemu hosted system 100% with a "tar fc" of the 6.0-BETA bootonly ISO > without the patch, and it's gone through many iterations fine with it) This e-mail is business-confidential and may be privileged. If you are not the intended recipient, please notify us immediately and delete it. If the email does not relate to Vordel's business then it is neither from nor authorized by Vordel. Thank you. I tested the patch with VMWare Workstation 5 eval. It works like a charm. Thanks! Jung-uk Kim I am seeing FreeBSD 6.0 RC1 panic in about the same way: I follow the
same repro steps as in the bug report, and get a panic at about the
same place. Unfortunately I don't know how to debug the kernel; all I
can say is that it prints this on the screen:
Panic: page fault
Uptime: 56s
Cannot dump. No dump device defined.
This is with VMware Workstation e.x.p build 16325.
--
But users will not now with glad cries glom on to a language that
gives them no more than what Scheme or Pascal gave them.
-- Guy Steele, http://www.sun.com/research/jtech/pubs/98-oopsla-growing.ps
I experienced this too. Here it was FreeBSD 6-RC1 running under Microsoft Virtual Server 2005. It seems to be fixed in the latest 6-STABLE snapshot from Oct 13. Using this version the installation worked fine. So this seems to be solved for 6.0-RELEASE. Markus State Changed From-To: open->closed Closing as this was fixed long back. |
Standard install fails in VMWARE 5 Workstation with Panic: Duplicate free of item 0xc1c21000 from zone 0xc144adc0(g_bio) cpuid = 0 KDB: enter: panic [thread pid 2 tid 100034 ] Stopped at kdb_enter+0x2b: nop db> db>where Tracing pid 3 tid 100034 td 0xc1943600 kdb_enter(c0854b84) at kdb_enter+0x2b panic(x086f563,c1c21000,c144adc0,c084f668,c086f547) at panic+0x127 ima_dbg_free(c144adc0,0,c1c21000) at uma_dgb_free_0x110 { note: the above text was manually copied, there may be a typo in it } How-To-Repeat: Create new VMWARE machine for freebsd using vmware defaults. Start a standard install using defaults for disk partitions. Select all for installation packages. System will panic shortly after "extracting base into / directory" is displayed.