[12:31] BenC, feel free to git pull hera.kernel.org:/pub/scm/linux/kernel/git/kyle/ubuntu-hppa.git branch master. [12:31] i've revvi've reverted the async scsi stuff which should help. === roh [n=roh@yamato.hyte.de] has joined #ubuntu-kernel [02:09] BenC: around? === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [03:06] BenC: http://70.29.57.2/ubuntu/xen/xen-naming.patch it only touches the xen bits [03:13] Keybuk: yeah [03:13] zul: ok [03:14] sweeeet...ill upload a new one tomorrow === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel [03:16] zul: I'll upload kernel-package [03:16] I need my changes in it [03:16] ok sounds good [03:17] im just rewriting the rules file so it uses kernel-package [04:00] BenC: can we get linux/linkage.h back? :) [04:00] http://librarian.launchpad.net/3507234/buildlog_ubuntu-edgy-i386.sysklogd_1.4.1-18ubuntu2_FAILEDTOBUILD.txt.gz === johanbr [n=j@d154-20-189-105.bchsia.telus.net] has joined #ubuntu-kernel [04:23] morning [04:47] BenC: ping? [05:55] Keybuk: ok [05:55] fabbione: hey [06:15] BenC: yo [06:15] BenC: do you feel like looking into the cluster stuff or is it too late for you? [07:27] fabbione: sorry, too much going on for the past hour or so, and I'm beat [07:29] BenC: no problem.. === johanbr [n=j@d154-20-189-105.bchsia.telus.net] has joined #ubuntu-kernel === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel === lloydinho [n=andreas@rosinante.egmont-kol.dk] has joined #ubuntu-kernel === pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl] has joined #ubuntu-kernel === johanbr [n=j@d154-20-189-105.bchsia.telus.net] has joined #ubuntu-kernel === pmjdebruijn [n=pmjdebru@pmjdebruijn.xs4all.nl] has joined #ubuntu-kernel === johanbr [n=j@d154-20-189-105.bchsia.telus.net] has joined #ubuntu-kernel === doko [n=doko@dslb-088-073-104-250.pools.arcor-ip.net] has joined #ubuntu-kernel === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel [12:35] http://paste.ubuntu-nl.org/18511 [12:36] do I have to be root? === zul [n=chuck@CPE0006258ec6c1-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel === ajmitch [n=ajmitch@ubuntu/member/ajmitch] has joined #ubuntu-kernel === fs [i=fs@213.178.77.98] has joined #ubuntu-kernel [02:07] BenC: when you wake up can you please pull from my edgy branch? [02:07] BenC: i have 2/3 fixes for GFS and GFS2 [02:07] we are only missing one from upstream now that i have no idea what to do about [02:07] and if you can manage to upload before you leave for holidays i can get the rh-c-s binaries to build too === Traxer|off [i=traxer@shell6.powershells.de] has joined #ubuntu-kernel === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel === kylem [n=kyle@cabal.ca] has joined #ubuntu-kernel [02:13] hey [02:15] BenC: so when are you going to upload a new kernel-package? [02:16] i hope he is going to do everything today before he goes in holidays [02:16] otherwise sparc is borked for headers and so are other arches :) [02:16] and packages [02:16] and ... [02:16] a.. [02:16] .. [02:16] . [02:16] when does his holidays start? [02:17] end of his friday i guess [02:19] oh.. === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel === thom [n=thom@amnesiac.heapspace.net] has joined #ubuntu-kernel === tuxmaniac [n=aanjhan@unaffiliated/tuxmaniac] has joined #ubuntu-kernel === nigel_c [n=nigel@nigel.suspend2.net] has joined #ubuntu-kernel === ivoks [n=ivoks@ubuntu/member/ivoks] has joined #ubuntu-kernel === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-kernel === fabbione [i=fabbione@gordian.fabbione.net] has joined #ubuntu-kernel [04:45] fabbione: actually, I'll be around till Sunday afternoon [04:45] but I am planning on an upload tonight [04:45] BenC: well it's weekend :) [04:45] not it isnt :) [04:46] kernel-package + grub + linux [04:46] BenC: btw the OOM killer doesn't work. i just found out by mistake [04:46] not for me yet :) === Kamion [n=cjwatson@83-216-156-196.colinw664.adsl.metronet.co.uk] has joined #ubuntu-kernel [04:59] just trying to find some documentation on the suspend format [04:59] so, the swsusp format appears to be: [05:00] PAGE_SIZE with 10 bytes at the end reading "S1SUSPEND\0" [05:00] then a struct swsusp_info [05:00] it replaces the entire swap partition? [05:00] think so, S1SUSPEND goes in the same place as SWAP-SPACE or SWAPSPACE2 AFAICT [05:01] see power/swsusp.c:mark_swapfiles [05:01] now, a struct swsusp_info is { struct new_utsname; u32; unsigned long; int; unsigned long; unsigned long } [05:01] BenC, Keybuk: well something is stored in md sb as i pasted on -devel [05:02] fabbione: can we not have this conversation right now, please [05:02] the corresponding bit of a swap partition is { unsigned int version; unsigned int last_page; unsigned int nr_badpages; unsigned char uuid[16] ; char volume_name[16] ; ... } [05:03] right [05:03] the swap partition is at the start of the page [05:03] uh [05:03] swap partition header [05:03] and the SWAPSPACE2 bit is at the end [05:04] the start of a swap partition is a char[1024] to allow room for boot images [05:04] the SWAPSPACE2 is right at the end of that [05:04] right [05:04] and the other fields like uuid and stuff immediately follow [05:04] uh, no [05:04] wrong [05:04] the start of a swap partition is a char[1024] [05:04] THEN the header struct [05:05] the SWAPSPACE2 is definitely at the very end of the page [05:05] it reads 0+PAGE_SIZE_10 [05:05] 0+PAGE_SIZE-10 [05:05] even [05:05] oh, sorry, you're right [05:05] page size confusion on my part [05:05] volumne_name appears to be the "label" [05:06] and uuid is obviously the UUID [05:06] yes, it is [05:06] (though mkswap doesn't have an option to set the UUID) [05:06] it generates it automatically [05:06] right [05:06] how come the installer didn't do that? custom mkswap? [05:06] busybox mkswap, yes [05:06] I'm pulling the uuid changes into that [05:06] d-i is more NIH than I am :) [05:06] :) [05:06] Keybuk: keep dreaming [05:07] ok [05:07] now the swsusp header goes at the END of the page too, by the looks of it [05:07] Keybuk: sure we can wait after stuff is broken and data lost.. no problem at all [05:07] it has a reserved block on the front of PAGE_SIZE - 20 - sizeof(swp_entry_t) [05:08] fabbione: dude, if you're not going to be helpful and go find out whether the RAID stuff actually does hardcode sd* names in the block somewhere, please be quiet [05:08] Keybuk: i told you before what is hardcoded. major and minors [05:08] he said on #ubuntu-devel that it hardcodes major numbers in the block [05:09] fabbione: ok, then it's broken [05:09] still, it might be helpful to tackle one problem at a time [05:09] and probably broken today, in fact [05:09] explains a few bugs [05:09] back to swap [05:09] Keybuk: well then the transition need to take that into account. You can't just break stuff like this [05:10] fabbione: dude, it's already broken [05:10] dapper won't guarantee ordering of multiple scsi devices [05:10] neither did breezy [05:10] this is us trying to FIX that [05:11] ok don't break my raid.. i don't care about others. [05:12] heh [05:14] static struct swsusp_header { [05:14] char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)] ; [05:14] swp_entry_t image; [05:14] char orig_sig[10] ; [05:14] char sig[10] ; [05:14] } __attribute__((packed, aligned(PAGE_SIZE))) swsusp_header; [05:14] Kamion: ^ so it appears that the swsusp header contains a copy of the original swp_entry_t [05:15] so a swsusp first page looks like "Blah blah blah ... swp_entry_t SWAPSPACE2 S1SUSPEND" === BenC [n=bcollins@debian/developer/bcollins] has joined #ubuntu-kernel [05:15] oh yes, good point, I hadn't got round to figuring out what orig_sig was [05:15] yeah [05:15] ok, messing with swap on a running system turns out to be a bad idea [05:16] I'm trying to find the resume code [05:16] to see how it puts it back [05:18] BenC: how ba? [05:18] d [05:19] Kamion: crash with a fsck bad [05:19] yum [05:19] BenC: what did you do? [05:20] Kamion: dunno about you, but I haven't found yet where it restores the original swap header [05:20] Kamion: swsusp_check [05:20] Oh, sorry, no, that's only in the failure case [05:21] No, wait, that's right [05:21] if (!memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) { memcpy(swsusp_header.sig, swsusp_header.orig_sig, 10); /* Reset swap signature now */ error = bio_write_page(0, &swsusp_header); [05:21] Grah, irssi hate [05:21] unintuitive naming, but right [05:21] The original signature is in the swsusp header, so it just copies it back [05:22] "Check for swsusp signature in the resume device and munge it" [05:22] this is confusing me ... these two bits of code seem to put the swp_entry_t in different places [05:23] oh, grr, swp_entry_t != swap_header [05:23] right [05:23] so swsusp does blat the header of the swap partition [05:23] GO SWSUSP! [05:25] are you sure? it reads the existing contents first [05:25] it does? [05:25] I think experimentation might be better than reading the code here [05:25] tbh, I think we just need to test this [05:25] if ((error = bio_read_page(0, &swsusp_header))) [05:25] return error; [05:25] if (!memcmp(SWSUSP_SIG, swsusp_header.sig, 10)) { [05:25] mjg59: care go guinea pig for us? you're the one man in the universe whose laptop can suspend and resume [05:26] can I suspend/resume in vmware, I wonder? [05:26] Wait, what's the problem you're working on here? [05:26] Kamion: that was just "mkswap -L `uuidgen`", which probably isn't what we wan't anyway [05:26] mjg59: finding swap devices by UUID [05:26] in particular, making sure that the UUID in the swap partition isn't destroyed by suspending [05:27] BenC: oh you completely rewrote the swap then - that will have zeroed the existing contents and stuff [05:27] I was thinking more of just dd'ing in a UUID [05:27] Ah, right [05:27] Can't right now. Or even this weekend, really... [05:27] I'm doing a fresh install in vmware at the moment; if swsusp will work there then I'll try it [05:28] Kamion: from what I remember, it works [05:28] There's no reason for swsusp to blat the uuid, so yeah, fixing it so it doesn't should be fine [05:28] mjg59: however, if it does in the current kernel, we're already screwed [05:29] since this is for dapper->edgy upgrades [05:29] we're pretty much stuck with whatever the dapper kernel does [05:30] well you can still mount / by uuid and write these info somewhere on the filesystem (for the swap) perhaps? [05:30] something like: [05:30] hash the last 4K of the swap [05:30] reboot [05:30] check for swap partitions [05:30] rehash to figure where the partition is gone [05:30] take action? [05:31] Oh, the risk that they'll upgrade then suspend and lose the uuid? [05:32] wouldn't that happen even booting on another linux distro that does mkswap at boot? [05:32] fabbione: yeah, sounds possible, but if we can do it all directly on upgrade then that's obviously better [05:32] fabbione: do those exist? [05:34] Kamion: i don't know.. i haven't used any distro != Debian || Ubuntu for the last 4 years [05:34] Sharing swap isn't a supported configuration, is it? [05:34] I don't think there's much we can do about that case [05:34] Given that we suspend into it [05:34] i think we could use partition roundings [05:34] there is always some space in between partitions [05:34] mjg59: there exist people who don't suspend to disk :-) [05:35] for them, it will work apart from this theoretical problem [05:35] we might be able to reuse it [05:35] like the block immediatly after the end of the swap [05:35] i doubt it's the start of the next partition (needs to be checked) [05:35] I'm much more comfortable sticking to the UUID if we can [05:35] if that space is really empty, we can make use of it [05:35] it's simpler and supported by existing tools [05:36] and the failure mode with swap is not as bad as the failure mode with other partitions [05:36] Kamion: Sure, but it's enabled by default. The supported install configuration is incompatible with shared swap. [05:36] Kamion: yes so am I but i am considering alternatives [05:36] if it fails, people don't have swap, big deal, they can fix it once they've booted [05:36] mjg59: only if you *actually suspend* [05:36] which desktop users will to a good first approximation never do [05:37] mjg59: yes, I agree that for laptop users it can't be supported [05:37] but we've never explicitly advertised it as unsupported either, and for desktop users it will always have worked well [05:37] echo -n "LABEL" | dd conv=trunc of=SWAP obs=1 seek=1052 [05:37] for the adventurous :p [05:37] label, not uuid? === Kamion would prefer uuid ... === fabbione goes to help wife [05:38] uuid is harder to encode for "testing whether one can mangle an active swap partition" purposes [05:38] if you want to write the uuid, just write to 1036 instead [05:41] Kamion: I think if there's a feature that's enabled by default that will destroy data in certain configurations, either (a) that feature shouldn't be enabled or (b) that configuration shouldn't be supported [05:41] what does "be supported" mean though? [05:41] "If you do this and stuff breaks, it's your problem not ours" [05:41] in practice, since we've never advertised it as unsupported, it appears to mean "we will feel free to fuck your system without prior warning if you didn't realise you couldn't do that" [05:41] which is a bit harsh [05:42] Well, in this case the system fucking would be limited to your swap potentially vanishing [05:42] right, so it's not too bad - but I'm just very very uncomfortable with dismissing problems as "unsupported" when we never warned people about them [05:43] I think when we're faced with a choice of "effectively impossible" or "may irritate someone who ought to be smart enough to fix it", we're effectively obliged to choose the latter and document it [05:43] Doing impossible things is outside our remit, no matter how happy it may make users :) [05:46] right, just saying that the "and document it" is not optional, and ideally needs to be in-their-face during the upgrade [05:47] uuidgen | perl -ne 's/-//g;print "%c",hex %1 while(/(..)/g)' | dd conv=notrunc of=/dev/hda5 obs=1 seek=1036 [05:48] s/print/printf [05:48] yes, sorry, mis-typed into IRC [05:48] and s/%1/\$1/ [05:49] that appears to survive a swapoff/swapon [05:53] and it survives a reboot [05:54] ok, so where we have an active (or inactive) swap partition without a UUID, we can modify it to include one without disturbing the running system [05:54] that check should include an "is a swap partition" check, obviously [05:54] that leaves us with [05:54] - v0 swap partitions (no UUID) [05:54] - partitions with a resume image [05:55] what do we do about those? [05:55] They haven't been supprted since 2.2, have they? [05:56] v0 swap partitions, that is [05:57] dunno, the documentation just implies that they were the only version supposrted before 2.2 [05:57] right [05:57] they're not supported ;) [05:57] you can't swapon a v0 partition [05:58] ok, so that just leaves us with partitions with a resume image [05:58] (and just thought, how do we find the resume image? :p) [05:58] Is there space in the header for a UUID? [05:58] Ha. That's a fun one. [05:58] mjg59: which header? [05:58] The swsusp header. [05:58] if swsusp includes the original swap header, we could just give resume= the smarts to find that [05:59] We need to deal with the situation where resume fails and swsusp doesn't redo the header [05:59] btw, any particular reason resume= is necessary? couldn't one just iterate /proc/partitions and look for a S1SUSPEND partition? [05:59] No, because you might have multiple OSs installed [05:59] does swsusp do that often? [05:59] that'd leave them with dead swap anyway, no? [05:59] swap wouldn't necessarily be shared [06:00] If you don't mount filesystems between them, that's a prefectly reasonable configuration [06:00] so the choice is what to do when we find them [06:02] Check whether they have the correct uuid and resume them? [06:05] right, I mean at upgrade time [06:06] someone upgrades from dapper to edgy, and we find that something listed in /etc/fstab as a swap partition to be mounted on boot is not active and contains a suspend image [06:06] I guess this is easy, we write a UUID into the right bit of the image [06:06] They're fucked anyway, presumably? [06:06] and adjust the resume= so whenever that does get resumed, it will work [06:06] Or do we support booting edgy with a dapper kernel? [06:07] we don't "support" it [06:07] I don't see any reason it wouldn't boot though [06:07] Ok [06:07] dapper->edgy isn't that large a jump [06:07] Kamion: do you concur? [06:07] dapper kernel won't write a uuid into the suspended image [06:07] mjg59: ? [06:08] I don't quite understand the situation you're suggesting [06:08] They're on dapper. They upgrade to edgy. They suspend? [06:08] Also, we don't have a resume= [06:08] That information lives in the initramfs [06:10] no [06:10] they're on dapper [06:10] they have a swap partition listed in /etc/fstab [06:10] that swap partition is not active, and contains an S1SUSPEND image [06:10] they upgrade to edgy [06:10] during the upgrade, while still in dapper [06:10] Whose suspended image is it? [06:11] Does it belong to the dapper system? [06:11] can we tell that? [06:11] I don't /think/ you can ever get into that situation [06:11] if it's in /etc/fstab, IMO, it belongs to dapper [06:11] mjg59: failed resume? [06:12] If it's a dapper image (a) it should have been mkswapped during resume, and (b) if it's resumed now it'll cause massive filesystem corruption [06:12] Keybuk: if so, then the failure is too late for recovery [06:12] mjg59: mkswapped during resume? [06:12] Keybuk: The failed resume, sorry [06:12] do you mean "mkswap run" or do you mean "the original swap header restored" ? [06:12] Though it's possible that that bug never got fixed [06:12] Failed resume should result in the suspended image being turned back into swap [06:13] right, but _NOT_ using mkswap, right? [06:13] We may use mkswap at the moment [06:13] do you know where I can find that out? [06:13] Though I think the kernel actually fixes it [06:13] Actually, yes [06:13] swsusp_check will rewrite it [06:13] ok, I can't find mkswap anywhere in the initramfs or boot scripts [06:13] So original swap header restored, I believe [06:14] ok [06:14] so we found a swap partition in /etc/fstab that contains a resume image [06:14] what we do? [06:14] mkswap [06:14] Yes [06:15] once they boot ignoring that resume image, the resume image is useless [06:15] Allowing that image to be restored would be actively dangerous [06:15] exactly [06:16] ok, that's fine [06:16] now, we do need to deal with resume= [06:16] We don't use resume= [06:16] we don't? how do we resume from hibernate? [06:16] context change, btw [06:16] we've upgraded the system, it's now running edgy [06:16] they want to suspend and resume [06:17] resume=/dev/hda5 ain't gonna work [06:17] We have a RESUME= statement in /etc/initramfs-tools/conf.d/resume [06:17] Initramfs generates a major and minor from that and echoes them into /sys/power/resume [06:17] right [06:17] so we need to extend initramfs to support RESUME/resume=UUID=... [06:18] and have it iterate /proc/partitions, look for a hibernate image on a swap partition with the given UUID [06:18] Please don't use "rescue=", that's a separate codepath [06:18] eh? [06:18] Uh, "resume=" [06:18] Mentioning it confuses the situation [06:18] resume= looks like the same code path to me [06:18] export resume=${RESUME} [06:18] Indirectly [06:18] resume=*) [06:18] resume=${x#resume=} [06:18] ;; [06:19] RESUME is otherwise entirely unmentioned in the initramfs code [06:19] The traditional semantics for "resume=" is that it's parsed by the kernel [06:19] is it still parsed by the kernel? [06:19] In our case, possibly not, but we never write any configuration that uses it [06:19] right [06:20] does RESUME=UUID=... sound insane? [06:20] No, that's fine [06:20] We change /etc/initramfs-tools/conf.d/resume [06:20] Ideally before and after point to the same partition [06:20] Then it just needs a small amount of work in initramfs-tools [06:20] "before and after point" ? [06:21] The partition pointed at before the rewrite should be the same as the one pointed at afterwards [06:21] right [06:21] that's ideally what we're shooting for :) [06:21] the difference is before it'd be /dev/?d?? but after would be UUID=... [06:21] Yes [06:22] with the advantage that after, it'll work even if the disk jumped from hda5 to sdb5 :p [06:22] you wouldn't want to just to /dev/disk/by-uuid/* ? [06:22] less code [06:22] Keybuk: Not quite [06:22] BenC: /dev/disk/by-uuid doesn't (yet) know about extracting a UUID from a suspended image [06:22] actually, no code changes if you do that [06:23] BenC: we use UUID=* elsewhere for consistency [06:23] Keybul: it's different than a swap image? [06:23] BenC: dunno yet [06:23] still waiting for Kamion to come back from vmware [06:23] Keybuk: It won't handle that if the change happens over a suspend/resume cycle [06:23] ok [06:23] But that's a massively pathological case, so [06:23] mjg59: can the change happen over a suspend/resume cycle? [06:23] If they move disks around, yes [06:24] It'll deal fine with the drivers/ide -> libata conversion [06:24] if they resumed before upgrade, changes are they did it from a dapper kernel [06:24] uh, doesn't this change mean they *CAN* move disks around between a suspend and resume, and have everything just work? [06:24] if they suspend again before rebooting to edgy, then that would break [06:24] I think [06:24] because things are mounted by UUID, the physical location or kernel-assigned name of the disk won't matter [06:24] Keybuk: No, because kernel restores with old hardware knowledge [06:25] is there any way we can disable suspend functionality until they reboot after this change? [06:25] So you'll resume, and the kernel will think "/ is on the first disk connected to this controller" when in fact it's now on the second [06:25] mjg59: have you had any cases of that so far? [06:25] Keybuk: Right now it won't even attempt to resume. With this change it'll attempt to resume and then blow up [06:26] depends how much they changed [06:26] tbh, I suspect this is a "WELL DON'T DO THAT THEN!" [06:26] You can't change hardware config and expect a resume to work [06:26] (sadly) [06:26] though people could get heavily bitten if the resume boot is subtly different to the suspend boot [06:26] ie. your raid controller takes an extra second to start up [06:26] There's a standard for a BIOS flag that gets set if the BIOS detects a changed config [06:26] We should probably check that [06:26] so your scsi controller wins [06:27] Oh, that's fine [06:27] but I suspect that's fine, actually [06:27] because your "first disk in this controller" info is still valid [06:27] As long as the hardware is the same, enumeration order is unimportant [06:27] right [06:27] this is, in fact, only if you add new duplicate controllers of a given type [06:27] The entire running kernel state gets overwritten by the old one [06:27] or swap the drives around on a particular controller [06:27] Or move PCI slots [06:27] I guess [06:28] but that's stupid [06:28] If the device ID changes, things explode [06:28] I'm trying to make sure that sunspots can't break it [06:28] But PCI device enumeration isn't dependent on startup speed - disk enumeration order may be [06:28] ie. udev loading modules in a different order [06:28] I think changing hardware configuration in the middle of an upgrade should just be strictly forbidden :) [06:28] Keybuk: Anyway, I need to pack [06:28] pack? [06:28] for? [06:29] Keybuk: Are you coming up this evening, or will I see you tomorrow? [06:29] I may be up this evening [06:29] depends when David turns up [06:29] Ok [06:29] We're leaving in about an hour [06:29] cool [06:29] BenC: does vmware work on an amd64? [06:30] does on mine [06:30] ok, let me install it for testing too [06:30]