| ppisati | moin | 08:43 |
|---|---|---|
| smb | ppisati, morning | 08:44 |
| smb | ppisati, Still in one piece? :) | 08:45 |
| * apw yawns | 08:48 | |
| apw | (himself) | 08:48 |
| * smb already had | 08:51 | |
| ppisati | smb: yep :) | 09:01 |
| === fmasi_afk is now known as fmasi | ||
| apw | smb, i thought the dm-raid45 driver was effectivly a meta-data reader, and setup md underneath once so read ? | 09:44 |
| apw | smb, and ... what do we think about just leaving it off for T, to figure out if anyone is actually affected by it | 09:48 |
| smb | apw, The dm-raid45 module is the kernel-side implementation (as I wrote in my reply) | 09:49 |
| smb | Right now the dmraid user-space uses it to set up the dm driver | 09:49 |
| smb | But as I wrote too, one could change it maybe to use dm-raid -> md | 09:50 |
| apw | so dmraid userspace is still using raid45 | 09:51 |
| smb | Or leave it off but change the installer to make mdadm at least support two formats | 09:51 |
| smb | apw, It seems to be as abandoned as the kernel module, yes | 09:51 |
| apw | hmmm | 09:51 |
| apw | well that is poop. what do we use to setup raid normally, dmsetup instead now ? | 09:51 |
| smb | Not sure whether RH silently came up with something differently named to replace it or just did not care for those | 09:52 |
| smb | apw, fakeraid not the normal raid | 09:52 |
| smb | apw, for softraid the tools should use mdadm already and that is md | 09:53 |
| smb | apw, dmraid is fakeraid which is those bios'es claiming to have raid but only do some meta-data and the rest is software | 09:53 |
| apw | smb, ok ... so from your email it sounded like some of the formats supported by fakeraid now were supported by mdadm ? | 09:58 |
| smb | apw, Mostly the IMSM. I can not say whether or if which of those might be DDF | 09:59 |
| smb | apw, Though I would doubt that a lot of those cared about any standard | 10:00 |
| apw | well presumably fakeraid support formats A B and C, do we know that list | 10:02 |
| smb | apw, Not from memory. We could use the source... | 10:05 |
| apw | smb, ok i am comparing now ... and will reply | 10:05 |
| smb | apw, I guess the problem might be that the utils say support this and that controller or board but not what kind of format that was | 10:07 |
| apw | smb, right ... am i right in thinking you have something which used this ? | 10:19 |
| smb | apw, Well I have one, maybe two kinds... not really very much | 10:22 |
| smb | apw, And one of those is my work-desktop... which is a lot of pain to try things on (while preventing to end up with a lot of pieces) | 10:23 |
| apw | smb, is either of those actually using it? or did you use something else | 10:26 |
| apw | smb, and if they are can you get me a dmsetup table off one | 10:26 |
| smb | apw, Neither is using it right now | 10:26 |
| apw | ok | 10:27 |
| smb | apw, And the work machine uses md raid | 10:27 |
| smb | apw, You would see nothing with dmsetup | 10:27 |
| apw | smb, i thought dmraid45 was a real dm personality when loaded | 10:28 |
| apw | it is used that way in the dmraid userspace | 10:28 |
| smb | apw, The problem is that "it" is quite ambiguous... | 10:29 |
| apw | the dmraid userspace uses the dmraid45 kernel module via making dm tables, which seems to doo it that way | 10:30 |
| smb | apw, Right, just when you asked whether I currently use "it" I was not sure you asked about dmraid or any softraid. | 10:31 |
| apw | i am being oblique indeed | 10:44 |
| apw | xnox, hey ... know anything about dmraid userspace ... | 10:44 |
| apw | it is so clear this has not changed like forever | 10:45 |
| smb | Wonder whether this would be worth a session on vUDS | 10:54 |
| apw | yeah we might want to touch on it in our 'misc' session at least | 10:56 |
| xnox | apw: smb: i want a vUDS session on fakeraid. IMSM works "best" with mdadm, which means we need to pull mdadm into initramfs (done) and actually start mdmon to monitor / make those "special" raid devices work (IMSM and DDF) | 11:37 |
| xnox | after 3.3 is merged, since that actually makes DDF work. | 11:37 |
| xnox | my motherboard has support for both DDF and IMSM raid devices. | 11:37 |
| xnox | but that means to organise switchout from dmraid, which helpfully will also try to activate "all" raid devices it can regornise. | 11:38 |
| xnox | I haven't tried yet on my machine to see what happens if both dmraid and mdadm are racing to activate same raid device, or if it's ok for both of them to activate it (as long as only one of them mounted I guess) | 11:38 |
| smb | xnox, I am not completely sure what I got. nvidia and something else. But we would also tend to rather want to drop the dm-raid45 special kernel module dmraid uses right now | 11:39 |
| smb | xnox, In the past (when I tried last) mdadm won but only worked read-only | 11:39 |
| xnox | smb: but mdadm does not support _all_ raids that dmraid does. | 11:39 |
| smb | (for intel msm) | 11:39 |
| smb | xnox, right | 11:39 |
| xnox | smb: for intel msm, mdadm is best. I was thinking to patch out IMSM out of dmraid & upload dmraid with "Depends: mdadm" to transition people to mdadm who use Intel MSM. | 11:40 |
| smb | xnox, The question would be whether (or how difficult) it would be to make dmraid use the dm-raid target instead (which then uses md in the background) | 11:40 |
| xnox | not sure how sane that approach is though. | 11:40 |
| smb | At least imsm is a known subset, so that does sound sane at least | 11:41 |
| xnox | smb: just using md in the background is not enough. For intel msm raid with mdadm, one needs to have mdmon daemon running - which actually does the talking to the firmware/raid-chip-on-board to write/read/update raid metadata, as far as I can tell. | 11:41 |
| xnox | DDF doesn't have 1-to-1 mapping into dmraid set of supported devices =/ and i'm happy to mostly ignore DDF for now, until some vendors come and say we really want this and that supported via mdadm. | 11:43 |
| xnox | (intel expressed such interest before) | 11:43 |
| smb | Yeah, I can see no easy way to figure out which is which. Hm, somewhat I'd be surprised that mdmon talks to firmware (that firmware seemed pretty dumb to me) But I would have to look into that. But yeah, probably that is doing the loggin via something else | 11:45 |
| apw | xnox, will you own getting a dmraid session on the core- track ... and put smb and myself on it ... as clearly this needs some work and we should have a BP for it :) | 11:50 |
| apw | xnox, that first bit really is a question btw :) | 11:50 |
| xnox | apw: yes. let me put it in. | 11:54 |
| apw | xnox, great, a plan then | 12:07 |
| xnox | apw: smb: summit is aweful, please "attend" http://summit.ubuntu.com/uds-1311/meeting/22017/transitioning-to-use-mdadm-by-default-for-some-of-the-fakeraid-devices/ as well =) | 12:09 |
| * xnox couldn't be bothered to scroll though non-searchable list of people who signed up to vUDS =) | 12:09 | |
| xnox | you are subscribed to the blueprint already... maybe summit will import that, maybe not. | 12:10 |
| apw | xnox, thanks ... | 12:29 |
| === gfrog_ is now known as gfrog | ||
| * ppisati disappears for a bit... | 16:48 | |
| === fmasi is now known as fmasi_afk | ||
| apw | henrix, i've applied that patch and tried to sort out the bug, it is missing the SRU bits | 17:51 |
| henrix | apw: thanks | 17:52 |
| henrix | apw: that bug has been fixed in Q before, and i thought the fix was applied from 3.2 stable. i was wrong | 17:54 |
| apw | henrix, ok, just needs the SRU templaste copying over from the last one i suspect | 17:55 |
| henrix | apw: yep, i'll take care of that | 17:55 |
| henrix | apw: thanks | 17:55 |
| apw | otherwise it looks fine to me, and well smb and sconklin have staked their reputations on it :) so i don't need to read it | 17:55 |
| henrix | heh | 17:55 |
| apw | clap4ham | 18:29 |
| apw | i am do going to remove unity from this machine | 18:29 |
| apw | that'd be the fourth time it has done htat in as many months | 18:30 |
| * apw is jetlagged to hell and back ... | 19:38 | |
| bjf | marrusl, around? | 23:44 |
| bjf | kamal, is bug 1163720 something you can verify or get someone to verify? | 23:45 |
| ubot2 | Launchpad bug 1163720 in linux (Ubuntu Raring) "Brightness control broken on XPS13 and 3.8.0-16, 3.8.0-22 and 3.11.0-12" [Medium,In progress] https://launchpad.net/bugs/1163720 | 23:45 |
| bjf | kamal, i seem to have a commit that has that as the buglink in quantal | 23:46 |
| marrusl | bjf, hey | 23:51 |
| bjf | marrusl, is bug 1208740 something you can verify | 23:54 |
| ubot2 | Launchpad bug 1208740 in linux (Ubuntu Raring) "Large pastes into readline enabled programs causes breakage from kernels v2.6.31 onwards" [Medium,Fix committed] https://launchpad.net/bugs/1208740 | 23:54 |
| bjf | ? | 23:54 |
| bjf | marrusl, or will arges be back this week and he can do it? | 23:54 |
| marrusl | bjf, arges is back I believe. one of us will get to it. making a note. | 23:55 |
| bjf | marrusl, thanks | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!