[12:04] <mjg59> Marvell haven't been too bad in the past, AFAIK
[12:34] <zyga> hello
[12:34] <zyga> I'm trying to write a fuse based fs with some dynamic files
[12:35] <zyga> I want something similar to /proc/foo where I can use cat to see the contents
[12:36] <zyga> when I make my virtual files have size 0 and mode with I_SFREG I cannot cat it
[12:36] <zyga> I need to supply some non-zero size to be able to read the content
[12:36] <zyga> I was wondering if /proc is using some special way to handle this
[12:36] <BenC> the size shouldn't have anything to do with it
[12:36] <zyga> stat'ing files in proc and my fs does not show any difference :/
[12:37] <BenC> read() operations don't even pay attention to the filesize
[12:37] <zyga> BenC: maybe proc is using mmap interface
[12:37] <BenC> cat doesn't
[12:37] <BenC> read() is read()
[12:37] <zyga> BenC: true, I didn't test that with a dumb program that relies only on read
[12:37] <zyga> BenC: still, as long as stat returns 0 in st_size I cannot see the contents with cat
[12:38] <BenC> there's lots of files in proc and /sys that show zero size and cat works on them just fine
[12:38] <zyga> BenC: that's why I'm asking ... I don't know why this happens
[12:38] <BenC> I'm doubting that has anything to do with it, but I'm also not familiar with fuse, so I'm not the right person to ask
[12:38] <zyga> maybe that's something fuse-specific
[12:41] <zyga> I see a sequence of stat, open and release (final close)
[12:41] <zyga> I never see any reads
[12:48] <BenC> did any of those fail?
[12:48] <BenC> perhaps the open failed?
[12:49] <BenC> strace cat /your/file
[12:49] <BenC> should tell you if the open failed for some reason
[12:49] <BenC> brb
[12:52] <zyga> BenC, no
[01:01] <zyga> BenC: I'm starting to see the problem
[01:01] <zyga> the call doesn't fail, python has mixed the stat structure somewhat
[01:01] <zyga> (python-fuse)
[01:01] <zyga> I don't really know which field gets passed where, I'll sort this out soon
[01:10] <zyga> what should be the st_size of a directory?
[01:36] <crimsun> zyga: hmm, in-kernel fuse?
[01:36] <crimsun> I see fuse 2.5.0
[01:38] <zyga> crimsun: ?
[01:38] <crimsun> zyga: what's triggering the bug?
[01:38] <zyga> crimsun: I don't know yet
[01:39] <zyga> crimsun: it seems that for files that have st_size == 0 the read function is never called
[01:39] <zyga> I'm looking at python2.4-fuse now
[01:39] <crimsun> sorry, I should have been more precise: What's your test case? (I guess you partially answered that)
[01:39] <crimsun> fuse 2.5.0 has a bunch of fixes
[01:40] <zyga> crimsun: I'm using 2.4.2
[01:41] <zyga> python-fuse is automatically setting blocksize to 4096
[01:42] <zyga> as well as hum...
[01:42] <zyga> it's broken :P
[01:47] <zyga> crimsun: by fuse 2.5.0, you ment fuse not, python-fuse, right?
[01:47] <crimsun> right.
[02:19] <zyga> crimsun, BenC: thanks for the help
[02:19] <zyga> it seems to be a fuse issue but I'm not 100% sure yet
[02:19] <zyga> I call it a day, night :)
[09:58] <Mithrandir> BenC: have you had a chance to look at the unionfs problems on PPC in the live cd?
[02:39] <zul> heylo
[02:39] <BenC> Mithrandir: should be fixed in -13
[03:08] <Mithrandir> BenC: great, thanks
[03:08] <BenC> Mithrandir: #ubuntu-meeting
[03:09] <Mithrandir> already there
[03:31] <JaneW> mjg59: PING
[03:59] <zooko> Greetings, folk of #ubuntu-kernel!
[04:00] <zooko> I'm considering installing the dapper gcc and dapper linux-source on my breezy system and compiling the kernel.  If I do so, do you want to hear any resulting bug reports?
[04:08] <BenC> it wont work well
[04:08] <BenC> it would be the same as installing the dapper kernel images from breezy
[04:08] <BenC> you would be better off just upgrading just the kernel image from dapper (and it's dependencies)
[04:09] <BenC> the kernel really doesn't care where it's compiled, it's the system it's running on that really matters
[04:09] <BenC> "installing the dapper kernel images" (not from breezy)
[04:45] <zooko> BenC: thanks for the suggestions.
[04:50] <zul> slacker
[04:53] <zooko> Hm.  I guess I'll go for gcc 4.0.whateverisindapper
[04:53] <BenC> are you still going to rebuild dapper kernel source in breezy?
[04:54] <zooko> Yes.
[04:54] <BenC> Just want to make sure you realize that it's not going to build a kernel any different than what is in dapper
[04:54] <BenC> it will be the same kernel (assuming you use the same .config's)
[04:54] <zooko> Understood.  Although I'll have slightly different configs...
[04:54] <zooko> I don't intend to request support from you on this.
[04:55] <BenC> I wasn't going to give any, but I just hate seeing someone waste time :)
[04:55] <zooko> I consider this channel to be for development, so I really mentioned it in case someone would say something like "Oh, please test such and such a bug while you do that" or some such.
[04:55] <zooko> :-)
[04:56] <BenC> I started 2.6.15-dapper kernel development on strictly breezy systems, so I know the outcome...your devices wont autoload, udev will become dumb and you'll typically be unhappy
[04:56] <zooko> What's the IRC channel for Ubuntu-using-bzr?  I'm interested in listening to how people use bzr.
[04:56] <zooko> Hm.
[04:56] <BenC> #bzr? note sure
[04:56] <zooko> That does sound intimidating.
[04:57] <zooko> Maybe I can avoid some of those problems by updating my udev package to dapper...
[04:57] <zooko> But now I am discouraged.  Maybe I'll stick with 2.6.12...
[04:58] <zooko> OTOH it can't hurt to try.  ;-)
[04:59] <BenC> it wont kill you thats for sure :)
[04:59] <zul> unless a large wooden mallet pops out of your computer and hits you over the head...its a new driver in 2.6.15
[05:00] <BenC> fortunately with udev broken, it never gets loaded
[05:01] <zul> lol
[05:01] <BenC> Try to avoid "modprobe kbd-electrocution" though
[05:01] <infinity> BenC: Erk, I don't see an ipw2100 sync in that changelog.
[05:02] <BenC> infinity: it was done...I thought I did the changelog entry
[05:02] <BenC> but it's surely done (1.1.4)
[05:02] <infinity> Guess I should have gone through the motions of reassigning that bug...
[05:02] <infinity> Oh, it's done?.. Cool.
[05:03] <infinity> Alright.  I'm on VAC as of now.
[05:04] <infinity> lamont's your bitch now.
[05:04] <lamont__> "By your command"
[05:50] <doko> BenC, infinity, please could you have a look if iptables is worth updating? ftp://ftp.netfilter.org/pub/iptables/changes-iptables-1.3.4.txt
[05:50] <BenC> is that the userspace stuff?
[05:51] <BenC> supposedly, our userspace and kernel drivers are out of sync terribly
[05:52] <Mithrandir> BenC: do you think a patch to add a label to swsusp images would have > 0 chance of being accepted upstream?
[05:52] <BenC> what sort of label?
[05:52] <Mithrandir> free-text, max 32 chars.
[05:53] <Mithrandir> unused by the kernel, but we could use it for stuff like "make sure you're resuming from the image that says "Ubuntu-$(uname -r)" and not the one which says "SuSE-$(uname -r)"
[05:53] <BenC> guess it all depends on what the purpose is
[05:53] <Mithrandir> similar, we would have support for suspend on the live cd.  Suspend to an USB stick, resume from that later.
[05:54] <BenC> ah, that does sound cool
[05:54] <Mithrandir> yeah, I thought so.
[05:54] <BenC> I would include it in our kernel, and I can push it upstream if you want
[05:54] <Mithrandir> I have the kernel patch mostly done, but would need to test it, naturally.
[06:02] <doko> BenC: iptables is userspace
[06:03] <BenC> doko: doesn't it depend on some kernel stuff (kernel headers or something)?
[06:03] <BenC> kernel-team@l.u.c has a user reporting problems with sync between kernel headers and iptables userspace
[06:06] <doko> BenC: it does
[06:06] <BenC> will the new version fix that?
[06:10] <doko> BenC: I didn't check, I just scanned dapper/main for packages with new upstream versions
[06:10] <BenC> if it helps that situation, then I'd say it's a good candidate for new upstream version
[06:11] <BenC> we already know the current package/setup is broken
[06:43] <zooko> So you know how I planned to compile 2.6.15-12.17 myself, on breezy?  And BenC warned me about this?
[06:44] <zooko> Well, instead I installed the kernel image from dapper, and all of its dependencies.
[06:44] <zooko> It *almost* works.  The only breakage that I can find is that one of my four hard drives is not detected.
[06:44] <zooko> Unfortunately, I really need that one, so now I must dig myself out of this situation...
[06:45] <zooko> Hm.  No /proc/config.gz.
[06:53] <zooko> Ah, and when I install linux-headers-2.6.15-12 I get this bug which Ben Collins has already assured me is impossible...
[06:53] <zooko> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.12/+bug/6384
[06:58] <zooko> Uh-oh.  I upgraded dpkg and debfoster in order to see if this would make Ben's assertion true.
[06:58] <zooko> Unfortunately it made it worse -- now I cannot back out of this situation anymore by using "dpkg --purge".
[06:59] <zooko> Oh yes I can.  I just need to dpkg --purge the *other* package instead of the new and uninstallable one.  Good.
[08:01] <zooko> I do hope that linux-image-2.6.12-9-amd64-k8 from dapper universe will recognize my fourth hard drive so that I can copy my work from it.
[08:36] <zul> shouldnt you have a backup plan?
[08:45] <aLeSD> hi akk
[08:45] <aLeSD> all
[08:45] <aLeSD> I have a question
[08:46] <aLeSD> why default kernels in ubuntu don't use preemtive?
[08:47] <aLeSD> another one is I'm compiling the kernel by hands... but it gives a kernel panic on rootfs mounting ... I use the usually make && make modules_install. I think it's because the support for the filesystem in ubuntu kernel is all modular (the most). Now how could I create an initd file by hands?
[08:48] <mjg59> BenC: Waa NetworkManager oopses my kernel
[08:48] <Mithrandir> hmm, they don't?
[08:48] <mjg59> (-12, -11 was fine)
[08:48] <Mithrandir> $ grep CONFIG_PREEMPT= /boot/config-2.6.15-12-686
[08:48] <Mithrandir> CONFIG_PREEMPT=y
[08:49] <BenC> mjg59: try -13, it should fix it
[08:50] <aLeSD> Mithrandir: wow ... I have only the 6.12 in my repository
[08:51] <BenC> daper kernels have preempt, not breezy
[08:51] <BenC> dapper
[08:52] <aLeSD> ok... could I compile my kernel by hand or I have to use make-kpkg
[08:52] <aLeSD> ?
[08:53] <aLeSD> ok ... stupid question... but It's my first time in ubuntu ... and i don't know how is it.. 
[08:53] <BenC> you can do whatever you want, but make-kpkg is prefered
[08:54] <aLeSD> ok I understand .-... make-kpkg
[08:54] <mjg59> BenC: Is that in the archive?
[08:55] <BenC> just uploaded today, so give it a few hours
[08:55] <mjg59> Ok
[08:55] <BenC> I assume you are getting an oops about "BUG in ...ieee80211"?
[08:55] <mjg59> Yup
[09:49] <zooko> For what it is worth, when I upgrade to 2.6.15 from dapper, everything works except for my promise raid controller 0000:00:08.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02)
[09:49] <zooko> 
[09:53] <cjb> zooko: Is there a module for it?  Anything in dmesg?
[09:57] <zooko> There is a sata_promise module loaded.
[09:57] <zooko> /var/log/syslog:Jan 19 13:33:13 yumyum kernel: [   37.708288]  sata_promise 0000:00:08.0: version 1.03
[09:57] <zooko> 
[09:57] <zooko> "1.03" is the version of the promise bios.  Not sure if that is the same number as in my syslog there.
[10:10] <BenC> modprobe sd_mod
[10:12] <zooko> no output.  sd_mod now appears in the output of lsmod.
[10:12] <zooko> It might or might not have been in lsmod before that.
[10:34] <BenC> are the drives connected sata drivers, or just ata?
[10:35] <BenC> just so happens that I got 4 promise 150 SATA controller cards in the mail from a very nice user today :)
[10:35] <BenC> my ATA drive doesn't appear to be recognized, but I assume that's because the controller driver doesn't support it (or maybe the controller doesn't)
[10:57] <tkup> how can I use a function from the kernel include files inside my module? I tried including the header file itself, but it didn't solve the problem. For instance, I included linux/swap.h but couldn't use any of the extern functions. Can anyone tell what I'm doing wrong?
[11:12] <BenC> tkup: explain how you can't use it
[11:12] <BenC> is it showing as unresolved when you load the module?
[11:12] <BenC> if so, that's because the functions aren't exported for module use (with EXPORT_SYMBOL())
[11:14] <tkup> BenC, that's right. the function isn't exported out. Does it mean that there's no other way but to reimplement that function?
[11:14] <BenC> you can add the EXPORT_SYMBOL to the file where the function is, and recompile the kernel
[11:14] <tkup> or link against that module that implements it,,,
[11:15] <cjb> tkup: Well, the obvious answer is to export it yourself, and persuade the kernel maintainers that it's needed by your code.
[11:15] <BenC> but you really should email linux-kernel@vger.kernel.org to see if your use of the function is correct or not
[11:15] <cjb> If you don't want to persuade them of that because you're not writing code for public consumption, it shouldn't be a problem to build your own kernel.  ;-)
[11:15] <BenC> tkup: unresolved functions in kernel modules like this isn't a matter of linker (ld) problems, it's the kernel enforcing what modules are allowed to do
[11:16] <tkup> BenC, cjb  I'm interested in add_to_swap.  the module is already GPL but nothing to write home about... just working on something I thought was interesting to see it work
[11:17] <BenC> I wouldn't reimplement the function (could create compatibility problems later on)
[11:17] <BenC> really, you should email l-k about the function you are using, if you are interested in releasing the module
[11:18] <BenC> see what they say about it, and maybe they could suggest the right way to handle it
[11:18] <tkup> I guess I could do what you said for starters and see if the module is interested before I write lkml
[11:18] <tkup> BenC, I'll email lkml and see if I should be using it at all
[11:19] <tkup> thanks
[11:20] <BenC> np
[11:49] <BenC> sweet, I got pata working on the sata_promise driver