| osmosis | could be this.. https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/113532 | 00:02 |
|---|---|---|
| ubotu | Launchpad bug 113532 in linux-source-2.6.20 "kernel 2.6.20 disk write performance much slower than 2.6.17" [Undecided,Confirmed] | 00:02 |
| osmosis | yah, looks like that bug has stuck around. | 00:07 |
| osmosis | When I use dd to create a 1G, my system comes to a hault. Should disk IO really send my load average up to 50? | 02:09 |
| === gnomefre1k is now known as gnomefreak | ||
| === thegodfather is now known as fabbione | ||
| kraut | moin | 08:25 |
| ackrcvd | Hi, I need to recompile the b43 driver in a default installation of 8.04... Do I need to recompile the entire kernel or just the b43 module? | 12:33 |
| ackrcvd | No one knows? | 12:54 |
| alex_joni | I would try recompiling the module only | 13:03 |
| ackrcvd | How would I go about doing that? | 13:12 |
| ackrcvd | I assume I only need linux-headers for this? | 13:12 |
| ackrcvd | How do I get the sources for the module... /lib/modules/2.6.24-16-generic/kernel/drivers/net/wireless/b43/b43.ko is the module I'm trying to recompile | 13:13 |
| alex_joni | ackrcvd: why do you need to recompile it? | 13:14 |
| ackrcvd | Applying patches suggeted to work with aircrack-ng suite | 13:15 |
| alex_joni | ackrcvd: you need to get the source from somewhere.. so probably apt-get source linux-image-2.6.24-16-generic | 13:16 |
| alex_joni | but it won't be a trivial thing to do | 13:16 |
| ackrcvd | So I would be required to rebuild the entire kernel? | 13:17 |
| alex_joni | probably | 13:17 |
| alex_joni | but you'll only use the module | 13:17 |
| ackrcvd | What I wanted to know was, If I had to follow the instructions on https://help.ubuntu.com/community/Kernel/Compile OR I could just recompile the b43 module | 13:17 |
| alex_joni | if you can get the exact same source, and can compile only the module, then that would probably be fine | 13:18 |
| alex_joni | (but I have no idea how you could/should do that) | 13:18 |
| ackrcvd | alex_joni: Cool... Thanks | 13:19 |
| abogani | alex_joni: How proceed your work about Ubuntu rtai kernel flavour? | 13:34 |
| alex_joni | abogani: pretty good :) | 13:36 |
| alex_joni | abogani: managed to build packages, put them in a repo, and built a live cd | 13:36 |
| abogani | alex_joni: Do you have plan to push your work in Ubuntu? | 13:37 |
| alex_joni | abogani: hmm.. didn't think about it | 13:39 |
| alex_joni | abogani: would it be usefull? | 13:41 |
| alex_joni | (gotta run to lunch for 30min, will be back though) | 13:41 |
| abogani | Oh Yes. | 13:41 |
| abogani | alex_joni: Anyway i hope to add Comedi into lum for Intrepid Ibex. I suppose that is a news for you. :-) | 13:41 |
| abogani | Good lunch! | 13:41 |
| abogani | :-) | 13:41 |
| alex_joni | abogani: cool, let me know if I can help | 13:41 |
| abogani | Ok | 13:41 |
| alex_joni | abogani: so far we tried to stick with LTS's | 13:42 |
| === asac_ is now known as asac | ||
| alex_joni | abogani: back | 14:16 |
| === ogasawara__ is now known as ogasawara | ||
| === gnomefre1k is now known as gnomefreak | ||
| === gnomefre1k is now known as gnomefreak | ||
| === gnomefre1k is now known as gnomefreak | ||
| r1ddl3r | Hello, i'm trying to make a developing tool for programming the 8051 series of microcontrollers, since i dont have deep knowledge on Linux is there any1 willing to answer some questions?? (Or i'm on the wrong channel again?? ) | 19:52 |
| r1ddl3r | lol dont swarm me with answers ppl, rofl | 19:55 |
| r1ddl3r | oke imma let ya to yer jobs... | 19:55 |
| mkrufky | rtg: bug # 220857 marked as no-fix will make Ubuntu no longer the distro of choice for v4l / dvb developers | 20:19 |
| mkrufky | and the bot doesnt notice... again... bug 220857 | 20:20 |
| ubotu | Launchpad bug 220857 in linux-ubuntu-modules-2.6.24 "linuxtv.org mercurial repository wont build against hardy kernel due to "disagrees about version of symbol videobuf_*" [Low,Won't fix] https://launchpad.net/bugs/220857 | 20:20 |
| mkrufky | this is because ubuntu has copies of cx88 and saa7134 in the ubuntu/media tree, causing conflicts | 20:20 |
| rtg | mkrufky: the media modules are built against the ALSA headers in LUM, not against the kernel. | 20:21 |
| mkrufky | why cant you place them in drivers/media ?? | 20:22 |
| mkrufky | that would avoid this issue | 20:22 |
| rtg | mkrufky: they are direct copies of the kernel sources from drivers/media. They have to be built outside the kernel environment in order to get the correct ALSA headers. | 20:23 |
| mkrufky | ok, but users will continue to attempt to get driver support for new devices using linuxtv.org sources, and after they install the sources and modprobe the new modules, the wrong versions are picked up | 20:24 |
| mkrufky | users dont know that thety have to delete the ubuntu versions first | 20:25 |
| mkrufky | and we cant script that into the v4l/dvb build system, because we build on all distros -- we're not ubuntu-specific | 20:25 |
| rtg | mkrufky: how about developing DKMS packages that use the kernel Makefile ? We have patches in that makefile that enforce the header file inclusion order. | 20:26 |
| mkrufky | im not familiar with DKMS packages | 20:27 |
| rtg | mkrufky: mdomsch from Dell developed it (or is the current maintainer) | 20:27 |
| mdomsch | good day | 20:27 |
| mkrufky | the linuxtv.org repositories are where v4l/dvb devel goes on for upstream kernels, and we put forth a ton of effort such that the tree is backwards compatable with older kernels, so that users can get driver support for new hardware on distro kernels | 20:28 |
| mkrufky | rtg: it doesnt do me any good to develop a DKMS package if i have to update it every day, rtg | 20:28 |
| rtg | mkrufky: we have somewhat the same problems, e.g., how to backport ALSA without borking external ALSA dependent drivers. | 20:28 |
| mdomsch | mkrufky, http://linux.dell.com/dkms/dkms.html if you're interested | 20:29 |
| mkrufky | people that are building their new v4l / dvb modules can build those modules against the LUM headers, if they like | 20:30 |
| mkrufky | then they can use the new drivers and it will work with new alsa | 20:30 |
| mkrufky | thats no big deal | 20:30 |
| mkrufky | the problem is, they dont even have this option with the current situation | 20:30 |
| rtg | mkrufky: I'm not sure what you're trying to tell me, but follow up with smb (who is online and did the work). I gotta take off. | 20:31 |
| mkrufky | DKMS looks nice, but linuxtv.org has its own backwards-compat solution, this is not needed for us | 20:32 |
| mkrufky | smb? | 20:32 |
| smb | me | 20:32 |
| mkrufky | ok, ttyl, rtg | 20:32 |
| mkrufky | oh, hi, smb | 20:33 |
| tseliot | mkrufky: why did you say that you would have to update a DKMS package every day? | 20:33 |
| mkrufky | as i was saying. bug 220857 marked as no-fix will make Ubuntu no longer the distro of choice for v4l / dvb developers | 20:33 |
| ubotu | Launchpad bug 220857 in linux-ubuntu-modules-2.6.24 "linuxtv.org mercurial repository wont build against hardy kernel due to "disagrees about version of symbol videobuf_*" [Low,Won't fix] https://launchpad.net/bugs/220857 | 20:33 |
| smb | mkrufky: Hi. I looked into that when we had problems with the cx88 and saa71.. driver. | 20:33 |
| mkrufky | tseliot: i represent the v4l / dvb kernel developers | 20:34 |
| mkrufky | tseliot: with digital television cards, distro kernels NEVER have support for the cards being sold today | 20:34 |
| smb | mkrufky: I followed just loosely. let me have a skip through the baglog | 20:34 |
| mkrufky | tseliot: so users must upgrade to the new drivers in the repositories hosted on linuxtv.org | 20:34 |
| mkrufky | ok, smb | 20:34 |
| mdomsch | mkrufky, DKMS exists exactly because each project had its own backport solution; each different; many broken. | 20:36 |
| mdomsch | DKMS is the underpinning of the work of the Linux Foundation Driver Backport Working Group | 20:36 |
| mkrufky | mdomsch: i, as a developer, need to run my developer sources on ubuntu | 20:36 |
| mkrufky | i must not run a package | 20:37 |
| mdomsch | and is required for all kernel modules Dell ships that aren't already on the distro media | 20:37 |
| mkrufky | i need to run the sources WITH the bugs | 20:37 |
| mkrufky | so that i can fix those bugs | 20:37 |
| mdomsch | sure... | 20:37 |
| mdomsch | DKMS can produce packages (debs, rpms, etc) but that's not it's core usefulness | 20:37 |
| tseliot | mkrufky: once you've set up the packaging scripts for DKMS you can create a script which replaces all the files with their updated versions and builds a new package (a shell script would be enough) | 20:38 |
| mkrufky | you are approaching this problem from a "how do we support the users" POV | 20:38 |
| mkrufky | but i am raising a different issue | 20:38 |
| mkrufky | i am raising, "how do we support the developers" POV | 20:38 |
| smb | mkrufky: The problem we faced was the need of a more recent ALSA driver to support newer cards. So ALSA was moved into lum to be independent. Unfortunately this raises problems for drivers that are to be compiled agains alsa headers. | 20:38 |
| mdomsch | yes | 20:38 |
| mkrufky | users, yes -- would be nice if somebody would make a DKMS package for v4l/dvb modules, regularly | 20:38 |
| mkrufky | but that doesnt help me | 20:38 |
| mdomsch | dkms lets you have lots of versions of the source of a module | 20:39 |
| mdomsch | e.g. /usr/src/somemodule-version1 | 20:39 |
| mdomsch | -version2 | 20:39 |
| mdomsch | -version3 | 20:39 |
| mdomsch | and track what's installed | 20:39 |
| mdomsch | I use it for development all the time | 20:39 |
| mkrufky | will somebody volunteer to maintain these such packages for ubuntu users that require the latest v4l-dvb modules? | 20:41 |
| smb | mkrufky: What the v4l-dvb modules would need is, optionally look into lum headers first. I know this would then be ubuntu specific but once in place would need no specific maintenance | 20:44 |
| mkrufky | please see the launchpad bug report -- LUM headers are missing things in the linux-headers and the source tree wont build against LUM, alone | 20:44 |
| mkrufky | to make a long story short -- i work for a company that makes these tv products, and am slowly converting my co-workers into linux users / linux developers. in the past, i can give them an ubuntu cd, tell them to pull from my linuxtv tree and build it. now, its not that simple any more, and it's easier for me to give them a fedora cd | 20:49 |
| smb | mkrufky: Yes the "right" headers are the linux-headers-lum-* ones. These have to be installed and the include path must use them before the kernel headers | 20:49 |
| mkrufky | isnt there a way to look in ubuntu/media/foo *after* not finding said module in the standard kernel first? | 20:50 |
| smb | mkrufky: It is not only the problem of the modules. Since ALSA is in the kernel but not always the most current. It cannot be simply overridden by replacing the modules. As you experienced all external modules will try to use the kernel headers. Which do not necessarily match | 20:53 |
| mkrufky | i see it as important that the "default" kernel have all modules working correctly | 20:53 |
| mkrufky | but once i build my own v4l / dvb modules from source, i deserve for alsa to be broken | 20:54 |
| mkrufky | and that is my fault, not ubuntu's | 20:54 |
| mkrufky | the fact is, i dont even have that opportunity, now | 20:54 |
| mkrufky | (without first removing those from ubuntu/media/foo) | 20:54 |
| mkrufky | and users wont know how to do it ... | 20:54 |
| mkrufky | now, if a user goes to build his own v4l/dvb modules, that user probably doesnt need alsa to work | 20:55 |
| mkrufky | if that user needs alsa to work, then that user has to simply wait for the next ubuntu kernel | 20:55 |
| smb | mkrufky: I see your point. But we also saw with the cx88 driver (as an example). That this requires alsa to work and produces quite awful problems when compiled against the kernel. So it might only partially help if those modules would sit somewhere else | 20:57 |
| mkrufky | it only requires alsa if the user needs DMA audio in analog mode | 20:57 |
| mkrufky | one can simply not use cx88-alsa | 20:58 |
| mkrufky | (it is blacklisted on my system) | 20:58 |
| mkrufky | cx88-alsa is a separate module, for exactly this reason | 20:58 |
| mkrufky | same goes for saa7134-alsa | 20:58 |
| smb | mkrufky: This might be true, but I had several users that required this and had unusable systems because of problems there. I agree the current situation is not good. The problem is to find a solution that is good for all. | 21:01 |
| mkrufky | ^^ the default installation should be a solution that is good for all | 21:02 |
| mkrufky | and we dont disagree, there | 21:02 |
| mkrufky | however...... | 21:02 |
| mkrufky | to fix this properly, you should do the following: | 21:03 |
| mkrufky | have cx88-alsa and saa7134-alsa disabled in the kernel build | 21:03 |
| smb | mkrufky: should be | 21:03 |
| mkrufky | in the LUM build, you build cx88-alsa and saa7134-alsa against the LUM alsa headers, using the cx88 and saa7134 headers from the kernel | 21:03 |
| mkrufky | but build the base cx88 and saa7134 modules WITH the kernel | 21:03 |
| smb | mkrufky: Ok. I see the point. | 21:04 |
| mkrufky | i dont see why cx88xx cx8800 cx8802 and cx88-dvb are not built in-kernel | 21:05 |
| smb | mkrufky: So the video modules could be simply replaced when compiling externally | 21:05 |
| mkrufky | same applies to saa7134 and saa7134-dvb | 21:05 |
| mkrufky | yes, that is correct | 21:05 |
| mkrufky | they depend, of course, on the v4l and dvb core dependencies | 21:05 |
| mkrufky | such as videobuf-foo , dvb-core, and any tuner / demod i2c client / dvb_frontend modules, etc | 21:06 |
| smb | mkrufky: The question is there: does this include anything sound related? | 21:06 |
| mkrufky | the sound modules in question are cx88-alsa and saa7134-alsa | 21:07 |
| mkrufky | those can be built outside | 21:07 |
| mkrufky | the cx88 & saa713x drivers themselves do not depend on any sound stuff | 21:07 |
| smb | mkrufky: No, sorry. I meant the v4l dependencies. And I think this might have been a reson to move the whole drivers. It might have been not that clear. | 21:08 |
| mkrufky | ah | 21:08 |
| mkrufky | i try to make myself accessible to you guys -- you should please always feel free to email me with those types of questions | 21:09 |
| mkrufky | and i am not always as difficult as i am being today :-P | 21:09 |
| smb | mkrufky: Ok, I/we surely come back to that offer. ;-) | 21:09 |
| mkrufky | anyway, v4l has absolutely zero dependency on alsa | 21:09 |
| mkrufky | ok, cool :-) | 21:10 |
| mkrufky | dvb also -- zero dependency on alsa | 21:10 |
| pwnguin | i got a question about building upstream kernel git | 21:11 |
| TankEnMate | what is the major differences between a -server and a -generic kernel? | 21:11 |
| pwnguin | Warn for stack frames larger than (needs gcc 4.4) (FRAME_WARN) [1024] (NEW) ? | 21:11 |
| pwnguin | i appear to have gcc 4.2 -- do i need to set that to 0? | 21:12 |
| smb | mkrufky: Ok, I take that point and see what can be done. But at least I think I understood the problem and see whether this can be changed | 21:12 |
| TankEnMate | *shrug* read the source luke! :) | 21:12 |
| mkrufky | smb: ok, cool... | 21:13 |
| pwnguin | TankEnMate: last i knew there wasnt much of a difference; you could try making a diff of the two ^_^ | 21:13 |
| mkrufky | smb: thank you -- i appreciate looking into this... and so will the other v4l/dvb developers, and all my co workers ;-) | 21:13 |
| TankEnMate | pwnguin: tried that.. problem i am having doesn't seem to be related to an config changes that I could see.. | 21:15 |
| smb | mkrufky: I hope we can get a solution that is good for everyone (well maybe most ;-)) which is what we all want in the end. | 21:15 |
| mkrufky | yes, exactly | 21:15 |
| TankEnMate | pwnguin: only thing I can think is that the source code must be different... | 21:15 |
| TankEnMate | anyone here ever come across a kernel complaining about a initrd image is bad, when you know for certain that it is ok? | 21:16 |
| smb | pwnguin: I am guessing a bit there but it might be a compile option. Maybe something gcc4.2 just ignores. Or the makefiles just make sure it isn't used when using an oldr compiler. anyhow, if it compiles, I guess it should be ok | 21:18 |
| FooEnMate | ugh.. | 21:26 |
| FooEnMate | anyone had a problem with a kernel complaining that an initrd image was corrupt when you know for certain that it is ok? | 21:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!