[12:52] <kylem> BenC, ok, i dunno what's up with the ABI.
[12:52] <kylem> i have the same ABI breakage with / without these patches it seems.
[12:58] <BenC> odd...there's no ABI breakage in current git that I saw
[12:58] <BenC> unless there's some stuff I didn't pull yet
[01:00] <BenC> just two commits from pkl that aren't even related to libata
[01:00] <kylem> kvm seems to have jumbled about
[01:02] <BenC> yeah, I overrode kvm ABI
[01:02] <BenC> grep -v drivers/kvm/ from debian/abi/*/* :)
[01:02] <kylem> heh ouch.
[01:02] <BenC> pretty much a no-op if anything in there changes
[01:02] <kylem> http://people.ubuntu.com/~kyle/feisty/
[01:03] <BenC> that G965 fix rings a bell, pretty sure we have a bug about that, right?
[01:04] <BenC> +	u64			n_sectors_boot;	/* size of ATA device at startup */
[01:04] <BenC> there's the HPA ABI change...struct ata_device
[01:05] <BenC> lba48 bug looks important
[01:07] <kylem> yeah
[01:07] <kylem> 1sec, i'll fix the abi change there.
[01:11] <kylem> hmm, no way to avoid this really. doh.
[01:12] <kylem> can't we just force the abi until release and tell people who built their modules against in-devel feisty tough luck?
[01:37] <jbailey> kylem: I'd say that's probably possible until kernel freeze. =)
[01:38] <jbailey> But ISVs and such will probably start following along at that poitn.
[03:35] <defendguin> I was looking for some help with a bug that crept in between -12 and -13
[03:36] <defendguin> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/99648
[03:37] <defendguin> there was an MMC update in -13 referencing bug 93171
[10:18] <capiira> hi all i tried to compile my own kernel and downloaded the linux-source 2.6.20 and used the config-2.6.20-14-generic from /boot and now i have a big 230mb kernel :) and wonder why
[10:19] <capiira> that's my content http://paste.ubuntu-nl.org/15006/
[10:22] <capiira> i see that there is too much stuff compiled but i used the original .config file
[10:51] <capiira> so nobody a life?
[10:55] <ilmari> the mmc merge in 2.6.20-13 "broke" HAL (bug 99648)
[10:59] <capiira> :/ hmm my kernel did become 230mb big again
[11:00] <capiira> and i need USB_SUSPEND disabled for my scanner
[12:19] <capiira> still no nobody a life?
[12:19] <ilmari> no, we're all lifeless corpses
[12:20] <capiira> can you help me with my kernel compilation prob ?
[12:20] <capiira> maybe i forgot to do something important
[12:26] <capiira> i downloaded the ubuntu linux-source-2.6.20, untared, did a ln -s to /usr/src/linux, copied a lastest generic config to /usr/src/linux/.config, did a sudo make clean and menuconfig and loaded the config, saved it and compiled
[12:26] <capiira> it always become 230mb big
[12:27] <capiira> compiled using make-kpkg
[12:35] <capiira> no one know ?
[12:44] <cjwatson> capiira: looks like the modules aren't stripped
[12:58] <capiira> how so? can i change that in menuconfig?
[12:58] <capiira> its my first kernel compilation and im just doing it because i need USB_SUSPEND off
[01:01] <cjwatson> make INSTALL_MOD_STRIP=1
[01:01] <cjwatson> see Documentation/kbuild/makefiles.txt
[01:09] <capiira> thx
[02:04] <capiira> you know how to use that with make-kpkg?
[02:05] <capiira> or if its possible to simply write it into the makefile
[02:17] <capiira> i wrote INSTALL_MOD_STRIP := 1 into the makefile variable section lets see what will happen
[03:56] <defendguin> ilmari, have you had any luck lucking for the cause of the regression?
[03:57] <ilmari> defendguin: no, but I did get hold of a -12 kernel and have attached the udevmonitor output
[03:57] <defendguin> i saw that
[03:58] <ilmari> it's definitely the mmc merge that caused it, but I haven't had time to go through the details of the changes
[03:58] <ilmari> (at work ATM)
[03:58] <defendguin> ilmari, me too
[03:58] <defendguin> i had to install xchat here at work so i could try to steer someone into looking at it
[04:01] <defendguin> bug 99648 if anyone is watching
[04:10] <crimsun> defendguin: it doesn't seem like a critical regression from edgy or dapper, so it likely won't be addressed in the next week.
[04:11] <defendguin> it breaks everyone's card reader ....
[04:14] <crimsun> everyone's?
[04:14] <zul> or just yours?
[04:16] <mjg59> Everyone's
[04:16] <ilmari> hal doesn't pick up MMC card readers any more
[04:16] <ilmari> because it can't find the parent device from the class-based DEVPATH 
[04:16] <ilmari> it needs to be /devices/-based
[04:19] <cjwatson> MMC is fixable in a post-release update, I think
[04:23] <defendguin> if ubuntu were release and all card readers were not working that would most certainly be a black mark on and reviews that it gets
[04:24] <defendguin> any reviews*
[04:25] <BenC> the bug is convoluted...is there a suggested patch we can review?
[04:29] <BenC> defendguin: have you tried any patches to fix it?
[04:30] <defendguin> BenC, no i have not.  I am not aware of any patches that are available to fix this particular problem. 
[04:30] <BenC> mjg59: do you have any ideas on the issue?
[04:31] <mjg59> BenC: When you pulled the mmc tree, did you pull the for_linus branch or the main one?
[04:31] <BenC> mjg59: I'm pretty sure I pulled for-linus
[04:32] <BenC> and I was pretty sure I tested it afterwards because I have mmc on several laptops here
[04:33] <mjg59> Well, it's clearly changed the device structure in such a way that hal no longer picks it up
[04:33] <mjg59> Options are either alter hal or alter the kernel
[04:34] <BenC> altering hal may be easier to do
[04:34] <BenC> question is, can we alter hal in such as a way as to be compatible?
[04:34] <mjg59> No clue.
[04:36] <BenC> you got any pointers to what needs to change in hal for this to work?
[04:36] <mjg59> The udev output ought to give a pretty clear indication
[04:36] <BenC> I think I can afford enough beer for Tollef to let hal changes through before I can get a new kernel through
[04:36] <Mithrandir> heh
[04:38] <BenC> Mithrandir: what's the chances I can get this in for RC, or should I just worry about post-RC?
[04:38] <BenC> Mithrandir: I'll post a diff for you and cjwatson once I get it done, so you can review it
[04:39] <\sh> BenC: can you give me some details on https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/55495 ?
[04:39] <Mithrandir> BenC: RC, I don't think so.  post-RC, if the patch isn't too scary.
[04:39] <BenC> ok
[04:41] <BenC> \sh: Ug, 8 months ago, hard to say
[04:41] <BenC> \sh: No mention in dapper/edgy changelog for that bug #?
[04:41] <\sh> BenC: well, dapper / edgy are still having problems with it...(install media kernel)
[04:42] <BenC> it's only marked fix committed, so it may be in -proposed
[04:42] <BenC> which means no install media available
[04:42] <\sh> BenC: that's the problem...
[04:42] <\sh> and I can't test it, without having a running installation on this dl320s...;)
[04:43] <Mithrandir> \sh: netboot it?
[04:44] <\sh> Mithrandir: could be a solution if I had any network where the machine is. I really need to do a manual install...:( how can I tweak the server CD? ,-)
[04:44] <Mithrandir> \sh: documented on the wiki, just search for custom
[04:46] <BenC> this seriously looks like a bug in hal of some kind
[04:47] <BenC> DEVNAME=/dev/mmcblk0p1
[04:47] <BenC> DEVLINKS=/dev/disk/by-uuid/3639-3635 /dev/disk/by-label/ilMobile
[04:47] <BenC> it gets that far in -14, but doesn't do the mount
[04:47] <\sh> Mithrandir: for the alternate, old d-i cd?
[04:48] <Mithrandir> yes
[04:48] <\sh> Mithrandir: found it thx a lot :)
[04:50] <\sh> BenC: found it in 2.6.15-26.47 ... actually we need to create 6.06.2 ;)
[05:12] <\sh> Mithrandir: sorry to ask, but when I need to change the default (isolinux) boot kernel in /install/ , I only have to replace it with the kernel I need, right? what about initrd.gz, what is needed for initrd.gz of the alternate installer cd ?
[05:12] <Mithrandir> \sh: yes, you can just replace it with the kernel you need, but you should ideally grab both the kernel and the initrd from a build of d-i
[05:14] <\sh> Mithrandir: thinking about dapper, I just want to "update" the installer kernel..nothing else. and I think there is no d-i build for 2.6.15-26.47 or higher
[05:14] <\sh> or is there a d-i rebuild for every kernel update?
[05:15] <Mithrandir> no, but you can do one yourself
[05:15] <\sh> Mithrandir: standard pbuilder run of d-i, I think
[05:15] <Mithrandir> yes, just make sure you have the necessary repositories enabled
[05:16] <\sh> Mithrandir: main and restricted 
[05:16] <Mithrandir> well, and -updates and -proposed?
[05:17] <\sh> Mithrandir: -security is the right one ;) the kernel is in the -security repos
[05:17] <Mithrandir> well, that then.
[05:19] <\sh> Mithrandir: thx...trying
[05:25] <\sh> Mithrandir: forgot to update amd64.cfg to use 2.6.15-28-amd64-server kernel
[05:27] <ilmari> go BenC!
[05:40] <mjg59> BenC: I can give you a one line fix for the kernel re 99648
[05:40] <BenC> mjg59: Ok
[05:41] <mjg59> http://www.codon.org.uk/~mjg59/tmp/fix_sd.diff
[05:41] <mjg59> The alternative looks like quite a lot of work on hal
[05:43] <BenC> Mithrandir: would you be against a post-RC upload of the kernel with that one-liner fix (nothing from git)?
[05:45] <ilmari> mjg59: yay!
[05:45] <cjwatson> I would really quite like the squashfs fix from git, although I realise it's a bit scary at this point
[05:45] <mjg59> What's happening with the HPA stuff?
[05:45] <mjg59> That's sort of required
[05:47] <BenC> mjg59: right now, it's not even in our git repo, so it's doing nothing
[05:47] <mjg59> BenC: We can't release without it
[05:47] <kylem> i posted the patches yesterday, not wanting to step on people's toes
[05:48] <kylem> since everyone is trying to get bug fixes in right now..
[05:48] <BenC> kylem: if you feel they are tested well enough, then please put them in git
[05:48] <mjg59> They're not tested anywhere near well enough, but the alternative is to revert back to drivers/ide
[05:48] <BenC> mjg59: what exactly are the implications of not having it?
[05:48] <mjg59> Various machines refuse to boot
[05:48] <kylem> basically all thinkpads
[05:48] <BenC> what's the symptoms of the failure?
[05:49] <mjg59> Reads beyond end of device
[05:50] <BenC> are there any bug reports that reflect this problem?
[05:50] <kylem> ... yes, the whole impetus for doing this in the first place.
[05:51] <BenC> I didn't mean it to say there weren't, just need something to bounce off of to justify the patch
[05:51] <BenC> got a bug number?
[05:51] <kylem> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/82314
[05:54] <rtg> mjg59: I have a laptop that exhibits the mmc problem with an SD card. I'm building with your patch and will test it shortly.
[05:54] <mjg59> rtg: It's trivially correct - the wireless stuff is rather more of a blocker
[05:55] <Mithrandir> BenC: wasn't the idea to do a kernel upload post-rc with the HPA and other really critical fixes?  If so, it can go in with those.
[05:55] <rtg> mjg59: I know, but I've been working on a I2C fault.
[05:55] <BenC> mjg59: what wireless stuff?
[05:55] <Mithrandir> mjg59: is there actually a bug report about the hpa stuff?
[05:55] <BenC> Mithrandir: see kyle's link
[05:56] <Mithrandir> ah, cheers
[05:56] <kylem> there's probably more, but that's the report that precipitated me actually writing the code in the first place.
[05:56] <mjg59> BenC: The fact that softmac drivers don't work with n-m
[05:56] <BenC> I've bumped that bug to critical, marked it inprogress and milestone for release
[05:57] <BenC> mjg59: ah, right, any real resolution for that?
[05:57] <BenC> or is it still in "we don't know why it wont work" phase?
[05:58] <rtg> BenC: "we don't know why it wont work"
[05:58] <mjg59> wpa_supplicant never receives the netlink messages
[05:58] <mjg59> Which is weird, since iwevent /does/
[05:58] <BenC> we're talking ieee80211_softmac, stock drivers, like bcm43xx, right?
[05:58] <mjg59> Yes
[05:58] <mjg59> bcm43xx and zd1211rw
[05:59] <BenC> I bet I can point to where to look
[05:59] <mjg59> That'd be a good start
[05:59] <BenC> ubuntu/net/wireless/wext-old.c
[05:59] <BenC> it replaces the stock net/ core wireless extensions
[06:00] <BenC> so that mac80211 stuff can have a compatibility layer
[06:00] <BenC> probably something in there that isn't quite compatible with softmac stuff
[06:01] <BenC> might be missing some nl stuff
[06:01] <rtg> BenC: Its not 100% failure. mjg59 can reproduce it, but I could not using the same model AP and a BCM43xx.
[06:01] <BenC> I was going to update the mac80211 stuff, but I ditched it because it's a large update
[06:01] <defendguin> you guys are awesome i hope someone is paying you for all this
[06:01] <mjg59> defendguin: Me? No.
[06:01] <defendguin> damn!
[06:02] <BenC> mjg59 gets paid in laptops and beer
[06:02] <defendguin> mmmm
[06:02] <mjg59> No new laptops for some time
[06:02] <mjg59> I'm starting to feel unloved
[06:03] <BenC> mjg59: might help if you identified some models that tend to give us the most problems and we can go from there :)
[06:03] <defendguin> mjg59, i got a bunch of old latitude D series laptops :-D
[06:04] <defendguin> that may or may not have good hardware
[06:04] <mjg59> BenC: TBH, I really don't have the time right now
[06:06] <BenC> oh, one bad thing about HPA
[06:06] <BenC> changes ABI
[06:06] <mjg59> Like I said, it's basically that or go back to drivers/ide
[06:07] <BenC> kylem: Can you show me the patches for HPA again?
[06:07] <kylem> http://people.ubuntu.com/~kyle/feisty/
[06:08] <BenC> kylem: Can you go ahead and commit 0001 and 0005?
[06:09] <kylem> 0002 is important too
[06:09] <kylem> and a one liner
[06:09] <BenC> yeah, that one too please
[06:09] <kylem> k.
[06:13] <BenC> kylem, mjg59: Is there any way to do this patch without the addition of n_sectors_boot?
[06:13] <BenC> that's the only thing changing the ABI
[06:13] <kylem> BenC, i think not doing that would break suspend/resume in some instances.
[06:14] <BenC> just wondering if there's some other way to store it
[06:14] <BenC> maybe (ab)use some other part of the struct ata_device
[06:14] <kylem> it's 8-bytes, so hard.
[06:15] <kylem> i'm testbuilding a patch, but even on my crestline it's kind of slow :P
[06:15] <kylem> i think if i abuse padding i can not break ABI on i386/amd64
[06:15] <kylem> and we can override it on the other architectures.
[06:16] <Mithrandir> I'd rather have you break the ABI and we take the pain than find random bugs later.
[06:16] <Mithrandir> even if it's bloody painful
[06:22] <BenC> kylem, mjg59: Why can't we use ata_hpa_resize() in ata_dev_same_device() and avoid the need for n_sectors_boot?
[06:23] <BenC> does it write to the device in some way?
[06:23] <kylem> n_sectors_boot is the very first size returned by IDENTIFY
[06:23] <kylem> the check is basically ensuring that if the drive firmware resets the size, that we make sure it's the same disk
[06:24] <kylem> but if it hasn't, then the size in the ata_id will still be the post-HPA size
[06:24] <mjg59> Yeah, you need both sizes to do the "Is this the same disk" check
[06:24] <kylem> the problem is, it may or may not be the same.
[06:25] <kylem> could probably do something really ugly like put it on an external linked list tagged by ata_id or something.
[06:26] <BenC> trying to understand the logic in this check
[06:26] <BenC> if the n_sectors_boot is the same, it really doesn't mean the device will show the same after HPA is applied, right?
[06:27] <BenC> trying to find the ide code
[06:28] <mjg59> IDE doesn't bother with the "Is this disk the same" check
[06:28] <mjg59> drivers/ide is very naive
[06:30] <Mithrandir> IDE doesn't have hotplug, though?
[06:30] <capiira> anyone know where i can get a proper .config version of the newest ubuntu kernel?
[06:30] <kylem> Mithrandir, drivers/ide has a few sata drivers.
[06:30] <Mithrandir> ok
[06:31] <BenC> capiira: /boot/config-`uname -r`
[06:32] <capiira> i used the one from /boot and noticed that my package is 228mb but not becuase of the kernel but becuase of all the modules
[06:32] <mjg59> capiira: strip the modules
[06:32] <BenC> right, we enable -g compilation
[06:33] <capiira> but how to do that ? i used make-kpkg
[06:34] <BenC> capiira: best bet is to disable CONFIG_DEBUG_INFO in the config
[06:34] <capiira> yeah but i used the config from /boot why its not equal the original ubuntu kernel ?
[06:35] <capiira> do they differs?
[06:35] <BenC> mjg59: In what context is the "same device check" important? Will it break things if the HPA size is different? Is it enough that the boot size is the same for things to work ok?
[06:36] <capiira> hmm found
[06:36] <capiira> CONFIG_DEBUG_BUGVERBOSE=y and CONFIG_DEBUG_INFO=y
[06:36] <cjwatson> the Ubuntu kernel package is built using debian/rules (in the standard way as for any package), not just make-kpkg
[06:36] <BenC> it just seems to me that for the same device check to be worth while, the post-hpa-resize size is the important one
[06:37] <capiira> ahh ok
[06:37] <Mithrandir> capiira: reading some of the wiki pages referenced in the topic is probably a good idea.
[06:38] <capiira> yeah thats what i did
[06:38] <capiira> https://wiki.ubuntu.com/KernelCustomBuild
[06:39] <capiira> they use make-kpkg too
[06:39] <mjg59> BenC: What's the code flow? ie, has the hpa resizing been re-performed before the "Is this disk the same" check?
[06:40] <capiira> Alternate Build Method: The Old-Fashioned Debian Way that's what i did
[06:40] <mjg59> The drive will have been reset over suspend/resume, so will have dropped back to the original size
[06:40] <kylem> could just blat it unconditionally, i suppose
[06:40] <mjg59> capiira: If you want to build a kernel identical to the shipped one, use dpkg-buildpackage and not make-kpkg
[06:40] <mjg59> BenC: l-r-m has to be reuploaded anyway, so is breaking the ABI really a huge issue?
[06:41] <capiira> yes that's what i want thx
[06:42] <capiira> mjg59, you  know a link that explains how to do with dpkg-buildpackage ?
[06:42] <BenC> mjg59: ABI breakage isn't merely a matter of uploads at this point
[06:42] <BenC> capiira: yes, the URL above has links to building the kernel
[06:42] <BenC> check the KnowledgeBase page
[06:43] <BenC> mjg59: there are other reasons why I don't want the ABI to change before release :)
[06:44] <mjg59> BenC: I'm a bit reluctant about modifying the patch beyond the testing it's already got
[06:45] <BenC> ignoring the ABI change, I'm still trying to wrap my head around if this check is correct or not
[06:46] <BenC> ata_dev_configure() is called after ata_dev_same_device() in ata_dev_revalidate()
[06:46] <BenC> the hpa resize occurs in ata_dev_configure
[06:46] <capiira> thx
[06:47] <kylem> http://marc.info/?l=linux-ide&m=117630937432256&w=2
[06:49] <BenC> kylem: Ah, good point...might be proper to set new_n_sectors to the native_max if hpa is enabled on the id
[06:49] <BenC> avoids all the ata_hpa_resize stuff, since it actually writes to the device, which is probably bad
[06:51] <mjg59> You have to do the ata_hpa_resize on resume
[06:52] <mjg59> Or do you mean avoid doing it unconditionally?
[06:52] <kylem> i mean, doing it unconditionally is probably the way to go. just entirely forget about the pre-HPA disk size
[06:58] <BenC> I was thinking more like breaking out the read_native_max into a helper and use that for the resume case to get new_n_sectors for hpa enabled id's
[06:59] <BenC> remove the whole block for "Are we the boot time size..."
[07:22] <BenC> kylem: do you have hw to test the hpa stuff?
[07:22] <kylem> well, anyone with an ata disk can test the most critical half of it
[07:22] <kylem> but no, i don't have any symptomatic hw.
[07:23] <kylem> my thinkpad predates using HPA, it just had the bios partition at the end of the disk unprotected
[07:24] <BenC> wonder how quick the people on the bug report can turn around a test run
[07:24] <BenC> guess I'll build a kernel and post it
[07:25] <rtg_> BenC: I'm committing the mmc fix. It appears to work. Thanks to mjg59.
[07:25] <BenC> I have it in my tree already
[07:25] <kylem> rtg_, rock!
[07:25] <BenC> rtg_: thanks for testing though
[07:26] <rtg_> BenC: Well then, I'll just let you commit it.
[07:27] <blueyed> BenC: Bug 84965 has been set to "Fix released" by you on 18 Mar ("Added to my git tree.), but does not seem to have hit the archives yet!?
[07:27] <blueyed> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/84965/
[07:28] <BenC> kylem: http://people.ubuntu.com/~bcollins/libata-hpa-support.diff
[07:28] <BenC> kylem: that's a redo of your 0003 patch, can you look it over?
[07:29] <BenC> I added ata_hpa_native_size() and used it
[07:29] <kylem> looks ok
[07:31] <BenC> I'm not absolutely sure of it...I don't know what the expected state of *dev is in this function, so reading it via *dev and deciding if *new_id is the same device may not be the right thing
[07:31] <BenC> we may need to use the n_sectors_boot after all
[07:32] <BenC> not too happy about an ABI bump, but might not be able to avoid it :/
[07:44] <BenC> blueyed: heh, was marked fix committed by chuck, but I never got the commit
[07:44] <BenC> zul: Do you have that patch still?
[07:45] <zul> BenC: looking
[07:45] <BenC> zul: Marked it in progress and assigned back to you
[07:45] <zul> dont think so unfortunately
[07:46] <zul> it might be on my backup drive, ill check again when im home
[07:48] <blueyed> BenC, zul: Thanks for looking into it!
[07:52] <BenC> rtg_: Hey, don't let me forget to bring the 5160 cpu's with me to Austin
[07:53] <BenC> I keep forgetting to send them out, but I can definitely carry them with me
[07:53] <rtg_> BenC: Gotta bug mdz about the MB price list.
[07:54] <BenC> he's probably pushing things like that off until UDS, so might be best to talk to him there
[07:54] <rtg_> I'm rooming with him, so I'll probably have opportunity.
[07:55] <BenC> ah, cool
[07:57] <ivoks> qemu still can't use CDROM on 20070411 :/
[08:39] <defendguin> BenC, what was the decision on that mmc bug from earlier is that going in before release or after it?
[08:39] <BenC> defendguin: before release
[08:39] <BenC> we have a one-liner fix for it
[08:39] <defendguin> yeah i saw that
[08:41] <defendguin> should i go and close out the bug saying a fix has been released or just wait till everyone gets it and we test it out to make sure?
[08:41] <mjg59> defendguin: fix-committed
[08:42] <mjg59> Not released as yet
[08:42] <defendguin> ahh
[08:56] <defendguin> anyone in here on the acpi team?
[08:59] <mjg59> Yes
[08:59] <kylem> mjg59, you /are/ the acpi team. ;P
[09:00] <mjg59> :(
[09:00] <pkl_> I thought rtg has also done some stuff on acpi :)
[09:00] <kylem> pkl_, less fun to tease mjg59 that way. :)
[09:01] <defendguin> hehe
[09:01] <mjg59> defendguin: What's up?
[09:01] <pkl_> I haven't, for which I'm eternally glad.
[09:02] <kylem> pkl_, hehe.
[09:02] <defendguin> i've had a bug outstanding since before edgy's release and i was wondering if someone could take a quick look at it 
[09:03] <mjg59> defendguin: I can take a look, but promise little
[09:04] <defendguin> i understand i don't think it would warrant going in anytime soon but it would be nice to see it finally work
[09:04] <mjg59> defendguin: Bug number would be helpful :)
[09:05] <defendguin> launchpad is being slow
[09:05] <mjg59> s/being/
[09:06] <defendguin> bug 44615
[09:06] <defendguin> where did ubotu go?
[09:06] <Nafallo> defendguin: never been here :-)
[09:06] <defendguin> sure he has
[09:06] <Nafallo> nope
[09:07] <defendguin> ok i'm crazy
[09:07] <Nafallo> not aslong as I've been anyway :-)
[09:07] <defendguin> mjg59, i remorted thsi back before dapper was released
[09:09] <mjg59> What does sudo acpi_fakekey 142 do?
[09:10] <defendguin> i'll have to write that down and get back to you
[09:11] <mjg59> Ok
[09:12] <defendguin> there is a very strict policy around here about bringing personal computers to work
[09:12] <mjg59> Heh. Not a problem.
[09:12] <defendguin> any other info i can collect?
[09:13] <mjg59> Working out whether that works would be a good start
[09:14] <defendguin> ok only 2 + hours
[10:08] <capiira> hmm hi what does that error mean ? make: *** No rule to make target `binary-debs'. Stop.
[10:15] <shawarma> Has anyone taken a look at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/96857 ? It renders Feisty uninstallable in qemu. :-(
[10:35] <BenC> shawarma: I did a livecd install under qemu just two days ago...I wonder what the difference is
[10:35] <Mithrandir> BenC: on amd64?
[10:36] <Mithrandir> iirc, it's amd64-specific
[10:36] <BenC> 64-bit Intel
[10:36] <Mithrandir> well, same thing.
[10:36] <Mithrandir> with a 64 bit install too?
[10:36] <shawarma> I'm using the 386 iso.
[10:37] <BenC> yeah, 64-bit install
[10:37] <shawarma> Mithrandir: I'm almost certain that you used an i386 iso as well, when you tested it?
[10:38] <shawarma> The initial reporter doesn't specify which host arch he's on. :-(
[10:38] <capiira> hmmmm :/ there is something wrong or something missing in that debian/rules tutorial from the topic site
[10:39] <Mithrandir> shawarma: oh, the cdrom bug, yes, that was i386, iirc.
[10:39] <capiira> i did exactly wht it's written there and get that make error
[10:40] <capiira> that error make: *** No rule to make target `binary-debs'. Stop.
[10:40] <BenC> capiira: sounds to me like you install linux-source-2.6.20 package instead of getting the linux-source-2.6.20 sources
[10:40] <BenC> there is a difference
[10:40] <capiira> i got the tar.gz
[10:40] <capiira> or bz
[10:41] <capiira> let me see
[10:41] <capiira> tar.bz2
[10:41] <capiira> linux-source-2.6.20.tar.bz2
[10:42] <shawarma> capiira: Instead of "apt-get install linux-source-2.6.20" you should "apt-get source linux-source-2.6.20"
[10:42] <capiira> ahh
[10:43] <capiira> do you think that's why i get a 230mb package after make-kpkg, too ?
[10:44] <shawarma> BenC: Actually, I don't seem to have any ide devices available at all in my qemu.
[10:44] <mjg59> capiira: No
[10:44] <capiira> then it must be right one if it works with make-kpkg or not ?
[10:45] <mjg59> capiira: No
[10:45] <capiira> ok
[10:45] <BenC> let me test real quick
[10:46] <capiira> complicated, sorry for disturbing just want to get my scanner to work :/
[10:46] <shawarma> BenC: I'm using 0.9.0 right now, but 0.8.3 (or whatever's in Edgy) does the same thing.
[10:48] <BenC> shawarma: trying now with a i386 cd from last night
[10:49] <BenC> I'm using qemu 0.8.2+dfsg
[10:49] <shawarma> BenC: Ok, cool. I'm using the server cd, but that shouldn't matter here, I suppose.
[10:49] <BenC> shouldn't
[10:49] <capiira> that bug https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/85488
[10:51] <shawarma> BenC: Just retested with latest daily both with and without kqemu (qemu 0.9.0). Same thing. No hard drive, no cd-rom.
[10:51] <shawarma> BenC: Not that kqemu should matter at all.
[10:51] <BenC> I see hd (sda), but no cdrom
[10:52] <shawarma> /sys/block only shows ram0-ram9
[10:52] <shawarma> Strange. I can try downgrading my qemu..
[10:53] <BenC> actually I see the cdrom, but it's failing to follow though with it
[10:53] <shawarma> BenC: You're using the qemu from feisty?
[10:53] <mjg59> Well, the lack of hdc is hardly surprising
[10:54] <mjg59> The provided dmesg in the bug log isn't useful
[10:54] <mjg59> We need the next page as well
[10:55] <shawarma> How would I extract that from a running qemu without net access between guest and host?
[10:55] <BenC> well, I can reproduce it, so all it does it reproduce the same exception
[10:56] <shawarma> I'm not sure when it last worked, unfortunately. In January it did, that's for sure..
[10:57] <shawarma> I cleverly overwrote the daily image I had an after that it stopped working.
[10:58] <mjg59> It's likely that it worked before that device was being run by libata
[10:58] <shawarma> Any idea when that happened?
[10:58] <shawarma> late february perhaps?
[10:59] <BenC> shawarma: you can try "modprobe -r ata_piix; modprobe piix" and see what happens
[11:00] <BenC> that just worked for me
[11:00] <shawarma> Nothing.
[11:00] <mjg59> Well, if that doesn't work, it's almost certainly some sort of qemu issue
[11:00] <shawarma> In fact, I'm not sure ata_piix was loaded in the first place..
[11:00] <mjg59> The piix driver hasn't changed
[11:01] <shawarma> I'll recheck.
[11:01] <BenC> I'm quite sure it did
[11:01] <BenC> since it shows "scsi1: ata_piix"
[11:01] <shawarma> mjg59: Well, it *used* to work in qemu.. 
[11:02] <mjg59> Yes and then we changed drivers
[11:02] <shawarma> True.
[11:03] <shawarma> Yes, ata_piix and piix are both indeed loaded.
[11:04] <mjg59> If loading piix did nothing, it's probably still bound to ata_piix
[11:05] <BenC> yeah, check dmesg after rmmod ata_piix
[11:05] <shawarma> according to lsmod nothing is using either.
[11:05] <BenC> make sure it released both ata devices
[11:05] <shawarma> There's no change in dmesg after remove ata_piix.
[11:05] <mjg59> And make sure that ide-generic isn't loaded
[11:05] <mjg59> Or ata-generic
[11:06] <mjg59> If none of this works, your problem bears no resemblance to the one that the bug's demsg dump is from
[11:06] <shawarma> ide-generic is busy, it seems.
[11:06] <mjg59> Right. Reboot it.
[11:07] <shawarma> ok.. and do what differently this time? unload {ide,ata}-generic first?
[11:07] <mjg59> Don't load them in the first place
[11:07] <shawarma> *I* didn't.
[11:07] <BenC> most ide drivers cannot be unloaded
[11:07] <shawarma> Can I blacklist it with a kernel parameter of som esort?
[11:08] <mjg59> shawarma: If ide-generic is binding, then you have a different bug
[11:08] <mjg59> Please provide everything in dmesg that's related to ata
[11:09] <shawarma> here or a new bug?
[11:09] <shawarma> or pastebin..
[11:10] <mjg59> pastebin is good for now
[11:10] <shawarma> Ok. I see no other way than typing it in, so I'll leave out the imestamps. they seem superfluous.
[11:10] <mjg59> Or take screendumps
[11:10] <mjg59> That's also fine
[11:11] <shawarma> Clever. :-)
[11:11] <shawarma> http://warma.dk/qemu.png
[11:12] <shawarma> In fact, I can let you have access to it via vnc?
[11:14] <shawarma> or not. Either way is good.
[11:14] <mjg59> Right, yes, that's clearly different.
[11:14] <shawarma> bugger.
[11:14] <BenC> no idea what that is
[11:15] <BenC> looks like a qemu bug though
[11:15] <mjg59> ata_std_prereset() is returning an error
[11:16] <mjg59> Though that should never happen
[11:16] <shawarma> I'll try 0.8.2+dfsg in a sec. I'm compiling it right now.
[11:16] <mjg59> Oh, I see
[11:16] <mjg59>        if (!pci_test_config_bits(pdev, &piix_enable_bits[ap->port_no] ))
[11:16] <mjg59>                 return -ENOENT;
[11:17] <capiira> hmm where does apt-get source saved the packages? there is nothing in /usr/src
[11:17] <shawarma> http://warma.dk/qemu2.png   <--- don't know if that helps?
[11:17] <shawarma> capiira: current directory
[11:18] <mjg59> ata_piix is binding and finding that the chip caims to be disabled
[11:18] <capiira> ohh i was in a temporally broken symlink dir
[11:20] <mjg59> capiira: These questions are probably better suited for #ubuntu than in here
[11:20] <capiira> yeah
[11:20] <shawarma> If it helps at all http://warma.dk/qemudmesg[1-7] .png has the complete dmesg output..
[11:21] <BenC> I just tried kqemu (0.9.0) and it works, but shows the same exceptions
[11:22] <BenC> but as I said, it actually works
[11:22] <BenC> just booted livecd
[11:23] <shawarma> weirdness.
[11:24] <shawarma> BenC: Homerolled qemu or the debian one? 
[11:24] <BenC> kvm-18 from feisty
[11:24] <shawarma> BenC: I used the qemu 0.9.0 source from debian experimental and compiled it for my edgy server.
[11:25] <shawarma> BenC: Oh. I don't have kvm-able hardware. :-(
[11:25] <BenC> kvm is qemu based, just add the -no-kvm option to it
[11:26] <BenC> and it's pretty much the same as qemu
[11:26] <shawarma> But you got it to work with vanilla qemu?
[11:26] <shawarma> Well, 0.8.2+dfsg..
[11:26] <BenC> with 0.8.2+dfsg it works if I rmmod ata_piix, and modprobe piix
[11:27] <shawarma> BenC: That's also necessary with the livecd, I expect?
[11:27] <BenC> yeah
[11:28] <shawarma> It drops you to a shell at some point, you do your thing, and .. what? exit out of the shell and the world continues?
[11:29] <mjg59> yes
[11:29] <mjg59> BenC: If it's failing with qemu, I suspect that it's quite possibly also failing with real hardware
[11:29] <mjg59> (And we do have a few bugs where people are losing CD drives and the like)
[11:30] <BenC> yeah, but this is the only way I have to duplicate it :)
[11:30] <BenC> I need to get it fixed before Friday
[11:32] <BenC> I'm wondering if the acpi stuff is breaking it
[11:33] <BenC> it's the main difference between what we have and jeff's stable tree
[11:33] <mjg59> We don't execute the acpi stuff on startup, do we?
[11:34] <mjg59> (No, we don't seem to)
[11:34] <mjg59> Does Jeff's stable tree work?
[11:36] <shawarma> Hmm... There's no dmesg in the initramfs.. How can I see what's in the buffer?
[11:44] <shawarma> Alright, retesting with qemu 0.8.2+dmesg
[11:45] <shawarma> Er... You know what I meant. :-)
[11:46] <BenC> same thing happens with nopataacpi=1
[11:46] <BenC> shawarma: dd if=/proc/kmsg of=/tmp/dmesg bs=1 &
[11:46] <BenC> shawarma: then you can "more /tmp/dmesg"
[11:47] <shawarma> BenC: Ah, I'll reboot and try again.
[11:48] <shawarma> Oh, that also contains the buffer?
[11:49] <shawarma> Yes, now I get the exceptions as well.
[11:49] <BenC> modprobe ata_generic all_generic_ide=1
[11:49] <BenC> that works too
[11:49] <capiira> ok compiling  :) i hope things work better using debian/rules :) let me go watch tv for 3h's
[11:49] <BenC> after rmmod ata_piix
[11:50] <BenC> so something is wrong with ata_piix
[11:52] <mjg59> DMA is hard
[11:54] <capiira> oh i did no "sudo" before AUTOBUILD=1 fakeroot debian/rules binary-debs ! it's needed ?
[11:54] <shawarma> No.
[11:54] <capiira> good thx :)
[11:54] <shawarma> That's that fakeroot is for.
[11:55] <capiira> ahh ok thx bbl
[11:56] <capiira> but you was right it was because of the apt install and apt source
[11:57] <capiira> its a little bit mixed in the tutorial
[12:15] <BenC> mjg59: do you know a way to force PIO with ata_piix?