=== marlinc_ is now known as marlinc
=== xnox_ is now known as xnox
=== stgraber_ is now known as stgraber
=== _ruben_ is now known as _ruben
=== alkisg_away is now known as alkisg
[07:36] <genkgo> jsalisbury: good news regarding the backup issue, great you find a version that does not exhibit the bug
[08:35] <caribou> smb: do you know of a way to have zfcp devices made available upon reboot without having to use chccdev -e ?
[08:36] <smb> caribou, yeah, I think that was touch /etc/sysconfig/hardware/<devid> iirc
[08:36] <caribou> smb: and devid being what ?
[08:37] <smb> like the argument you give chccwdev 0.0.xxxx
[08:38] <smb> caribou, but I might have the path wrong... a sec
[08:42] <smb> caribou, So I am a bit confused as I have found some installs without it... maybe I forgot to actually do those... hm... but if /etc/sysconfig is there its .../hardware/config-ccw-0.0.xxxx
[08:42] <caribou> smb: ok, I'll try that
[08:44] <caribou> smb: I don't have a /etc/sysconfig
[08:46] <JanC> sysconfig sounds like a RH thing
[08:46] <smb> Yeah I think it might have been a thing they got rid of
[08:47] <smb> Initially it was there but I know have two guests I did install but ended up being different
[08:48] <smb> caribou, So for that case you probably can add a modprobe.d file that adds the device numbers with the device parameter
[08:52] <JanC> udev?
[08:55] <JanC> well, probably needs more than udev (this is SCSI over fibre, I understand)
[08:57] <smb> Yeah, well also its common (especially LPARs) to not want to enable all devices on the channel subsystem that are visible. 
[08:59] <JanC> I don't have that sort of equipment, but I can see why you won't want that
[09:04] <caribou> smb: JanC: googling about it yesterday brought back RHEL hits about a /etc/zfcp.conf file containing a list of devices to enable
[09:06] <smb> caribou, I guess in our case that will need some part of sysvinit or systemd to care about it... 
[10:55] <caribou> well, looks like we will need a zfcp specific kernel which needs to be smaller than 32Mb
[10:55] <caribou> apw: smb ^^
[10:59] <smb> caribou, I believe I remember needing a kernel not sure about the memory limitation
[11:00] <caribou> smb: well, if I try to use our standard kernel, I get MLOLOA018E: DUMP memory limit reached: 0x2000000 bytes. which is coherent with what inaddy said
[11:02] <smb> caribou, ah ok... 
[11:44] <pkern> smb: https://packages.qa.debian.org/s/sysconfig.html does it on Debian
[11:47] <smb> pkern, Yeah thanks. It just sounded like RH (which iirc have most of their config there). For s390x it would have been sysconfig-hardware. And my confusion because there are slightly differing installations around
=== _bjf is now known as bjf
[13:44] <popey> hello!
[13:44] <popey> My 14.04 machine (x220) freezes a LOT!
[13:45] <popey> probably heat related, it's in a docking station. I am getting https://bugs.launchpad.net/ubuntu/+source/thermald/+bug/1543046
[13:45] <ubot5`> Launchpad bug 1543046 in thermald (Ubuntu) "thermald spamming kernel log when updating powercap RAPL powerlimit" [High,Fix released]
[13:45] <popey> which says it's fix released.
[13:45] <popey> I'm on 4.2.0-34-generic but I am seeing that still  - is the fix in 14.04?
[14:08] <cking> popey, i'd like to answer that right away, but I'm completely snowed under with some other higher priority items. I believe the fix should be in 14.04, but I need to check and I've not got the free cycles at the moment
[14:10] <popey> ok cking 
[14:11] <cking> popey, can you file a bug, and attach the output from dmesg. I have an x220 so I can see if I can reproduce the error if need be
[14:12] <cking> but I probably can't devote much time on this until late tomorrow or monday
[14:30] <popey> cking: ok
[14:30] <popey> cking: no hurry
[14:33] <popey> cking: done bug 1564443
[14:33] <ubot5`> bug 1564443 in linux-lts-wily (Ubuntu) "System freezes, dmesg spammed, overheating laptop" [Undecided,New] https://launchpad.net/bugs/1564443
[15:03] <jsalisbury> genkgo, The Ubuntu 3.13.0-17 kernel also for almost 24 hours without hittting the bug, so we're getting closer.  It will take a few days to narrow down the commits since it takes at least 8 hours to reproduce
[15:03] <genkgo> jsalisbury: hehe, awful debugging
[15:03] <genkgo> jsalisbury: but great we are getting close
[15:04] <jsalisbury> genkgo, just time consuming.  Yeah we are getting there.  Once I find the last good and first bad commit, I should be able to review the commits between them and figure it out.
[15:06] <genkgo> jsalisbury: the user that reported the bug first was running 3.13.0-49
[15:07] <genkgo> was was the earliest kernel with the bug you found?
[15:07] <genkgo> i.e. what is the gap between the tested good version and bad version?
[15:08] <jsalisbury> genkgo, I thinkg -49 is the last know earliest version with the bug.  So right now -17 is good and -49 is bad, but there are allot of commits between the two.  I'm going to test in between those versions and then repeat when I have those test results.
=== kamal__ is now known as kamal
[15:10] <genkgo> alright, that leaves at least 5 more tests
[15:11] <jsalisbury> genkgo, we should have it figured out within a week or sooner
[15:11] <genkgo> great, really great
[15:12] <jsalisbury> genkgo, it would be easy to say the bug doesn't happen after 8-9 hours of testing, but giving it a ful 12 - 24 hours gives more confidence
[15:13] <genkgo> jsalisbury: i understand, i also think that the earlier versions should exhibit the bug easier
[15:14] <jsalisbury> genkgo, yes, I was able to reproduce the bug in an hour or two with earlier kernels, so I hope the first next bad kernel I hit happens fast in the testing.
[15:14] <genkgo> jsalisbury: is it already where it is the kernel or the integration services?
[15:14] <genkgo> clear
[15:15] <jsalisbury> genkgo, I think it's definatly in the kernel, since I tested all the different versions of LIS with CentOS and could not reproduce the bug.
[15:15] <genkgo> alright
=== askb_ is now known as askb
[17:24] <leitao> ogasawara, Hello Leann. I just answered 1556096, but I am not able to assign back to ckt.
[17:25] <ogasawara> leitao: thanks, I'll take a look
[17:30] <leitao> ogasawara, thanks. Also, 1564487 is a regression after the cherry pick of 8244062ef1e54502ef55f54cced659913f244c3e
[17:34] <ogasawara> leitao: ack, I'll get the team to take a look at that as well
[17:35] <leitao> ogasawara, thank you!
=== ghostcube_ is now known as ghostcube
=== mamarley is now known as Guest55970
=== mamarley_ is now known as mamarley