=== asac_ is now known as asac [10:44] Hi [10:44] I get the following error while kernelcompile: [10:45] http://paste.debian.net/12712/ [10:46] the only I changed was debian/changelog (new version) and CONFIG_VERSION_SIGNATURE [12:04] bboschman: what's the command you used? [12:30] alex_joni, CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-server [14:38] I see you moved the virtio drivers into a seperate udeb, and marked it priority: extra.. Is the latter deliberate? [14:45] Is timg around? He's marked bug #183033 as "fix committed" for intrepid, which I don't think it is. [15:47] soren: it is...we don't want all those modules being forced in lowmem netboots [15:48] I can think of modules that are much more ripe for a move to extra than virtio. virtio will actually be used. :) [15:49] soren: but if it's forced to be loaded on lowmem systems, it makes the lowmem install useless :) [15:49] AFAICS, it's only virtio and crypto that are extra, while *everything* else is there by default. [15:49] Or am I reading too much into the priority of the udebs? [15:49] I can change the extra setting if you want, I just need it in a separate udeb [15:50] I think you are reading too much into it [15:50] Ok. [15:50] What I'm seeing is that the virtio_pci and virtio_ring modules were missing in the installer. [15:50] d-i failed to find my nic. [15:51] Truth be told, I didn't spend *that* much time on it, but it just seemed to me that the only difference between now and back when it worked was that virtio_ring and virtio_pci were moved to a udev with priority: extra. [15:52] ...and it just so happens that the only two udebs marked as extra are crypto and virtio. === kylem_ is now known as kylem === mkrufky is now known as mkrufky-lunch === thegodfather is now known as fabbione [18:22] guys how do i build the git linux-modules in hardy it keeps saying it needs the source for 2.6.24-21 but the latest package in the repo is 2.6.24-19 === mkrufky-lunch is now known as mkrufky === chuck_ is now known as zul [19:08] how do i retrieve a specific version from the git kernel repository [21:17] what kernel release is the 2.6.26-4 kernel in Intrepid using? [21:20] baron1984: 2.6.26 [21:20] final? [21:22] will the backports for ACPI in the Linus git tree be backported into Intrepid? [21:22] baron1984: 2.6.26 final + cherry picked patches from 2.6.27-rcX is the plan [21:22] suspend to ram broken since last kernel update in hardy 64 bit [21:22] anybody who can confirm that? [21:23] suspend to RAM just doesn't work in ANY Linux kernel for me [21:23] baron1984: what are the backports for ACPI? [21:23] it does in 2.6.26-4 on Intrepid [21:23] but when I reboot [21:23] it freezes [21:23] kernel panic comes up [21:23] just before it restarts [21:23] suspend works with kernel 2.6.24-19 [21:23] I've filed a bug on it [21:23] [patch] acpi: fix crash in core ACPI code, triggered by CONFIG_ACPI_PCI_SLOT=y [21:24] may fix this? [21:24] bug 251338 [21:24] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/251338 [21:25] the initial report was for Hardy [21:25] but I redid the dumps with 2.6.26-4 on Intrepid [21:26] baron1984: I am not sure what your situation is - Is the intrepid kernel a regression from Hardy? [21:27] amitk: No, in fact it's a large improvement, ACPI has gone from hardly working at all to working "more" [21:27] it crashes on reboot after having suspended [21:28] I've asked Foxconn what their problem is [21:28] they told me to go buy Vista [21:28] well, after several layers of "support" [21:29] sounds like fighting words to me [21:29] or like a mystical curse [21:29] who "buys vista" ? [21:29] telling me to yank out my RAM modules and see if the problem continues? [21:29] never install vista on an old machine! [21:29] baron1984: so what are you looking to be backported? and from where? [21:29] oh, I have Vista, it's an OEM copy [21:29] and this motherboard is a replacement [21:30] it makes sense to run vista on a NEW machine that COMES with it installed [21:30] (if you absolutely must) [21:30] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222 [21:30] I think this may fix the problem? [21:33] baron1984: that bug only enables custom DSDTs. Do you have one for your board? [21:33] I'm sure I could come up with one [21:33] there was a Gentoo guide on how to do it [21:35] http://www.lesswatts.org/projects/acpi/overridingDSDT.php [21:35] that may work [21:36] but only when the patch that allows it lands [21:36] unless I want to futz about with a custom kernel on an Alpha distribution [21:36] (I really don't) [21:40] amitk: If I understand this correctly [21:41] I'd build the DSDT, and just place it into /boot? [21:42] baron1984: you could give it a try when the next kernel is available. The git commits have already landed. I just checked [21:43] baron1984: correct [21:44] amitk: How exactly would I fix the DSDT I have? [21:44] I do not know assembler [21:46] baron1984: there is a lot of documentation around to fix DSDT, but you should start by looking if someone has already posted something for your board at http://acpi.sourceforge.net/dsdt/view.php [21:47] http://acpi.sourceforge.net/dsdt/index.php [21:54] amitk: should I upload my disassembled dsdl in to Launchpad? [21:54] or would this not be kosher? [21:55] amitk [21:55] looks like it probes to find out what Windows it's using [21:55] and if it doesn't find one, it falls back to NT 4 [21:57] baron1984: that is usually the beginning of DSDT problems - customization of behaviour for differnt windows versions :) [21:57] If (MCTH (_OS, "Linux")) [21:57] Store (0x03, OSVR) [21:57] peculiar [21:57] it doesn't do that setting for any Windows version [21:58] it gets better [21:58] baron1984: it is unlikely that anybody will be able to help with a particular DSDT. You are on your own there because it is so HW specific. But the acpi list is a good place to ask for help. [21:58] there is no package 0x03 [21:58] only 0x04 [21:59] you figure recompiling it telling it to detect Linux and use Windows Vista's DSDT package would help? [21:59] B-) [21:59] baron1984: as a rule of thumb, from the ACPI maintainer - they try to be bug-compliant with Windows for the ACPI implementation. And they keep pleading to BIOS vendors not to do different things for different OSes. [22:03] amitk: This is sabotage [22:03] plain and simple [22:03] there's no other explanation for telling Linux to use different DSDL table [22:05] amitk: I recompiled it and got 7 warnings [22:05] Acquire (MUTE, 0x03E8) [22:06] Warning 1103 - ^ Possible operator timeout is ignored [22:07] oh hell no [22:07] I know what they did [22:07] they gave a bogus table just for Linix [22:07] *Linux [22:07] that they know will break it [22:08] clever bastards [22:13] http://ubuntuforums.org/showthread.php?p=5451708#post5451708 [22:33] soren: ping [22:44] BenC: Oui? [22:45] soren: in zinc:~bcollins/ is the test virtual package [22:45] BenC: i386? [22:45] soren: amd64 [22:45] Whee! [22:46] My favourite :) [22:46] soren: I can do 32-bit later if needed [22:46] soren: NOTE: it's based on -server build, so uname looks like -server and everything is installed as 2.6.26-4-server, and it conflicts with the -server image [22:46] soren: I don't see that as a problem really, but just so ya know [22:47] BenC: I'm curious how you'll pull of building an amd64 kernel for i386, though. You said you'd use the same approach, right? [22:48] s/of/off/ [22:48] soren: I have no intention of doing that [22:48] Oh, ok. [22:49] You did mention a similar use case for this approach in Boston, didn't you? [22:51] Perhaps, but I can't recall what it is