=== mamarley_ is now known as mamarley
=== AceLan_ is now known as AceLan
=== _ruben_ is now known as _ruben
=== sconklin_ is now known as sconklin
[16:55] <cristian__c> jsalisbury: hi
[16:57] <jsalisbury> cristian__c, hello
[16:58] <cristian__c> jsalisbury: I've talked with a guy in #linux-wireless
[16:58] <cristian__c> jsalisbury: he gave me a suggestion
[16:59] <jsalisbury> cristian__c, great.  
[16:59] <jsalisbury> cristian__c, did you happen to add the info to the bug, I haven't reviewed it in a bit
[17:01] <cristian__c> ' with the patch being 2 years old, apparently without any fundamental complaints, it might make more sense to specifically blacklist your particular system based on its DMI strings from within hp_wmi_bios_2009_later(), rather than doing a blanket revert (which might break/ regress other systems) - pretty much a two-line patch'
[17:02] <cristian__c> ' apparently, yes - but it was also needed to unbreak other systems, therefore it's probably better to fix it (add a quirk for your notebook mainboard), rather than just reverting it (and thereby breaking other systems that had been working for 2 years by now)'
[17:03] <cristian__c> jsalisbury: I've told him i would have talked with you
[17:03] <cristian__c> either author/ original committer
[17:04] <cristian__c> (in this case hung either garrett)
[17:05] <jsalisbury> cristian__c, ok, all you system dmi info is in the bug, so I'll build a test kernel with a quirk for your board and see if it fixes things
[17:06] <cristian__c> jsalisbury: do you think his proposal (blacklistig my system by dmi from wmi bios function) rather than simply reverting the commit?
[17:07] <jsalisbury> cristian__c, reverting the commit could cause other regressions, so blacklisting may be best
[17:07] <cristian__c> jsalisbury: yeah, thanks. He says the idea is something so: blacklist only my system in the code, so there is no risk to hurting other systems
[17:08] <cristian__c> *to hurt
[17:08] <cristian__c> jsalisbury: ok, thank yoj very much
[17:08] <cristian__c> *you
[17:08] <cristian__c> :)
[17:08] <jsalisbury> cristian__c, I'll try that and post a test kernel in the bug shortly
[17:08] <cristian__c> yeah, ok. then I'll look launchpad page in the next days
[17:09] <cristian__c> thanks again
[17:09] <jsalisbury> np
=== cristian__c is now known as cristiac
=== cristiac is now known as cristian_c
=== cristian__c is now known as cristian_c
[19:35] <jsalisbury> cristian_c, after digging a bit while creating a patch, I think a patch was actually recently sent upstream to fix this(Commit 8a1513b).  I'll build a test kernel with it, and see if that makes it so we don't need to blacklist your board.
[19:36] <cristian_c> jsalisbury: ah, ok
[19:36] <jsalisbury> cristian_c, I'll post a link to a test kernel in the bug shortly
[19:36] <cristian_c> yeah, I'll check
[19:36] <cristian_c> and I'll try that
[19:37] <cristian_c> jsalisbury: I suppose, I've to report results in the launchpad bug webpage
[19:37] <jsalisbury> cristian_c, that would be great, thanks
[19:38] <cristian_c> ok
[19:41] <jsalisbury> cristian_c, are you still running Vivid?  The commit I just mentioned is already in Wily, but not in Vivid or older releases yet.
[19:42] <cristian_c> jsalisbury: I've to try wily
[19:43] <jsalisbury> cristian_c, no, you don't need to upgrade.  If you are still on a release older than while, I can just post a link to the wily test kernel to try out.
[19:43] <cristian_c> jsalisbury: could I use 4.2 test kernel in older releases, either have I to use it in wily release?
[19:43] <cristian_c> jsalisbury: ok
[19:43] <cristian_c> my release is older than wily
[19:45] <jsalisbury> cristian_c, The fix went in to the upstream 4.3-rc2 kernel, but was also cc'd to stable.  It was already applied the Wily kernel, but not Vivid or Trusty yet.  I'll just post a link to a kernel you can test in the bug.  That will make it easier then you having to upgrade right now.
[19:47] <cristian_c> jsalisbury: ok
[19:52] <cristian_c> uhm... from triaged to 'in progress'...
[19:54] <jsalisbury> cristian_c, ok, I just posted a link to the kernel to test.  You just need to install the linux-image and linux-image-extra .deb packages then reboot.
[19:57] <cristian_c> jsalisbury: ok, so no -headers and -headers-generic...
[20:00] <jsalisbury> cristian_c, no, you should need them for this quick test
[20:00] <cristian_c> ok
[20:16] <cristian_c> jsalisbury: ok, I've catched threebdeb packages
[20:17] <cristian_c> linux-headers-...-generic...i386, linux-image-...-generic....i386 and linux-image-extra-...-generic...i386
[20:18] <jsalisbury> cristian_c, great.  you should only need the last two, but you can install all three.
[20:19] <cristian_c> jsalisbury: but I don't see linux-headers....all_deb in that page
[20:19] <cristian_c> jsalisbury: ah,ok, sorry
[20:19] <cristian_c> now, I install them
[20:19] <jsalisbury> cristian_c, you should only need linux-image and linux-image-extra
[20:19] <cristian_c> ok
[21:56] <cristian_c> jsalisbury: ok, I've installed 4.2.0-18 kernel
[21:58] <cristian_c> jsalisbury: linux-headers-...-generic...i386 requested linux-headers....all_deb as dependency, so I've not installed it
[21:59] <cristian_c> then, I've installed the other two packages: linux-image and linux-image-extra
[21:59] <cristian_c> jsalisbury: I restarted the machine and I've tried the kernel
[22:00] <cristian_c> jsalisbury: no more regressions, exactly as for your previous revert kernel
[22:00] <cristian_c> 4.0.0-1
[22:01] <jsalisbury> cristian_c, so would you say it resolves the bug?
[22:01] <cristian_c> jsalisbury: of course, original bug exists yet, and workaround generates the same effects
[22:02] <cristian_c> jsalisbury: it splves the regression, exactly as for the revert
[22:02] <cristian_c> *solves
[22:03] <jsalisbury> cristian_c, that's good news.  That means the regression is fixed in Wily and soon to be fixed in Vivid and Trusty.
[22:03] <cristian_c> jsalisbury: it'sma good step, if wily mainline kernel already contains the regression fix, it can be treated as solved
[22:03] <cristian_c> jsalisbury: yeah
[22:04] <cristian_c> I've tried 4.2.0-18 as suggested from you
[22:04] <jsalisbury> cristian_c, so you could either upgrade to wily or stay on Vivid and wait for the fix to come in through updates
[22:04] <cristian_c> jsalisbury: I'll try to install directly Wily to get a confirmation
[22:04] <cristian_c> :)
[22:04] <jsalisbury> cristian_c, great.  I look forward to hear how it goes.
[22:05] <cristian_c> jsalisbury: of course, original bug as stated in the report, exists yet
[22:05] <cristian_c> jsalisbury: ok
[22:05] <jsalisbury> cristian_c, yeah, I'm going to look further into that again, now that this other regression is solved.
[22:05] <cristian_c> jsalisbury: I'll update the bug report with confirmation of disappeared regression
[22:06] <jsalisbury> cristian_c, thanks.  
[22:07] <cristian_c> and then I'll try to install wily directly to confirm further
[22:07] <cristian_c> jsalisbury: ok
[22:07] <jsalisbury> cristian_c, awesome. running wily will be a good starting point to continue with the original bug.
[22:07] <cristian_c> ok
[22:07] <cristian_c> I'll do that
[22:08] <cristian_c> jsalisbury: see you soon
[22:08] <cristian_c> thanks again
[22:08] <jsalisbury> cristian_c, you too.  thanks for all the testing!
[22:08] <tron103> Hey all, I'm trying to add mellanox infiniband support into the netboot image. The Ubuntu provided drivers seem buggy, so I'm trying to use the official Mellanox package with uses DKMS. Any clue on how to get DKMS modules compiled for a netboot image?
[23:24] <apw> tron103 (N,BFTL), modules in a netboot image are identicle to those in the main kernel just packaged up differently so install the dkms package on a real system and grab the binaries from there