=== hughhalf_ is now known as hughhalf === tyhicks` is now known as tyhicks === shuduo-afk is now known as shuduo === jibel_ is now known as jibel [09:37] Hey Guys [09:37] Can somebody tell me why the Option CONFIG_MMC_UNSAFE_RESUME cant be set in new kernels? (4.0+) [09:39] I want to bind my sd card as /home, but then my laptop cant use suspend. The solution for people with an older kernel was this Option. Now it doesnt exist anymore. [09:40] denlud, well from the name UNSAFE does not sound that positive [09:40] denlud, did you have some kind of kernel command line override to enable that mode ? [09:40] It declares a SD Card as unremoveable. [09:41] Its only unsafe, if you change your sd cards. [09:41] i think yoiu can enforce that from userspace somehow [09:41] denlud: that behaviour became the default IIRC from chatting to the MMC maintainer and so the option went away [09:41] as being allowed to be, but ... does the option have an override to opt-in, otherwise that is a risky proposition [09:42] It becomes default? [09:42] But my /home isnt working after suspend.... [09:42] - CONFIG_MMC_UNSAFE_RESUME=y is now default behavior [09:42] cirtianly the changelogs imply the option became the default which fits amitk's memory [09:42] yes [09:43] denlud: and here is a line from his his weekly report to me: [09:43] * Submitted a new version of the patchset that makes MMC_UNSAFE_RESUME [09:43] default behaviour. [09:43] Ok, but it isnt working.... [09:44] What should i try anymore....i already tried alot :( [09:44] denlud: try talk to ulfh on #linaro-kernel [09:44] https://www.kernel.org/doc/menuconfig/drivers-mmc-core-Kconfig.html [09:44] This option sets a default which can be overridden by the [09:44] module parameter "removable=0" or "removable=1". [09:45] i think that may no longer exist [09:45] (now dont ask me how to set it if there is no module :P ) [09:45] But that was my Question.....:D [09:45] did you dig in sysfs ? [09:46] dig in sysfs? Sorry i am a Linux Beginner... [09:47] find /sys -name '*removable*' [09:47] check if there is anything mmc related [09:48] aha ... so it seems there is a cmdline option: [09:48] mmc_core.removable=0 [09:48] add that to youir kernel commandline [09:49] and see if that fixes it [09:49] yes that could be the solution!! [09:50] If that fixes my Problem, i love you ogra_ :D You dont know what i already make to get my /home work... [09:50] denlud, that option no longer exists in later kernels [09:50] it was removed when the option was set to =y and removed [09:50] really? [09:51] yes [09:51] how mean [09:51] not really, i think your sysfs thing is worth persuing [09:51] as the kernel behaves different depending how the card is marked removable/not [09:51] but the unsafe toggle for all cards is gone [09:52] as many machines using it have two slots one inside which is not-removable and one outside which is [09:52] so they need both semantics, different per card [09:52] whether you can lie to the kernle and say your external card is "not-removable" less easy to tell [09:52] on quick inspection [09:52] it's you arm types who have made this this way :) [09:53] I dont get why my SD Card isnt working, and my internal space is working. They are both MMC's. [09:53] Oh ok, apw... [09:53] ubuntu@localhost:~$ find /sys -name '*removable*'|grep mmcblk1 [09:53] find: ‘/sys/kernel/debug’/sys/devices/platform/soc/7864900.sdhci/mmc_host/mmc1/mmc1:1234/block/mmcblk1/removable [09:53] so seems on systems with mmc i have such a sysfs node [09:54] dennis@Yoda:~/kernel/linux-source-4.4.0$ find /sys -name '*removable*'|grep mmcblk1 [09:54] find: "/sys/kernel/debug"/sys/devices/pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable [09:54] : Keine Berechtigung [09:54] find the equivalent on your system and make sure the content is "0" [09:55] well, if mmcblk1 is your mmc device ... else your command needs to filter "mmcblk0" [09:56] my working mmc device is mmcblk0 (the internal space) [09:56] so: find /sys -name '*removable*'|grep mmcblk0 [09:56] shoving a card in mine it is marked non-removable ... so i'd kinda expect that work be ok [09:56] would [09:56] but perhaps that is a lie from my bios or something, hmmmm [09:58] find: "/sys/kernel/debug"/sys/devices/pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable [09:58] how can i lie to my kernel now, and say its non removeable? [09:58] I dont get it sorry... [10:01] why do you look at mmcblk1 ? [10:02] (you said above it is mmcblk0) [10:03] No, the already working mmc is mmcblk0 [10:03] home "is" mmcblk1 [10:04] denlud, what sort of machine is this ... [10:04] Its a Lenovo 100s [10:04] and it only has 32Gb internal space. 14" version [10:04] denlud, and is the mmcblk0 "inside" and mmcblk1 a removable slot ? [10:04] Yes. [10:07] and when you s/r what happens to your card goes into error or something ? [10:08] https://forum.ubuntuusers.de/topic/sd-karte-home-wird-falsch-behandelt/ [10:08] Here I posted all outputs. [10:08] Dont want to post It here, its very much... [10:09] yep [10:09] well on a cursory examination i cannot actually see a way to override the behaviour, it seems to be defined [10:10] by the machine definition telling the slot whether it is removable, and if it is, it gets zapped on s/r [10:10] My second output I posted there was after suspend, when my /home isnt working anylonger. And the programs are already crashed [10:11] So I must try a flipping of the bios removeable bit? [10:13] denlud, i am not sure you would even have such a setting, you might, but ... [10:13] though the description implies the card should be handled as if the old UNSAFE is set, so i am not sure [10:14] why this is not working as one would expect, i guess some later change [10:14] http://apple.stackexchange.com/questions/113202/can-i-mark-a-sd-card-as-permanent-storage [10:15] Oh, that is for apple. I thought if it would be for windows. I can install Windows. flipping the bit in the BIOS, install Linux and be happy. [10:19] Seems like I have to give my Laptop back... [10:20] Or should i try flipping the BIOS non removeable bit? pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable [10:23] denlud, i have no idea if that is even the right kind of bit as that is marked non-removable already ... right, it is 0 [10:25] dennis@Yoda:~/kernel/linux-source-4.4.0$ cat /sys/devices/pci0000:00/0000:00:12.0/mmc_host/mmc2/mmc2:aaaa/block/mmcblk1/removable [10:25] 0 [10:26] this descrption still says that the kernel should be behaving as it was with unsafe set, which should work [10:26] ie the card should just be being s/r as well [10:27] You think the problem must be somewhere else? [10:28] it feels like the card is not handling s/r well [10:28] i wonder if i can confirm that here somehow ... === davmor2_ is now known as davmor2 [10:30] Can i send you a pastebin link, i make some orders after suspend. And there some I/O Errors I think. [10:30] *? [10:31] http://pastebin.com/FwzhraHt [10:32] This output is after suspend. Maybe you can take a look at it. [10:33] (At the moment when /home isnt working) [10:36] because it becake readonly obviously [10:36] *became [10:38] ...can I do something against that bevior? [10:39] denlud, ok i just added an sd card in my external sd slot, which i believe is marked removable [10:39] denlud, and after a s/r it is still there and working, no errors [10:39] denlud, what kernel version are you using [10:39] I tried 4.2, 4.4.0-12 and 4.4.0-18 and 4.4.6 [10:40] so i am using 4.4.0-20 and it worked there for me, but i would expect -18 to be the same for mmc things [10:40] so that for me suggests it is machine specific in some way, but i am not really sure what to suggest as mine works [10:40] or at least not affecting everyeone [10:42] Maybe I try another SD Card [10:42] What datasystem are you using FAT? [10:46] denlud, ext4, so something which cares if the media is ripped out [10:48] Ok, so i try another SD Card now and thats all i can try or? [10:48] i am out of obvious ideas at this point [10:49] Ok, but thank you and ogra_ for your help. [10:49] And sorry for my english, I dont write in english very often. [10:49] np [10:49] your english is perfectly understandable === henrix_ is now known as henrix === Beret- is now known as Beret === mukhbiir is now known as neoark === Trevinho_ is now known as Trevinho === Ursinha_ is now known as Ursinha === infinity_ is now known as infinity === kloeri__ is now known as kloeri === dgadomski_ is now known as dgadomski === ghostcube_ is now known as ghostcube [13:04] cking: any news about pkg-zfs/pkg-spl packaging repositories? the one at git://kernel.ubuntu.com/cking/pkg-zfs.git is still very much out of date, and the zfs user space source packages don't reference anything.. [13:05] also are there any plans to include ZFS support in the ubuntu installer? couldn't find anything in the beta 2 iso that would allow me to setup zfs as root fs [13:06] fg__, i will get onto that, just I'm buried in some other higher priority tasks at the moment [13:06] fg__, no, it's not going to be supported in the 16.04 installer [13:10] I figured you would have other stuff on your plate with the nearing release, but figured asking would not hurt ;) thanks! [13:16] apw, So fwiw I dug out an old aspire one that got mmc card reader and I neither can see any attempt (4.4.0-18) to eject the card and can suspend/resume even with an ext3 mounted and cd'ed into the path on a terminal window to keep it occupied === leitao_ is now known as leitao === ogra_` is now known as ogra_ [13:28] Hi, I've analyzed bug 1570195 down to an issue in DPDK (not clear what it is exactly yet) and the kernel (can drive virtio into an infinite loop) [13:28] bug 1570195 in linux (Ubuntu) "Net tools cause kernel soft lockup after DPDK touched VirtIO-pci devices" [Medium,Confirmed] https://launchpad.net/bugs/1570195 [13:29] smb: arges: ^^ the bug holds a lot of debug info, but I'll give you the tl;dr and ask you a few important questions for confirmation before I go out to the dpdk and kernel community [13:30] the most important open question to me would be - "what would need to happen" in the virtio protocol/host/guest-implementation so that the loop at the end of virtnet_send_command becomes an infinite loop [13:30] it seems the buffers never change/refill again - but that is my assumption [13:30] look at this for the loop http://lxr.free-electrons.com/source/drivers/net/virtio_net.c#L1011 [13:31] cpaelzer, maybe you allow me/us a bit to read into the bug [13:31] oh absolutely - I'm happy about a few more eyes trying to reinterpret [13:31] yea what smb said : ) lots of data [13:31] I might have diverged from the right way several times [13:32] cpaelzer, There is rarely "the" right way anyway [13:34] cpaelzer: without reading the entire bug, have you been able to eliminate any variables causing this bug? dpdk/ovs/virtio/multiqueue ; does it work with newer kernel version, etc [13:35] yes [13:35] ovs is out of the scope [13:35] also dpdk doesn't need to run traffic, just initializing the devices is enough [13:35] anything that goes through virtnet_send_command seems to block === dgadomski is now known as dgadomski_ [13:36] and upstream dpdk also fails with the same issue? [13:36] I didn't check an upstream kernel yet, but can do that along you are reading this === dgadomski_ is now known as dgadomski [13:36] cpaelzer, with initializing you mean let the app grab the devices not bound to a linux driver === dgadomski is now known as dgadomski_ === dgadomski_ is now known as dgadomski [13:36] smb: this is virtio - dpdk grabs the device even while bound with a linux driver [13:36] that is part of the problem as it leaves it behind in a broken state [13:37] arges: I can test upstream versions of both over the next hour and let you and the bug know - a good test for sure [13:37] not that I would have seen anything in the dpdk commits, but one can never be sure [13:38] cpaelzer: yup [13:42] cpaelzer, Hm, imo that should not be possible and probably is the problem. While the virtio network driver is bound to the device dpdk should not be able to directly access it. But thats right now a high level opinion (without much research) [13:42] smb: it does work and it is how the people use it [13:42] smb: which doesn't counter your opinion at all - I wondered myself at first [13:49] smb: I asked on the DPDK channel what the opinion of the DPDK Maintainers to that is [13:49] e.g. do they epxect people to reinitialize devices ? [13:50] or even not to use them while bound to virtio-pci in general (but what would the PMD driver be for then) === PaulW2U_ is now known as PaulW2U [13:56] cpaelzer, I could imagine that being bound there, though there is also the virtio bus involved and there the virtio-net driver. But with the whole stack set up I can imagine that virtio-net could make certain assumptions which may be messed up by something else touching the lower level protocol [14:01] smb: thanks, that is like a +1 to my theory [14:01] still in general we would like to protect the kernel by e.g. detect too much retries in that loop and bail out right? [14:04] I'll later on once confirmed on latest upstream of kernel and dpdk send mails to their mailing lists [14:04] cpaelzer, heh... well the question is a bit whether virtio protocol should ever be in the situation to have a loop. The answer from that side might be that should never happen so one needs to fix the loophole of getting there. [14:04] IMHO the kernel should get a protection to return an error instead of hanging [14:04] and DPDK should more clearly state to either not do it this way OR add something like "after you touched it it is broken, you need to reinit" [14:05] smb: yeah, but so far I con only point at the end of the loophole and can't clearly say which part breaks it :-) [14:06] If the virtio nic would behave like a physical one you would get an error when trying to access it without rebinding to some userspace io driver, wouldn't you [14:06] smb: yes [14:07] smb: also a lot of people ran into trouble by dpdk (by default) grabbing all virtio-pci devices (usually shutting your ssh connection down) [14:07] unfortunately so far no one responded on the DPDK IRC chan [14:07] cpaelzer, Oh I know... [14:08] but if nothing gets back the mail will do [14:08] you have to blacklist/whitelist things to go on with virto-pci [14:08] ah you mean you ran into that smb? [14:08] Yeah... not sure that was even with real hw and accidentally forgetting the blacklist ... [14:09] back in 2.0 [14:10] at least some state of kiss your network connectivity good bye after trying what happens when I run testpmd... [14:19] smb: ha - the dpdk maintainer responded [14:19] smb: the admin is supposed to reinitialize [14:19] known deficiency [14:20] I'll submit patches for the docs of dpdk and our readme in packaging and our serverguid doc about it [14:20] yet I think the kernel should protect itself in some way and will start the discussion on that later as well [14:23] cpaelzer, yeah somehow it should be similar to real hw. I just cannot really say how this all should interact together... [14:28] smb: there is a patch that it no more initializes when bound to virtio-pci [14:29] smb: just discussing with the DPDK maintainer - I'll try to backport that [14:29] that would mean a user would have to unbind it from virtio-pci before using it in dpdk [14:29] and to use it in the normal linux world would have to rebind it [14:29] that would reinitialize and all is good [14:30] cpaelzer, I think that would make it behave "normal" so much better [14:30] ack === smoser` is now known as smoser === ghostcube__ is now known as ghostcube [19:47] lamont, I pinged upstream regarding you bug again. I cc'd you on the mail, so you can stay in the loop. [19:48] woot === ghostcube_ is now known as ghostcube === alexlist` is now known as alexlist [23:53] Heey whats up? [23:56] I have a Problem with my diskspace, would be great if someone can i help me. I have downloaded to much porns, now my home memory is full. How can i expand it with an external drive?