[02:16] <zul> mjg59: hmm...i already have a patch for rtl8180 in my tree and i have pushed it to ben already
[07:02] <fabbione> morning guys
[07:09] <crimsun> hi fabbione 
[07:09] <fabbione> hi crim
[12:12] <LaschW> may there be a chance to have the ipt_TTL module (I'm not talking about ipt_ttl) in the next kernel images for dapper? There are more and more ISP's who don't allow more than one computer conected so manglint TTL's to a fix value would be very helpfull.
[12:13] <LaschW> s/manglint/mangling/
[12:28] <LaschW> fabbione: $IPT -t mangle -A OUTPUT -o $INET_IFACE -j TTL --ttl-set 128
[12:28] <fabbione> still doesn't help...
[12:28] <LaschW> fabbione: Most ISP's only check TTL, so up to now
[12:29] <LaschW> fabbione: ?Why not?
[12:29] <fabbione> according to RFC the max internet radius is 30
[12:29] <fabbione> or better
[12:29] <fabbione> there cannot be more than 30 hops between 2 hosts
[12:30] <fabbione> if an ISP doesn't allow more than one machine to connect
[12:30] <fabbione> it's clearly not TTL that's going to help you
[12:30] <fabbione> because each machine generate it's own packet with its own TTL
[12:31] <fabbione> so that rule would only increase/reset a TTL to 128
[12:31] <CataEnry> hi all
[12:31] <LaschW> fabbione: And this 'per machine' TTL's will be set to the same value on a gateway using ipt_TTL
[12:31] <mjg59> fabbione: ISPs can drop packets with a TTL of 28 when they expect it to be 29
[12:32] <fabbione> mjg59: when you traverse a NAT box, TTL is regenerated in the new pkt afaik
[12:32] <LaschW> fabbione: And for this there is a need for the ipt_TTL module, as RH does
[12:32] <fabbione> it's easy to workaround at client side ;)
[12:33] <fabbione> i could just 'mangle' the outgoing packet to a TTL 30 and zack
[12:33] <fabbione> i hide the other boxes behind one
[12:33] <fabbione> but well.. let see what Ben has to say
[12:33] <LaschW> fabbione: Thats what I'm talking about. You need ipt_TTL for this
[12:34] <fabbione> LaschW: so you need to workaround...
[12:35] <LaschW> fabbione: I now how to do this! But I think most Ubuntu Newbies don't. According the fact that the target group of Ubuntu are new Linux Users...
[12:36] <LaschW> fabbione: Or are you expecting new Ubuntu users to build their own kernel modules first? ;-)
[12:37] <fabbione> LaschW: i find weird that's not builded
[12:38] <LaschW> fabbione: Pardon my broken english... What do you mean with 'i find weird that's not builded'
[12:38] <fabbione> according to iptables man page it's there
[12:38] <fabbione> meaning that's supported by vanilla kernel
[12:39] <fabbione> config:CONFIG_IP_NF_MATCH_TTL=m
[12:39] <fabbione> config:CONFIG_IP_NF_TARGET_TTL=m
[12:39] <fabbione> werid
[12:39] <fabbione> weird
[12:40] <LaschW> fabbione: Hhhm, In the beginning I muddled ipt_nat and ipt_NAT. And it seems many docs do so likewise...
[12:42] <LaschW> fabbione: Ubuntu linux-image is missing 'config:CONFIG_IP_NF_TARGET_TTL=m'
[12:42] <fabbione> LaschW: the past i did was from .15
[12:42] <LaschW> fabbione: So does Debian...
[12:43] <LaschW> fabbione: grep IPT /boot/config-2.6.12-9-k7
[12:44] <fabbione> interesting
[12:44] <fabbione> it looks like it gets automatically unset
[12:44] <fabbione> fun
[12:44] <LaschW> fabbione: s/IPT/TTL/ pardon me...
[12:44] <fabbione> yeah i got that
[12:46] <LaschW> fabbione: I've been digging netfilter mailing lists if there might be any incompatibility using ipt_nat and ipt_NAT at the same time, but dindn't find any.
[12:52] <CataEnry> cya next time
[12:53] <fabbione> LaschW: it makes more sense to look at Kconfig
[12:53] <fabbione> but i don't have time right now
[12:54] <LaschW> fabbione: Kconfig, the KDE GUI Tool?
[12:54] <fabbione> no
[12:54] <fabbione> Kconfig the set of files that acutally build the kernel :)
[12:54] <fabbione> the KDE tool is make xconfig
[12:54] <fabbione> gnome: make gconfig
[12:55] <LaschW> fabbione: Ok, I was a bit shocked, to be honest. :-))
[12:56] <LaschW> fabbione: I had in mind this weird Kcontrol kernel config module *laugh*
[12:56] <fabbione> tsk
[12:56] <fabbione> :P
[12:57] <LaschW> fabbione: :P, fullack
[01:01] <chmj> the current kernel source in git is unbuildable? or am I missing something ? 
[03:11] <zul> mjg59: ping
[03:20] <mjg59> zul: Hi
[03:34] <zul> mjg59: i already wrote a patch for rtl8180 i already pushed it to benc
[03:34] <mjg59> zul: Ok, cool
[03:50] <zul> so it will get in when it gets in
[03:58] <BenC> zul: speaking of the rtl8180, can you email me the external-driver info for it?
[03:58] <BenC> I have all your patches in locally, except that one
[03:59] <BenC> I need to clean it up a little, since it's building with a local copy of ieee80211, and I need to make it use the stock one from net/ieee80211
[04:00] <dilinger> there's an rtl8180 driver?
[04:01] <dilinger> url?
[04:01] <BenC> sf I believe
[04:02] <dilinger> oh, look at that, partly based on my code
[04:04] <dilinger> too bad i don't have an rtl8180 anymore
[04:17] <zul> BenC: ok ill do it tonight
[04:19] <fabbione> hey BenC 
[04:19] <BenC> fabbione: hey
[04:19] <fabbione> smoking break and i will be back in a sec
[04:19] <fabbione> btw.. .15-rc2 boots on davem box
[04:19] <BenC> puff one for me
[04:19] <fabbione> we must be doing something wrong
[04:20] <BenC> it's too cold and wet to smoke outside
[04:20] <BenC> ok
[04:20] <BenC> for sparc64, I used our old config, and did a "make oldconfig" to update it
[04:20] <BenC> I should do a default config just to see if that works
[04:20] <fabbione> it's freezing here.. but if i smoke inside i can wave khtxbye to my testicles
[04:21] <dilinger> BenC: where are you?
[04:21] <BenC> virginia
[04:21] <BenC> I should make my office the "smoking room"
[04:22] <BenC> but I hate all the nicotine getting on my hw
[04:22] <BenC> s/nicotine/tar/
[04:23] <dilinger> ah, ok.  not that far away
[04:42] <BenC> zul: ping
[04:50] <zul> pong
[05:00] <BenC> ping: any bugreport to reference for the ali patch?
[05:00] <BenC> tulip patch that is
[05:07] <mjg59> http://www.ath-driver.org/ is looking quite promising
[05:09] <makx> anyone seen infinity?
[05:09] <mjg59> makx: He's quite possibly asleep right now
[05:09] <makx> aah ok
[05:10] <makx> mjg59: you fixed suspend for sesse's laptop. do you send fix upstream?
[05:10] <mjg59> makx: Not yet, because I'm not convinced it's the right fix
[05:10] <mjg59> Need to discuss it with PCMCIA upstream
[05:10] <makx> ok, cool so it's rolling
[05:21] <zul> BenC: yeah there is..just dont remmber off the top of my head, ill have to check
[05:23] <BenC> zul: btw, gregkh has a speakup patch I am going to use instead of yours
[05:24] <zul> BenC: he does? cool..
[05:48] <BenC> fabbione: A defconfig compile with our tree doesn't boot for me
[05:48] <BenC> fabbione: I'm going to have to do a stock 2.6.15-rc2 compile to see if I broke something, but I can't see that being the case
[05:49] <BenC> 99% of the code we introduced either doesn't touch sparc64, or is just drivers that are being compiled modular right now
[05:56] <mjg59> BenC: Are all the patches from 2.6.12 in the git tree?
[06:06] <mjg59> BenC: Also, ndiswrapper is completely broken on amd64
[06:19] <BenC> ndiswrapper never did work properly on amd64 in breezy, IIRC
[06:20] <BenC> all patches from breezy (except a lot of acpi, and patches that were obsoleted) are in
[06:20] <BenC> also, minus the sk98lin patch
[06:20] <BenC> rtl8180 may be a no go in breezy
[06:21] <BenC> it's using it's own internal ieee80211 stack, and it isn't playing well with the rest of the system
[06:24] <dilinger> any idea whether the original author reverse engineered the management frames stuff, or got some documentation?
[06:26] <mjg59> BenC: ndiswrapper worked fine on amd64 in Breezy
[06:26] <mjg59> We're missing at least the patch that fixes the clock on AMD64s with ATI chipsets
[06:26] <mjg59> BenC: I'll look into the rtl8180 thing at some stage
[06:27] <BenC> mjg59: last release from the project was 7 months ago
[06:27] <BenC> mjg59: do you have a patch name for the amd64?
[06:28] <dilinger> if someone can hook me up w/ an rtl8180 card, and i don't need to reverse engineer the mgmt frame stuff (that's why i stopped working on rtl8180 in the first place), i'm more than happy to start hacking away at the driver again
[06:29] <mjg59> BenC: Not off the top of my head. 
[06:29] <BenC> mjg59: clokc == video clock, or hw clock?
[06:30] <mjg59> HW clock
[06:30] <mjg59> It gets two timer interrupts per HZ
[06:31] <BenC> kernel-apic-timer-fix
[06:31] <mjg59> That's the one
[06:31] <BenC> that was still broken for me in breezy
[06:32] <mjg59> Uhm. How so?
[06:32] <BenC> it needs to be applied to i386 for k8 chipsets too (like Sempron, which isn't 64-bit)
[06:32] <mjg59> Oh, right. Eww.
[06:32] <mjg59> Well, upstream are entirely failing to try to fix it properly
[06:33] <BenC> I had to boot with noapictimer on my laptop at ubz
[06:33] <BenC> is it a hw bug?
[06:33] <mjg59> Seems to be
[06:34] <mjg59> Windows runs itself off the apic timer rather than using a timer interrupt
[06:34] <mjg59> So you don't see it there
[06:34] <mjg59> bcm430x is still rather broken, yes
[06:35] <mjg59> Its worker queue just fell over on me
[06:38] <mjg59> dilinger: You're in the US, right?
[06:39] <dilinger> mjg59: yea; nyc
[06:41] <BenC> mjg59: are you actually getting packets through it yet?
[06:42] <mjg59> BenC: Oh, christ no :)
[06:46] <BenC> I'm at a loss here
[06:46] <BenC> noapictimer doesn't seem to be an i386 option
[06:46] <BenC> yet it worked for my Sempron using a -k7 kernel
[06:46] <mjg59> The i386 apic code is quite different to the amd64 stuff
[06:46] <BenC> it's only in arch/x86_64/kernel/apci.c
[06:46] <BenC> yeah, but why did the kernel option make my timer work :)
[06:47] <dilinger> mjg59: know anything around that's vacationing in NY?
[06:54] <mjg59> dilinger: Afraid not
[06:54] <fabbione> BenC: ok... i don't think we have any sparc specific patch... where does the boot hang?
[06:55] <mjg59> BenC: Basically, on the affected chipsets, we either need to drop interrupts from the first apic pin or from irq 0
[07:06] <BenC> fabbione: can't tell, it doesn't spit anything out, and I can't even do a break to get at the .register and .stack output
[07:06] <fabbione> ah
[07:07] <BenC> fabbione: I'm getting the stock -rc2 so I can atleast tell dave that it isn't our fault :)
[07:07] <BenC> it may be a enterprise bug, since dave doesn't have any machines like this
[07:07] <BenC> and my U2 is buried in other stuff, so I can't test that right now
[07:08] <fabbione> BenC: eheh ok.. he is getting a E280R
[07:08] <fabbione> so he will have no excuses
[07:09] <BenC> E280R doesn't have the CENTRAL 4-slot hw, so who knows if it will be the same bug
[07:09] <BenC> if it will show the same bug that is
[07:10] <fabbione> BenC: if you can push me a .deb somewhere i can probably test it tomorrow
[07:10] <fabbione> right now i am building gcc-4.0 for the libstdc transition
[07:11] <fabbione> and i really can't stop it after these many hours
[07:11] <fabbione> dilinger: ping?
[07:11] <BenC> ok, I'll get it on people
[07:11] <fabbione> thanks
[07:14] <BenC> mjg59: amd64 apic timer patch is in git now
[07:14] <dilinger> fabbione: yo
[07:15] <BenC> mjg59: do you think it would be ok to pull -mm's acpi git patch?
[07:17] <mjg59> BenC: Sure
[07:21] <mjg59> Oooh ooh ooh
[07:21] <mjg59> Suspend to RAM has started working on my amd64
[07:24] <mjg59> I'm actually going to blame vgacon changes for usplash not working any more
[07:29] <mjg59> Ok, maybe it's not that, then
[07:30] <mjg59> BenC: Possibly over-optimistic, but is there any chance of more up-to-date orinoco drivers?
[07:32] <mjg59> Ok, now that's *very* odd
[07:32] <mjg59> If I run usplash from a console, it looks fine
[07:46] <jbailey> mjg59: Just not from an Xterm.  Tried that, it was a mistake.
[07:56] <BenC> mjg59: there's some vgacon patches in -mm
[07:56] <BenC> may want to look at them
[07:56] <mjg59> Nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnngh.
[07:56] <mjg59> 2.6.15 breaks vbetool.
[07:56] <mjg59> Entirely.
[07:56] <BenC> one is a doublescan fix, and one is a fix for something else (some other corruption)
[08:05] <mjg59> Nnnnnngh.
[08:44] <mjg59> BenC: Have you added anything that changes the behaviour of /dev/mem ?
[08:44] <BenC> yeah, but it's not in -4.4
[08:44] <BenC> err, -3.3
[08:44] <BenC> it's in git though
[08:45] <BenC> is it breaking something, because I can disable it?
[08:45] <BenC> elmo had requested the devmem patch
[08:45] <mjg59> Not sure - I'm having problems trying to make vbetool work, but I think that one's just a symptom rather than a cause
[08:45] <mjg59> Ah, yeah, it's triggering if I mmap /dev/zero, so probably not you
[08:46] <mjg59> mmap is returning EACCES
[08:46] <mjg59> And I can't see why
[08:46] <fabbione> hmmm
[08:47] <fabbione> capability?
[08:47] <mjg59> Running as root
[08:47] <mjg59> This is on amd64, though
[08:47] <mjg59> Looking at the kernel, that can only happen if the file is unreadable or unwritable
[08:47] <fabbione> i remember once they broke capability in such a way not even root could do anything
[08:54] <mjg59> Hmm. It's claiming that I don't have write access to the file.
[08:54] <mjg59> Hngh.
[09:19] <BenC> is this -3.3 or -4.4?
[09:20] <mjg59> -4.4
[09:21] <mjg59> Never mind, figured it out
[09:21] <mjg59> The kernel's just got more picky about mmaping in general
[09:21] <mjg59> So I've got a vbetool that at least partially works for amd64
[09:22] <mjg59> And now my amd64 suspends and resumes
[09:22] <BenC> sweet
[09:22] <BenC> lamont: ping
[09:23] <lamont> ack
[09:23] <BenC> lamont: you'll be happy to know that I did a git pull from the ia64 and parisc repo's today
[09:23] <lamont> how did it get to be 1330 already!?  sigh
[09:23] <lamont> BenC: woot!
[09:24] <fabbione> ia64?
[09:24] <dilinger> lamont: whee, it's 1530 already! ;p
[09:24] <fabbione> we did never pull from ia64 repo
[09:24] <fabbione> oh that might be why ia64 did never boot
[09:24] <lamont> dilinger: I have appts this afternoon to go deal with. sigh
[09:24] <mjg59> Hmm. 2.6.15 is resulting in my mouse driver not being loaded.
[09:24] <BenC> -mm's patches pull from an ia64 repo, so I figured it can't hurt for us to pull too
[09:24] <fabbione> BenC: are the changes already propagated to kernel.org?
[09:24] <BenC> it's only like 50k of diff
[09:25] <BenC> mjg59: odd
[09:25] <fabbione> mjg59: it works here.. usb mouse
[09:25] <mjg59> Oh, hang on
[09:25] <mjg59> psmouse is loaded
[09:25] <mjg59> mousedev isn't
[09:25] <BenC> fabbione: they are in 2.6.15-rc1-mm2
[09:25] <mjg59> Latest hotplug, udev and initramfs-tools
[09:25] <mjg59> Anyone have any other things to try?
[09:25] <fabbione> BenC: i meant in our git repo
[09:25] <BenC> thought mousedev was hardcoded to load
[09:25] <lamont> BenC: and someone was working on making initramfs happy with ia64 too, so that's good
[09:26] <jbailey> lamont: Someone other than me?
[09:26] <mjg59> Yeah, I can just stick it in modules fo rnow
[09:26] <lamont> jbailey: someone here in the lab
[09:26] <jbailey> lamont: Cool!
[09:26] <lamont> (fails on debian too, you see...)
[09:26] <BenC> fabbione: yeah, this is the first pull I did
[09:26] <fabbione> BenC: ok
[09:26] <BenC> afk for about 10 minutes
[09:41] <BenC> fabbione: oh, just got what you meant, no, I haven't pushed yet
[09:41] <BenC> trying a build to make sure I didn't break anything
[09:42] <fabbione> BenC: ehhe ok
[09:49] <BenC> zul__: ping
[09:52] <zul__> yo
[09:56] <zul__> what did i do now? ;)
[09:56] <fabbione> zul__: you did nothing
[09:56] <fabbione> that's why we are going to kill you
[09:56] <BenC> zul__: I have everything I can take from your repo, so if you can kill it, and start fresh, I can start taking things again
[09:56] <fabbione> isn't time to fix some bugs? ;)
[09:57] <BenC> fabbione: never tell the prey that it is about to die :)
[09:57] <fabbione> ehehe
[09:57] <zul__> BenC: okie dokie
[09:57] <zul__> there is a global conpiracy agains me
[09:58] <BenC> zul__: only thing I need is some info on that tulip patch
[09:58] <BenC> and thanks for the patches too
[09:58] <fabbione> how did i die?
[09:59] <mjg59> Remote closed the connection
[09:59] <fabbione> ah
[09:59] <fabbione> xchat did die
[09:59] <fabbione> thanks
[10:01] <BenC> fabbione: kiko has a question, he'll be here in a sec
[10:02] <kiko> hey ho
[10:02] <kiko> fabbione, padrino mio
[10:02] <kiko> what happened to libipt_ROUTE in breezy?
[10:02] <BenC> he's wondering what happened to iptables ROUTE between hoary and breezy, says it's no longer there...
[10:03] <fabbione> ROUTE?
[10:03] <kiko> granted, it never actually worked :)
[10:03] <fabbione> that would be iptables is the package.. not the kernel
[10:03] <kiko> well
[10:03] <BenC> so that has nothing to do with the kernel?
[10:03] <fabbione> i would like to understand what this thing was doing
[10:04] <kiko> I don't quite understand but IIRC netfilter and the kernel have a bit of a incestuous relationship
[10:04] <fabbione> kiko: yes they do.. that's clear
[10:04] <fabbione> a libipt_SOMETHING mostlikely need a ipt_SOMETHING.ko in the kernel
[10:04] <kiko> right
[10:05] <kiko> okay
[10:05] <kiko> so what does ipt_ROUTE do
[10:05] <kiko> it adds a ROUTE iptables target
[10:05] <kiko> which allows you to do routing changes for packets that match a filter
[10:06] <kiko> for instance, you can modify the default route used for packets for a specific service
[10:06] <fabbione> oh yeah i see
[10:06] <fabbione> you don't need that
[10:06] <fabbione> iptables are for pussies
[10:06] <kiko> padrino!
[10:06] <fabbione> you can just use LAR
[10:06] <kiko> iproute2?
[10:06] <fabbione> that's the same i use here
[10:06] <fabbione> yes
[10:06] <fabbione> Linux Advanced Routing
[10:06] <kiko> hmmm
[10:07] <kiko> I believe we tested that and failed, but we can always try harder
[10:07] <kiko> okay
[10:07] <fabbione> kiko: i have working config
[10:07] <fabbione> +s
[10:07] <kiko> fabbione, mail something to me?
[10:07] <fabbione> kiko: my consigliere.. it's no problem at aaaalllll
[10:08] <kiko> since i'm already chattering about
[10:08] <kiko> we have one box that has a via-rhine ethernet onboard that just hangs when booting with the breezy kernel
[10:09] <kiko> we're atm using the hoary kernel
[10:10] <BenC> sysrq work at all on it?
[10:10] <BenC> maybe see where it's hanging
[10:10] <kiko> given it's a diskless box it's pretty unlikely we can use it much.
[10:10] <kiko> okay, that would be a start
[10:11] <kiko> let me try and find out where it hangs and poke back
[10:13] <kiko> BenC, do we have alt-sysrq on by default in our kernels?
[10:13] <kiko> so we do!
[10:13] <kiko> thanks
[10:13] <BenC> I believe so
[10:15] <zul__> *sigh* 8 year anniversary tonight..
[10:21] <zul__> later
[10:22] <fabbione> zul__: have fun
[10:22] <fabbione> look at the positive side.. you might get laid ;)
[10:34] <zul__> oh i know i will..
[10:34] <zul__> laster
[10:57] <BenC> fabbione: booting 2.6.15-rc2 stock
[10:57] <fabbione> BenC: cool
[10:57] <fabbione> anyway.. i am off to bed
[10:57] <fabbione> good night guys
[10:57] <BenC> good night
[10:59] <BenC> sweet
[10:59] <BenC> fabbione: stock crashes too
[10:59] <fabbione> ahah cool
[10:59] <fabbione> gonna tell davem
[10:59] <fabbione> ehehhe
[10:59] <fabbione> *grins*
[11:18] <mjg59> BenC: The rtl8180 driver seems to be actively developed in CVS
[11:19] <mjg59> (file) Makefile  1.1.1.4  7 weeks  i855crt  Updated to work with current ieee802.11 stack
[11:19] <mjg59> Looks sort of promising
[11:19] <BenC> odd, I pulled from CVS
[11:19] <BenC> and it was broken
[11:19] <BenC> broken meaning it was popping out all kinds of errors regarding ieee80211 stuff
[11:20] <BenC> rtl8180-sa2400-dev is the module I checked out
[11:20] <mjg59> Ah
[11:21] <mjg59> You want rtl818x-newstack
[11:21] <BenC> ah,
[11:21] <BenC> cool, thanks
[11:21] <mjg59> And rtl8187-newstack/ for USB support
[11:28] <BenC> fabbione: emailed davem my oops
[11:29] <BenC> mjg59: lol, the rtl8187-newstack has the .cmd.c files from the kernel build in it :)
[11:31] <mjg59> BenC: Heh
[11:51] <chuck_> BenC: 18673
[11:51] <BenC> chuck_: thanks
[11:51] <chuck_> no probs
[12:02] <BenC> this driver is gawd aweful
[12:02] <BenC> it's using htonl instead of cpu_to_* stuff