| === 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 | ||
| genkgo | jsalisbury: good news regarding the backup issue, great you find a version that does not exhibit the bug | 07:36 |
|---|---|---|
| caribou | smb: do you know of a way to have zfcp devices made available upon reboot without having to use chccdev -e ? | 08:35 |
| smb | caribou, yeah, I think that was touch /etc/sysconfig/hardware/<devid> iirc | 08:36 |
| caribou | smb: and devid being what ? | 08:36 |
| smb | like the argument you give chccwdev 0.0.xxxx | 08:37 |
| smb | caribou, but I might have the path wrong... a sec | 08:38 |
| 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:42 |
| caribou | smb: I don't have a /etc/sysconfig | 08:44 |
| JanC | sysconfig sounds like a RH thing | 08:46 |
| smb | Yeah I think it might have been a thing they got rid of | 08:46 |
| smb | Initially it was there but I know have two guests I did install but ended up being different | 08:47 |
| smb | caribou, So for that case you probably can add a modprobe.d file that adds the device numbers with the device parameter | 08:48 |
| JanC | udev? | 08:52 |
| JanC | well, probably needs more than udev (this is SCSI over fibre, I understand) | 08:55 |
| smb | Yeah, well also its common (especially LPARs) to not want to enable all devices on the channel subsystem that are visible. | 08:57 |
| JanC | I don't have that sort of equipment, but I can see why you won't want that | 08:59 |
| 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:04 |
| smb | caribou, I guess in our case that will need some part of sysvinit or systemd to care about it... | 09:06 |
| caribou | well, looks like we will need a zfcp specific kernel which needs to be smaller than 32Mb | 10:55 |
| caribou | apw: smb ^^ | 10:55 |
| smb | caribou, I believe I remember needing a kernel not sure about the memory limitation | 10:59 |
| 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:00 |
| smb | caribou, ah ok... | 11:02 |
| pkern | smb: https://packages.qa.debian.org/s/sysconfig.html does it on Debian | 11:44 |
| 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 | 11:47 |
| === _bjf is now known as bjf | ||
| popey | hello! | 13:44 |
| popey | My 14.04 machine (x220) freezes a LOT! | 13:44 |
| 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? | 13:45 |
| 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:08 |
| popey | ok cking | 14:10 |
| 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:11 |
| cking | but I probably can't devote much time on this until late tomorrow or monday | 14:12 |
| popey | cking: ok | 14:30 |
| popey | cking: no hurry | 14:30 |
| 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 | 14:33 |
| 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:03 |
| 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:04 |
| genkgo | jsalisbury: the user that reported the bug first was running 3.13.0-49 | 15:06 |
| 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:07 |
| 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. | 15:08 |
| === kamal__ is now known as kamal | ||
| genkgo | alright, that leaves at least 5 more tests | 15:10 |
| jsalisbury | genkgo, we should have it figured out within a week or sooner | 15:11 |
| genkgo | great, really great | 15:11 |
| 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:12 |
| genkgo | jsalisbury: i understand, i also think that the earlier versions should exhibit the bug easier | 15:13 |
| 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:14 |
| 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 | 15:15 |
| === askb_ is now known as askb | ||
| leitao | ogasawara, Hello Leann. I just answered 1556096, but I am not able to assign back to ckt. | 17:24 |
| ogasawara | leitao: thanks, I'll take a look | 17:25 |
| leitao | ogasawara, thanks. Also, 1564487 is a regression after the cherry pick of 8244062ef1e54502ef55f54cced659913f244c3e | 17:30 |
| ogasawara | leitao: ack, I'll get the team to take a look at that as well | 17:34 |
| leitao | ogasawara, thank you! | 17:35 |
| === ghostcube_ is now known as ghostcube | ||
| === mamarley is now known as Guest55970 | ||
| === mamarley_ is now known as mamarley | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!