[12:04] Marvell haven't been too bad in the past, AFAIK === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel === zyga [n=zyga@ubuntu/member/zyga] has joined #ubuntu-kernel [12:34] hello [12:34] I'm trying to write a fuse based fs with some dynamic files [12:35] I want something similar to /proc/foo where I can use cat to see the contents [12:36] when I make my virtual files have size 0 and mode with I_SFREG I cannot cat it [12:36] I need to supply some non-zero size to be able to read the content [12:36] I was wondering if /proc is using some special way to handle this [12:36] the size shouldn't have anything to do with it [12:36] stat'ing files in proc and my fs does not show any difference :/ [12:37] read() operations don't even pay attention to the filesize [12:37] BenC: maybe proc is using mmap interface [12:37] cat doesn't [12:37] read() is read() [12:37] BenC: true, I didn't test that with a dumb program that relies only on read [12:37] BenC: still, as long as stat returns 0 in st_size I cannot see the contents with cat [12:38] there's lots of files in proc and /sys that show zero size and cat works on them just fine [12:38] BenC: that's why I'm asking ... I don't know why this happens [12:38] 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] maybe that's something fuse-specific [12:41] I see a sequence of stat, open and release (final close) [12:41] I never see any reads [12:48] did any of those fail? [12:48] perhaps the open failed? [12:49] strace cat /your/file [12:49] should tell you if the open failed for some reason [12:49] brb [12:52] BenC, no === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [01:01] BenC: I'm starting to see the problem [01:01] the call doesn't fail, python has mixed the stat structure somewhat [01:01] (python-fuse) [01:01] I don't really know which field gets passed where, I'll sort this out soon === tkup|bed [n=tkup@cpe-67-10-255-86.houston.res.rr.com] has joined #ubuntu-kernel [01:10] what should be the st_size of a directory? [01:36] zyga: hmm, in-kernel fuse? [01:36] I see fuse 2.5.0 [01:38] crimsun: ? [01:38] zyga: what's triggering the bug? [01:38] crimsun: I don't know yet [01:39] crimsun: it seems that for files that have st_size == 0 the read function is never called [01:39] I'm looking at python2.4-fuse now [01:39] sorry, I should have been more precise: What's your test case? (I guess you partially answered that) [01:39] fuse 2.5.0 has a bunch of fixes === crimsun git pulls [01:40] crimsun: I'm using 2.4.2 [01:41] python-fuse is automatically setting blocksize to 4096 [01:42] as well as hum... [01:42] it's broken :P [01:47] crimsun: by fuse 2.5.0, you ment fuse not, python-fuse, right? [01:47] right. [02:19] crimsun, BenC: thanks for the help [02:19] it seems to be a fuse issue but I'm not 100% sure yet [02:19] I call it a day, night :) === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-12.17 uploaded (I have no clever code name) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/ === Topic (#ubuntu-kernel): set by BenC at Wed Jan 18 02:16:17 2006 === psusi [n=phreak@54.161.205.68.cfl.res.rr.com] has joined #ubuntu-kernel === rikai-2 [n=gtk2@pool-70-105-231-88.port.east.verizon.net] has joined #ubuntu-kernel === JaneW [n=JaneW@dsl-146-130-233.telkomadsl.co.za] has joined #ubuntu-kernel === chmj [n=chmj@196.44.1.98] has joined #ubuntu-kernel === rikai-2 [n=gtk2@pool-70-105-231-88.port.east.verizon.net] has joined #ubuntu-kernel === rikai [n=gtk2@pool-70-105-231-88.port.east.verizon.net] has joined #ubuntu-kernel === CataEnry [n=Enrico@host232-21.pool8250.interbusiness.it] has joined #ubuntu-kernel [09:58] BenC: have you had a chance to look at the unionfs problems on PPC in the live cd? === ubuntulog [i=ubuntulo@trider-g7.fabbione.net] has joined #ubuntu-kernel === Topic for #ubuntu-kernel: Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-12.17 uploaded (I have no clever code name) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/ === Topic (#ubuntu-kernel): set by BenC at Wed Jan 18 02:16:17 2006 === doko [n=doko@dslb-084-059-108-033.pools.arcor-ip.net] has joined #ubuntu-kernel === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [02:39] heylo [02:39] Mithrandir: should be fixed in -13 === CataEnry [n=cataenry@host232-21.pool8250.interbusiness.it] has joined #ubuntu-kernel === mgalvin [n=mgalvin@ubuntu/member/mgalvin] has joined #ubuntu-kernel [03:08] BenC: great, thanks [03:08] Mithrandir: #ubuntu-meeting [03:09] already there === slushpupie [i=jay@slushpupie.com] has joined #ubuntu-kernel [03:31] mjg59: PING === zooko [n=user@blk-215-95-202.eastlink.ca] has joined #ubuntu-kernel [03:59] Greetings, folk of #ubuntu-kernel! [04:00] 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] it wont work well [04:08] it would be the same as installing the dapper kernel images from breezy [04:08] you would be better off just upgrading just the kernel image from dapper (and it's dependencies) [04:09] the kernel really doesn't care where it's compiled, it's the system it's running on that really matters [04:09] "installing the dapper kernel images" (not from breezy) === lamont__ [n=lamont@mib.fc.hp.com] has joined #ubuntu-kernel === CataEnry [n=cataenry@host232-21.pool8250.interbusiness.it] has joined #ubuntu-kernel [04:45] BenC: thanks for the suggestions. === ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-13.18 uploaded (The "Stick it to da man" Release) | Daily Diet of Destruction: http://people.ubuntu.com/~bcollins/kernels-daily/ [04:50] slacker [04:53] Hm. I guess I'll go for gcc 4.0.whateverisindapper [04:53] are you still going to rebuild dapper kernel source in breezy? [04:54] Yes. [04:54] 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] it will be the same kernel (assuming you use the same .config's) [04:54] Understood. Although I'll have slightly different configs... [04:54] I don't intend to request support from you on this. [04:55] I wasn't going to give any, but I just hate seeing someone waste time :) [04:55] 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] :-) [04:56] 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] What's the IRC channel for Ubuntu-using-bzr? I'm interested in listening to how people use bzr. [04:56] Hm. [04:56] #bzr? note sure [04:56] That does sound intimidating. [04:57] Maybe I can avoid some of those problems by updating my udev package to dapper... [04:57] But now I am discouraged. Maybe I'll stick with 2.6.12... [04:58] OTOH it can't hurt to try. ;-) [04:59] it wont kill you thats for sure :) [04:59] 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] fortunately with udev broken, it never gets loaded [05:01] lol [05:01] Try to avoid "modprobe kbd-electrocution" though [05:01] BenC: Erk, I don't see an ipw2100 sync in that changelog. [05:02] infinity: it was done...I thought I did the changelog entry [05:02] but it's surely done (1.1.4) [05:02] Guess I should have gone through the motions of reassigning that bug... [05:02] Oh, it's done?.. Cool. [05:03] Alright. I'm on VAC as of now. [05:04] lamont's your bitch now. [05:04] "By your command" === rikai [n=gtk2@pool-70-105-231-88.port.east.verizon.net] has joined #ubuntu-kernel === smurf [n=smurf@debian/developer/smurf] has joined #ubuntu-kernel === rikai-2 [n=gtk2@pool-71-241-195-206.port.east.verizon.net] has joined #ubuntu-kernel === rikai-2 [n=gtk2@pool-71-241-195-206.port.east.verizon.net] has joined #ubuntu-kernel [05:50] 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] is that the userspace stuff? [05:51] supposedly, our userspace and kernel drivers are out of sync terribly [05:52] BenC: do you think a patch to add a label to swsusp images would have > 0 chance of being accepted upstream? [05:52] what sort of label? [05:52] free-text, max 32 chars. [05:53] 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] guess it all depends on what the purpose is [05:53] similar, we would have support for suspend on the live cd. Suspend to an USB stick, resume from that later. [05:54] ah, that does sound cool [05:54] yeah, I thought so. [05:54] I would include it in our kernel, and I can push it upstream if you want [05:54] I have the kernel patch mostly done, but would need to test it, naturally. [06:02] BenC: iptables is userspace [06:03] doko: doesn't it depend on some kernel stuff (kernel headers or something)? [06:03] kernel-team@l.u.c has a user reporting problems with sync between kernel headers and iptables userspace [06:06] BenC: it does [06:06] will the new version fix that? [06:10] BenC: I didn't check, I just scanned dapper/main for packages with new upstream versions [06:10] if it helps that situation, then I'd say it's a good candidate for new upstream version [06:11] we already know the current package/setup is broken === zooko [n=user@blk-215-95-202.eastlink.ca] has joined #ubuntu-kernel [06:43] So you know how I planned to compile 2.6.15-12.17 myself, on breezy? And BenC warned me about this? [06:44] Well, instead I installed the kernel image from dapper, and all of its dependencies. [06:44] It *almost* works. The only breakage that I can find is that one of my four hard drives is not detected. [06:44] Unfortunately, I really need that one, so now I must dig myself out of this situation... [06:45] Hm. No /proc/config.gz. [06:53] 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] https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.12/+bug/6384 [06:58] Uh-oh. I upgraded dpkg and debfoster in order to see if this would make Ben's assertion true. [06:58] Unfortunately it made it worse -- now I cannot back out of this situation anymore by using "dpkg --purge". [06:59] Oh yes I can. I just need to dpkg --purge the *other* package instead of the new and uninstallable one. Good. === zooko [n=user@blk-215-95-202.eastlink.ca] has joined #ubuntu-kernel [08:01] 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] shouldnt you have a backup plan? === ds [n=nnds@dsl092-014-052.sfo1.dsl.speakeasy.net] has joined #ubuntu-kernel === aLeSD [n=alex@76.Red-88-5-94.staticIP.rima-tde.net] has joined #ubuntu-kernel [08:45] hi akk [08:45] all [08:45] I have a question [08:46] why default kernels in ubuntu don't use preemtive? [08:47] 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] BenC: Waa NetworkManager oopses my kernel [08:48] hmm, they don't? [08:48] (-12, -11 was fine) [08:48] $ grep CONFIG_PREEMPT= /boot/config-2.6.15-12-686 [08:48] CONFIG_PREEMPT=y [08:49] mjg59: try -13, it should fix it [08:50] Mithrandir: wow ... I have only the 6.12 in my repository [08:51] daper kernels have preempt, not breezy [08:51] dapper [08:52] ok... could I compile my kernel by hand or I have to use make-kpkg [08:52] ? [08:53] ok ... stupid question... but It's my first time in ubuntu ... and i don't know how is it.. [08:53] you can do whatever you want, but make-kpkg is prefered [08:54] ok I understand .-... make-kpkg [08:54] BenC: Is that in the archive? [08:55] just uploaded today, so give it a few hours [08:55] Ok [08:55] I assume you are getting an oops about "BUG in ...ieee80211"? [08:55] Yup === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel === zooko [n=user@blk-215-95-202.eastlink.ca] has joined #ubuntu-kernel [09:49] 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] [09:53] zooko: Is there a module for it? Anything in dmesg? [09:57] There is a sata_promise module loaded. [09:57] /var/log/syslog:Jan 19 13:33:13 yumyum kernel: [ 37.708288] sata_promise 0000:00:08.0: version 1.03 [09:57] [09:57] "1.03" is the version of the promise bios. Not sure if that is the same number as in my syslog there. [10:10] modprobe sd_mod [10:12] no output. sd_mod now appears in the output of lsmod. [10:12] It might or might not have been in lsmod before that. === zooko is now known as zookofamilytime [10:34] are the drives connected sata drivers, or just ata? [10:35] just so happens that I got 4 promise 150 SATA controller cards in the mail from a very nice user today :) [10:35] 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] 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? === makx [n=max@baikonur.stro.at] has joined #ubuntu-kernel [11:12] tkup: explain how you can't use it [11:12] is it showing as unresolved when you load the module? [11:12] if so, that's because the functions aren't exported for module use (with EXPORT_SYMBOL()) [11:14] 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] you can add the EXPORT_SYMBOL to the file where the function is, and recompile the kernel [11:14] or link against that module that implements it,,, [11:15] tkup: Well, the obvious answer is to export it yourself, and persuade the kernel maintainers that it's needed by your code. [11:15] but you really should email linux-kernel@vger.kernel.org to see if your use of the function is correct or not [11:15] 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] 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] 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] I wouldn't reimplement the function (could create compatibility problems later on) [11:17] really, you should email l-k about the function you are using, if you are interested in releasing the module [11:18] see what they say about it, and maybe they could suggest the right way to handle it [11:18] I guess I could do what you said for starters and see if the module is interested before I write lkml [11:18] BenC, I'll email lkml and see if I should be using it at all [11:19] thanks [11:20] np [11:49] sweet, I got pata working on the sata_promise driver