--- Day changed

--- Log opened Fri Mar 18 23:59:04 2005
00:13 -!- ijuz_ [~ijuz@p54ABF9DF.dip.t-dialin.net] has joined #xen
00:20 -!- ijuz [~ijuz@p54ABFE48.dip.t-dialin.net] has quit [Ping timeout: 480 seconds]
00:30 -!- mikelcu [~o_o@c-24-21-186-135.client.comcast.net] has joined #xen
00:30 < mikelcu> dang so #xen on freenode really closed down...
01:08 < schweeb> there was a #xen on freenode?
04:14 < mikelcu> yeah for a while at least
04:32 -!- visik7 [~ciao@host155-36.pool80182.interbusiness.it] has joined #xen
04:44 -!- deac [~deac@xdsl-195-14-217-119.netcologne.de] has joined #xen
05:20 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has joined #xen
05:20 < enum> yo...
05:21 < enum> does dom0 kernel be compiled for x86_64?
05:21 < ijuz_> enum: not yet, afaik
05:22 < visik7> current xen-stable doesn't support amd64
05:22 < enum> so Im trying to figure out how it runs in 32-bit mode.. 
05:22 < enum> if I cannot cimpile my kernel for x86_64
05:23 < enum> or do I just have to setup a x86 OS on my amd64
05:23 < visik7> what's the problem ?
05:23 < visik7> yes u need to do that
05:23 < enum> suck
05:23 < visik7> only IA64 and x86 are supported
05:23 < visik7> amd64 porting is in progress
05:23 < visik7> afaik
05:23 < enum> k..thanks
07:27 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has quit [Ping timeout: 480 seconds]
10:50 -!- atari [~atari@213.144.146.89] has quit [Ping timeout: 480 seconds]
11:29 -!- ijuz_ [~ijuz@p54ABF9DF.dip.t-dialin.net] has quit [Quit: (hardware...)]
11:42 -!- ijuz_ [~ijuz@p54ABBDF3.dip.t-dialin.net] has joined #xen
12:15 -!- ShawnWork [~c0db680a@CPEdeadbeef0000-CM000039d4cc6a.cpe.net.cable.rogers.com] has quit [Quit: CGI:IRC (Ping timeout)]
12:44 < cw> ia64 is barely supported actually
12:45 < Beirdo> Ahhhh
12:45 < Beirdo> that explains it
12:45 < Beirdo> I guess I'll have to wait to use xen then
12:45 < schweeb> Beirdo: ia64 is intel's spec
12:45 < Beirdo> I know that
12:46 < Beirdo> <visik7> only IA64 and x86 are supported
12:46 < Beirdo> <visik7> amd64 porting is in progress
12:46 < mikegrb>  silly schweeb 
12:46 < Beirdo> at 5:23am
12:46 < schweeb> oh yea... that one time when I was _sleeping_
12:46 < cw> Beirdo: there is an ia64 port in the tree
12:46 < cw> so he is right
12:46 < Beirdo> I have AMD64
12:46 < cw> it's just it's not complete
12:47 < cw> i dont think he claimed otherwise
12:47 < Beirdo> schweeb: scrollback is sweet
12:47 < schweeb> Beirdo: did you download any of the other tarballs?
12:47 < Beirdo> not yet, I just got up
12:48 < cw> Beirdo: you could build 32-bit and use 32-bit kernels for now
12:48 < schweeb> if you do, type 'make -C xen' in the root directory of the tarball... that'll compile only the hypervisor
12:49 < Beirdo> cw: I'll wait, I'm not going to cripple the system just to use xen
12:49 < schweeb> do you have any 32bit userspace, Beirdo? or is it all 64?  I've not used a 64bit arch yet
12:49 < Beirdo> I think it's 64bit, dunno
12:50 < cw> Beirdo: fair enough, i wouldn't either :)
12:50 < cw> Beirdo: but to be fair unless you have lots of ram most people won't notice much difference
12:50 < Beirdo> yeah, I'd notice the difference :)
12:51 < Beirdo> especially as I wanna run 64-bit userland in some of the domains
12:52 < cw> you have to wait for that then sorry
13:54 < ijuz_> stupid question... on my laptop i have to use the nvidia driver... does it work with xen?
13:58 < cw> i doubt it
13:58 < cw> it might work with some hacking, but i wouldn't count on it
13:59 < cw> ijuz_: why to you *have* to use the nvidia driver? what doesn't work with the nv driver?
13:59 < ijuz_> because i have flickering lines with the nv driver
13:59 < ijuz_> (with all version of XFree86 and X.org)
14:00 < cw> hmm... what chips is that?
14:00 < cw> and have you tried frobbing the mode-lines to match whatever the nvidia driver uses?
14:00 < ijuz_> geforce 2go
14:01 < cw> odd, i would assume that is old enough to have most quirks ironed out
14:01 < ijuz_> it's only a few pixels i don't think it's the modline
14:01 < ijuz_> probably the 1600x1200 displays aren't sooo common with this chip
14:02 < cw> i would probably check the modlines using xvidtune and see if they are close to each other
14:02 < ijuz_> ok, i'll try
14:02 < cw> if not, manually use what the nvida driver uses with nv
14:02 < cw> if that doesn't work, i have no idea :)
14:03 < cw> ijuz_: ok, the nv binary blob doesn't have any cli/sti which i was worried about... so maybe it could be make to work
14:06 < ijuz_> first i have to figure how to get anything working :)   i just thought how i could use xen for demonstrating networkign stuff without carrying around a stack of boxes
14:06 < schweeb> 1600x1200 displays are perfectly common
14:07 < schweeb> the Dell Inspiron series had the GF2Go
14:07 < schweeb> and prolly 1/4 of the Inspirons that shipped with that chip had 1600x1200
14:07 < ijuz_> exactly, it's a latitude (the same like a inspiron 8100), but there are not millions of these
14:09 < schweeb> if I were you, I'd look into BIOS updates... a lot of the display problems I used to have with my 8200 were fixed with BIOS upgrades
14:18 < ijuz_> i think it's still the newest, not so important, i can use an older laptop for xen
15:55 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has joined #xen
16:36 < mikelcu> does anyone have trouble mounting hard disks other than the one that dom0 resides on, after boot?
16:37 < mikelcu> i.e. I boot off hda and neither hdb nor hdc will not mount after I boot
16:37 < mikelcu> with error busy or already mounted, neither of which is true
16:40 < mikelcu> er ignore that double negative, typo
16:41 < Sir_Ahzz> ?
16:41 < Sir_Ahzz> that's odd.
16:42 < mikelcu> yeah I thought so too
16:42 < mikelcu> the partitions in queation are known good too
16:42 < Sir_Ahzz> which xen you using?
16:42 < mikelcu> 2.0.5 now, 2.0.3 before, but it seems to behave the same
16:43 < Sir_Ahzz> huh
16:43 < Sir_Ahzz> what mainboard and chipset?
16:43 < mikelcu> tyan tiger MP
16:43 < mikelcu> amd 760 I think
16:43 < Sir_Ahzz> *nod*
16:43 < Sir_Ahzz> I assume it works fine with the same linxu source code compled as i386?
16:44 < mikelcu> which source, the kernel?
16:44 < mikelcu> or xen
16:44 < Sir_Ahzz> things to test: any old linux kernel, kernel compiled from xen-patched kernel compiled as i386 (standard target)
16:44 < Sir_Ahzz> eg skip the ARCH=xen part when compiling your dom0 kernel.
16:45 < Sir_Ahzz> we want to make certain that it is indeed xen itself that's messing things up 
16:45 < mikelcu> sure
16:45 < Sir_Ahzz> by using the same source tree that you used to compile xenlinux for dom0 we can determine if it's related to the xen parts.
16:45 < mikelcu> ah yeah I did set it to athlon/k7
16:45 < Sir_Ahzz> preferably use the package script and config that's standard for your distro.
16:46 < mikelcu> there isn't one ;)
16:46 < Sir_Ahzz> also, try uxing cpu=686 for your xenlinux. UP.
16:46 < Sir_Ahzz> what distro are you running?
16:46 < Sir_Ahzz> second, make certain that devfs is NOT compiled in, or is deactivated on boot.
16:46 < mikelcu> gentoo
16:46 < mikelcu> no it isn't
16:47 < Sir_Ahzz> scan the list archives for messages relatign to gentoo. I remember hearing something similar to this on gentoo.
16:47 < mikelcu> hm really I didn't see anything
16:47 < mikelcu> I'll look again
16:47 < mikelcu> first I'm gonna reboot built for i386 though
16:47 < Sir_Ahzz> *nod* 
16:47 < mikelcu> way way back when I had many problems with Athlon/K7
16:47 < Sir_Ahzz> heh
16:48 < mikelcu> but it seemed to have cleared up somewhere along the way and I've been using it lately
16:48 < Sir_Ahzz> *nod* understand.
16:48 < Sir_Ahzz> I'd want my cpu features as well. :)
16:48 < mikelcu> never bothered to look into it, there wasn't enough real benefit to care about being that specific
16:48 < mikelcu> yeah they're nice but it's not that visible of a difference
16:49 < mikelcu> it's not a high-performance box or anything ;)
16:49 < mikelcu> something is definitely fishy though, my kernel builds are segfaulting
16:49 < mikelcu> that smells a bit like hardware
16:49 < Sir_Ahzz> are you using poartage to compile your xenlinux kernel, or are you doing it by hand?
16:49 < Sir_Ahzz> umm.
16:49 < mikelcu> manual
16:50 < Sir_Ahzz> if builds are segfaulting, then you have either a bad kernel or bad system. 8-P
16:50 < mikelcu> yeh
16:50 < Sir_Ahzz> get your system stable on a standard linux kernel, then move forward on xen.
16:50 < mikelcu> fs/file_table.c: In function `get_empty_filp': fs/file_table.c:103: internal compiler error: Segmentation fault
16:50 < mikelcu> The bug is not reproducible, so it is likely a hardware or OS problem
16:50 < mikelcu> whee 
16:50 < Sir_Ahzz> that's a memory corruption.
16:50 < mikelcu> just what I was thinking
16:51 < mikelcu> damnit
16:51 < Sir_Ahzz> build a UP k7 kernel and see if you can get rid of that error first.
16:51 < Sir_Ahzz> preferably install a pre-built kernel for k7, try a compile to see if you get rid of the errors.
16:51 < mikelcu> yeah I'm booting back to an old one
16:52 < Sir_Ahzz> brb
17:00 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has quit [Ping timeout: 480 seconds]
17:07 < mikelcu> hm ok interesting news
17:08 < Sir_Ahzz> ?
17:08 < mikelcu> ran a short memtest86, everything tested ok
17:08 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has joined #xen
17:09 < mikelcu> no segfaults compiling while running on older, non-xen kernel
17:09 < mikelcu> and mounting other drives works
17:10 < mikelcu> doh I take it back
17:10 < mikelcu> got a segfault during a rebuild
17:11 < mikelcu> so ignore that, it is something else, but the mounting issue seems to be related to xen in some way
17:12 < Sir_Ahzz> ouch.
17:12 < Sir_Ahzz> could be a memory corruption nly.
17:12 < Sir_Ahzz> tat's oddlyenough triggered in xen due to location of structures.
17:12 < mikelcu> hmmmm
17:13 < mikelcu> I'll start pulling DIMMs in a sec
17:14 < Sir_Ahzz> *nod*
17:14 < mikelcu> this has not been a good hardware month for me
17:16 < Sir_Ahzz> heh
17:18 < cw> mikelcu: what compiler is saying that? what does gcc -v say?
17:18 < Sir_Ahzz> he's showing the classical "marginal ram" issues.
17:18 < cw> oh, it's random? well, fix the hardware first then
17:18 < Sir_Ahzz> SMP machines tend to be more sensitive to ram than others in my experience.
17:18 < cw> nothing much you can do about that
17:19 < mikelcu> it's 3.4.3
17:19 < cw> SMP athlons are fine, i have one here
17:19 < Sir_Ahzz> that's what he's doing right now. :) isolating the bad ram (if it's ram and not mainboard)
17:19 < cw> heh, sorry, just got back and was too lazy to read the backscroll
17:19 < Sir_Ahzz> had an old dual ppro that was VERY sensitive to ram.
17:19 < mikelcu> this machine has been running stable for a really long time, and had some recent hardware replacements, I wouldn't be terribly surprised if a DIMM is going
17:19 < Sir_Ahzz> no biggie. :)
17:20 < cw> mikelcu: you tried memtest86 right?
17:20 < mikelcu> yeah
17:20 < cw> and it passes ok?
17:20 < mikelcu> well, memtest86+
17:20 < mikelcu> yeah but I didn't let it run all the way, I just let it do the first 10 tests or so
17:20 < mikelcu> that usually finds any big problems
17:21 < cw> gcc is a good memory tester, it would be a great Ph.D thesis for someone
17:21 < mikelcu> hm, only 1 segfault building while on the non-xen kernel
17:21 < mikelcu> compared to many many more while running xen
17:21 < cw> well, not all corruption will segfault
17:21 < Sir_Ahzz> what kenerl were you running when you segfaulted?
17:21 < mikelcu> sure
17:21 < mikelcu> 2.6.10
17:21 < mikelcu> this one is 2.6.9
17:21 < Sir_Ahzz> UP 686 or MP k7?
17:22  * cw always uses ECC memory for a reason
17:22 < mikelcu> lemme look I don't even remember
17:22 < mikelcu> heh this is ECC
17:22 < Sir_Ahzz> then you should be getting a memory parity error via kprintf
17:22 < cw> nah, linux has no ECC handlers in most cases
17:22 < mikelcu> it's a K7
17:22 < cw> you really need a separate ECC driver and gunk that's not in mainline
17:23 < Sir_Ahzz> I though the cpu generated a NMI on ec errors via firmware.
17:23 < cw> for k8/ia64 though you might get an machine check which will print something, but not usually anything for k7/p4 stuff
17:23 < cw> Sir_Ahzz: depends on the chipset how it's dealt with
17:23 < Sir_Ahzz> true
17:24 < Sir_Ahzz> I've allways gotten some kind of interupt on memory parity error.
17:24 < cw> usually a bios setting, but not 100% reliable
17:24 < Sir_Ahzz> this is true
17:24 < cw> a large company i know uses ecc memory and has their own ecc gunk to track proboems
17:24 < cw> but thay have 10s of thousands of machines so they see them all the time
17:25  * cw is actually after some marginal PC2100 DIMMS for testing
17:26 < mikelcu> hehe I might have a couple here :P
17:26 < cw> yeah, but they have a lifetime warranty so you can get new ones for free chances are
17:26 < mikelcu> if the non-K7 doesn't help I'm going to let memtest run for a few hours
17:26 < cw> non-k7 doesn't mean it's ok ... it just means it's not stressing the ram as hard probably and makes it harder to break
17:26 < mikelcu> if I can remember who I bought them from
17:26 < mikelcu> this box is like 4 years old
17:27 < cw> dump the spds
17:27 < cw> that should tell you
17:34 < mikelcu> whee instant segfault
17:34 < mikelcu> ooh and a hard lock
17:34 < mikelcu> this has to be hardware
17:34 -!- deac [~deac@xdsl-195-14-217-119.netcologne.de] has quit [Ping timeout: 480 seconds]
17:36 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has quit [Ping timeout: 480 seconds]
17:38 < mikelcu> well all the segfaulting is fun, but does anyone think that is related to the inability to mount other drives when booted into xen?
17:38 < Sir_Ahzz> The Magic 8Ball(tm) says..... "Probably..."
17:38 < Sir_Ahzz> with bad hardware ANYTHING is possible. :)
17:38 < mikelcu> heh true that
17:38 < cw> mikelcu: actually, i dont see why it necessarily would
17:39 < cw> mikelcu: what happens when you try and mount other drives?
17:39 < mikelcu> the mount thing is really consistent though, and the segfaulting is random-ish
17:39 < mikelcu> device busy or already mounted...
17:40 < Sir_Ahzz> cw, i've had funky IDE errors like that with bad ram before.
17:40 < Sir_Ahzz> maintain a couple dozen machines and you see just about everything possible. ;)
17:42 < mikelcu> it's just the consistent nature that makes me think it's something different
17:42 < mikelcu> to get a segfault I have to be _doing_ something, but for the mount doesn't work regardless of whether or not the system is busy at all
17:43 < mikelcu> well that and the mount works fine from a non-xen kernel
17:43 < Sir_Ahzz> it's common for ram to not generate errors unless you push the memory usage to extremes in bandwidth to/from the cpu.
17:43 < Sir_Ahzz> isolate your segfaults first.
17:45 < mikelcu> I've got memtest running again
17:45 < Sir_Ahzz> *nod*
17:45 < mikelcu> I just noticed something actually
17:45 < Sir_Ahzz> if thereis a hardware issue, then it'll find it.
17:45 < mikelcu> my procs are hot
17:45 < Sir_Ahzz> LOL
17:45 < Sir_Ahzz> > 75c?
17:46 < mikelcu> just barely but yes
17:46 < mikelcu> 76 and 77 respectively
17:46 < mikelcu> wonder is my heatsinks are gunked up
17:46 < mikelcu> s/is/if/
17:46 < Sir_Ahzz> ouch
17:46 < Sir_Ahzz> that's too hot
17:46 < cw> Sir_Ahzz: i use ECC everywhere, it makes a huge difference
17:46 < mikelcu> cw: yeah it does
17:47 < Sir_Ahzz> anything over 70c and ALL of my athlon tbird and XPs start segfaulting. 8-P
17:47 < cw> Sir_Ahzz: memory errors are a pain, undetected memory errors are agony
17:47 < Sir_Ahzz> he's having heat issues.
17:47 -!- deac [~deac@xdsl-195-14-216-202.netcologne.de] has joined #xen
17:47 < Sir_Ahzz> athlons really don't like > 70c temps. 8-P
17:47 < mikelcu> yeah these are way hotter than normal
17:47 < mikelcu> dammit I'm out of canned air
17:47 < Sir_Ahzz> their timings get skewedjust enough to make wonky things happen. :)
17:48 < ijuz_> uhm, about no processor likes >70C :)
17:49 < mikelcu> I bet memtest won't find anything
17:49 < mikelcu> because it's not the RAM
17:49 < Sir_Ahzz> *nod*
17:49 < Sir_Ahzz> probably overheatedcpus generating errors. :)
17:49 < cw> mikelcu: might not, if it's CPUs though you can test one at a time
17:49 < mikelcu> they got hotter during compilation which is why I only saw the segfault then
17:49 < mikelcu> yeh
17:49 < ijuz_> why don't you cool them better?
17:50 < mikelcu> they've never been this hot before
17:50 < Sir_Ahzz> probably heatsinks/fans plugged with gunk.
17:50 < Sir_Ahzz> I clean my cases every 3 months.
17:50 < mikelcu> yeah I have pets :P
17:51 < Sir_Ahzz> that will do it. *grin*
17:51 < mikelcu> I'll just let memtest do a full run then pull it all apart and clean it
17:51 < Sir_Ahzz> just make yourself a mental note to clean em out thoroughly every 3 months.
17:51 < Sir_Ahzz> or get a case that is sealed w/ externally removeable intake filters.
17:51 < Sir_Ahzz> memtest won't heat the cpu like a compile will.
17:51 < Sir_Ahzz> 8-P
17:51 < cw> mikelcu: this is a dual athlon right?
17:52 < mikelcu> no but I need to eliminate the RAM as a problem if I can
17:52 < mikelcu> cw: yes
17:52 < cw> mikelcu: do you see the occasional MCE?
17:52 < Sir_Ahzz> mike, eliminate the heat issue first.
17:52 < Sir_Ahzz> it's a known hardware problem.
17:52 < Sir_Ahzz> memory is an unknown.
17:52 < mikelcu> cw: no, nothing
17:52 < Sir_Ahzz> always tackle the knowns first. from harware viewpoint.
17:52 < mikelcu> I haven't had a single issue with this box till really recently
17:53 < cw> mikelcu: sometimes things just go bad, it happens
17:53 < Sir_Ahzz> 4 years is about the poit things start breaking for me. :)
17:53 < mikelcu> yep
17:53 < mikelcu> yeah I'm not complaining, it's been working like a champ for along time
17:53 < Sir_Ahzz> stop memtest grab a vaccumme and start cleaning. :)
17:53 < Sir_Ahzz> just beware ESD
17:54 < mikelcu> naw I gotta take the sinks off
17:54 < Sir_Ahzz> you can usually unscrew the fans from the sinks.
17:54 < mikelcu> vacuum doesn't get inside the blades well enough
17:54 < Sir_Ahzz> that's better sinc eyou can untrap the crud.
17:54 < Sir_Ahzz> neverremove a sink if you can avoid it. it's a pain getting the air bubbles out of old thermal grease. 8-P
17:54 < mikelcu> tell me about it
17:55  * Sir_Ahzz offers up17 years of PC repair experience. :)
17:55 < mikelcu> lst time I cleaned them I did a full disassemble and wipedown
17:55 < mikelcu> last*
17:55 < mikelcu> s'why I didn't think of heat because that was relatively recent 
17:56 < mikelcu> ok I'm gonna go tear down a wall
17:56 < mikelcu> I'll revisit this if the mount issue continues after the heat and memory have been addresses
17:57 < mikelcu> cnat tpye tdoay
17:57 < mikelcu> thanks for the input guys
17:57 < Sir_Ahzz> *nod8 np
17:57 < Sir_Ahzz> just pass on the help to others.
17:58 < mikelcu> yup
17:58 < mikelcu> bbl
18:36 -!- Fidget001 [~rpage@adsl-214-114-38.gnv.bellsouth.net] has joined #xen
18:39 -!- Fidget001 [~rpage@adsl-214-114-38.gnv.bellsouth.net] has quit [Remote host closed the connection]
19:05 < ijuz_> i'm running xen and the odd thing that happens is that X (started normally by kdm) doesn't start allways, mostly i was able to start it manually, now i tried to start it manually while i was compiling a kernel and got a reboot
19:06 < Sir_Ahzz> read thread on agp gart on the mailing list.
19:15 < ijuz_> so i should just not build/load agpgart?
19:15 < Sir_Ahzz> I would go read the list. I havne't attempted to run any X11 stuff on xen myself.
19:15 < ijuz_> i read the mails
19:16 < ijuz_> ok
20:02 -!- sunny [sunny@opencurve.org] has quit [Quit: Lost terminal]
20:02 -!- sunny [sunny@opencurve.org] has joined #xen
22:29 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has joined #xen
23:01 -!- enum [~enum@cpe-24-175-6-236.houston.res.rr.com] has quit [Ping timeout: 480 seconds]
--- Log closed Sat Mar 19 23:59:01 2005