freebsd on opensolaris dom0
Adrian Chadd
adrian at freebsd.org
Sun Jun 7 05:31:49 UTC 2009
I can't trigger this here with my Centos 5.3 domU. I have a feeling
this may be related to the hypervisor/dom0 environment.
Not to say it isn't a bug, it is just going to take me more time to
try and figure out.
I'll commit some more Xen tidyups to -current and build a new image
for you. It'll still have the bug but it will at least include the
local source changes I am trying out. That will make testing a bit
easier on me.
Thanks,
Adrian
2009/6/7 Bruno Damour <llama at ruomad.net>:
> Adrian Chadd wrote:
>>
>> What, so fetching data from ftpd running on the xen domU to another
>> LAN connected host?
>>
>>
>>>
>>> so the problem seems to come more from upload traffic than download ?
>>>
>>
>> See, thats the sort of information I need to reproduce the problem. :)
>>
>>
>
> I enable a ftp on a local LAN host (not the dom0) and it confirms that ftp
> get works whereas a ftp put command triggers an immediate crash :
>
> # ftp 192.168.0.103
> ftp: Unknown port `ftp', using port 21
> Connected to 192.168.0.103.
> 220 random FTP server ready.
> Name (192.168.0.103): bruno
> 331 Password required for bruno.
> Password:
> 230 User bruno logged in.
> Remote system type is UNIX.
> Using binary mode to transfer files.
> ftp> get zaum_by_slbprod-2.6.sql
> local: zaum_by_slbprod-2.6.sql remote: zaum_by_slbprod-2.6.sql
> 229 Entering Extended Passive Mode (|||14185|)
> 150 Opening BINARY mode data connection for zaum_by_slbprod-2.6.sql
> (10514 bytes).
> 226 Transfer complete.
> 10514 bytes received in 00:00 (31.29 KB/s)
> ftp> put foobar
> local: foobar remote: foobar
> 229 Entering Extended Passive Mode (|||20050|)
> 150 Opening BINARY mode data connection for foobar.
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex xennetif_tx (network transmit lock) r = 0
> (0xc39430a0) locked @
>
> /home/adrian/work/freebsd/xen/svn/head/sys/dev/xen/netfront/netfront.c:1144
> KDB: stack backtrace:
> X_db_sym_numargs(c03578d2,c3527ab4,c01166d5,c037b2c8,478,...) at
> X_db_sym_numargs+0x146
> kdb_backtrace(c037b2c8,478,ffffffff,c050a9cc,c3527aec,...) at
> kdb_backtrace+0x29
> witness_display_spinlock(c0359db5,c3527b00,4,1,0,...) at
> witness_display_spinlock+0x75
> witness_warn(5,0,c0383c74,c3527b5c,c,...) at witness_warn+0x1fd
> trap(c3527b88) at trap+0x13e
> alltraps(c39430a0,0,c037b2c8,478,2,...) at alltraps+0x1b
> xlvbd_add(c3943000,c3527cc8,c00c6924,c03ce780,c3782538,...) at
> xlvbd_add+0x36b3
> intr_event_execute_handlers(c37087ec,c3782500,c034fbb5,4e9,c3782570,...)
> at intr_event_execute_handlers+0x125
> intr_event_add_handler(c3948140,c3527d38,c034f8e8,335,c37087ec,...)
> at intr_event_add_handler+0x41f
> fork_exit(c00afe50,c3948140,c3527d38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc3527d70, ebp = 0 ---
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0x2
> fault code = supervisor read, page not present
> instruction pointer = 0x21:0xc02f719b
> stack pointer = 0x29:0xc3527bc8
> frame pointer = 0x29:0xc3527bf8
> code segment = base 0x0, limit 0xf9800, type 0x1b
> = DPL 1, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 12 (irq135: xn)
> [thread pid 12 tid 100024 ]
> Stopped at xlvbd_add+0x204b: cmpl $0,0(%edx)
> db> bt Tracing pid 12 tid 100024 td 0xc3756d80
> xlvbd_add(c39430a0,0,c037b2c8,478,2,...) at xlvbd_add+0x204b
> xlvbd_add(c3943000,c3527cc8,c00c6924,c03ce780,c3782538,...) at
> xlvbd_add+0x36b3
> intr_event_execute_handlers(c37087ec,c3782500,c034fbb5,4e9,c3782570,...)
> at intr_event_execute_handlers+0x125
> intr_event_add_handler(c3948140,c3527d38,c034f8e8,335,c37087ec,...)
> at intr_event_add_handler+0x41f
> fork_exit(c00afe50,c3948140,c3527d38) at fork_exit+0xb8
> fork_trampoline() at fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xc3527d70, ebp = 0 ---
> db>
>
>
More information about the freebsd-xen
mailing list