Back to Home / #uml / 2007 / 11 / Prev Day | Next Day
#uml IRC Logs for 2007-11-01

---Logopened Thu Nov 01 00:00:56 2007
02:02|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
02:19|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has joined #uml
02:54|-|rjbell4 [~bbell@c-75-67-251-249.hsd1.nh.comcast.net] has quit [Read error: Operation timed out]
02:54|-|rjbell4 [bbell@c-75-67-251-249.hsd1.nh.comcast.net] has joined #uml
03:59|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
04:51|-|camgirl29 [~camgirl29@ANantes-257-1-94-46.w90-25.abo.wanadoo.fr] has joined #uml
04:53|-|camgirl29 [~camgirl29@ANantes-257-1-94-46.w90-25.abo.wanadoo.fr] has quit []
05:21|-|da-x [~karrde@xiv-glob.ser.netvision.net.il] has joined #uml
06:43|-|Magotari [~karol@adps180.neoplus.adsl.tpnet.pl] has quit [Read error: Connection reset by peer]
06:44|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection]
06:47|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has joined #uml
06:54|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has quit [Read error: Connection reset by peer]
06:56|-|Baltam [~WIKIMOKI@tor-irc.dnsbl.oftc.net] has joined #uml
07:08|-|tyler29 [~tyler@ARennes-257-1-144-77.w86-210.abo.wanadoo.fr] has joined #uml
07:19|-|SNy [882b54dd25@bmx-chemnitz.de] has quit [Remote host closed the connection]
07:24|-|karol [~karol@abhz69.neoplus.adsl.tpnet.pl] has joined #uml
07:24|-|karol changed nick to Magotari
07:25<Magotari-#uml->>Cursed be the person who invented wireless internet, because it just simply sucks under Linux. Thank you, closed vendors, I hope your stocks fall down to nothing and your companies go bankrupt.
07:34|-|Magotari [~karol@abhz69.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds]
08:50|-|tyler29 [~tyler@ARennes-257-1-144-77.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
09:02|-|tyler29 [~tyler@ARennes-257-1-176-199.w86-214.abo.wanadoo.fr] has joined #uml
09:07|-|dang [~dang@aa-redwall.nexthop.com] has joined #uml
09:51|-|Magotari [~karol@abic200.neoplus.adsl.tpnet.pl] has joined #uml
10:15|-|Magotari [~karol@abic200.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds]
10:35|-|Tuxbubling [~tuxbublin@sat78-6-88-160-130-34.fbx.proxad.net] has joined #uml
10:35<Tuxbubling-#uml->>hello there
10:35|-|dsoul [darksoul@vice.ii.uj.edu.pl] has quit [Ping timeout: 480 seconds]
10:35<Tuxbubling-#uml->>what's the best way doing network with uml? I tried the bridge way, but i'm really disapointed with performances
10:47|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has joined #uml
10:54|-|Magotari [~karol@abhr207.neoplus.adsl.tpnet.pl] has joined #uml
10:54<Magotari-#uml->>Tuxbubling: I read the channel logs. Is the performance problem bandwidth or latency?
10:54<Tuxbubling-#uml->>bandwidth
10:55<Tuxbubling-#uml->>latency is a bit high but not that much
10:55<Magotari-#uml->>Wow. That is unexpected. I thought it would be the other way around.
10:55<Tuxbubling-#uml->>bandwidth is like crap :(
10:55<Magotari-#uml->>Hmm... I used to get 200 kilobytes per second without a major problem. I never tested it more, my ISP topped out first.
10:56<Tuxbubling-#uml->>ouch
10:56<Tuxbubling-#uml->>200kb is slow for me
10:56<Tuxbubling-#uml->>btw i don't even have them for sure
10:56<Tuxbubling-#uml->>let me scp somethin
10:56<Magotari-#uml->>I don't think there are any faster methods than tuntap and/or bridging. Try just tuntap, maybe... No idea.
10:56<Magotari-#uml->>Bridging should just work fine.
10:57<Tuxbubling-#uml->>64 bytes from 10.50.50.150: icmp_seq=1 ttl=64 time=0.320 ms actually latency is a bit crap too :|
10:57<Tuxbubling-#uml->>do you have a page on tuntap correct method??
10:57<Magotari-#uml->>Usually the first one or two pings suck.
10:58<Magotari-#uml->>Then it gets a tad better.
10:58<Magotari-#uml->>Let me see...
10:59<Tuxbubling-#uml->>if 311ms is better... then yes it's better :p
10:59<Magotari-#uml->>http://user-mode-linux.sourceforge.net/network.html
11:00<Tuxbubling-#uml->>maybe got a problem with my routes...
11:00<Tuxbubling-#uml->>let me check that
11:02<Tuxbubling-#uml->>even ssh/scp takes ages to connect :(
11:04<Magotari-#uml->>Networking is my bane, so I am not too useful, sadly.
11:05<Tuxbubling-#uml->>on the link you gave me
11:05<Tuxbubling-#uml->>what's 192.168.0.254 ??
11:05<Tuxbubling-#uml->>a tap0 device?
11:06<Magotari-#uml->>That is an ip which you can access with the host.
11:07<Tuxbubling-#uml->>oh
11:07<Magotari-#uml->>Use an unused IP there.
11:07<Tuxbubling-#uml->>whitout configuring anything on host?
11:08<Magotari-#uml->>The host side of things will be taken care of by uml.
11:08<Magotari-#uml->>You only need to work in the guest.
11:08<Magotari-#uml->>When you do "ifconfig blah blah blah", your host will adjust to it.
11:09<Magotari-#uml->>This is not horribly secure, but it works. If you want to do it securely, you need to use a preconfigured device.
11:09<Tuxbubling-#uml->>[root@localhost ~]# ifconfig eth0 10.50.50.150 netmask 255.255.255.0
11:09<Tuxbubling-#uml->>[42949395.280000] z�HSIOCSIFFLAGS: Operation not permitted
11:09<Magotari-#uml->>:/
11:09<Magotari-#uml->>Anyone more experienced here?
11:09<Magotari-#uml->>Because I suck at this horribly.
11:14<Tuxbubling-#uml->>i don't get it :/
11:15<Magotari-#uml->>Neither do I.
11:17<caker-#uml->>host:/dev/net/tun permissions correct?
11:17<caker-#uml->>must be r/w of the user UML is running under
11:17<Tuxbubling-#uml->>yes correct
11:17<caker-#uml->>(sorry, haven't read entire scrollback, just taking a stab)
11:18|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has joined #uml
11:18<Tuxbubling-#uml->>i made both /dev/net/tun and chroot//dev/net/tun chmoded 666
11:18<Tuxbubling-#uml->>then mount-binded first into second
11:30<Tuxbubling-#uml->>any ideas?
11:36<peterz-#uml->>Magotari: the thing that really gets me is not wireless interwebs, but the fact that we need to be connected to even use our desktops. The GNOME people are on utter crack with their online-desktop crap
11:36<Tuxbubling-#uml->>gnome s***
11:36<Tuxbubling-#uml->>:p
11:37<peterz-#uml->>(of course I have long since stopped using gnome)
11:37<peterz-#uml->>but the idea seems to be spreading that online-desktops are a good idea
11:37<Magotari-#uml->>I hate gnome. Ratpoison does the trick for me.
11:38<peterz-#uml->>yeah, little too restrictive for my taste, but I hear you
11:38<Magotari-#uml->>It helps focus. :)
11:38<Magotari-#uml->>Xfce4 is good too for me, but really...
11:38<Magotari-#uml->>Recently fluxbox has been getting my attention.
11:40<Magotari-#uml->>To go back on topic a bit, try ratpoison + few Xnests connected to virtual machines.
11:41<Magotari-#uml->>A great way to switch between the desktops on the vms.
11:50|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
11:50<rjbell4-#uml->>jdike: Sure, let me know what I can do to help reproduce the gdb issue, or to help debug it on my end.
11:50<jdike-#uml->>Hi guys
11:50<jdike-#uml->>rjbell4, actually it's already fixed, I think
11:51<jdike-#uml->>just in rc1, not in .23
11:57<rjbell4-#uml->>jdike: Ok, I'll check out .24-rc1
11:59<jdike-#uml->>I'm going to send them to -stable so they will appear in 2.6.23.2 or something
12:02<jdike-#uml->>that's why I swore I fixed it already - I just lost track of when it went to mainline
12:05|-|ram [~ram@pool-72-90-125-50.ptldor.fios.verizon.net] has quit [Ping timeout: 480 seconds]
12:16<jdike-#uml->>hmm
12:16<jdike-#uml->>I was manipulating git wrongly
12:17<rjbell4-#uml->>jdike: arch/um/drivers/ubd_kern.c should include linux/scatterlist.h (or similar) to pick up sg_page()
12:17<jdike-#uml->>there's a fix for that too, Linus just hasn't picked it up
12:17<rjbell4-#uml->>ok
12:18<rjbell4-#uml->>jdike: How about this one?
12:18<rjbell4-#uml->>arch/um/sys-x86_64/../sys-i386/ldt.c: In function âwrite_ldtâ:
12:18<rjbell4-#uml->>arch/um/sys-x86_64/../sys-i386/ldt.c:278: error: âstruct user_descâ has no member named âlmâ
12:18<rjbell4-#uml->>Just got it, haven't look at it yet.
12:18<jdike-#uml->>dunno about that
12:20<rjbell4-#uml->>Found a reference here: http://l4x.org/k/?d=35650
12:21<Magotari-#uml->>Those random umids are driving me crazy. I swear, one damn day I will make them predictable. Maybe a hash function of the commandline and/or path? Agrh.
12:22<Magotari-#uml->>Or simple 1 2 3 4...
12:22<jdike-#uml->> if (ldt_info.base_addr == 0 && ldt_info.limit == 0 &&
12:22<jdike-#uml->> (func == 1 || LDT_empty(&ldt_info))) {
12:22<jdike-#uml->>that's line 277-278, and I see no .lm there
12:30<rjbell4-#uml->>jdike: I'm guessing it's in LDT_empty()
12:30<jdike-#uml->>me too, but there's no .lm there either
12:31<rjbell4-#uml->>hmmm
12:32<rjbell4-#uml->>jdike: After it get's through the pre-processor, it's:
12:32<rjbell4-#uml->>if (ldt_info.base_addr == 0 && ldt_info.limit == 0 && (func == 1 || ( (&ldt_info)->base_addr == 0 && (&ldt_info)->limit == 0 && (&ldt_info)->contents == 0 && (&ldt_info)->read_exec_only == 1 && (&ldt_info)->seg_32bit == 0 && (&ldt_info)->limit_in_pages == 0 && (&ldt_info)->seg_not_present == 1 && (&ldt_info)->useable == 0 && (&ldt_info)->lm == 0))) {
12:32<jdike-#uml->>useable?
12:32<jdike-#uml->>no
12:33<jdike-#uml->>there's a LDT_empty in arch/um/include/desc.h, but it looks like you're getting a different one
12:34|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
12:35<rjbell4-#uml->>jdike: I think I have ./include/asm-um/host_ldt-x86_64.h, symlinked from ./include/asm-um/host_ldt.h
12:38<jdike-#uml->>I suppose we can just get rid of the lm part
12:39<jdike-#uml->>it's commented out of LDT_entry_b
12:40<rjbell4-#uml->>./include/asm-x86/desc_32.h and ./include/asm-x86/desc_64.h have different LDT_empty() implementations. include/asm-um/desc.h uses the desc_32.h one, but ldt.c pulls in one from include/asm-um/host_ldt-x86_64.h, which matches desc_64.h
12:40<jdike-#uml->>yeah
12:58|-|tyler29 [~tyler@ARennes-257-1-176-199.w86-214.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
13:00|-|kos_tom [~thomas@humanoidz.org] has joined #uml
13:04<peterz-#uml->>jdike: where does this hostfs thing live?
13:04<jdike-#uml->>fs/hostfs?
13:04<peterz-#uml->>bah
13:04<peterz-#uml->>I was looking under arch/um
13:04<jdike-#uml->>hehe
13:16|-|tyler29 [~tyler@ARennes-257-1-125-252.w86-210.abo.wanadoo.fr] has joined #uml
13:35[~]jdike #uml prepares patches for -stable#uml-> prepares patches for -stable
13:35|-|kos_tom [~thomas@humanoidz.org] has quit [Remote host closed the connection]
14:14|-|dsoul [darksoul@vice.ii.uj.edu.pl] has joined #uml
14:16<jdike-#uml->>I think the FP fixes are too risky for -stable
14:25|-|dsoul [darksoul@vice.ii.uj.edu.pl] has quit [Ping timeout: 480 seconds]
14:26|-|dsoul [darksoul@vice.ii.uj.edu.pl] has joined #uml
14:30<ds2-#uml->>has anyone considered or is working on getting tunneling in USB support from the host like in vmware?
14:30<ds2-#uml->>considering
14:31<jdike-#uml->>that's been considered
14:31<jdike-#uml->>no one has actually done it
14:31<ds2-#uml->>hmm
14:32<ds2-#uml->>wonder if the vhcd would work as a starting point..hmmm
14:33<ds2-#uml->>jdike: was it from people here or just a random posting on the list?
14:33<jdike-#uml->>on uml-devel probably, long ago
14:35<ds2-#uml->>oh
14:51<Tuxbubling-#uml->>jdike: got a slow network - bad latency and crappy bandwidth - in bridge mode, any idea ??
14:53<jdike-#uml->>traffic from the host is OK?
14:53<Tuxbubling-#uml->>yes
14:54<Tuxbubling-#uml->>host > guest = crap
14:54<Tuxbubling-#uml->>guest > internet = crap
14:54<jdike-#uml->>host -> guest is easier to debug
14:56<ds2-#uml->>how are you measuring this?
14:56<Tuxbubling-#uml->>well just trying to connect to the guest trough ssh and it takes so long
14:57<Tuxbubling-#uml->>trying to reach internet from the guest
14:57|-|dsoul [darksoul@vice.ii.uj.edu.pl] has quit [Ping timeout: 480 seconds]
14:57<Tuxbubling-#uml->>ping is quite ok, but takes tooo long to get anything
14:57<Tuxbubling-#uml->>downloading files from yum is crap ...
14:58<ds2-#uml->>any packet loss?
14:58<Tuxbubling-#uml->>my bridge is mounted on a second interface specially dedicated for that
14:58<Tuxbubling-#uml->>ds2: no but 300ms response time
14:58<jdike-#uml->>try ping with MTU payload
15:00<Tuxbubling-#uml->>somethin like?
15:02<Tuxbubling-#uml->>actually: 43 packets transmitted, 36 received, 16% packet loss, time 41998ms
15:02<Tuxbubling-#uml->>host > guest
15:02<ds2-#uml->>packet loss will seriously impair TCP performance (which is what ssh users)
15:02<ds2-#uml->>the 42sec RTT doesn't help either ;)
15:03<Tuxbubling-#uml->>44 packets transmitted, 41 received, 6% packet loss, time 43085ms << guest > host
15:03<ds2-#uml->>I wonder if the stats on the bridge are accurate, do you see errors on the interface, with ifconfig?
15:04<Tuxbubling-#uml->>RX packets:5201 errors:173 dropped:173 overruns:0 frame:173 << on eth0
15:04<ds2-#uml->>eth0 on the guest or host?
15:04<Tuxbubling-#uml->>TX packets:104 errors:0 dropped:573 overruns:0 carrier:0 << on uml-conn0
15:04<Tuxbubling-#uml->>host
15:05<Tuxbubling-#uml->>nothing on eth0 guest
15:05<ds2-#uml->>dropped 573? hmmm that can't be good
15:05<Tuxbubling-#uml->>i don't think so
15:05<Tuxbubling-#uml->>what could be the problem?
15:05<ds2-#uml->>w/o diving into the code, I donno; but packet loss is what is killing performance
15:06<Tuxbubling-#uml->>sky2 eth0: rx error, status 0x5ca0002 length 1482
15:06|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
15:06<Tuxbubling-#uml->>blah
15:06<Tuxbubling-#uml->>i'm under chroot
15:07<Tuxbubling-#uml->>not tested yet outside jail
15:10<Tuxbubling-#uml->>hey outside doesn't change anything :(
15:10<rjbell4-#uml->>jdike: I'm wondering if the ldt problem isn't with include/asm-um/arch/ldt.h. The #ifdef __x86_64__ check must be failing, and I don't think it should.
15:10<ds2-#uml->>don't expect chroot to make a difference
15:10|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has left #uml [Leaving]
15:10|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has joined #uml
15:10<jdike-#uml->>^W in the wrong window
15:11<Tuxbubling-#uml->>ds2: pinging the bridge is ok
15:12<ds2-#uml->>hmmm
15:12<Tuxbubling-#uml->>what could i try?
15:13<ds2-#uml->>donno
15:16|-|dsoul_ [darksoul@vice.ii.uj.edu.pl] has joined #uml
15:17<Tuxbubling-#uml->>:'(
15:20<Magotari-#uml->>Tuxbubling: Did you try just tuntap?
15:20<jdike-#uml->>what interfaces are showing lost packets?
15:21<Tuxbubling-#uml->>Magotari: can't make it work :/
15:21<rjbell4-#uml->>jdike: Why does arch-um/Makefile undefined __$(SUBARCH)__ ? That's what drops the lm field from struct user_desc, which results in the mis-matched LDT_empty call in arch/um/sys-i386/ldt.c.
15:21<Tuxbubling-#uml->>jdike: host eth0 and uml-conn0
15:22|-|dsoul [darksoul@vice.ii.uj.edu.pl] has joined #uml
15:22|-|dsoul [darksoul@vice.ii.uj.edu.pl] has quit [Remote host closed the connection]
15:22<rjbell4-#uml->>arch/um/sys-i386/ldt.c uses arch-specific macros, while it is compiled without the SUBARCH defined.
15:22<jdike-#uml->>rjbell4, various host headers define things that UML doesn't want when __$(SUBARCH)__ is defined
15:23<rjbell4-#uml->>This reeks of x86_64/i386 merger fall-out. :-P
15:23<jdike-#uml->>maybe
15:23<Tuxbubling-#uml->>what should be my default route?
15:24<Magotari-#uml->>The same ip as you put in the commandline.
15:24<Magotari-#uml->>(With which you started uml.)
15:24<Tuxbubling-#uml->>Magotari: i meant in bridge mode
15:24<Magotari-#uml->>Oh. Sorry.
15:25<jdike-#uml->>I wonder why we have both desc.h and host-ldt-*.h
15:26<jdike-#uml->>nothing uses desc.h
15:26<rjbell4-#uml->>jdike: In 2.6.23, there were separate files for include/asm/arch/ldt.h. They were separate arches.
15:26<jdike-#uml->>I guess that would explain it
15:26<rjbell4-#uml->>Now they've been merged to one file, based on __x86_64__, which uml undefines.
15:26<Tuxbubling-#uml->>kind of weird have better ping on google.com than other computers on my network O_o
15:27<Magotari-#uml->>So your whole network is slow?
15:28<Tuxbubling-#uml->>not at all
15:28<Tuxbubling-#uml->>only with the guest
15:28<Magotari-#uml->>Ah I see.
15:29<jdike-#uml->>the guest isn't under memory pressure?
15:29<Tuxbubling-#uml->>[root@localhost ~]# free -m
15:29<Tuxbubling-#uml->> total used free shared buffers cached
15:29<Tuxbubling-#uml->>Mem: 241 162 79 0 3 66
15:29<Tuxbubling-#uml->>-/+ buffers/cache: 92 148
15:29<Tuxbubling-#uml->>Swap: 0 0 0
15:29<Tuxbubling-#uml->>don't think so
15:32<Magotari-#uml->>It would be great to see if this happens with a different transport. But this is just my idea of debugging, trying lots of things hoping to bisect the problem.
15:33|-|Tuxbubling [~tuxbublin@sat78-6-88-160-130-34.fbx.proxad.net] has quit [Read error: Connection reset by peer]
15:35<jdike-#uml->>looks like he has more network troubles now
15:36<Magotari-#uml->>Yup.
15:37<Magotari-#uml->>And I think I should get myself a 64bit computer. I even know a good brand: Qemu.
15:37<jdike-#uml->>hehe
15:38<jdike-#uml->>a little slow, but can't beat the price
15:38<Magotari-#uml->>Yeah. I am sure 64bits brings lots of nice bugs to find, so I want to play around a bit.
15:39<Magotari-#uml->>I read about half of the uml code (maybe understanding a third), and I could not come up with any obivous bugs.
15:41<rjbell4-#uml->>jdike: I've only found three files using __x86_64__ in 2.6.23, and it looks okay to leave it defined in all cases. Of course, it's used a lot more in 2.6.24-rc1, as a result of the merger.
15:41<rjbell4-#uml->>jdike: I'm thinking of compiling with it still defined...
15:41<jdike-#uml->>try it then
15:46<rjbell4-#uml->>Problem in ipc/util.c. ip_parse_version is defined as a constant, and include/asm-um/unistd.h defines __ARCH_WANT_IPC_PARSE_VERSION
15:48<rjbell4-#uml->>Trying without it defined now
15:53|-|tyler29 [~tyler@ARennes-257-1-125-252.w86-210.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
15:58<peterz-#uml->>jdike: send you a patch
16:00<jdike-#uml->>looks fine to me
16:01<peterz-#uml->>was halfway though looking thought the various filesystems ere I realized the obvious
16:01<peterz-#uml->>:-)
16:03|-|tyler29 [~tyler@ARennes-257-1-32-162.w81-53.abo.wanadoo.fr] has joined #uml
16:10<rjbell4-#uml->>jdike: Well, I finally got something compiled, but now I get the following running it:
16:10<rjbell4-#uml->>Checking that ptrace can change system call numbers...check_ptrace : expected SIGSTOP, got status = 11
16:13<jdike-#uml->>that's a segfault
16:13<jdike-#uml->>you need yet another patch
16:15<jdike-#uml->>http://rafb.net/p/79x6Eo78.txt
16:26|-|ram [~ram@bi01p1.co.us.ibm.com] has joined #uml
16:33<rjbell4-#uml->>jdike: That's why I asked first before trying to figure it out. Retrying with patch now...
16:36<rjbell4-#uml->>Well, it runs...
16:36<rjbell4-#uml->>...though gdb segfaults
16:42|-|Nem^ [~Nem@dslb-084-056-253-078.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
16:47<rjbell4-#uml->>Here's what I did to get 2.6.24-rc1 to compile, that I don't think you already have: http://n01se.net/paste/Bbz
16:47<rjbell4-#uml->>jdike: ^^^
16:48<rjbell4-#uml->>Doesn't fix my problem unforunately, but at least it runs the same as 2.6.23 now
16:52<jdike-#uml->>Yuck
16:52<jdike-#uml->>Al did a lot of that on purpose
16:54|-|tyler29 [~tyler@ARennes-257-1-32-162.w81-53.abo.wanadoo.fr] has quit [Quit: ++]
16:58<rjbell4-#uml->>jdike: A lot of what?
16:58<jdike-#uml->>the -U__$(SUBARCH)__ stuff
17:03<rjbell4-#uml->>jdike: Hmm, I think __x86_64__ is used in more places than I though. My quick grep job wasn't complete.
17:04<rjbell4-#uml->>Nonetheless, it's working ... so far ...
17:25|-|Magotari [~karol@abhr207.neoplus.adsl.tpnet.pl] has quit [Ping timeout: 480 seconds]
17:29|-|karol [~karol@abhr207.neoplus.adsl.tpnet.pl] has joined #uml
17:29|-|karol changed nick to Magotari
17:30<Magotari-#uml->>Hereby I restate what I said before about wireless internet and closed vendor.
17:32<jdike-#uml->>it wasn't polite?
17:33<Magotari-#uml->>It wasn't.
17:34<Magotari-#uml->>Long story short, my current connection sucks, and on the other computer I am faced with "chicken before egg" problems...
17:34<Magotari-#uml->>I could download the latest -mm to get wireless network, but I need wireless network to do that.
17:35<Magotari-#uml->>THe kernel panics upon modprobe the wireless card driver module.
17:35<Magotari-#uml->>And if I compile it in, panic on boot.
17:36<Magotari-#uml->>I usually don't need looking for bugs, they find me.
17:48|-|hfb [~hfb@pool-71-106-219-180.lsanca.dsl-w.verizon.net] has quit [Quit: Leaving]
17:53<ds2-#uml->>Magotari: what card?
17:53<Magotari-#uml->>8187, if I remember right.
17:53<Magotari-#uml->>A very strange one.
17:53<Magotari-#uml->>The system tells me it is USB...
17:53<Magotari-#uml->>But it is in fact built into the computer itself!
17:54<Magotari-#uml->>Unless you ask me for the card which I am using on this computer, in which case ipw2100.
18:05<ds2-#uml->>Hmmm that's an intel thing hmmm
18:05<ds2-#uml->>get a real wireless interface ;)
18:06<jdike-#uml->>ipw2100 is well-supported
18:06<jdike-#uml->>that shouldn't be a problem
18:06<Magotari-#uml->>Yes, it is well supported.
18:06<Magotari-#uml->>I have not had much trouble with it, but ubuntu makes everything hell. Since I got it, I could not hold a connection for long.
18:07<Magotari-#uml->>Now, the 8187 thing, that is new.
18:09<Magotari-#uml->>The biggest problem is the router here.
18:15|-|dang [~dang@aa-redwall.nexthop.com] has quit [Quit: Leaving.]
18:25|-|dsoul_ changed nick to dsoul
19:01|-|krau [~cktakahas@200.184.118.132] has quit [Quit: Varei!!!]
19:03|-|ram [~ram@bi01p1.co.us.ibm.com] has quit [Ping timeout: 480 seconds]
19:05|-|Nem^ [~Nem@dslb-084-057-255-125.pools.arcor-ip.net] has joined #uml
20:01|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has joined #uml
20:30|-|Magotari_ [~karol@abhr207.neoplus.adsl.tpnet.pl] has joined #uml
20:30|-|Magotari [~karol@abhr207.neoplus.adsl.tpnet.pl] has quit [Quit: Reconnecting]
20:30|-|Magotari_ changed nick to Magotari
22:50|-|aroscha [~aroscha@chello213047053193.30.11.tuwien.teleweb.at] has quit [Quit: aroscha]
23:01|-|dang [~dang@nemesis.fprintf.net] has joined #uml
23:08|-|Nem^ [~Nem@dslb-084-057-255-125.pools.arcor-ip.net] has quit [Ping timeout: 480 seconds]
23:18|-|Nem^ [~Nem@dslb-084-056-231-155.pools.arcor-ip.net] has joined #uml
23:29|-|jdike [~jdike@pool-71-248-190-161.bstnma.fios.verizon.net] has quit [Quit: Leaving]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has left #uml [Rotating Logs]
23:59|-|VS_ChanLog [~stats@ns.theshore.net] has joined #uml
---Logclosed Fri Nov 02 00:00:33 2007