| smoser | kees, yeah, that string doesn' tmean anything to me. | 01:46 |
|---|---|---|
| smoser | although i woudl suspect 'rs' == 'rightscale' | 01:46 |
| smoser | kees, i appear wrong rs != rightscale, but rackspace | 02:05 |
| smoser | https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/473711 indicates that | 02:05 |
| ubot2 | Launchpad bug 473711 in aptitude "aptitude crashes when trying to free an invalid pointer" [Undecided,New] | 02:05 |
| kees | smoser: ah-ha. thanks! | 02:09 |
| smoser | and I know that they have forked our -xen kernel | 02:09 |
| smoser | or at least have maintained a xen ubuntu-like kernel | 02:10 |
| bryceh | RAOF, hmm, well | 02:14 |
| bryceh | RAOF, hmm, seems 5e7833 is already in the natty kernel tree | 02:15 |
| RAOF | Since when? | 02:16 |
| kees | RAOF: Ubuntu-2.6.38-1.27 | 02:17 |
| kees | $ git tag --contains 5e78330126e23e009502b21d1efdabd68ab91397 | head -n1 | 02:18 |
| kees | Ubuntu-2.6.38-1.27 | 02:18 |
| RAOF | Thanks. (I haven't yet got my natty ubuntu branch set up) | 02:18 |
| bryceh | heh, there is also a b5e7833, which is completely unrelated | 02:19 |
| === emma is now known as em | ||
| * apw yawns | 09:08 | |
| smb | apw, o/ | 09:08 |
| === ogra_ is now known as ogra | ||
| apw | diwic, about ? | 10:26 |
| diwic | apw, pong | 10:26 |
| === Nafallo_ is now known as Nafallo | ||
| === diwic is now known as diwic_afk | ||
| apw | diwic_afk, heh ... damn | 10:36 |
| apw | diwic_afk, i wanted to ask you about your sound bugs ... and getting them closed on upload | 10:36 |
| diwic_afk | apw, well, I saw two of them closed today | 11:00 |
| diwic_afk | So it seems to have been working fine | 11:00 |
| apw | diwic_afk, well no, as its not closing any which are alsa-driver | 11:00 |
| apw | https://bugs.launchpad.net/ubuntu/natty/+source/linux/+bug/672699 | 11:00 |
| ubot2 | Launchpad bug 672699 in ubuntu-cdimage "screen-reader does not work " [Undecided,Fix released] | 11:00 |
| apw | argle | 11:00 |
| apw | https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/718402 | 11:01 |
| ubot2 | Launchpad bug 718402 in alsa-driver "[Realtek ALC892] Recording problem" [Undecided,Fix committed] | 11:01 |
| apw | that one was in the changelog, but not againt linux, so it wasn't closed | 11:01 |
| apw | i wonder if they should be being moved to linux when they are deemed to need a kernle patc | 11:01 |
| apw | patch | 11:01 |
| diwic_afk | apw, hmm, maybe you're right | 11:03 |
| diwic_afk | apw, it wouldn't be too hard for me to move them to Linux when I send the patch | 11:03 |
| apw | diwic_afk, depends if you rely on them being in alsa-driver for tracking, as you can 'also affect' linux and at least you get the upload information splatted in, but otherwise probabally shift it to linux | 11:05 |
| diwic_afk | apw, ok, that makes sense | 11:06 |
| apw | diwic_afk, i can however assume if something is only on alsa-driver, and i have a buglink in the upload for it that i can just close it out fix released | 11:07 |
| apw | for the current situation? | 11:07 |
| diwic_afk | apw, the general case is that the bug should be closed even if it is against alsa-driver. | 11:08 |
| apw | yeah, there is no way to 'automate' via the nomal process, but we might be able to launchpad lib it. for now i can just spin the list, it is short | 11:09 |
| diwic_afk | apw, because the general case is that bugs against alsa-driver should really be against linux ;-) | 11:10 |
| apw | i assume alsa-driver exists just to say "sound issue" and then moves to linux or pulse or whatever is really the issue once someone in the know knows | 11:10 |
| diwic_afk | apw, it exists because there is no way to subscribe the "ubuntu-audio" team via apport | 11:11 |
| diwic_afk | but yeah, it's handy and it works for us | 11:11 |
| apw | diwic_afk, oh so actually if we had an arsenal script which literally just subscribed ubuntu-audio and moved them alsa-driver -> linux ... as soon as it saw them, would that do what you want | 11:13 |
| apw | diwic_afk, ok closed off the two whcih wern't closed | 11:16 |
| === diwic_afk is now known as diwic | ||
| PhoenixSTF | hello | 12:53 |
| PhoenixSTF | I got and issue with VT6421a controler that fails errors a lot with WD and samsung HDD, i have the 2.6.35-25 kernel and it is still bugging | 12:54 |
| smb | PhoenixSTF, I vaguely remember some patches for that sort of combination, though they were very specific to the ids. It might be yours just is not included. | 12:56 |
| PhoenixSTF | smb, can i help in some way to get it fixed? | 12:57 |
| smb | PhoenixSTF, possibly. But give me a sec to find the changes again | 12:58 |
| PhoenixSTF | smb, thanks m8 :) | 12:59 |
| PhoenixSTF | smb, i got the chip in front of me so i can take a picture or ref the serial number or manufacteur code of it, if it helps | 13:00 |
| smb | PhoenixSTF, nah, the os is more interested in internal things. I believe lspci should show it | 13:01 |
| PhoenixSTF | smb, ok tell me what to do | 13:02 |
| smb | Yep. So I found the last time they touched that. (sata_via: apply magic FIFO fix to vt6420 too) | 13:03 |
| smb | but it checks for board id, so i need to check the code how that is looked up | 13:04 |
| smb | PhoenixSTF, But you could look up what numbers (for vendor/model and subvendor/model) lspci will give you for the sata controller | 13:06 |
| PhoenixSTF | smb, ok ill try and give you that, its a pci sata controler ok | 13:07 |
| PhoenixSTF | ok i got 2 of them, on is working fine, the other one has got all the issues | 13:07 |
| PhoenixSTF | 00:0c.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50) | 13:07 |
| PhoenixSTF | 00:0d.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID Controller (rev 50) | 13:08 |
| smb | Would both have WD disks connected? Actually you will need to use lspci -vvvnn to get the numbers in hex as well | 13:09 |
| PhoenixSTF | yes | 13:10 |
| PhoenixSTF | i swaped drives between boath controlers | 13:10 |
| PhoenixSTF | i have 2 wd, 1 samsung and 1 seagate, the only one it doesnt complain about is the seagate | 13:11 |
| PhoenixSTF | so i have now a samsung drive on it and gives me the bug of ICR something error | 13:12 |
| PhoenixSTF | smb, the output is a bit big can i paste here? | 13:12 |
| smb | Hm, that could then be a different problem than the one they got fixxed. You could pastebin it and send the link here | 13:12 |
| PhoenixSTF | ok | 13:13 |
| PhoenixSTF | http://pastebin.com/Z0qsP4cZ | 13:13 |
| PhoenixSTF | oh the controler that is buging, works a bit better alone (I mean less errors), without the other controler on, | 13:15 |
| smb | Ok, so this one gets mapped to a board id of vt6421 and for that the quirk gets enabled. Actually for that one even before the latest change | 13:15 |
| PhoenixSTF | ? | 13:16 |
| PhoenixSTF | well its a VT6421A not a VT6421 | 13:16 |
| smb | Means whatever that fixed, you already have it | 13:16 |
| PhoenixSTF | does it matter? | 13:16 |
| smb | not in the driver code | 13:16 |
| PhoenixSTF | well if I have the fix why the issue? | 13:17 |
| smb | that just looks at the 0x3249 from the model number | 13:17 |
| smb | Just saying it is not that issue that got fixed | 13:17 |
| smb | You probably have a different | 13:17 |
| PhoenixSTF | ok | 13:17 |
| PhoenixSTF | i got the same board extra do you whant me to mail it you? lol xD | 13:18 |
| smb | When you say one controller alone works better it sounds a bit like there is some interaction. Heh, got enough not completely working kit. :-P | 13:18 |
| smb | I suspect it would be good to try a recent mainline kernel (to see whether this still shows the same issues) | 13:19 |
| PhoenixSTF | that is the thing the 1st controler, doesnt give any kind of trouble at all | 13:19 |
| smb | and if that is the case, it would be best to open an upstream bugzilla | 13:19 |
| PhoenixSTF | i had 3 controlers on it, and it was rock solid | 13:19 |
| PhoenixSTF | the other 2 with are the same, gives me the creeps with WD | 13:19 |
| smb | So it could also be a real hw fail | 13:20 |
| smb | Maybe not if two show the same problem | 13:20 |
| PhoenixSTF | that is it i tried the HD with my 1st controler, and everything is fine, i take it out of the server out it on my desktop and its fine... connect it to the 2nd controler in the server and ICR blabla bla | 13:21 |
| PhoenixSTF | i got a seagate on the 2nd controler, ok no problem. Samsung, ICR blablabla | 13:22 |
| PhoenixSTF | its the issue with WD and Samsung... i dont know if it is something to do with the controler manufacteur | 13:23 |
| smb | From what I read in that part of the code it has to do with how much data a drive sends before handshaking | 13:24 |
| smb | apparently some wd drives do 40 double words while other only do half | 13:24 |
| PhoenixSTF | whant me to send my HDD info? | 13:26 |
| apw | smb, isn't it a bit odd that both those controllers are ide | 13:27 |
| smb | Must admit that I am reaching my limit of usefulness. This goes into detail levels beyond me. | 13:27 |
| apw | identicle from the lspci output, yet one works and the other not | 13:27 |
| smb | apw, yes, though both bound to via_sata driver | 13:28 |
| apw | PhoenixSTF, these are both discrete sata cards yes ? | 13:28 |
| PhoenixSTF | thanks anyway smb, sorry for the trouble, if you find anything or anyone that can give some help i would apriciate | 13:29 |
| PhoenixSTF | discrete? | 13:29 |
| PhoenixSTF | what do you mean? | 13:29 |
| apw | as in physical cards plugged into a slot | 13:29 |
| PhoenixSTF | yes | 13:29 |
| PhoenixSTF | pci | 13:29 |
| PhoenixSTF | boath | 13:29 |
| smb | PhoenixSTF, Well the best advice is to do a test with a very recent kernel and then an bugzilla report | 13:29 |
| apw | one card working and one not implies one of two things, either one card is broken, or the support for multiple cards sucks | 13:30 |
| PhoenixSTF | i got the ubuntu server 10.10 | 13:30 |
| apw | one thing you might try is swapping the cards, so the other one is the 'first' one | 13:30 |
| smb | * https://bugzilla.kernel.org/show_bug.cgi?id=15173 | 13:30 |
| smb | * http://article.gmane.org/gmane.linux.ide/46352 | 13:30 |
| smb | * http://thread.gmane.org/gmane.linux.kernel/1062139 | 13:30 |
| PhoenixSTF | yes well anole it works better but still outputs errors with wd | 13:30 |
| ubot2 | bugzilla.kernel.org bug 15173 in Serial ATA "sata_via VT6421 softRAID" [Normal,Resolved: code_fix] | 13:30 |
| PhoenixSTF | the only problem is with the WD and Samsung HDD | 13:30 |
| apw | if its card related it should move to the other one, and if its s/w t should stay with the slot | 13:30 |
| smb | PhoenixSTF, Those are links to the previous bug reports and some mial threads | 13:30 |
| PhoenixSTF | smb, done that! | 13:31 |
| PhoenixSTF | apw i moved the card to every combination possible in 6 pci slots | 13:31 |
| PhoenixSTF | 1st, last, second, one after another, one before the other etc | 13:32 |
| apw | so order doen't matter then whether its detected first or second | 13:32 |
| PhoenixSTF | no | 13:32 |
| PhoenixSTF | or alone | 13:32 |
| PhoenixSTF | even alone gives trouble with the wd hdd | 13:32 |
| PhoenixSTF | I got a 1TB seagate, no problem at all | 13:32 |
| smb | apw, From the the gmane article it sound like you can get hosed depedning on number of drives and how much they send after the host indicates a hold | 13:33 |
| PhoenixSTF | the 500 Gb wd caviar.... well handshake problem and blablabla | 13:33 |
| PhoenixSTF | a lot of handshake problems but only on that controler.... | 13:34 |
| apw | but he has two controllers and its ok on one of them if i am reading right; yet they are the same contollers | 13:35 |
| apw | that bit makes less sense to me | 13:35 |
| PhoenixSTF | apw, I know thats what is bugging me! | 13:36 |
| apw | yet if i understand you, and we switch the two identlce cards round the issue follows the bad card (ie swap the two slots they are in) | 13:36 |
| PhoenixSTF | apw, yes but only with the Western digital and Samsung HDD | 13:37 |
| apw | so there has to be something different with that actual card than the other one | 13:37 |
| PhoenixSTF | they are diferent in design | 13:37 |
| apw | even if only triggered by the specific HDDs | 13:37 |
| smb | apw, So that may be some physical defect that gets triggered by certain drive characteristics... | 13:38 |
| smb | eh you said that | 13:38 |
| smb | already. :) | 13:38 |
| apw | smb, yeah a defect on both, neither fatal on its own, only in combination | 13:38 |
| PhoenixSTF | apw let me correct that, alone gives some issues 2 | 13:38 |
| PhoenixSTF | less but it gives | 13:38 |
| * smb is thinking... was that pci or pcie | 13:39 | |
| PhoenixSTF | PCI | 13:39 |
| apw | but the nasty thing for us, is the kernel thinks the two cards are the same cards | 13:39 |
| PhoenixSTF | ? | 13:39 |
| smb | It are the same I thought | 13:39 |
| apw | <PhoenixSTF> they are diferent in design | 13:39 |
| PhoenixSTF | irq are diferent | 13:39 |
| PhoenixSTF | one is 16 other 17 | 13:39 |
| apw | no the two cards are not the same | 13:40 |
| PhoenixSTF | no they arent | 13:40 |
| PhoenixSTF | the chip is | 13:40 |
| apw | yet they are i'd the same | 13:40 |
| PhoenixSTF | manufacteur isnt | 13:40 |
| PhoenixSTF | one has a esata port, the OK one | 13:40 |
| PhoenixSTF | the other doesnt | 13:40 |
| PhoenixSTF | one is green | 13:40 |
| PhoenixSTF | other is red | 13:40 |
| apw | yet the PCI information including the manufacturer _is_ the same on the two cards | 13:41 |
| apw | from your pci output | 13:41 |
| PhoenixSTF | do you guys what a picture from boath cards? | 13:41 |
| smb | very confusing | 13:41 |
| apw | PhoenixSTF, no i beleive you when you say they are different | 13:41 |
| smb | Right | 13:41 |
| apw | i am not actually interested in that they are different, i am interested in the | 13:42 |
| smb | Just they seem to report as exactly the same | 13:42 |
| PhoenixSTF | i know you believe, just well something might stand out you might notice .... | 13:42 |
| apw | fact they _say_ they are not different | 13:42 |
| apw | which either means they genuinely report they are not different | 13:42 |
| apw | or there is some other bug which gets the identity wrong | 13:42 |
| apw | but as i understand PCI ids they are fundamental things the cards return when interrogated | 13:42 |
| apw | Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] | 13:42 |
| apw | Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] | 13:43 |
| PhoenixSTF | ok let me get this easier on you I got one extra card, i can mail it to any one of you | 13:43 |
| apw | who makes the two officialy ? | 13:43 |
| PhoenixSTF | apw the chip is the same on boath | 13:43 |
| apw | PhoenixSTF, without the exact HDD drives which trigger the issue, this is not going to necessarily tell us anything (having the card) | 13:43 |
| PhoenixSTF | thats os the only thing that is the same | 13:43 |
| apw | right so the first id's should match and the second id's the ones i have pasted should not | 13:44 |
| mjg59 | One possibility is that they're different revisions and that that information is available somewhere in a chip-specific register | 13:44 |
| PhoenixSTF | i can mail the HDD 2, has long has you return it! | 13:44 |
| PhoenixSTF | xd | 13:44 |
| PhoenixSTF | xD | 13:44 |
| mjg59 | apw: There's no real reason why subsystem IDs should vary | 13:44 |
| PhoenixSTF | i am going to poweroff my server and take out the OK board! | 13:45 |
| apw | mjg59, lets look at it a different way, is it reasonable for two completely different sata cards to have the same primary pci ids ? | 13:46 |
| apw | it doesn't seem so to me | 13:46 |
| apw | 00:0c.0 RAID bus controller [0104]: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] (rev 50) | 13:46 |
| apw | 00:0d.0 RAID bus controller [0104]: VIA Technologies, Inc. VT6421 IDE RAID Controller [1106:3249] (rev 50) | 13:46 |
| tgardner | apw, clone makers do it all the time. | 13:46 |
| mjg59 | apw: Sure | 13:46 |
| mjg59 | apw: It's the common case for generic parts | 13:47 |
| apw | they are allowed to do that? oh dear | 13:47 |
| apw | i'd have expected the subsystem id to vary on clones | 13:47 |
| smb | apw, I guess what you get is the identity of the chipset used not necessarily the brand and type of card | 13:47 |
| apw | so any card specific bugs ... and you are dead | 13:47 |
| PhoenixSTF | so no way to fix it? | 13:48 |
| mjg59 | apw: Well, it's difficult to see how you can produce a card-specific bug | 13:48 |
| apw | bad wiring anything really | 13:48 |
| mjg59 | If there's a problem at the physical layer then it doesn't matter - the card's just broken | 13:49 |
| mjg59 | Not going to fix that in software | 13:49 |
| apw | no indeed. i was thinking where there are some modes which work and others not | 13:50 |
| mjg59 | Any vendor who's sufficiently uninterested in product differentiation isn't going to have changed thedrivers | 13:50 |
| mjg59 | So if it works under Windows with the vendor drivers then there's something we're doing wrong | 13:50 |
| PhoenixSTF | ok let but why with WD cards? and why in linux? | 13:50 |
| mjg59 | The most likely explanation is that there's some bit in the card firmware that influences the behaviour | 13:50 |
| apw | PhoenixSTF, does this card work with the 'bad' drives in windows | 13:51 |
| PhoenixSTF | not tested it... | 13:52 |
| PhoenixSTF | not windows fan.... | 13:52 |
| apw | (who is :) | 13:52 |
| mjg59 | So it may just be a bad card | 13:52 |
| PhoenixSTF | correct | 13:52 |
| mjg59 | Timing tolerances may vary between driver manufacturers | 13:52 |
| smb | mjg59, The explanation for the older fix for wd was that those could send more after being told to wait and the change doubled the watermark of the fifo buffer. Asuming the windows drivers may have used the bigger value. O | 13:53 |
| PhoenixSTF | mjg59, sorry but the issue is with specific HDD, Seagate no problems at all, WD and samsung... well thats anoter thing | 13:53 |
| PhoenixSTF | i got transmithion problems with the samsung and the card is now alone | 13:53 |
| PhoenixSTF | exception Emaks | 13:54 |
| PhoenixSTF | and Bad CRC | 13:54 |
| PhoenixSTF | has i said before, I have a extra card, COmplements of Amazon, and i can give it to charity, so i dont mind giving to a developer to check it out | 13:55 |
| smb | To be honest, as apw said, its not only having the card. It could be interaction with specific drives or even the board | 13:59 |
| PhoenixSTF | dont mind sending the hdd along with it | 13:59 |
| PhoenixSTF | i am Pro Ubuntu | 13:59 |
| PhoenixSTF | when i mean pro is suportive | 13:59 |
| PhoenixSTF | i dont mind lending or giving stuff to get something done... | 14:00 |
| PhoenixSTF | has long has everybody benifits from it | 14:00 |
| apw | we're probabaly not the best people to send such a thing to, probabally the driver maintainer would be better placed to make sure of it to fix the issue | 14:01 |
| PhoenixSTF | or if you whant i can give access to my server with boath drives in it | 14:01 |
| PhoenixSTF | apw, well i just want to help on getting it fixed, a lot of people are complaining on the same thing... | 14:02 |
| PhoenixSTF | so who do i talk 2???? | 14:03 |
| PhoenixSTF | xD | 14:04 |
| apw | hmmm, normaly i file bugs in upstream bugzilla and sub the maintainer in MAINTAINERS | 14:04 |
| PhoenixSTF | oh and guys apw, smb, and mjg59, sorry for any trouble i might have caused and thanks for your support :) | 14:05 |
| apw | no trouble | 14:05 |
| PhoenixSTF | ok apw tell me how Yoda | 14:05 |
| smb | Jeff Garzik would be sata maintainer, but in pathces there is also a JosephChang from via direct... | 14:05 |
| PhoenixSTF | yes i see | 14:05 |
| PhoenixSTF | so i register in it | 14:05 |
| PhoenixSTF | what do i do? | 14:06 |
| * apw is unsure what you are asking | 14:07 | |
| * smb probably would try writing to JosephChang. He cannot do worse than not respond | 14:07 | |
| PhoenixSTF | LOL | 14:08 |
| === joaopinto_ is now known as joaopinto | ||
| sforshee | I'm looking more advice on the toshiba resume problem I asked about last week (hanging for 5 minutes in the ACPI _WAK method) | 14:48 |
| sforshee | Messing with the triggering of the timer interrupt didn't change anything, I think what the bios is reporting is correct based on what I saw | 14:49 |
| === sconklin-gone is now known as sconklin | ||
| sforshee | Although I think there is some sort of problem related to the hpet, I'm not sure what it is or if it has anything to do with the hang during resume | 14:49 |
| sforshee | I've pasted some excerpts from the disassembled AML and a trace of the _WAK method execution | 14:49 |
| sforshee | http://pastebin.ubuntu.com/571148/ | 14:49 |
| sforshee | http://pastebin.ubuntu.com/571149/ | 14:49 |
| sforshee | Of interest is the point in the trace where the timestamp jumps 5 minutes into the future | 14:50 |
| sforshee | This corresponds to the TRAP method in the AML source, right after it writes a value to some IO space | 14:50 |
| sforshee | I assume this represents making some sort of call into the BIOS? | 14:50 |
| sforshee | Any ideas on how to debug this? | 14:51 |
| mjg59 | Yes, it means it's going into the BIOS | 14:57 |
| mjg59 | It also means that there's no practical way to debug what it's doing | 14:57 |
| sforshee | Whatever it's doing, it seems to be stuck in there until there's an interrupt from the hpet | 14:58 |
| sforshee | Because if the hpet is in periodic mode when this happens, it resumes quickly | 14:59 |
| mjg59 | It's entirely possible that the system management code waits for an interrupt but doesn't actually set one up | 15:02 |
| mjg59 | Maybe we should just put the HPET in periodic mode over suspend/resume | 15:02 |
| sforshee | The hpet is being used as the broadcast tick device, so would that be something the tick code would do? | 15:05 |
| sforshee | The hpet resume as already run by the time this is happening | 15:05 |
| sforshee | s/as/has/ | 15:06 |
| mjg59 | It would need some special casing | 15:06 |
| sforshee | okay, I'll poke around at the code a bit and see if I can come up with a sane way of doing that | 15:07 |
| sforshee | thanks mjg59 ! | 15:07 |
| cking | I wonder if Windows puts the HPET into periodic mode over S3 | 15:18 |
| mjg59 | cking: Windows doesn't do tickless | 15:20 |
| cking | aha | 15:20 |
| mjg59 | I think they go to a minimum of 60Hz | 15:20 |
| cking | hence we catch these corner cases and windoze doesn't | 15:20 |
| * apw_ scoffs a dog | 15:49 | |
| apw_ | heh ... doughnut | 15:49 |
| smb | Who let the dog out? :) | 15:49 |
| apw_ | cat is away .. | 15:50 |
| tgardner | apw: weren't you and JFo working on how to _not_ spam certain classes of bugs? tracking bugs for example. | 15:58 |
| apw_ | yeah some are excluded ... what got hit? | 15:59 |
| tgardner | apw: bug #718839 | 16:00 |
| ubot2 | Launchpad bug 718839 in linux "QA Regression test kernel-security reports two failures on 2.6.24-28.84 Xen" [Undecided,Incomplete] https://launchpad.net/bugs/718839 | 16:00 |
| apw_ | will look ... likely missing a tag | 16:01 |
| tgardner | apw: so, something bjf's create-* tools should add ? | 16:01 |
| apw_ | waiting for it to load to check, but they have tags so likely we are avoiding them | 16:02 |
| apw_ | not | 16:02 |
| bjf | tgardner, current versions of create-* tools addd "kernel-release-tracking-bug" and "kernel-cve-tracking-bug" tags | 16:05 |
| bjf | apw, ^ | 16:05 |
| tgardner | bjf, which this tracking bug did not have. | 16:05 |
| tgardner | guess that explains it | 16:05 |
| bjf | tgardner, bug # ? | 16:06 |
| tgardner | bjf: bug #718839 | 16:06 |
| ubot2 | Launchpad bug 718839 in linux "QA Regression test kernel-security reports two failures on 2.6.24-28.84 Xen" [Undecided,Incomplete] https://launchpad.net/bugs/718839 | 16:06 |
| bjf | tgardner, for a while i was using "kernel-tracking-bug" | 16:06 |
| bjf | tgardner, that is not a bug that we created | 16:07 |
| tgardner | bjf, ah, I see. | 16:07 |
| tgardner | then they deserve to get spammed :) | 16:07 |
| bjf | well, i wouldn't say that but :-) | 16:08 |
| apw | spam them spam them | 16:09 |
| smb | tgardner, I seems the v2.6.32.29.13 is there. That it went from v2.6.32.28.13 would just mean there is no drm33 update | 16:14 |
| smb | Or did I misunderstand the question alltogether? | 16:14 |
| tgardner | smb, there doesn't seem to be a v2.6.32.28.* tag | 16:15 |
| tgardner | so, you skipped .28 ? | 16:15 |
| smb | tgardner, Are you looking on kernel.org or kernel.ubuntu.com? | 16:15 |
| tgardner | smb, git://kernel.ubuntu.com/smb/linux-2.6.32.y-drm33.z.git | 16:16 |
| smb | tgardner, That would be my testing ground and proe to forgetting tags | 16:16 |
| tgardner | ah, how inconvenient. | 16:16 |
| tgardner | smb, what is the kernel.org path ? | 16:17 |
| === herton is now known as herton_lunch | ||
| smb | tgardner, I (hope) to have it in the announce. git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git | 16:18 |
| smb | tgardner, But I just pushed the last tag to kernel.ubuntu.com | 16:19 |
| tgardner | smb, OK, I changed path to kernel.org | 16:19 |
| smb | Yes, that is better as its the official thing | 16:20 |
| bjf | smb, your email had: git://git.kernel.org/pub/scm/linux/kernel/git/smb/linux-2.6.32.y-drm33.z.git | 16:28 |
| smb | bjf, Good, so that should be correct | 16:28 |
| === herton_lunch is now known as herton | ||
| === cmagina is now known as cmagina-lunch | ||
| === cmagina-lunch is now known as cmagina | ||
| === sforshee is now known as sforshee-lunch | ||
| === bo is now known as Guest30036 | ||
| === sforshee-lunch is now known as sforshee | ||
| apw | http://people.canonical.com/~apw/cve/pkg/linux.html | 20:11 |
| bjf | JFo, can you accept nominations on: bug #723945 ? | 21:07 |
| ubot2 | Launchpad bug 723945 in linux-ti-omap4 "CVE-2010-4258" [Undecided,New] https://launchpad.net/bugs/723945 | 21:07 |
| * jjohansen -> lunch | 21:13 | |
| JFo | bjf, I can | 21:17 |
| JFo | bjf, I'm getting timeout errors | 21:19 |
| bjf | heh, figures | 21:19 |
| JFo | but I'll work on it until I'm done | 21:19 |
| bjf | thanks | 21:19 |
| JFo | np | 21:21 |
| JFo | this timeout is making me crazy. I haven't been able to accept the first nomination yet :-/ | 21:32 |
| === sconklin is now known as sconklin-afk | ||
| apw | bjf, did you get your noms done? | 22:17 |
| bjf | apw, nope, but it's not holding me up | 22:18 |
| apw | bug # ? | 22:18 |
| bjf | bug #723945 | 22:18 |
| ubot2 | Launchpad bug 723945 in linux-ti-omap4 "lockdep warning in KSM" [Undecided,New] https://launchpad.net/bugs/723945 | 22:18 |
| bjf | ok, that's just odd | 22:18 |
| apw | bjf, hrm, timeouts for me on them all | 22:20 |
| JFo | apw, I gave wgrant the oops number in #launchpad | 22:21 |
| JFo | I'm hopeful that there is something going on behind the scenes to address it | 22:21 |
| apw | JFo, ack, launchpad is a mess | 22:21 |
| JFo | yup :-/ | 22:21 |
| JFo | bjf, any reason that guy changed the title of the bug? | 22:22 |
| JFo | or was that expected | 22:22 |
| bjf | JFo, not that i'm aware of, was just discussing with tgardner | 22:23 |
| JFo | ah | 22:23 |
| === ericm|ubuntu is now known as 5EXAB9OY8 | ||
| === poelzi- is now known as poelzi | ||
| === nik0 is now known as niko | ||
| === mdeslaur_ is now known as mdeslaur | ||
| === RAOF_ is now known as RAOF | ||
| JFo | bjf, I am still checking your bug periodically, still no joy yet | 23:19 |
| bjf | JFo, heh, thanks, maybe just ignore it til tomorrow | 23:19 |
| JFo | I'l hold off and try again before I drop off tonight. Just wanted to let you know I hadn't forgotten about you :) | 23:20 |
| === achiang` is now known as achiang | ||
| jjohansen | sconklin, bjf: that hardy xen kernel from the ubuntu-on-ec2 ppa is special | 23:33 |
| jjohansen | it builds by pulling in linux-source as a dependency and then copies the kernel source in and uses the debian dir and patches in the directory | 23:33 |
| jjohansen | its a mess, and it is going away. | 23:33 |
| jjohansen | but I am not sure how soon, there is still testing etc of the new image builds to be done | 23:34 |
| jjohansen | the new image build == to how the packages are pulled in and rolled into the ami image to be published for use on ec2 | 23:35 |
| sconklin | jjohansen: ok, thanks, I'm just not clear on what kernels we deliver for ec2 and/or xen and where they are built, etc | 23:35 |
| jjohansen | sconklin: apparently neither am I :) I had thought we were pulling in a the hardy -xen kernel for the images, but what really was being pulled in was a custom ppa based on that. | 23:36 |
| * jjohansen smb and smoser (mostly smoser) are working on changing that | 23:37 | |
| jjohansen | for the other kernels, there are the karmic and lucid ec2 topic branches, and maverick and natty -virtual flavors | 23:38 |
| jjohansen | so just to be clear hardy will be moving to the the hardy -xen kernel but its not there yet | 23:39 |
| jjohansen | sconklin: we also provided an intrepid ec2 kernel from the same ppa as the hardy kernel, but intrepid is no longer supported so you can forget it. And we never supplied a proper jaunty kernel | 23:40 |
| sconklin | ok, thanks. | 23:40 |
| === popey_ is now known as popey | ||
| JFo | stepping away to grab some dinner bbiab | 23:51 |
| === sconklin is now known as sconklin-gone | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!