[12:03] this is hilariously cool [12:03] acpi is rapidly ascending my list of cool things [12:04] okay [12:04] we need to send desrt away on holiday [12:05] ACPI would be pretty cool if there was a single hardware manufacturer that actually got it right. [12:06] i agree. [12:06] Getting it "almost right" and then having Microsoft fix it via software updates doesn't count. [12:06] Most vendors get it fine nowadays [12:06] Though I would kill for Microsoft's big database of DSDT fixes. [12:06] Linux, on the other hand, really still doesn't [12:07] mjg59 is here [12:07] mjg59: My impression seems to be that we follow the spec well enough in most cases, but we don't have nearly enough workarounds in place to compete with Windows. [12:07] mjg59: But I'm willing to believe we also break spec occasionally. === licio [n=licio@ubuntu/member/licio] has joined #ubuntu-devel [12:08] We demonstrably break spec in a couple of ways that probably don't matter [12:08] But then we come up against issues like the fact that Windows has just adopted the ACPI world while Linux tries to work without it when possible [12:08] So we get weird interrupt routing conflicts [12:09] VIA interrupt routing is still slightly fucked on ACPI systems [12:09] Because their APIC behaves slightly different to Intel ones [12:10] Well, in Windows, it's an all-or-nothing thing. You either have an "ACPI PC" or a "Legacy PC", and everything is defined from there. [12:10] <\sh> infinity: in windows it's: "I have a windows pc" [12:10] Which cause no end of issues when ACPI was still shiny and new, and I was constantly holding down F7 (I think?) during windows installs to say "nu uh, don't use ACPI" === robitaille [n=daniel@ubuntu/member/robitaille] has joined #ubuntu-devel [12:10] \sh: No, very not true. [12:11] Suspend/resume is (generally) broken because our drivers are fucked [12:11] <\sh> infinity: for the plain windows user it is] [12:11] The "plain" windows user gets their machine shipped with Windows pre-installed by an OEM who should know what the sanest configuration is. [12:12] When doing it yourself, Windows is just as fragile as Linux, if not more (says the man who's just spent ~24 hours reinstalling Windows on a system, because it's grumpy with his hardware configuration) [12:13] <\sh> infinity: right...but then, one day, she gets an ubuntu cd and no one is there to help her... [12:13] get more oems then [12:14] Indeed, the solution to the "non-technical user" isn't to make our installer EVEN BETTER (I can tell you from the past day's experience, ours IS better), it's to get more OEMs shipping Linux pre-installed. [12:15] No amount of simple installation can replace an OEM pre-configuring a system "just right", so you don't have to. === slomo [n=slomo@ubuntu/member/slomo] has joined #ubuntu-devel [12:15] ok [12:16] so i can't find anything in this DSDT about sleeping [12:16] the ACPI spec says i should see SLP_EN or SLP_TYP.... [12:16] all i have is SLPB [12:16] desrt: No, those are just registers [12:16] They're defined in the fadt [12:16] but nothing in the code references them.... [12:17] No [12:17] The kernel writes to them directly [12:17] <\sh> Oh Lord, please send Michael Dell a message that he has to pre-install Linux on Desktops and not this 666 Redmond OS. [12:17] oh. [12:17] so ACPI specifies a register region where writes mean certain things [12:17] like sleep is done the same way on every laptop ever [12:17] You call the _PTS and _GTS methods, and then the kernel writes to those registers [12:17] Yeah [12:18] prepare to sleep? [12:18] The registers aren't necessarily in the same place [12:18] Prepare to sleep and going to sleep [12:18] <\sh> who is in charge of the kernel these days (ubuntu-server)? [12:18] i have PTS but not GTS [12:18] GTS is optional [12:19] i wonder what would happen if i booted a system with practically no drivers installed.... [12:19] i seriously get the impression that some driver is screwing up [12:19] <\sh> s/pc/apple IIe/ ? [12:19] i assume _WAK is what happens when it comes back [12:19] \sh: BenC, with occasional input from others. (mjg59 for all things ACPI and otherwise desktop shiny, Fabio for sparc, me for occasional server input and vga16fb breakage, crimsun for all things audio..) [12:20] desrt: Yup [12:21] i wonder if PTS is what makes the light on the case start woobing [12:21] or if this is HW [12:21] <\sh> infinity: ok...do you think it's possible to fix a problem in the scsi area, which let the areca controller not doing their work correctly? as well, the configuration management software for areca is segfaulting with the actual kernel of dapper (server) [12:22] <\sh> infinity: to be more precise, 2.6.16 is fixing this problem and it's known by the areca patch maintainer afaik from our hardware oem support :) [12:22] \sh: File a bug, and explain it better that "not doing their work correctly", since I have several anecdotal reports that areca works just fine. [12:22] woh. [12:22] there's an OSYS field (operating system, i assume) [12:22] \sh: And put a pointet to the patch in the bug. [12:23] it gets initialised in _INI to different numbers depending on the OS [12:23] desrt: The name OSYS is Apple specific, but yeah [12:23] DSDT code can be platform specific [12:23] hrrrm [12:23] On the Macs, the only difference seems to be a small amount of HPET setup. No idea why. [12:23] if (darwin) 0x2710, if (linux) 0x3e8, else 0x7d1 === Chipzz just found a gnome-power-manager bug [12:24] <\sh> infinity: ok, i'll try... [12:24] Chipzz: If you only found one, you're not looking very hard. [12:24] and an OSDW() function which gets called on wake up which checks this register [12:24] the check is LEqual(OSYS,0x2710), though... which assuming LEqual means what i think, darwin linux and 'else' match. [12:25] infinity: pretty nasty one in my case [12:25] but an easy fix I think [12:25] 0x3e8 is a weird choice [12:25] oh. logical equal. ok. [12:25] so it does different things on wake up if the running OS is darwin [12:25] OSDW() must mean 'OS is darwin' === Lukketto [n=Lukketto@host150-175.pool873.interbusiness.it] has joined #ubuntu-devel [12:26] if osdw \_sb.pci0.sbus.enab() [12:26] Sounds smbus related [12:26] think it might be causing me to not wake up? [12:27] If it is, probably only because of Linux bugs [12:27] you're becoming more jaded about linux :) [12:27] Linux is far from perfect. === storm [n=joel@200.208.133.109] has joined #ubuntu-devel [12:27] infinity: the GUI allows "When laptop lid is closed" to be set to "nothing", but the gconf description of those keys doesn't have that value in it's list... [12:27] heresy === Lukketto [n=Lukketto@host150-175.pool873.interbusiness.it] has left #ubuntu-devel [] [12:28] I had those keys set to "nothing", and as a result, when opening the lid after closing it, X went in an endless crash-loop === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-devel [12:28] Chipzz: can you file a bug please [12:28] I will === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-devel [12:29] sladen: you the gnome-power-manager maintainer? [12:32] sladen: file the bug in launchpad or upstream? I noticed on one of the gnome-power-manager bugs that ubuntu has quite some changes wrt upstream, and upstream isn't very happy about that... [12:33] hmm [12:33] mjg59; what are these smbus _Qxx methods? [12:33] Chipzz: urm. Given how much time that g-p-m upstream (Richard Hughes) spends answering bugs on launchpad, we might have to disagree about that [12:33] Not sure [12:33] mjg59; and what exactly happens if there's an error in the ACPI code? [12:33] Chipzz: please stop making up 'conflict' when there isn't one [12:33] _ prefixed stuff is supposed to be standards [12:33] two _Qxx methods under Device (SMB0) call this PNOT() function which references undefined variables [12:33] Erm, standardised [12:34] 5.6.2.2.2 [12:34] They may be defined in an SSDT [12:34] it has to do with getting a query number from the hardwre [12:34] "Embedded Controller Query and SMBus Alarm control method" [12:34] sladen: I read one of his comments where he expressed his frustration about chasing a bug that turned out to be ubuntu-specific [12:35] Chipzz: well yes. But that's not "isn't very happy about" the changes [12:35] // following is a method that OSPM will schedule after [12:35] // it receives an SCI and queries the EC to receive value 7 [12:35] Method(_Q07) { [12:35] Chipzz: That particular grumpiness is has been long since sorted [12:35] s/is has/has/ === mirak [n=mirak@AAubervilliers-152-1-66-60.w86-198.abo.wanadoo.fr] has joined #ubuntu-devel [12:37] then I'm probably making to much of an issue about it; it was just something that stuck in my mind [12:38] is there a way to run the installer from a runing ubuntu installation ? [12:39] mirak: Not "the installer", per se, but you can just bootstrap a chroot with "debootstrap", which may be what you're looking for. [12:40] infinity: I know deboostrap but don't like it [12:40] I fell it gives a partial installation [12:40] infinity: why couldn't I run the installer ? [12:40] Well, d-i just does debootstrap + install a bootloader + set up user/pass + install extra package selection (say, ubuntu-desktop) + reboot [12:41] I mean since it's runnable from a live cd, it must be runnable from a normal installation [12:41] infinity; if i inject my own DSDT into the initramfs is there a kernel commandline i can give to have it not load it? [12:41] infinity: it won't ask for timezone etcetera [12:41] infinity; just incase :) [12:41] mirak: ubiquity (the livecd installer) has some very specific requirements for what it installs from, requiring access to the read-only filesystem of the livecd, etc. [12:41] mirak: it is meant to give only a base install (or "partial installation", like you call it) [12:42] I can see nothing wrong with that? [12:42] desrt: Better off haking sure you have two kernels installed, and only mucking with the initramfs of one. :) === desrt makes initrd.safe :) [12:42] Chipzz: no but I did it for my actual system and I feel like it's broken [12:43] I debootstrap installs all the time, and they're never "broken". [12:43] infinity: ok about ubiquity. [12:44] so what's the exact procedure ? [12:44] as far as I remember I must install the kernels too [12:45] "Installing this package on a normal system is unlikely to be useful." [12:45] ok I will try anyway :) === Fjodor [n=sune@0x55510b65.adsl.cybercity.dk] has joined #ubuntu-devel [12:45] debbostrap + install kernel and bootloader + install langpack (optional, obviously) + set up a user [12:45] and what about timezone plus locales etcetera ? [12:45] heh [12:45] tzconfig for timezones. [12:46] why doesn't https://launchpad.net/distros/ubuntu/dapper/+source/gnome-power-manager/+bugs list any bugs? [12:46] locales come from installing the langpack(s). [12:46] I just submitted one so there must be bugs [12:46] Chipzz: because launchpad bugs are targetted at the whole distro, not on dapper [12:46] for some crazy reason [12:46] also I see most recent bugs to the right after submitting my report [12:46] s,dapper/,, [12:47] And it's not particularly crazy to assume that a bug filed on dapper probably also applies to other releases. [12:47] this is silly :) [12:47] It would certainly apply to edgy, for instance. :) === jouston [n=jouston@59-105-136-199.adsl.static.seed.net.tw] has joined #ubuntu-devel [12:47] just clicking on the wrong link may be causing a lot of users to submit duplicate bug-reports [12:48] infinity: i think there should be a better way of handling that, it's pretty crazy that the url for translations involves the "dapper/" while the url for bugs doesn't [12:49] mdke: I think it was a mistake to have the release in the URLs at all, TBH. === ompaul [n=ompaul@ubuntu/member/ompaul] has joined #ubuntu-devel [12:50] mdke: Bugs apply to package versions, not distro releases. [12:50] this is true [12:50] (ie: apache2 2.0.55-4 will have the same bugs in both dapper and edgy) [12:50] but package versions are unique across releases [12:50] even if the upstream version is the same [12:50] Chipzz: No they're not. [12:51] Chipzz: We don't rebuild the whole archive with new version numbers for each release. Plenty of packages have the same version in dapper as they had in warty. [12:51] debian has -sarge1 for security updates to packages in sarge [12:51] so even if the upstream version would be the same, sarge would have -sarge1 while testing/unstable would have -1 [12:51] Chipzz: Security updates are UPDATES. When nothing changes, the packages aren't revved. [12:51] hrrrm you are right about that [12:51] Chipzz: False. I have packages in sarge that are the same version as in potato. (really) [12:52] probably because the maintainer doesn't care about them anymore === desrt dpkg-reconfigure linux-image [12:52] Chipzz: Or because they're reasonably bug-free and don't need to be gratuitously rebuilt. === Fjodor_ [n=sune@0x55510b65.adsl.cybercity.dk] has joined #ubuntu-devel [12:52] Chipzz: Though in the case of potato->sarge, yes, they should have been updated for policy changes if nothing else. [12:52] there's still several transitions, like the c++ ones [12:53] I don't maintain anything that uses C++. :) [12:53] The only transition I've ever been subject to was the old /usr/doc -> /usr/share/doc transition. [12:53] what I was trying to point out is that it's probably pretty rare to have the same versions across releases [12:53] Not really. And certainly not in Ubuntu. [12:53] Since we release frequently, we have plenty of packages that don't change. === Fujitsu [n=fujitsu@c211-28-183-112.eburwd7.vic.optusnet.com.au] has joined #ubuntu-devel [12:54] Like i said, there are lots (LOTS) of packages with the same version in warty, hoary, breezy, AND dapper. [12:54] And far more for just, say, breezy/dapper. [12:54] <\sh> apaapa [12:54] <\sh> infinity: [12:54] <\sh> adsasd [12:55] <\sh> grmpf === desrt wonders what Loki is doing in his ACPI tables [12:55] jdub: should we use the ubuntu-traffic list for the ubuntu weekly newsletter (or some other list) or should we create a proper ubuntu-newsletter list maybe? [12:55] <\sh> what was that,,,3 minutes no keyboard input and then again? [12:55] mgalvin: ubuntu-news exists already [12:56] mgalvin: is perfect for your newsletter [12:56] mdke: oh right, duh === mgalvin *blushes* [12:56] infinity: I think I will use debootstrap, because I don't really trust what will do ubiquity. I want to install on a second partition that is on LVM [12:56] mgalvin: it's very underused [12:57] i see, one or two posts a month :) === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-devel [01:00] \sh: the cat walking across the keyboard? ;) [01:00] <\sh> Chipzz: no..keyboard just didn't reply..and I was hammering on the keyboard like a cat walking across the keyboard ;) [01:01] infinity: ok, ubiquity is useless since I use LVM [01:01] oh I see :) [01:02] mirak: use the alternate install CD [01:03] I will use the netinstal.iso I think [01:04] sladen: I wanted to know if there is a way to run the installer script that is on the alternate install CD but from a running distro [01:05] mirak: debootstrap ? [01:05] mgalvin: ubuntu-news [01:06] jdub: yup, thanks, we will use that [01:06] jdub: is planet still getting a 404 from my blog? I'm wondering if there is something wrong on my end [01:07] mirak: out of interest, what are you actually trying to achieve? [01:07] sladen: it's a piece of the puzzle. I would find intersting to have all the steps [01:08] sladen: I just want to install to another partition a clean dapper. in fact I already deboostraped, but I really wonder why I can't just have all the steps and a guide like with the installer on the alternate installer [01:09] I just wasting my time in fact ;) [01:09] mirak: apt-get source debian-installer [01:10] sladen: ah !!! thanks [01:10] mirak: ultimately it calls debootstrap [01:19] is there any way to put my root filesystem on a ramdisk without using initrd? [01:19] desrt: #ubuntu might be able to help [01:19] good call === sorush20 [n=sorush20@82-43-184-143.cable.ubr07.newm.blueyonder.co.uk] has joined #ubuntu-devel [01:34] hi ugys just wanted to know if this bug would be fixed soon or later? [01:34] "this" being...? [01:34] https://launchpad.net/distros/ubuntu/+source/cupsys/+bug/43824/+index [01:34] Malone bug 43824 in cupsys "HP Laserjet 1000 doesn't work with cups2" [Normal,Confirmed] [01:34] sorush20: "sooner or later" is a good approximation, yes [01:34] crimsun: you develop too? [01:35] did I tell you about the amarok bug too? [01:35] not cups*, but I'm involved. [01:35] which one? [01:35] well is there anyway that I can print? [01:35] and the bug is better addressed in -bugs [01:36] is martin pitt here? [01:36] Martin Pitt [01:36] pitti is not present; it's the weekend [01:36] okay.. [01:36] I have not idea why I upgraded to dapper knowing there would be these problems.. [01:37] GDI printers annoy me, cheap and nasty === \sh [n=shermann@xdsl-84-44-156-168.netcologne.de] has joined #ubuntu-devel [01:38] but runs fine in breezy [01:39] how would I downgrade to breezy cupsys? [01:40] sorush20, you reinstall breezy - walking back is not the way forward, you could try to change the sources but would it work I have no idea [01:40] sorush20, doing it like a dist upgrade === JaneW [n=JaneW@dsl-146-167-152.telkomadsl.co.za] has joined #ubuntu-devel [01:43] sorush20: this is not a support channel; either ask on #ubuntu, or read apt-get's man-page to find out how to downgrade a package === Fjodor [n=sune@0x55510b65.adsl.cybercity.dk] has joined #ubuntu-devel [01:46] sorush20: (if at all possible of course; but I think it would involve something like apt-get install -t breezy ...) === eggauah [n=daniel@200.228.25.81] has joined #ubuntu-devel === Jimmey__ [n=james@user-6843.lns5-c7.dsl.pol.co.uk] has joined #ubuntu-devel === Jimmey__ [n=james@user-6843.lns5-c7.dsl.pol.co.uk] has left #ubuntu-devel [] === mdz [n=mdz@george.kkhotels.co.uk] has joined #ubuntu-devel === DShepherd [n=dwight@port0151-afr-adsl.cwjamaica.com] has joined #ubuntu-devel === Burgundavia [n=corey@ubuntu/member/burgundavia] has joined #ubuntu-devel === shawarma [i=foobar@sirius.linux2go.dk] has joined #ubuntu-devel [01:57] sorush20: no pvt messages please === sorush20 [n=sorush20@82-43-184-143.cable.ubr07.newm.blueyonder.co.uk] has left #ubuntu-devel [] === Fjodor_ [n=sune@0x55510b65.adsl.cybercity.dk] has joined #ubuntu-devel === robitaille [n=daniel@ubuntu/member/robitaille] has joined #ubuntu-devel [02:05] <\sh> any way to get rid of those processes? root 6086 0.0 0.0 0 0 ? S 01:57 0:00 [mmcqd] === Chipzz is now known as Chipz === Chipz is now known as Chipzzz === Chipzzz is now known as Chipzz [02:08] \sh: I may be mistaken, but looks like a kernel process from a driver? [02:08] <\sh> Chipzz: it should be the mmc card reader...and I have two of them now, and I'm not able anymore to mount a sd card ;) [02:09] have you tried stopping the process accessing the card reader? [02:10] I have similar processes like that when using /dev/video from ivtv [02:10] they go away when I quit mplayer [02:11] <\sh> Chipzz: hmm... [02:12] <\sh> automounting is what process? udev? hal? dbus?? [02:12] just try unmounting it? [02:12] <\sh> it's not mounted [02:12] <\sh> but it was mounted [02:12] <\sh> and I removed it to fast it seems [02:13] hrrrm [02:13] <\sh> let's leave it for now.. [02:13] <\sh> I'll go to bed just now. [02:14] nn :) [02:14] <\sh> thought i can build quickly a SD gpg key container with dm-crypt support [02:15] <\sh> but it looks like that I'm screwed with automount in the moment ;) [02:15] it's possible it's a bug in the driver too [02:15] (I guess) [02:16] like, you unmounted correctly, but that process failed to quit [02:16] <\sh> Chipzz: if removing the card is a correct unmount, but I doubt it ;) [02:17] if it's still mounted, you can always try putting it back in and unmounting properly [02:17] <\sh> Chipzz: but if I'll try to reproduce it, to let mount a not formatted sd card ;) [02:17] (like a floppy disk) [02:18] *g* :) [02:18] <\sh> cryptsetup -y create gpgkeys /dev/mmcblk0pl1 \n mkfs.ext2 /dev/mapper/gpgkeys and then remove it [02:18] <\sh> et voila screwed up [02:22] \sh: is this you? http://www.uni-koeln.de/bin2/maillist/linux-fai/20060531.095843/171988 :) [02:23] <\sh> Chipzz: yes [02:23] <\sh> Chipzz: how did you find it? [02:26] \sh: fai homepage [02:26] just browsing the archive [02:26] <\sh> Chipzz: ah :) === rpedro_ [n=rpedro@87-196-70-42.net.novis.pt] has joined #ubuntu-devel === bioeng [n=bferguso@68.216.133.80] has joined #ubuntu-devel [02:33] Hi everyone [02:33] I'm having some programming related problems that I could use some help with [02:33] bioeng: -> #ubuntu [02:33] bioeng: This isn't a support channel for development on Ubuntu, it's a channel for the developing *of* Ubuntu. [02:34] ok [02:34] I'll try that channel === Hobbsee [n=Hobbsee@ubuntu/member/hobbsee] has joined #ubuntu-devel === LaserJock [n=mantha@ubuntu/member/laserjock] has joined #ubuntu-devel [02:37] infinity, he will probably get more help in here. [02:37] welp. it just sucks. === desrt compiled a kernel with no drivers (seriously... no drivers) [02:38] it still does not sleep [02:38] or rather, wake up from sleep === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-devel [02:38] My question was to ask if it would be a good idea to do a CS minor while finishing my EE degree [02:38] desrt: Fun [02:39] So the kernel's blowing up somewhere in generic code [02:39] but I'll go to another room if necessary [02:39] You're under boot camp, right? [02:39] i had another thought [02:39] ya. bootcamp [02:39] Ok [02:39] what if it was failing to set the proper parameters on the DRAM before going to sleep [02:39] and by the time it woke up again it had forgotten who it was [02:39] That's possible, but unlikely [02:39] (That is, I've found one machine ever that appears to do that) [02:40] think i'll have better luck with efi? [02:40] The Intel datasheets are public - you're looking for "self refresh" [02:40] No, you'll have no luck at all with efi [02:40] no acpi there i assume === bioeng [n=bferguso@68.216.133.80] has left #ubuntu-devel [] [02:41] in your opinion what is the next most likely problem? [02:41] Oh, acpi, but completely absent testing of it ever in the slightest [02:41] (btw... i tried the s3_ flags and i also enabled USB and HID support in my kernel to see if i could at least see capslock working -- no love) [02:41] It's utterly broken [02:41] Anyway. [02:42] Next thing to try is shoving reboots in arch/i386/kernel/acpi/wakeup.S [02:42] that's the entry for coming back from sleep? [02:43] is there a kernel sponsored way to reboot or should i just try and trash my cr2 and hope for a triple fault? [02:43] Just cut and paste the triple fault code from include/asm-i386/mach-default/mach_reboot.h [02:43] Oh, hang on, that's not where it is [02:43] oo. pre-programmed triple fault :) [02:44] Might be under arch/i386 somewhere [02:44] ok [02:44] The fallback reboot code is to do a triple fault [02:44] nod. that never fails :p [02:44] So then see if it's ever getting into the wakeup code in the first place [02:44] do x86 chips still come up in real mode at 0xf0000 these days? [02:44] Seemingly so [02:44] wow [02:44] it's in kernel/reboot.c [02:44] Well, not /quite/ [02:45] case 'h': /* "hard" reboot by toggling RESET and/or crashing the CPU */ [02:45] Coming back from acpi sleep, it immediately jumps to the address put into the wakeup code register [02:45] reboot_thru_bios = 0; [02:45] break; [02:45] mjg59; i bet it does that by going to 0xf0000 first [02:46] Riddell: around? [02:46] desrt: Yeah [02:46] mjg59; there's a special memory address you can set in the PC bios (in the 0000:0400 range) which causes the power-on BIOS code to jump to some address VERY quickly [02:46] But at that side of things, the hardware is supposed to be dealing with it [02:46] It's not something an ACPI OS needs to care about [02:47] so..... [02:47] because this isn't really a real PC [02:47] So if it gets all the way through the wakeup code, you get to stick reboot calls in the C code [02:47] i assume the firmware copies some bios boot block code into the f000 segment.... [02:47] and we have to hope that nobody tries to modify it [02:47] ACPI /sortof/ works on the minis and MBPs [02:47] (Reportedly) === chiddy [n=chiddy@pool-70-20-127-234.pitt.east.verizon.net] has joined #ubuntu-devel === joel_ [n=joel@200.208.133.109] has joined #ubuntu-devel [02:48] desrt: Giving 2.6.17-rcwhatever might be worth a go [02:48] Just to make sure it's not something that's been fixed already [02:48] that's a good idea [02:48] i'm using 16 now [02:49] Or even -mm [02:49] i have to admit i'm confused. apple must have ROM blocks at 0xf0000 [02:49] or else when the hardware came up (really came up, at first).... [02:51] i miss the good old days of serial and parallel ports [02:52] back in the day when you could toggle some external pin on the machine with a single instruction [02:52] debugging was more fun [02:53] Oh, yeah, I've done ACPI debugging with a panel of LEDs on the parallel port [02:53] this laptop screams when it comes to building kernels === nokko [n=ubuntu@195-245-89-185.dtcom.ro] has joined #ubuntu-devel [02:54] Fujitsu: still there? [02:54] Yes. [02:54] I'm always here :) [02:54] Fujitsu: could we please go private? (i am the person with the bug) [02:54] Fujitsu: i see that people here don't like us talking about bug reports [02:55] OK, nokko. === TomB_ [n=ownthebo@ACCA062F.ipt.aol.com] has joined #ubuntu-devel === \sh__ [n=shermann@xdsl-81-173-254-3.netcologne.de] has joined #ubuntu-devel [03:04] uh [03:04] how is one supposed to make a call to a .c file from real mode? [03:06] from real mode ? [03:06] Is this on topic? [03:06] are you tinkering with the boot code or what ? [03:06] desrt: You don't? === desrt is left wondering how to reboot the system.... [03:07] __asm__ __volatile__("int3"); [03:07] that'll triple-fault me? [03:07] Read machine_emergency_restart() from kernel/reboot.c [03:08] oh. you need an empty IDT for that to work [03:08] and you also need to be in protected mode [03:08] i don't think realmode supports the idea of triple-faulting [03:09] why not? [03:09] desrt: machine_real_restart may provide some hints.. [03:09] desrt, may I ask what you're doing ? [03:10] shackan: Tripping a reboot during kernel setup, to see where his resume is failing. === Amaranth [n=amaranth@ubuntu/member/amaranth] has joined #ubuntu-devel === joel_ is now known as magicstorm [03:10] infinity; intense.... === desrt just jumps to bios :) [03:10] kprintf'ing something more verbose and then do __asm__ __volatile__("cli; hlt;") and halt the machine ? :) === sorush20 [n=sorush20@82-43-184-143.cable.ubr07.newm.blueyonder.co.uk] has joined #ubuntu-devel [03:14] hi guys any development on this bug [03:14] https://launchpad.net/distros/ubuntu/+source/amarok/+bug/45487/+index [03:14] Dude, you were just in here an hour or two ago, asking about cups bugs, AND you brought that one up. [03:14] <\sh> sorush20: #kubuntu-devel [03:15] sorush20: This is not a support channel. Bugging people about YOUR pet bugs does not get them fixed faster. [03:15] <\sh> sorush20: and it's not a supported package... [03:15] infinity for dpl! [03:15] upl? [03:15] that's an appointed position :) [03:15] Fujitsu: i think the main problem with ubiquity is that it doesn't show intelligent errors: for instance, now i moved all the data into just one folder on the same partition (for backup purposes) and it crashed much later, with similarly strange errors. then i ran a df -h and it showed me "use% -- 100%" (which means partition is full). [03:15] desrt, descriptor privilege level ? :D [03:15] Fujitsu: it should simply say: partition full. right? [03:16] Fujitsu: i mean, it should even check for this from the beginning! [03:16] makko, yes, it's not particularly good at the moemnt. [03:16] Fujitsu: i think checking it from the beginning is simple to implement and i simply don't understand why it doesn't. [03:17] Fujitsu: i mean... how can you begin to install if you can very easily make sure you don't have enough space on the partition? [03:17] SCORE [03:17] my system reboots on wakeup from sleep now [03:17] good thing we decided to teach that assembly class last term about oldschool DOS x86 stuff :) [03:18] <\sh> desrt: hmmm....oldschool dos x86 stuff? teach them z80 ;) [03:18] heh [03:20] Hmm, we don't have xulrunner in the archive? [03:21] bddebian: We will somewhere shortly after Tuesday. [03:22] <\sh> bddebian: apt-cache search xulrunner says no [03:22] bddebian: It hit Debian too late to be useful for dapper. [03:22] infinity: OK, thx [03:22] <\sh> good night folks === ealden [n=ealden@202.128.54.110] has joined #ubuntu-devel [03:22] Fujitsu: maybe you could tell ubiquit devs about implementing better error messages and checking space available. i guess ubiquity only checks partition size and assumes it's being formatted. [03:23] ubiquity [03:23] makko, they are going to fix it a lot, I guess. [03:28] infinity: Do you happen to know much/anything about it? === desrt just did something comically stupid [03:29] wow. [03:29] step 1: be sure to make a backup copy of your MBR [03:29] step 2: blow the MBR away [03:29] step 3: realise that you saved the backup copy of the MBR on the harddrive itself [03:30] bddebian: It? [03:30] bddebian: Oh, xulrunner? A bit. [03:30] desrt: But you can boot from CD, so it's all good. [03:31] infinity; but... my harddrive.... [03:31] infinity: Any idea why there is no i386 build log on p.d.o? [03:31] desrt: MBR != Partition table... [03:31] desrt: Unless you zeroed a LOT of sectors... [03:31] infinity; ok. "the first 512 bytes of my disk" [03:31] which contain both the mbr and the partition table [03:31] desrt: First 512 bytes is just the MBR. No reason you can't mount that disk from a CD boot. [03:31] you are wrong [03:32] I are not. [03:32] first 512 bytes also contains the partition table [03:33] explain to my why, then, the boot CD doesn't seem to think i have partitions :) [03:33] Probably because I'm wrong. ;) [03:34] desrt: maybe it's just teasing you [03:35] Fujitsu: wow, already 87 updates? [03:35] makko, yes. [03:35] Fujitsu: that's what adept notifier says [03:36] Fujitsu: from now on i guess it's much better for canonical to release a community edition (like mandriva) and then, after one month, a final version. that way we'll get more beta testers. [03:37] makko: Dapper has been available to the "community" for months [03:37] bddebian: then i don't understand why so many bugs are being detected so late [03:37] bddebian: really... it frustrates me [03:38] makko: that's not a reflection of the development, that's a reflection of people testing it at a given time [03:38] bddebian: maybe most of them download the live cd only when it's "official" enough [03:38] makko: I don't recall seeing your nick around prior to very recently? [03:38] bddebian: i changed it, why? [03:38] bddebian: oh, and i am new to #ubuntu-devel === robitaille [n=daniel@ubuntu/member/robitaille] has joined #ubuntu-devel [03:43] crimsun, bddebian, Fujitsu: so i think it would be very helpful if we advertized two "official" releases, like mandriva. what do you think? [03:43] makko: I don't see the difference. And if you live Mandriva, go to Mandriva [03:43] The Ubiquity disaster has been a bit bad. [03:43] "disaster"? [03:44] I would categorise it as a disaster. [03:44] Aye what disaster? [03:44] bddebian: why do you say i like mandriva? [03:44] bddebian: did i offend you? [03:44]