[00:13] <mekius> Anyone know if pata_via is going to be reenabled in the Ubuntu kernels in the near future?
[00:24] <mekius> If anyone is around, how is it determined whether to load ide-generic?  We have a chipset which doesn't work with the via28xxx module, but loading ide-generic makes the drive appear.  ide-generic is obviously not ideal, but at least it works.  Shouldn't this load if no other module loads for a piece of hardware?
[00:24] <mekius> This is why I ask about pata_via since I'm assuming it will autoload
[00:32] <Kano> hi, could somone fix the powerpc build of 2.6.24? it did not find a modules file
=== asac_ is now known as asac
=== clever is now known as clever[rev]
=== \sh_away is now known as \sh
[07:25] <kraut> moin
=== clever[rev] is now known as clever
=== \sh is now known as \sh_away
[16:58] <tseliot> BenC are you there?
[16:59] <tseliot> I'm trying to get the nvidia driver to work with DKMS however the compilation fails
[17:00] <tseliot> here are the two files I had to add to debian/ :
[17:00] <tseliot> http://albertomilone.com/ubuntu/nvidia-kernel-source.postinst
[17:00] <tseliot> http://albertomilone.com/ubuntu/nvidia-kernel-source.prerm
[17:00] <tseliot> and this is the modified debian/rules:
[17:00] <tseliot> http://albertomilone.com/ubuntu/rules
[17:01] <BenC> tseliot: it fails to compile in the postinst?
[17:01] <tseliot> yep
[17:02] <BenC> what's the failure message?
[17:02] <tseliot> this is the command which the dkms should execute:
[17:02] <tseliot> echo "MAKE[0]=\"export IGNORE_XEN_PRESENCE=1; make -C /usr/src/nvidia-${nv_drv_choice}/ -f Makefile.kbuild SYSSRC=/usr/src/linux-headers-${flavours} KBUILD_PARAMS="-C /usr/src/linux-headers-${flavours}" module\""
[17:03] <tseliot> if you need the exact error I can log out, install the generated driver and reproduce the problem
[17:03] <BenC> I can't really help you without knowing what the actually error is
[17:03] <tseliot> ok, I'll be right back with the error
[17:35] <tseliot> BenC here is what happens when I install nvidia-kernel-source
[17:35] <tseliot> Unpacking nvidia-new-kernel-source (from .../nvidia-new-kernel-source_100.14.23+2.6.22.1_i386.deb) ...
[17:35] <tseliot> Setting up nvidia-new-kernel-source (1:100.14.23+2.6.22.1) ...
[17:35] <tseliot> Adding Module to DKMS build system
[17:35] <tseliot> Doing initial module build
[17:35] <tseliot> Error! Bad return status for module build on kernel: 2.6.22-14-generic (i686)
[17:35] <tseliot> Consult the make.log in the build directory
[17:35] <tseliot> /var/lib/dkms/nvidia/100.14.23/build/ for more information.
[17:35] <tseliot> Installing initial module
[17:35] <tseliot> Error! Could not locate nvidia.ko for module nvidia in the DKMS tree.
[17:35] <tseliot> You must run a dkms build for kernel 2.6.22-14-generic (i686) first.
[17:35] <tseliot> Done.
[17:35] <tseliot> now I'll paste the real error from the log
[17:37] <tseliot> DKMS make.log for nvidia-100.14.23 for kernel 2.6.22-14-generic (i686)
[17:37] <tseliot> Mon Dec 17 18:34:23 CET 2007
[17:37] <tseliot> make: Entering directory `/usr/src/nvidia-100.14.23'
[17:37] <tseliot> make: Nothing to be done for `/usr/src/linux-headers-2.6.22-14-generic'.
[17:37] <tseliot> NVIDIA: calling KBUILD...
[17:37] <tseliot> make CC=cc -C modules
[17:37] <tseliot> make: Entering an unknown directory
[17:37] <tseliot> make: *** modules: No such file or directory.  Stop.
[17:37] <tseliot> make: Leaving an unknown directory
[17:37] <tseliot> NVIDIA: left KBUILD.
[17:37] <tseliot> nvidia.ko failed to build!
[17:37] <tseliot> make: *** [module] Error 1
[17:37] <tseliot> make: Leaving directory `/usr/src/nvidia-100.14.23'
[17:38] <tseliot> BenC this is all it says. Ideas?
[17:38] <BenC> ok, next time, use pastebin :)
[17:38] <tseliot> sure :P
[17:39] <BenC> -C modules
[17:44] <tseliot> BenC ok this is the only line of the new error
[17:44] <tseliot> make: *** modules: No such file or directory.  Stop.
[17:46] <BenC> well, it's doing -C in the wrong place
[17:48] <tseliot> the nvidia kernel source package should put the content of the former nvidia source tarball into /usr/src/nvidia-100.14.23
[17:50] <tseliot> BenC here is the content of that folder:
[17:50] <tseliot> http://pastebin.com/m6c3fa512
[17:52] <tseliot> BenC and here's the content of the dkms.conf:
[17:52] <tseliot> http://pastebin.com/d769a1430
[18:00] <mekius> Hi, anyone here able to tell me why the pata_via driver is not included in the kernel?  Also is there an easy way to build a single module without rebuilding the entire kernel so we can just package this module?
[18:05] <rtg_> mekius: hardy? 'CONFIG_PATA_VIA is not set' might just be  an oversight.
[18:06] <mekius> rtg_: On gutsy kernel, 2.6.22-14
[18:07] <mekius> I have read there were issues with it during dapper/edgy, but haven't found any info on it from feisty/gutsy
[18:07] <mekius> I saw some updates to it as recent as 2.6.22-6
[18:07] <rtg_> mekius: dunno. you'll have to rebuild the kernel and experiment with it.
[18:07] <mekius> ok, I will try it out
[18:08] <rtg_> mekius: just so you know, the earliest opportunity to get it enabled by default will be for Hardy.
[18:08] <mekius> Yes, I assumed was the case
[18:08] <mekius> I have 3 VIA chipsets to test against, so I'll be able to provide some testing data
[18:09] <mekius> Hopefully all goes well as we are having issues with a chipset that isn't supported by the old pata driver and ide-generic doesn't load by default to cover it
=== \sh_away is now known as \sh
[18:18] <mekius> rtg_: Is there anywhere that I could read why the module was disabled?
[18:18] <cheguevara> damn the new linux-restricted-modules-2.6.24 FTBFS again
[18:18] <rtg_> mekius: perhaps search LP? BenC was dealing with pata stuf f last time.
[18:19] <mekius> rtg_: I work for gOS and have contacts at VIA who I'm trying to get to be more open and write their drivers in the community, so any information on what is broken would be good :)
[18:19] <mekius> rtg_: OK, I'll look around
[18:19] <BenC> mekius: I believe there is a bug about this...the libata-pata driver doesn't work as well as the ide driver, or something along those lines
[18:20] <tseliot> BenC: any ideas? The nvidia-new-kernel-source package I made seems to contain the same files as Mandriva's equivalent nvidia-dkms package...
[18:21] <BenC> mekius: I believe we disabled the pata-via driver because it was getting broken when host-protected-area was being ignored
[18:21] <mekius> BenC: Ok, I will dig around, just unfortunate since we have some newer hardware and they are begging for it to be supported heh.
[18:22] <BenC> tseliot: sounds to me like the proper vars aren't getting passed to the underlying build
[18:22] <mekius> BenC: Do you know if anyone has attempted to fix these issues, or will they still exist if I build it manually?
[18:23] <mekius> BenC: I'll look around launchpad, like I said I saw an update in 2.6.22-6 for it, but nothing after that
[18:23] <mekius> Also some misc updates before that revision as well
[18:24] <BenC> mekius: sad part is, that was disabled because of feisty, and it seems we never tried re-enabling it to see if it was still broken
[18:24] <BenC> so it may work, we just don't know
[18:25] <rtg_> mekius: if you saw updates in 2.6.22.Y, then they are also upstream.  You might try the current 2.6.24-rc kernel.
[18:25] <tseliot> BenC: yes, I know, but how are those variables passed in the official debian/rules you made?
[18:25] <mekius> BenC: Well I can test with a few chipsets and report back.  I will let you know how well it works.
[18:25] <mekius> BenC: I realize that testing is hard without the hardware around :)
[18:26] <BenC> tseliot: check the rules file, I don't recall off the top of my head
[18:26] <mekius> rtg_: Is that in the Hardy repo?
[18:26] <rtg_> mekius: yep, but you'll have to enable the CONFIG option.
[18:26] <BenC> mekius: any testing you can provide is very much appreciated
[18:27] <rtg_> mekius: I can build a CONFIG_PATA_VIA in about 20 minutes one if you want to test.
[18:27] <mekius> rtg_: Sry, I'm not all that familiar with Ubuntu, I do this when I install the package?
[18:28] <mekius> BenC: Can do, I need to test anyway, so might as well try to get this working upstream :)
[18:29] <mekius> rtg_: Does it just run make menuconfig during install if I set evn var CONFIG=true?
[18:29] <rtg_> mekius: um, its a little more involved then that. gimme a few minutes....
[18:29] <mekius> rtg_: ok, thx
[18:33] <tseliot> BenC: this is the line you use in your rules:
[18:33] <tseliot> $(ROOT_CMD) make -C $(builddir)/$$i/nv-new -f Makefile SYSSRC=/usr/src/linux-headers-$$i KBUILD_PARAMS="-C /usr/src/linux-headers-$$i SUBDIRS=$(builddir)/$$i/nv-new" module;
[18:35] <BenC> tseliot: I have to be honest, I've never worked with dkms, so I don't know how to set it up to pass those vars down to the sub-build
[18:35] <BenC> tseliot: mdomsch would be the guy to talk to
[18:36] <tseliot> BenC: I really appreciate your honesty. I'll go bug mdomsch then ;)
=== \sh is now known as \sh_away
=== \sh_away is now known as \sh
[19:08] <rtg_> mekius: http://people.ubuntu.com/~rtg/linux-image-2.6.24-2-generic_2.6.24-2.3_i386.deb-pata-via
[19:09] <mekius> gah, browser tries to load it heh
[19:10] <mekius> wget :)
=== chuck__ is now known as zul
[19:38] <mekius> rtg_: Is that just a .deb then?
[19:39] <rtg_> mekius: yes. download it, then 'sudo dpkg -i linux-image-2.6.24-2-generic_2.6.24-2.3_i386.deb-pata-via'
[19:39] <mekius> yeah
[19:41] <reynaldo> rtg_ hi, can I stole you a minute?
[19:41] <rtg_> reynaldo: yes?
[19:42] <mekius> rtg_: going to take a bit of work since i need to install it via a chroot into the system I installed onto the harddrive.  Is this going to cause conflicts with the modules in the linux-ubuntu-modules package?
[19:43] <rtg_> mekius: you need to be on bare metal in order to install a kernel. A chroot isn't gonna test your VIA disk problems.
[19:44] <rtg_> mekius: and no, the modules installed are completely separate.
[19:45] <mekius> rtg_: well what i'll do is install the kernel to the hard drive and then reboot to the hard drive, only option :/
[19:45] <mekius> can't get booted into the hard drive copy, well maybe if i could load ide-generic in the initrd
[19:45] <mekius> if this doesn't work, i'll try that
[19:45] <rtg_> mekius: I see. then that may be the only way.
[19:46] <mekius> rtg_: Yeah, I'm having all kinds of fun, can't you tell :)
[19:46] <rtg_> mekius: yep - its a bitch when your base drivers don't work.
[19:48] <mekius> indeed
[19:48] <rtg_> reynaldo: I don't have a Freenode registered nick. You'll have to use email.
[19:49] <mekius> ide-generic is so slow too, took over an hour to install heh
[19:51] <rtg_> mekius: one of the features I hope our installer guys figure out is a way to blow an ISO onto a USB drive. It really speeds things up.
[19:51] <reynaldo> rtg_: ok, sending it over, thanks a lot.
[19:52] <mekius> rtg_: :)
[19:54] <mekius> rtg_: wish me luck heh
[19:55] <rtg_> mekius: hopefully it won't trash your drive, which is a real possibility with the protected area stuff.
[19:55] <mekius> rtg_: Just a test system, no important date
[19:55] <mekius> data*
[19:57] <rtg_> mekius: I would expect to work on a fresh install, but an upgrade from a driver that honors HPA to a driver that does not is surely gonna trash something.
[19:57] <mekius> rtg_: I think it's booting :D
[19:58] <mekius> still waiting for it, but it has made it farther then before
[19:58] <kylem> rtg_, BenC, i was going through old photos and thought you might like this: http://www.flickr.com/photos/__kyle/2117175970/in/set-72157603479056297/
[19:59] <mekius> rtg_: So the new driver doesn't support something important is what you are saying?
[19:59] <mekius> rtg_: Well it booted fine without destroying anything :D
[19:59] <mekius> rtg_: This is good news for me heh
[19:59] <rtg_> kylem: man, that seems like awhile ago.
[20:00] <kylem> http://www.flickr.com/photos/__kyle/2116459477/in/set-72157603479056297/
[20:00] <kylem> it was. ;-)
[20:00] <BenC> kylem: sweet
[20:00] <BenC> it was only a little more than 6 months ago
[20:00]  * BenC loved the "Follow Me" truck
[20:01] <BenC> I have the other side to the dueling cameras photo
[20:02] <mekius> rtg_: Did you see any updates to pata_via since 2.6.22-14?
[20:02] <rtg_> mekius: can you paste the 'lspci -vvnn' output in http://paste.ubuntu-nl.org/. Lets be sure its doing what we think.
[20:02] <mekius> rtg_: I didn't find anything while searching
[20:02] <mekius> rtg_: ok
[20:03] <rtg_> mekius: I haven't been looking at the .22 tree since we stopped Gutsy development.
[20:03] <mekius> ok
[20:04] <mekius> hmm, ok, we may have some issues, can't gurantee they are due to this module exactly, but definitely having problems
[20:04] <BenC> http://www.flickr.com/photos/__kyle/2117196194/in/set-72157603479056297/
[20:05] <BenC> kylem: ^^ it's not too often you get to see what you'll look like in 40 years :)
[20:05] <rtg_> mekius: for example?
[20:05] <kylem> hehe
[20:05] <rtg_> BenC: yuk, yuk.
[20:05] <mekius> Well getting a lot of graphics corruption, might be due to files not being read of the disk?
[20:05] <mekius> happens when i moved windows mostly
[20:06] <rtg_> mekius: that could be VIA agp.
[20:07] <rtg_> mekius: its unlikely to be a disk issue.
[20:07] <mekius> Well we are using openchrome drivers, so maybe an incompatibility :/
[20:08] <mekius> rtg_: paste.ubuntu-nl.org/48573
[20:11] <rtg_> mekius: looks right. the 0581 PCI device ID is specifically supported.
[20:12] <reynaldo> rtg_: sent, thanks again.
[20:15] <reynaldo> BenC: hi there ben, gently pinging again. still waiting for your answer. I understand you must be _uterly_ bussy but I just dont want you to forget or even worst, to think I forget about it.
[20:16] <BenC> reynaldo: I'll catch it in the morning. Sorry it's taking so long
=== \sh is now known as \sh_away
[20:17] <BenC> wtf
[20:17] <BenC> I can't see what is causing this:
[20:17] <BenC> dpkg-genchanges: warning: duplicate files list entry for package xorg-driver-fglrx (line 23)
[20:17] <BenC> that's while building lrm on i386...can't reproduce it locally
[20:18] <reynaldo> BenC: no need to be sorry, we are all just trying to help ;) thanks again!
[20:25] <mekius> rtg_: Ah, might be due to the via drm driver getting loaded
[20:26] <rtg_> mekius: it does sound like a graphics issue.
[20:26] <mekius> yeah, i'll try to unload it, but the terminal is hosed heh
[20:26] <mekius> having to type blind
[20:28] <mekius> Good thing I know how the tab completion behaves like the back of my hand :0
[20:28] <mekius> :)
[20:33] <mekius> rtg_: Is is possible to build and distribute the pata_via module in a seperate package
[20:34] <rtg_> mekius: yes, but you'll have to tell me what the advantages are.
[20:34] <mekius> rtg_: Hmm, seems to only get corrupted when shaped windows come into play
[20:34] <rtg_> mekius: I think its the only driver that supports you PCI IDs
[20:35] <mekius> rtg_: Well we would just use it on our machines for now
[20:35] <mekius> I've only tested it on the one machine
[20:35] <mekius> i can test on another quick and see how that does
[20:36] <mekius> Have another notebook with 1106:0571
[20:51] <somerville32> rtg_, did you apply my patch?
[20:53] <rtg_> somerville32: this one? http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=c0bb64a179acfab520ef9050eb712afd715f6866
[20:54] <somerville32> No, the one about the userspace typedefs being hidden behind #ifdef __KERNEL__
[20:57] <rtg_> somerville32: did you send it to the kernel team mailing list 'cause I don't see it (which doesn't mean I might not have deleted it by accident)
[20:58] <somerville32> rtg_, Yes I did send it
[20:58] <somerville32> but I forgot to set the subject line
[20:59] <rtg_> somerville32: did you ever see it appear? The SPAM filter might have eaten it.
[21:00] <somerville32> I'll check the archive
[21:00] <somerville32> It is in the archive
[21:00] <somerville32> https://lists.ubuntu.com/archives/kernel-team/2007-December/001946.html
[21:01] <mekius> rtg_: Do you think we'll have issues shipping pata_via or would my test here prove that it works ok?
[21:03] <rtg_> mekius: I would like to see at least a couple of unique PCI IDs tested. I need to research just what the issues were, 'cause if they were HPA then there might be some update issues.
[21:04] <mekius> rtg_: Ok, I will try to test on a couple more computers today and get back to you.  They should all have different VIA IDE controllers
[21:04] <mekius> Two are laptops, one's a desktop.
[21:04] <mekius> I'll have to double check, the others might be using sata
[21:04] <rtg_> mekius: send the results to the kernel team list so it gets a little wider distribution.
[21:04] <mekius> Ah ok, will do
=== \sh_away is now known as \sh
=== \sh is now known as \sh_away
[21:13] <somerville32> rtg_, Did you find the e-mail?
[21:15] <mekius> rtg_: Where can I find the list info?
[21:15] <rtg_> somerville32: yes. I think I postponed dealing with it until I saw what happened upstream. However, its simple enough I'll go ahead and apply it (after build testing). If it causes on the next rebase it'll be simple enough to fix.
[21:16] <somerville32> rtg_, Will you be able to upload today?
[21:17] <rtg_> somerville32: no. its not likely until after the the 1st. Canonical is pretty much shut down all of next week.
[21:17] <somerville32> The 1st of January?
[21:17] <rtg_> somerville32: yes.
[21:17] <rtg_> mekius: https://lists.ubuntu.com
[21:17] <somerville32> rtg_, I needed the fix for Alpha 2.
[21:17] <mekius> rtg_: thx
[21:18] <rtg_> somerville32: its already too late. Alpha2 is being baked this week.
[21:19] <somerville32> Then I guess I'll just have to patch xfce4-battery-plugin for now
[21:19] <mekius> rtg_: If I verify that it works for a few devices would it be able to go into the Hardy alphas?
[21:20] <rtg_> mekius: Alpha3 https://wiki.ubuntu.com/HardyReleaseSchedule
[21:21] <mekius> rtg_: k
[21:29] <tseliot> BenC: I just wanted to let you know that thanks to mdomsch and to your help I got DKMS + NVIDIA to work!!!
[21:36] <BenC> tseliot: excellent
[21:41] <tseliot> BenC: I was successful but I had to edit the dkms.conf manually.
[21:42] <tseliot> However I can't seem to escape the dollar sign as I usually do
[21:42] <tseliot> this command in the debian/rules
[21:42] <tseliot> echo "MAKE[0]=\"make module KERNDIR=/lib/modules/\$kernelver IGNORE_CC_MISMATCH=1 SYSSRC=\$kernel_source_dir\"" >> $(CURDIR)/debian/dkms.conf
[21:42] <tseliot> becomes:
[21:42] <tseliot> MAKE[0]="make module KERNDIR=/lib/modules/\ernelver IGNORE_CC_MISMATCH=1 SYSSRC=\ernel_source_dir"
[21:43] <tseliot> and I don't know why $kernelver becomes \ernelver
[21:43] <tseliot> even if I escape the dollar sign with \$ i.e. \$kernelver
[21:45] <rtg_> tseliot: try $(kernel_source_dir) 'cause I think its a make macro.
[21:48] <tseliot> rtg_: mdomsch told me not to expand the variable
[21:49] <rtg_> tseliot: ok, then how about $$kernelver and $$kernel_source_dir
[21:51] <tseliot> rtg_: I get this:
[21:51] <tseliot> MAKE[0]="export IGNORE_XEN_PRESENCE=1; make -C modules /usr/src/nvidia-100.14.23/ -f Makefile.kbuild SYSSRC=/usr/src/linux-headers-2.6.22-14-generic KBUILD_PARAMS=-C
[21:51] <rtg_> tseliot: ok, I don't know enough about the layers of shell scripts and make files.
[21:52] <tseliot> neither do I. thanks for trying ;)
[22:39] <tseliot> rtg_, BenC: I solved it!
[22:39] <tseliot> $$""kernelver
[22:39] <tseliot> $$ gives $
[22:39] <tseliot> however $$kernelver is interpreted as a variable and it's not escaped
[22:40] <tseliot> $$""kernelver means $ + nothing + kernelver
[22:40] <tseliot> yay!
=== cheguevara_ is now known as CheGuevara