TheGrebs.com:IRC Logs:#xen:2006:02:01

---	Log	opened Wed Feb 01 00:00:11 2006
00:08	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has quit [Quit: jimix]
00:33	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has joined #xen
00:49	<rusty>	OK, any clue with "Error: Device 2048 (vbd) could not be connected. Hotplug scripts not working.
00:49	<rusty>	"?
00:51	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has quit [Quit: jimix]
00:53	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has joined #xen
00:57	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has quit [Quit: ]
01:01	\|-\|	sdog [~sdog@213-193-182-28.adsl.easynet.be] has joined #xen
01:13	\|-\|	nicolas [~nicolas@130.158.161.128] has quit [Quit: Leaving]
01:21	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has quit [Quit: Client exiting]
01:48	\|-\|	Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has quit [Quit: foo]
02:02	\|-\|	DV_ [~veillard@194.98.169.93] has joined #xen
02:10	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
02:47	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has joined #xen
03:02	\|-\|	dme [~dme@host-84-9-60-139.bulldogdsl.com] has quit [Remote host closed the connection]
03:04	\|-\|	dme [~dme@host-84-9-60-139.bulldogdsl.com] has joined #xen
03:25	\|-\|	_David_ [~david@CPE-203-45-91-168.nsw.bigpond.net.au] has joined #xen
04:01	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has joined #xen
04:05	[~]	muli ponders the pciback/pcifront patches
04:31	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
05:02	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
05:42	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has quit [Remote host closed the connection]
05:55	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
05:58	\|-\|	_David_ [~david@CPE-203-45-91-168.nsw.bigpond.net.au] has left #xen [Kopete 0.9.2 : http://kopete.kde.org]
06:09	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Read error: Connection reset by peer]
06:09	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
06:10	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
06:21	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has quit [Remote host closed the connection]
06:21	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has joined #xen
06:26	\|-\|	_David_ [~david@CPE-203-45-91-168.nsw.bigpond.net.au] has joined #xen
06:27	\|-\|	_David_ [~david@CPE-203-45-91-168.nsw.bigpond.net.au] has left #xen []
07:03	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
07:04	\|-\|	lilo [~lilo@lilo.usercloak.oftc.net] has quit [Quit: leaving]
07:05	\|-\|	DV_ [~veillard@194.98.169.93] has quit [Remote host closed the connection]
07:20	\|-\|	lilo [~lilo@24.167.94.255] has joined #xen
07:24	\|-\|	Tv [~tv@GMMDXXVII.dsl.saunalahti.fi] has joined #xen
07:28	\|-\|	bernarde [~bernarde@tux01.ltc.ic.unicamp.br] has joined #xen
07:30	\|-\|	Welty [~welterlb@proxy2-ibtnet.bull.fr] has joined #xen
07:39	\|-\|	surriel changed nick to riel
07:40	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
07:41	<@MarkW>	aliguori: I actually found some docs. They're just not always obvious on IBM's zseries pages
07:41	<@MarkW>	aliguori: Of particular interest / utility to me was (what appears to be!?!?!) a hypercall interface that allows textual commandlines to be passed to the control program for execution.
07:43	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
07:44	<aliguori>	MarkW, interesting, gotta run to class though, ttyl
07:44	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Quit: Leaving]
07:44	\|-\|	MarkW [~MarkW@maw48.kings.cam.ac.uk] has left #xen [Kopete 0.10.2 : http://kopete.kde.org]
07:46	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
07:47	<muli>	markw, that is one of the ugliest things about dcss
07:47	<muli>	comes complete with ebcdic conversion utilities, last time I looked at it
07:47	[~]	muli barfs
07:52	\|-\|	bernarde [~bernarde@tux01.ltc.ic.unicamp.br] has quit [Remote host closed the connection]
07:56	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
08:01	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
08:04	[~]	riel wonders if serial console is currently known-broken
08:06	<riel>	I can get output on it, but no input ;(
08:06	<tab>	riel: is that a SMP dom0 ?
08:06	<riel>	I think so, let me check
08:06	<riel>	yes, SMP
08:07	\|-\|	nags [~nags@125.16.129.16] has quit [Quit: Linux Desktop Testing Project - http://ldtp.freedesktop.org]
08:07	<riel>	with sync_console=1 otherwise it hangs on bootup ;)
08:08	<tab>	that's a "known" problem
08:09	<tab>	looks like nothing notify the kernel that there's stuff in the ring buffer ..
08:09	<riel>	SMP only, or UP too ?
08:09	<tab>	SMP only
08:10	[~]	riel will have to try with dom0_cpus=1 or whatever that was
08:10	<tab>	we have dom0 UP, thus people doesn't hit the bug here often
08:11	<tab>	not sure that's related to SMP or by the extra instruction in the SMP kernel ..
08:11	<tab>	would be good to know i guess
08:20	\|-\|	toks [~toks@bi01p1.nc.us.ibm.com] has joined #xen
08:25	\|-\|	anball [~anball@bi01p1.nc.us.ibm.com] has joined #xen
08:27	<riel>	ok, I guess it would have to be a UP compiled dom0
08:27	<riel>	simply starting xen with nosmp doesn't fix this issue either
08:38	\|-\|	rpg [~rpg@pixpat.austin.ibm.com] has joined #xen
08:39	\|-\|	DV_ [~veillard@194.98.169.93] has joined #xen
09:06	\|-\|	[Sir_Ahzz][Sir_Ahzz] changed the topic of #xen: http://www.getxen.org/ \|\| xm-test results http://xmtest.dague.org \|\| Winter XenSummit slides http://www.xensource.com/company/xensummit.html \|\| Xen 3.0.1 is now available - bugfixes and cleanups.
09:06	<@Sir_Ahzz>	Morning you schizos. :)
09:07	<schula>	moin
09:07	<schula>	;)
09:07	<@Sir_Ahzz>	It's looking like I'll get to build my xen cluster again later this spring or summer.
09:07	<@Sir_Ahzz>	I miss it.
09:09	\|-\|	bernarde [~bernarde@tux01.ltc.ic.unicamp.br] has joined #xen
09:10	\|-\|	dansmith [~dan@bi01p1.co.us.ibm.com] has joined #xen
09:17	\|-\|	DV_ [~veillard@194.98.169.93] has quit [Ping timeout: 480 seconds]
09:27	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has joined #xen
09:46	\|-\|	jamesm [~jmorris@nat-pool-bos.redhat.com] has joined #xen
10:07	\|-\|	aliguori [~anthony@horatio-023.cs.utexas.edu] has joined #xen
10:17	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has joined #xen
10:18	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has joined #xen
10:21	\|-\|	jerone [~jerone@adsl-71-145-181-130.dsl.austtx.sbcglobal.net] has joined #xen
10:32	\|-\|	toks [~toks@bi01p1.nc.us.ibm.com] has quit [Remote host closed the connection]
10:45	\|-\|	aliguori [~anthony@horatio-023.cs.utexas.edu] has quit [Remote host closed the connection]
10:58	\|-\|	zwane [~zwane@S0106001217d33fa6.vc.shawcable.net] has joined #xen
11:07	\|-\|	pvanhoof [~pvanhoof@mailhost.newtec.be] has quit [Remote host closed the connection]
11:07	\|-\|	Basic_py [~Basic@warden.real-time.com] has quit [Quit: Leaving]
11:08	\|-\|	naemon [~naemon@spyglass.dllstx5.theplanet.com] has joined #xen
11:09	\|-\|	naemon [~naemon@spyglass.dllstx5.theplanet.com] has quit [Quit: ]
11:15	\|-\|	naemon [~naemon@spyglass.dllstx5.theplanet.com] has joined #xen
11:19	\|-\|	spb [~spb@pan.object4.net] has quit [Ping timeout: 480 seconds]
11:28	\|-\|	spb [~spb@pan.object4.net] has joined #xen
11:33	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has joined #xen
11:35	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
11:37	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has quit [Quit: Leaving]
11:43	\|-\|	yorkedork [~thom@cpe-071-065-223-102.nc.res.rr.com] has joined #xen
11:44	\|-\|	yorkedork [~thom@cpe-071-065-223-102.nc.res.rr.com] has quit [Quit: ]
11:51	\|-\|	toks [~toks@bi01p1.nc.us.ibm.com] has joined #xen
11:55	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has joined #xen
12:00	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has joined #xen
12:09	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
12:14	\|-\|	aliguori [~anthony@cpe-70-112-37-78.austin.res.rr.com] has joined #xen
12:15	\|-\|	athomas [~athomas@host86-136-81-69.range86-136.btcentralplus.com] has quit [Quit: Leaving]
12:20	<thelsdj>	anyone know details on hwo the xen networking works with vmx domains using ioemu? appears there isn't a vif for them, but a tunX device, and I can't quite figure out how to add an ip on the dom0 side of the interface
12:21	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
12:26	\|-\|	aliguori [~anthony@cpe-70-112-37-78.austin.res.rr.com] has quit [Quit: Leaving]
12:33	<johnlev>	has kip macy been around here recently?
12:36	<stekloff>	thelsdj: ioemu uses the qemu-dm emulation for the networking
12:39	<stekloff>	I think you need to set the IP in the vmx domain
12:41	\|-\|	pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has joined #xen
12:49	<thelsdj>	stekloff: ya i know, i'm just trying to get the xm-test network tests to work with hvm domains, getting somewhere now
12:49	<thelsdj>	need to add ip inside the domain, and on xenbr0, plus add a route to xenbr0 (thats what i was missing before)
12:50	<thelsdj>	now i just need to clean up the tests so they auto detect if using a different bridge, and the network to add the route on
12:50	<stekloff>	ok, the network tests are really lame right now
12:53	<thelsdj>	yea i'm fixing them a bit, and going to try to add some stress tests
12:54	<thelsdj>	i've got 2 of them to pass for hvm domains so far, and the 3rd almost passes, just can't handle the largest ping size
12:54	<thelsdj>	now to figure out how to do some string manipulation with python
12:54	<stekloff>	are you going to send patches?
12:54	<thelsdj>	ya i plan to
12:54	<stekloff>	thanx
12:55	<ns>	thelsdj: thanks! saving us some work that was on our plate
12:55	<ns>	thelsdj: but we weren't getting around to..
12:56	<thelsdj>	well i'm able to crash the domain by throwing a little traffic at the network so thats why i want a test for it :)
12:56	<ns>	thelsdj: yep, there are several networking bugs that need investigation ;)
12:57	<ns>	thelsdj: these are any type of domains, right, not just hvm?
12:59	<thelsdj>	no, this is just hvm, which may just be a problem with the qemu io stuff, but would still like a test to demonstrate it
13:01	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Read error: Connection reset by peer]
13:01	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
13:03	<thelsdj>	now to figure out how to get the Network.py file to detect the bridge used in the domain config file
13:03	<thelsdj>	hrm guess i could just pass it as an option from the test script but doesn't seem like the best solution
13:08	<Cyis>	arg... I hate it when people jump in front of the commuter train... at least this time they had the presence of mind to do it on the bosses time and not mine (ie- on the way home)
13:09	<thelsdj>	how long does it take to get started again? or did you have to find another way home?
13:10	<Cyis>	usually takes them about 2 hours to get things moving on schedule again
13:10	<stekloff>	thelsdj: is that info in xenstore?
13:10	<Cyis>	this morning was just shy of that
13:11	<thelsdj>	stekloff: no, doesn't appear to be
13:12	\|-\|	aliguori [~anthony@horatio-023.cs.utexas.edu] has joined #xen
13:35	[~]	aliguori wonders why we went to 2.6.14 instead of .15
13:35	<aliguori>	or even .16
13:35	<stekloff>	aliguori: they had it done
13:35	<stekloff>	aliguori: I suspect they will increment
13:35	<aliguori>	stekloff, hrm
13:35	<tab>	aliguori: because it was one of staging tree we had
13:35	<tab>	+the
13:36	<aliguori>	tab: do you know if there's a plan to go up to one of the .16 rcs?
13:36	<tab>	aliguori: today or tomorrow we will upgrade to 2.6.15, if I understood correctly
13:37	<tab>	for .16 I'm not sure
13:37	<aliguori>	excellent
13:37	<aliguori>	tab, thanks!
13:37	<tab>	but heh, we only have to count on CL goodwill .. :\
13:37	<Cyis>	hopefully if updated for .16 they'll keep the earlier .15 patches as well
13:38	<aliguori>	tab: heh :-)
13:40	\|-\|	aliguori [~anthony@horatio-023.cs.utexas.edu] has quit [Quit: Leaving]
13:50	\|-\|	jm_c [jm@d213-103-240-30.cust.tele2.fr] has joined #xen
13:52	\|-\|	naemon [~naemon@spyglass.dllstx5.theplanet.com] has quit [Quit: Leaving]
13:59	\|-\|	sdog [~sdog@213-193-182-28.adsl.easynet.be] has quit [Remote host closed the connection]
14:07	\|-\|	jm_c [jm@d213-103-240-30.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
14:14	\|-\|	monrad [~mikkel@213083190131.sonofon.dk] has quit [Quit: leaving]
14:18	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Read error: Connection reset by peer]
14:18	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
14:18	\|-\|	jm_c [jm@d83-177-201-13.cust.tele2.fr] has joined #xen
14:23	\|-\|	Shoragan_ [~shoragan@d072.apm.etc.tu-bs.de] has joined #xen
14:23	\|-\|	Shoragan [~shoragan@d072.apm.etc.tu-bs.de] has quit [Read error: Connection reset by peer]
14:29	\|-\|	bernarde [~bernarde@tux01.ltc.ic.unicamp.br] has quit [Ping timeout: 480 seconds]
14:30	<thelsdj>	here is initial xm-test patch to fix hvm network tests: http://thelsdj.org/xmtest-network-hvm.patch i'll be mailing to the list soon
14:31	<stekloff>	thelsdj: cool
14:32	<thelsdj>	they don't 100% pass because the largest pings fail on the 02 and 05 test, but everything else works
14:32	<thelsdj>	but 11 passes 100%
14:32	<stekloff>	thelsdj: the pings are a different issue
14:32	<stekloff>	they fail on non-hvm as well
14:35	\|-\|	sdog [~sdog@213-193-182-28.adsl.easynet.be] has joined #xen
14:37	<thelsdj>	does the largest ping fail on 11_ on non hvm?
14:37	<thelsdj>	as they work on hvm
14:38	<stekloff>	yes, I think so
14:38	<stekloff>	there's a different bug for the pings failing and it isn't hvm specific
14:51	\|-\|	_David_ [~david@CPE-203-45-91-168.nsw.bigpond.net.au] has joined #xen
14:51	\|-\|	_David_ [~david@CPE-203-45-91-168.nsw.bigpond.net.au] has left #xen []
14:52	<ns>	thelsdj:could you also update the xmtest documentation?
14:57	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has joined #xen
15:03	<thelsdj>	ns: what needs to be updated?
15:04	<ns>	if you fixed the network tests - would be good to get some info regarding running networking on vmx domains
15:04	<ns>	there
15:05	<ns>	stekloff:thelsdj: i'm thinking those tests should not be XFAIL but FAIL
15:05	<ns>	the functionality is there, the fact that it fails is a bug
15:05	<stekloff>	ns: they are currently XFAIL because of the ping bug
15:05	<stekloff>	I'm glad thelsdj got around to fixing the network tests, 'cause I hadn't
15:05	<ns>	the XFAIL category should be used if the code to support it isn't there (unimplemented feature, for instance)..right?
15:06	<thelsdj>	hrm where is the xm-test documentation?
15:06	<stekloff>	thelsjd: good question
15:06	<stekloff>	there's a README
15:06	<ns>	that's in docs
15:06	<stekloff>	the HOWTO for writing tests was never submitted
15:06	<thelsdj>	i don't think theres really any need for documentation fixes
15:06	<ns>	ok
15:07	<thelsdj>	basically these changes don't require the user to do anything else
15:07	<ns>	agreed for that
15:07	\|-\|	jm_c [jm@d83-177-201-13.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
15:07	<thelsdj>	the patch that added checking for the pcnet32 module is all the new stuff the user needs to take care of
15:07	<stekloff>	I don't think docs need updating for the network patch
15:07	<ns>	we should be doing a doc update for the tests themselves
15:07	<stekloff>	ns: I only updated the README, so perhaps I should update the other docs
15:10	<ns>	stekloff: yeah, but hold off on that till next week, no hurry..
15:10	<ns>	I'll take a first pass through it as soon as I can
15:14	<thelsdj>	hrm hping doesn't appear to work for me
15:17	<ns>	hmmm..what is your guest?
15:18	\|-\|	jm_c [jm@d213-103-219-19.cust.tele2.fr] has joined #xen
15:25	<thelsdj>	2.4 kernel, as i couldn't get any 2.6 kernels to boot hvm
15:26	\|-\|	sdog [~sdog@213-193-182-28.adsl.easynet.be] has left #xen []
15:34	<ns>	hmmm, we've been running fine so far..have you tried the latest xen-unstable tree after the hvm merge?
15:35	<dansmith>	thelsdj: what trouble are you having with 2.6?
15:35	<thelsdj>	dansmith: i haven't got a single 2.6 kernel to succesfully boot, tried multiple i've built myself and a few live cds
15:35	<thelsdj>	let me see if i can find one of the problems
15:36	<ns>	wonder if the vmx docs need updating..
15:36	<dansmith>	thelsdj: hmm, which kernels have you tried? I think the one we're using is the default from RHEL4
15:37	<thelsdj>	i think this was with kernel.org sources: 2.4.14 http://thelsdj.org/vmx-disk.png just hung there
15:37	<thelsdj>	i've sense figured out the pty trick for getting better output but haven't gone back to a 2.6 since
15:37	<dansmith>	thelsdj: nice window decorations :)
15:38	<dansmith>	thelsdj: can you grab the kernel image out of a FC4 RPM and try that?
15:39	<ns>	don't know if that acpi message is good..
15:39	<thelsdj>	ya i'll see if i can find that
15:40	<ns>	or just download the current xen-unstable
15:40	<thelsdj>	well i've been using xen unstable
15:40	<dansmith>	ns: no, I want him to use a stock FC4 kernel for inside the HVM domain
15:40	<thelsdj>	yea
15:40	<dansmith>	ns: we don't build a kernel for the user, we use one they already have
15:41	<thelsdj>	you mean like this? http://download.fedora.redhat.com/pub/fedora/linux/core/4/i386/os/Fedora/RPMS/kernel-2.6.11-1.1369_FC4.i586.rpm
15:41	<dansmith>	thelsdj: yup
15:42	<thelsdj>	ok will try that
15:42	<stekloff>	thelsdj: my xm-test for hvm just grabs my FC3 kernel: vmlinuz-2.6.12-1.1381_FC3
15:42	<stekloff>	and it works fine
15:42	<dansmith>	stekloff: fc3?
15:42	<dansmith>	hmm, well, maybe thelsdj should try that one, just to be apples-to-apples
15:43	<thelsdj>	i'm using gentoo as host, don't even bother building non xen kernels when installing, plus its 64bit so to build a non xen 32bit kernel i need to makea 32bit non-vmx guest and build it inside there heh
15:43	<thelsdj>	hrm well fc3 doesn't show a 2.6.12, maybe thats an update somewhere else, the release only had 2.6.9
15:44	<dansmith>	thelsdj: that would be in the updates tree
15:44	<thelsdj>	ok, found http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/i386/kernel-2.6.12-1.1381_FC3.i686.rpm
15:46	<thelsdj>	have yet to figure out a shortcut to rebuilding the xm-test disk image, if i drop the dl files in, make seems to asume some steps are already done and fails, maybe i should try to fix that
15:47	<dansmith>	thelsdj: stekloff wrote the disk.img building stuff, so he would know the shortcut
15:47	<stekloff>	thelsdj: yeah... the make process needs to be fixed
15:48	<stekloff>	the Makefile.am in ramdisk requires initrd to be built, but doesn't check if it already exists
15:48	<stekloff>	when building the disk.img
15:48	<stekloff>	it's on my todos
15:51	\|-\|	bestorga [~bestorga@bi01p1.co.us.ibm.com] has joined #xen
15:53	<thelsdj>	so why does: 'disk.img: $(XMTEST_VER_IMG)' not do what it should? (which is not build the image if it exists, or is it an issue of make thinking it needs to be rebuilt?
15:54	<stekloff>	look at the $(BR_TAR): and others, they don't check
15:55	<stekloff>	there's no check to see if it exists already except by existing:
15:55	<stekloff>	So, a check needs to be put in there
15:57	\|-\|	matta [~matta@c-68-80-22-194.hsd1.pa.comcast.net] has joined #xen
15:59	<thelsdj>	ah right so because $(BR_IMG) is dependency of $(XMTEST_VER_IMG) even if the initrd exists it still asumes br_img needs to be built
16:00	<stekloff>	yep
16:00	<stekloff>	so, just needs to be changed
16:06	<ns>	dansmith: thelsdj: no,make sure you're using latest xen-unstable on dom0, issue is there, not in guest, likely
16:07	<ns>	in addition to above issue, of course
16:07	\|-\|	jm_c [jm@d213-103-219-19.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
16:10	<thelsdj>	i have not updated dom0 since the hvm import and subarch changes
16:12	\|-\|	_David_ [~david@202.148.226.15] has joined #xen
16:17	\|-\|	stephand [~syon@G0a39.g.pppool.de] has joined #xen
16:18	\|-\|	stephand [~syon@G0a39.g.pppool.de] has quit [Quit: ]
16:18	\|-\|	jm_c [jm@d80-170-19-219.cust.tele2.fr] has joined #xen
16:26	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has quit [Quit: jimix]
16:27	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has joined #xen
16:32	<thelsdj>	stekloff: also the xm-test makefiles fail if you pass the hvm kernel or modules paths as relative paths (well it gets all the way to trying to find the kernel when building disk.img and failing there)
16:52	<stekloff>	Yeah, I was thinking about putting a check in the configure.ac
16:53	<stekloff>	thelsdj: feel free to patch the configure.ac with tests
16:53	<thelsdj>	looks like the fc3 kernel works, and hping works with that also!
16:53	<stekloff>	cool
16:54	<thelsdj>	so now to try out latest unstable, and write some network tests that hit the network a little harder
16:59	\|-\|	mejlholm [~mejlholm@port79.ds1-abc.adsl.cybercity.dk] has quit [Quit: Client exiting]
17:02	\|-\|	rusty [~rusty@bh02i525f01.au.ibm.com] has joined #xen
17:06	\|-\|	dansmith [~dan@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
17:07	\|-\|	jm_c [jm@d80-170-19-219.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
17:13	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
17:16	<ns>	stekloff:thelsdj: note that hping is not a complete substitute for tcp, code path not the same
17:16	<ns>	we want to also throw ssh tests wget tests in there
17:17	<stekloff>	I need to extend the disk.img file system
17:17	<stekloff>	to create room for things
17:17	\|-\|	Bicster [~Bicster@ip195.planetfall.com] has joined #xen
17:17	<stekloff>	another thing to correct...<sigh>
17:17	<Bicster>	anyone have a 2.6.15 kernel running under Xen w/ SMP on x86_64?
17:19	\|-\|	jm_c [jm@d83-179-129-249.cust.tele2.fr] has joined #xen
17:20	\|-\|	DarkHelmut [~mbrennek@helios.2nw.net] has quit [Ping timeout: 480 seconds]
17:22	\|-\|	toks [~toks@bi01p1.nc.us.ibm.com] has quit [Quit: Leaving]
17:26	\|-\|	jerone [~jerone@adsl-71-145-181-130.dsl.austtx.sbcglobal.net] has quit [Ping timeout: 480 seconds]
17:34	\|-\|	mccabemt [~mccabemt@sclab-171-76.sclab.clarkson.edu] has joined #xen
17:37	\|-\|	mccabemt [~mccabemt@sclab-171-76.sclab.clarkson.edu] has left #xen []
17:38	\|-\|	rharper [~rharper@pixpat.austin.ibm.com] has quit [Quit: Leaving]
17:42	<thelsdj>	stekloff: with a few pointers i could maybe submit a patch for adding wget and dropbear
17:44	<ns>	thelsdj: that would be great, we'd be glad to help you out
17:45	<thelsdj>	woo, latest xen-unstable kernel panics :)
17:45	<Bicster>	the kernel panics or xen panics? on mine, xen paniced
17:46	<Bicster>	and the 2.6.15 kernel only works non-SMP, which is why I asked a moment ago...
17:46	<thelsdj>	kernel panics
17:46	<thelsdj>	with the 2.6.14
17:46	<Bicster>	oh, I thought you meant 2.6.16rc1
17:46	<thelsdj>	soon as init runs
17:47	<thelsdj>	and i have no serial on this system
17:49	<rpg>	i am seeing a kernel panic on 2.6.14, x86_64 as well w/ latest unstable
17:50	<Bicster>	I was trying 3.0.1 w/ 2.6.16rc1 and 2.6.15. hrm
17:50	\|-\|	woody [~woody@bi01p1.co.us.ibm.com] has joined #xen
17:51	<thelsdj>	rpg: ya this is x86_64 with vt
17:54	<ns>	looks like the kernel merge isn't quite so smooth as the hvm merge
17:54	<stekloff>	yeah
17:54	<stekloff>	rpg: do you have console output?
17:55	<Cyis>	I'm wondering where the .15 and .16rc1 patches you're applying are... they aren't in xen-unstable.hg
17:56	<rpg>	stekloff: yes
17:57	<rpg>	thelsdj, i do not have vt
17:58	<ns>	can somebody report to xen-devel?
17:58	<rpg>	ns, sure, i'll cut and paste my console output
17:58	<ns>	thanks, rph
17:58	<ns>	s/h/g
18:00	<rpg>	thelsdj, is your box smp? x86_64 boots fine w/o smp but smp causes the panic
18:00	\|-\|	jm_c [jm@d83-179-129-249.cust.tele2.fr] has quit [Read error: Connection reset by peer]
18:00	<thelsdj>	rpg: yes its smp, i'll try w/o smp and see if that works
18:01	<woody>	rpg, smp panics? little more information, what type of hardware?
18:02	<rpg>	woody: dual opteron, smp on, 4 gigs of ram
18:03	<thelsdj>	mine is dual core presler
18:03	<woody>	rpg, try maxcpus=1 in grub on the kernel line
18:03	<thelsdj>	woody: on the xen or dom0 line?
18:04	<woody>	thelsdj, on kernel and module
18:05	<thelsdj>	woody: that fixes my panic
18:05	<woody>	thelsdj, wow
18:06	<thelsdj>	now, can i try telling dom0 only 1 cpu but still allowing xen multiple?
18:07	<woody>	thelsdj, does /proc/cpuinfo show one proc?
18:07	<woody>	thelsdj, what is xen multiple?
18:07	<rpg>	woody, thelsdj, maxcpus=1 on the module line allows dom0 to boot ... xen still sees 2 cpus but dom0 only 1
18:08	<thelsdj>	ah yes
18:08	<thelsdj>	i have that too, ok, great
18:08	<thelsdj>	interesting
18:08	<woody>	rpg, hmm HT ? but one real CPU initialilzed?
18:09	\|-\|	dansmith [~dan@c-24-21-32-166.hsd1.or.comcast.net] has joined #xen
18:09	<woody>	rpg, thelsdj dual core?
18:09	<thelsdj>	mine is dual core intel presler with VT
18:10	<woody>	thelsdj, so for one physical you will see 2 in /proc?
18:10	<thelsdj>	no, it would show that it was 2 cores
18:10	<thelsdj>	but only one entry in proc
18:11	<thelsdj>	siblings = 2 and cpu cores = 2
18:11	<woody>	thelsdj, k but what was that xen multiple ?
18:12	<thelsdj>	i thought you meant maxcpus=1 would turn off xen seeing more than 1 core
18:12	<woody>	thelsdj, no it was to possibly get past the panic
18:12	<woody>	thelsdj, sorry
18:13	<rpg>	woody, no ht, two physical cpus
18:15	<woody>	rpg, thelsdj when I brought up on VT 4 way HT + dual it came up in /proc with 16, putting in maxcpus=1 showed only 1 proc initialized in dmesg
18:16	<rpg>	woody: i only put maxcpus=1 on the module line
18:16	<woody>	I put it on kernel and module
18:17	<woody>	little retent, sorry
18:18	\|-\|	jm_c [jm@d83-177-192-163.cust.tele2.fr] has joined #xen
18:18	<thelsdj>	rpg: you still going to drop output to xen-dev?
18:19	<rpg>	thelsdj, sure just sent it
18:23	\|-\|	rpg [~rpg@pixpat.austin.ibm.com] has quit [Remote host closed the connection]
18:23	\|-\|	anball [~anball@bi01p1.nc.us.ibm.com] has quit [Quit: Leaving]
18:24	\|-\|	stekloff [~stekloff@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
18:34	\|-\|	DarkHelmut [~mbrennek@helios.2nw.net] has joined #xen
18:36	<ns>	feel free to also post to xen-devel and cover any additional info..
18:41	\|-\|	bestorga [~bestorga@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
19:06	<johnlev>	hey, I'm getting EPERM on trying to read control/sysrq in my domain with 3.0 testing.
19:06	<johnlev>	this used to work...
19:07	\|-\|	jm_c [jm@d83-177-192-163.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
19:07	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
19:14	<johnlev>	aliguori: any suggestions on where to go sniffing around now my domain gets EPERM reading control/sysrq?
19:14	\|-\|	Shoragan_ [~shoragan@d072.apm.etc.tu-bs.de] has quit [Quit: Leaving]
19:15	<aliguori>	johnlev, you're reading that within the domU?
19:16	<johnlev>	yep
19:16	<Shaun2>	any idea why i might be getting this error? Error: Device 0 (vif) could not be connected. Backend device not found.
19:16	<Shaun2>	using lvm
19:16	\|-\|	Basic_py [~Basic@gatekeeper.real-time.com] has quit [Quit: Leaving]
19:16	<Shaun2>	/dev/vg/image is their...
19:16	\|-\|	schultmc [~schultmc@zealot.progeny.com] has quit [Remote host closed the connection]
19:17	<Shaun2>	disk = [ 'phy:vg/fs_1048,sda1,w','phy:vg/fs_1049,sdb1,w', ]
19:17	<aliguori>	johnlev: are you getting it in the kernel? perhaps your xenbus is not working correctly? i assume this is opensolaris right?
19:17	<johnlev>	Shaun: that's the vif
19:17	<Shaun2>	oh
19:17	<Shaun2>	duhh
19:17	<johnlev>	aliguori: yeah. it used to work, I've just noticed it's broken since we uprevved our xen version
19:17	<aliguori>	johnlev, how old of a version were you on?
19:18	<johnlev>	aliguori: it might be our xenbus port, yes (but it would be a little odd if so since other reads are ok)
19:18	<Shaun2>	i bet if i installed bridgeutils it would work :)
19:18	\|-\|	jm_c [jm@d213-103-117-3.cust.tele2.fr] has joined #xen
19:18	<johnlev>	aliguori: ancient, 18th October
19:18	<aliguori>	johnlev, ah, that's what I figured :-)
19:18	<johnlev>	Shaun: it might help :)
19:18	<aliguori>	johnlev, since then, permission checking was added
19:18	<aliguori>	before, permissions were never enforced
19:18	<johnlev>	ah, that's a big piece of the problem indeed :)
19:19	<aliguori>	are you sure your not accidently reading /control/sysrq? or perhaps your control tools aren't setting permissiosn right?
19:19	<johnlev>	that'd be ENOENT, right? the dom0 side of things is still on Linux
19:20	<johnlev>	anyway, now I have some idea why things might have changed, I'll dig back
19:20	<johnlev>	thanks!
19:20	<aliguori>	np :-) good luck
19:20	<Shaun2>	johnlev: lol, thanks, i wiped this box so it was a clean install, guess i figured it was already installed :)
19:20	<aliguori>	Shaun2, unfortunately, that's a pretty generic error.. it's really hard to even say where you should start looking
19:20	<aliguori>	:-(
19:21	<aliguori>	could be a bad config, bad udev/hotplug.. most of the time, that error tends to be a user-error though, not a xen bug
19:22	<ns>	however, not having bridge-utils would be a fairly fatal issue ;)
19:22	<Shaun2>	aliguori: vif should have tipped me off... it's just that i was having errors with loops the other day so i immediatly though it was somthing simular since i just converted my backend to use LVM
19:22	<ns>	the install log should have the error (brctl not found)
19:23	<aliguori>	ns: yes, that's a good one too, but don't we have a check for bridge-utils in install.sh?
19:23	<Shaun2>	well... for a centos minimal install so far you need... gcc gcc-c++ patch python-devel ncurses-devel zlib-devel tetex-latex transfig bridge-utils
19:24	<aliguori>	that sounds right
19:27	<ns>	yep - the install has the error, but it's not fatal :(
19:27	\|-\|	mOdY [m0dY@62.139.160.212] has quit [Ping timeout: 480 seconds]
19:27	<ns>	people rarely check their install logs
19:27	<Shaun2>	with my UML setup, i gave each guest a custom mac (their primary ip converted to hex) and used a dhcp server to assign them their ip on boot... i noticed that xen has some options for specifing dhcp or a ip and what not, how does that work... if i give a ip/netmask/gateway to the config does it auto configure the guest some how?
19:30	<ns>	you're better off using the domain's distro config files for normal IP setup rather than going through the xend script
19:34	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
19:35	<johnlev>	ouch, setting xenstore trace makes the vif fail to connect.
19:36	<ns>	oh really..might be exposing some race condition..
19:37	<johnlev>	ok, maybe not, in fact
19:44	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has quit [Ping timeout: 480 seconds]
19:57	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
20:03	\|-\|	pvanhoof [~pvanhoof@d54C0FBBD.access.telenet.be] has quit [Remote host closed the connection]
20:07	<johnlev>	aliguori: caught it. had nothing to do with xenstore, it was a screwed-up scanf change
20:07	\|-\|	jm_c [jm@d213-103-117-3.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
20:07	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has joined #xen
20:12	<Bicster>	meh ... 2.6.15 works on x86 but not x86_64
20:12	<tab>	Bicster: we know
20:12	\|-\|	matta [~matta@c-68-80-22-194.hsd1.pa.comcast.net] has quit [Quit: Download Gaim: http://gaim.sourceforge.net/]
20:14	<Bicster>	tab, I've been trying to get it to work for a few days and nobody on the ML bothered to mention that fact.
20:14	<Bicster>	lol/arrgh
20:16	<Bicster>	does .16rc1 function correctly on x86?
20:17	<tab>	maybe
20:18	\|-\|	jm_c [jm@d213-103-230-106.cust.tele2.fr] has joined #xen
20:18	<Bicster>	fwiw when I try to boot .16rc1 on x86_64, xen itself panics
20:19	<tab>	what it is saying ?
20:19	<Bicster>	it's all hex to me ... I have a log of it, but it's back at my office
20:20	<Bicster>	.15 works on x86_64 with 'nosmp'
20:20	<tab>	there's a text message at the end
20:20	<Bicster>	sorry, I don't recall
20:20	<Bicster>	I will check tomorrow when I return to work
20:22	<Bicster>	oh well..whomever did away with ARCH=xen is my hero
20:22	<ns>	amen
20:22	<Bicster>	genkernel works and so does make-kpkg :)
20:23	<tab>	I did most work to remove it
20:23	<Bicster>	tab += beer
20:23	<tab>	despite what the chglog say ...
20:24	<tab>	thanks Bicster
20:25	<Bicster>	I also got my first vmx guest up and running today. That was a nice little victory. Performance is even passable when accessing windoze via rdesktop
20:25	<tab>	good to hear that not everything is screwed ;)
20:26	<tab>	anyway time to sleep here, night' guys
20:26	<Bicster>	it's called the bleeding edge for a reason ;) I'm impressed any of it works at all.
20:26	<Bicster>	nite
20:36	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Ping timeout: 480 seconds]
20:38	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has joined #xen
21:00	\|-\|	mdday [~mdday@cpe-024-163-120-222.nc.res.rr.com] has quit [Quit: mdday]
21:01	\|-\|	ns [~niv@bi01p1.co.us.ibm.com] has quit [Quit: Leaving]
21:07	\|-\|	jm_c [jm@d213-103-230-106.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
21:18	\|-\|	jm_c [jm@d83-179-132-207.cust.tele2.fr] has joined #xen
21:34	<aliguori>	johnlev: :-)
21:34	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has quit [Quit: jimix]
21:36	\|-\|	jimix [~jimix@bh02i525f01.au.ibm.com] has joined #xen
21:36	<johnlev>	now I'm on to resume hanging in xenbus, inevitably our problem again :)
21:36	<aliguori>	resumes always fun to debug :-)
21:38	\|-\|	JViz [Anomaly@adsl-065-013-131-023.sip.int.bellsouth.net] has joined #xen
21:38	<johnlev>	HYPERVISOR_console_io is a lifesaver
21:40	<aliguori>	indeed :-)
21:57	<Cyis>	curious where all the .15 patches are
21:57	<Bicster>	I grabbed 2.6.15 from mercurial
21:57	<Bicster>	changeset 19797
21:58	<Cyis>	that's not in xen-unstable.hg or xen-3.0-testing.hg
21:58	<Cyis>	those change sets are only around 87xx
21:58	<Bicster>	no, it's in linux-2.6-xen.hg
21:59	<Bicster>	and if you're running x86_64, it isn't stable
21:59	<Bicster>	knock wood, x86 seems to be working ok for me here
22:01	<Cyis>	I guess I just assume if it's not in xen-unstable.hg or xen-3.0-testing.hg it isn't stable and not something I'm gonna worry about
22:01	\|-\|	mOdY [m0dY@62.139.160.212] has joined #xen
22:01	<Bicster>	I meant unstable as in won't boot at all in SMP
22:02	<Bicster>	might boot without SMP
22:03	<Cyis>	I don't have any SMP-based x86_64 systems so I guess that wouldn't bother me
22:03	\|-\|	_David_ [~david@202.148.226.15] has left #xen [Kopete 0.9.2 : http://kopete.kde.org]
22:07	\|-\|	jm_c [jm@d83-179-132-207.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
22:09	<Cyis>	is the linux-2.6-xen.hg the full kernel source or just the sparse tree?
22:10	<Bicster>	full source, I'm not aware of a sparse tree or patch for that kernel
22:18	\|-\|	jm_c [jm@d83-179-128-63.cust.tele2.fr] has joined #xen
22:18	<Cyis>	needs to be an easier way to manage the changes until it gets in the mainstream kernel...
22:27	\|-\|	Guest1814 [~dhendrix@c-69-247-65-201.hsd1.nm.comcast.net] has quit [Quit: Leaving]
22:44	\|-\|	jerone [~jerone@adsl-71-145-175-218.dsl.austtx.sbcglobal.net] has joined #xen
22:55	\|-\|	Basic_py [~Basic@warden.real-time.com] has joined #xen
22:55	\|-\|	aliguori [~anthony@cpe-70-116-13-229.austin.res.rr.com] has quit [Read error: Connection reset by peer]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has left #xen [Rotating Logs]
22:59	\|-\|	VS_ChanLog [~stats@ns.theshore.net] has joined #xen
23:07	\|-\|	jm_c [jm@d83-179-128-63.cust.tele2.fr] has quit [Ping timeout: 480 seconds]
23:18	\|-\|	jm_c [jm@d83-179-137-87.cust.tele2.fr] has joined #xen
23:22	\|-\|	jm_c [jm@d83-179-137-87.cust.tele2.fr] has quit [Quit: ]
---	Log	closed Thu Feb 02 00:00:21 2006