Bug#822397: FTBFS: configure: error: "Some plugins are missing dependencies
On Sat, May 21, 2016 at 04:46:01PM +0200, Santiago Vila wrote: > I'm making the usual tidy up here: > > Reassign to linux because that's where the real bug was. > Affects because it made this package to FTBFS. Thanks! -- Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin signature.asc Description: Digital signature
Re: LTS kernel in jessie-backports
On 05/24/2016 08:23 PM, Ben Hutchings wrote: On Tue, 2016-05-24 at 21:51 -0400, Nicholas D Steeves wrote: Dear Debian Kernel Team, My primary area of interest is btrfs on Debian. The most reliable way of limiting one's risk while using this experimental file system is to run the most recent LTS kernel, and to minimize the use of exotic features, or in some cases not use them at all (eg: RAID56 which doesn't yet have proven scrub/self healing support). In the interest of providing the most stable btrfs experience to users of Debian stable, would it be possible to fork the jessie-backport of src:linux from 4.4.6-1, update it to 4.4.11-1, and then continue to maintain the branch? I believe I am underqualified to maintain it myself, but if it would be sufficient to learn the workflow of patch-level updates to the src:linux-derived package, then I might be able to help with the effort. That's not how Debian backports suites work, sorry. I maintain forks of debian kernels for the LinuxCNC project. The workflow i use may be useful to you if you want to maintain your own fork, Nicholas. As Ben says, this would be a personal fork of yours that you would maintain, it would not become part of the debian backports repo. My work is in two parts, tracked in two git repos: The first is a build system that builds my custom debian-based linux image (plus a bunch of other packages that are important to me but that you probably don't care about): https://github.com/SebKuzminsky/linux-rtai-build (see the 3.4-wheezy branch). This build system first makes a dsc, then builds the dsc in pbuilder into debs. The second is my fork of the debian linux kernel packaging repo. The original debian repo is here: https://anonscm.debian.org/cgit/kernel/linux.git My fork is here: https://github.com/SebKuzminsky/linux-rtai-debian (see the 3.4.55-rtai branch) Feel free to ask me questions if any of that doesn't make sense. -- Sebastian Kuzminsky
Re: LTS kernel in jessie-backports
On Tue, 2016-05-24 at 21:51 -0400, Nicholas D Steeves wrote: > Dear Debian Kernel Team, > > My primary area of interest is btrfs on Debian. The most reliable way > of limiting one's risk while using this experimental file system is to > run the most recent LTS kernel, and to minimize the use of exotic > features, or in some cases not use them at all (eg: RAID56 which > doesn't yet have proven scrub/self healing support). In the interest > of providing the most stable btrfs experience to users of Debian > stable, would it be possible to fork the jessie-backport of src:linux > from 4.4.6-1, update it to 4.4.11-1, and then continue to maintain the > branch? > > I believe I am underqualified to maintain it myself, but if it would > be sufficient to learn the workflow of patch-level updates to the > src:linux-derived package, then I might be able to help with the > effort. That's not how Debian backports suites work, sorry. Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
LTS kernel in jessie-backports
Dear Debian Kernel Team, My primary area of interest is btrfs on Debian. The most reliable way of limiting one's risk while using this experimental file system is to run the most recent LTS kernel, and to minimize the use of exotic features, or in some cases not use them at all (eg: RAID56 which doesn't yet have proven scrub/self healing support). In the interest of providing the most stable btrfs experience to users of Debian stable, would it be possible to fork the jessie-backport of src:linux from 4.4.6-1, update it to 4.4.11-1, and then continue to maintain the branch? I believe I am underqualified to maintain it myself, but if it would be sufficient to learn the workflow of patch-level updates to the src:linux-derived package, then I might be able to help with the effort. Kind regards, Nicholas
Bug#777683: e1000e driver, empty TX queue after IP drop causes dev_watchdog
I too have the same problem on Debian as 3 others do. As a former Ethernet driver developer, I noticed that the queue is empty when the interrupt was fired. And that it appeared hung in the Linux qdisc portion at Interrupt context, to a point of having watchdog timer expiring. My relevant details is: Dell OptiPlex 980 3.16.0-4-amd64 linux/3.16.7-ckt25-2 (2016-04-08) x86_64 Intel Gigabit Ethernet 82578DM Gigabit Network Connection (rev 05) From what I've gathered from the following potentially duplicate bug #798512 and Intel Community Forums: 1 - It isn't CPU-related 2. This error happened in the following Linux kernel versions: a. 3.16.0-4-amd64 b. 3.19.5 (source: Intel communities) c. 4.3+70~bpo8+1 b. 3.16.7-ckt11-1 3. This error does NOT happen in the following Linux kernel versions (take this with a grain of salt, for we haven't a reliable repeatable bug inducement yet): a. 3.16.7-ckt20-1+deb8u4 4. Intel driver used but still have error b. 3.3.3-NAPI 5. Intel hardware having this problem a. Intel I217-V (rev 04) (onboard) (has lspci SERR-) b. Intel 82578DM (rev 05) (onboard) (has lspci SERR+) c. Intel Corporation 82579V Gigabit Network Connection (rev 05) (onboard) 6. Linux network a. eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 b. eth0: mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000 So far, common thread of the alike problems is the following (more reports will eliminate a few): 1. e1000e driver 2. ip link using 'qdisc' and 'pfifo_fast' option 2. onboard Ethernet (PCI-related?) 3. Starting at Linux 3.16.0 4. IP outgoing packets dropped was non-zero (mostly 32 packets) 4. share similar call stack backtrace: Bug #777683 call stack backtrace [ 295.041406] [] ? dump_stack+0x41/0x51 [ 295.041417] [] ? warn_slowpath_common+0x77/0x90 [ 295.041420] [] ? warn_slowpath_fmt+0x4c/0x50 [ 295.041425] [] ? mod_timer+0x127/0x1e0 [ 295.041430] [] ? dev_watchdog+0x236/0x240 [ 295.041433] [] ? dev_graft_qdisc+0x70/0x70 [ 295.041436] [] ? call_timer_fn+0x31/0x100 [ 295.041439] [] ? dev_graft_qdisc+0x70/0x70 [ 295.041442] [] ? run_timer_softirq+0x209/0x2f0 [ 295.041445] [] ? __do_softirq+0xf1/0x290 [ 295.041448] [] ? irq_exit+0x95/0xa0 [ 295.041451] [] ? smp_apic_timer_interrupt+0x45/0x60 [ 295.041455] [] ? apic_timer_interrupt+0x6d/0x80 [ 295.041456] [] ? get_next_timer_interrupt+0x1d6/0x250 [ 295.041465] [] ? cpuidle_enter_state+0x4f/0xc0 [ 295.041468] [] ? cpuidle_enter_state+0x48/0xc0 [ 295.041472] [] ? cpu_startup_entry+0x2f8/0x400 [ 295.041475] [] ? start_kernel+0x492/0x49d [ 295.041478] [] ? set_init_arg+0x4e/0x4e [ 295.041480] [] ? early_idt_handlers+0x120/0x120 [ 295.041483] [] ? x86_64_start_kernel+0x14d/0x15c [ 295.041485] ---[ end trace aaf46f7eeccba58f ]--- [ 295.041502] e1000e :00:19.0 eth-office: Reset adapter unexpectedly Intel Community Forums (Intel 3.3.3-NAPI driver): (source: https://communities.intel.com/message/305442#305442) [] ? dump_stack+0x40/0x57 [] ? warn_slowpath_common+0x81/0xb0 [] ? warn_slowpath_fmt+0x5c/0x80 [] ? dev_watchdog+0x229/0x240 [] ? dev_deactivate_queue.constprop.34+0x60/0x60 [] ? call_timer_fn+0x30/0xf0 [] ? dev_deactivate_queue.constprop.34+0x60/0x60 [] ? run_timer_softirq+0x17d/0x2b0 [] ? __do_softirq+0x107/0x270 [] ? irq_exit+0x86/0x90 [] ? smp_apic_timer_interrupt+0x3e/0x50 [] ? apic_timer_interrupt+0x82/0x90 [] ? cpuidle_enter_state+0xe8/0x220 [] ? cpuidle_enter_state+0xc3/0x220 [] ? cpu_startup_entry+0x294/0x350 [] ? start_secondary+0x150/0x190 Debian Bug #798512 ] ? warn_slowpath_common+0x77/0x90 ] ? warn_slowpath_fmt+0x4c/0x50 ] ? mod_timer+0x127/0x1e0 ] ? dev_watchdog+0x236/0x240 ] ? dev_graft_qdisc+0x70/0x70 ] ? call_timer_fn+0x31/0x100 ] ? dev_graft_qdisc+0x70/0x70 ] ? run_timer_softirq+0x209/0x2f0 ] ? __do_softirq+0xf1/0x290 ] ? irq_exit+0x95/0xa0 My /var/log/message (3.6.14): dmesg: e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k dmesg: e1000e :00:19.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode dmesg: e1000e :00:19.0 eth0: Detected Hardware Unit Hang: May 24 18:44:55 sandbay kernel: [ 840.766377] [] ? dump_stack+0x5d/0x78 May 24 18:44:55 sandbay kernel: [ 840.766391] [] ? warn_slowpath_common+0x77/0x90 May 24 18:44:55 sandbay kernel: [ 840.766396] [] ? warn_slowpath_fmt+0x4c/0x50 May 24 18:44:55 sandbay kernel: [ 840.766410] [] ? dev_watchdog+0x236/0x240 May 24 18:44:55 sandbay kernel: [ 840.766418] [] ? dev_graft_qdisc+0x70/0x70 May 24 18:44:55 sandbay kernel: [ 840.766424] [] ? call_timer_fn+0x31/0x100 May 24 18:44:55 sandbay kernel: [ 840.766435] [] ? dev_graft_qdisc+0x70/0x70 May 24 18:44:55 sandbay kernel: [ 840.766439] [] ? run_timer_softirq+0x209/0x2f0 May 24 18:44:55 sandbay kernel: [ 840.766444] [] ? __do_softirq+0xf1/0x290 May 24 18:44:55 sandbay kernel: [ 840.766452] [] ? irq_exit+0x95/0xa0 May 24 18:44:55 sandbay kerne
Bug#756900: #756900: nfs-utils: NFS 1.3 fixes NFS systemd integration
I recently upgraded my NFSv3 clients from wheezy to jessie, and they just DID NOT WORK. The NFS sysvinit init scripts had dependency cycles & race conditions when used under systemd. I ended up writing my own systemd units for the parts I needed (foo.mount, statd, & rpcbind), and disabling the rest. While working on that, I discovered that upstream has already solved this problem. nfs-utils 1.3.x includes native systemd integration. This week I went to upgrade my NFSv3 server to stretch (from pre-systemd). I was disappointed to discover that Debian STILL doesn't have nfs-utils 1.3.x. I guess I'll have to write my own systemd units again! :-/ If upgrading nfs-utils right now will cause problems, I totally get that. Keeping things working is a lot harder for all of Debian than for just me. But can someone please at least reply and say what the blockers ARE? This ticket has been open for nearly TWO YEARS, with no reply. This makes it hard for me to manage $boss's expectations. PS: some of my jessie issues were in rpcbind, not nfs-utils. #806336 looks particularly relevant; which also appears to be ignored. PPS: maybe this issue HAS been discussed, just somewhere else. Due to the maintainer archive link on https://tracker.debian.org/pkg/nfs-utils, I checked https://lists.debian.org/debian-kernel/, but I found nothing. I also found nothing in "wnpp-check nfs-utils".
Bug#823552: [PATCH] Re: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
> dev_err(dev, "couldn't get clock\n");
> return -EINVAL;
> }
> clk_prepare_enable(exynos->clk);
OK, so I took Mark's advice and moved the phy instantiation towards the end
of the function (after the regulators have successfully come up). It reduced
the number of probes, even with the original initramfs, dramatically, so
it seems to work quite well. It also reduces the text for each deferred probe
by a lot, since we no longer have the dummy regulator message for each one
(only the message about “no suspend clk specified” is left). Finally, this
arrangement reduced the need for extra error handling to a minimum.
Cc-ing Felipe and and linux-usb@, and adding the patch as a reply to this
message.
/* Steinar */
--
Homepage: https://www.sesse.net/
Bug#823552: [PATCH] dwc3-exynos: Fix deferred probing storm.
dwc3-exynos has two problems during init if the regulators are slow
to come up (for instance if the I2C bus driver is not on the initramfs)
and return probe deferral. First, every time this happens, the driver
leaks the USB phys created; they need to be deallocated on error.
Second, since the phy devices are created before the regulators fail,
this means that there's a new device to re-trigger deferred probing,
which causes it to essentially go into a busy loop of re-probing the
device until the regulators come up.
Move the phy creation to after the regulators have succeeded, and also
fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
which doesn't contain the I2C driver), this reduces the number of probe
attempts (for each of the two controllers) from more than 2000 to eight.
Reported-by: Steinar H. Gunderson
Signed-off-by: Steinar H. Gunderson
---
drivers/usb/dwc3/dwc3-exynos.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index dd5cb55..2f1fb7e 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -128,12 +128,6 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, exynos);
- ret = dwc3_exynos_register_phys(exynos);
- if (ret) {
- dev_err(dev, "couldn't register PHYs\n");
- return ret;
- }
-
exynos->dev = dev;
exynos->clk = devm_clk_get(dev, "usbdrd30");
@@ -183,20 +177,29 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
goto err3;
}
+ ret = dwc3_exynos_register_phys(exynos);
+ if (ret) {
+ dev_err(dev, "couldn't register PHYs\n");
+ goto err4;
+ }
+
if (node) {
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
dev_err(dev, "failed to add dwc3 core\n");
- goto err4;
+ goto err5;
}
} else {
dev_err(dev, "no device node, failed to add dwc3 core\n");
ret = -ENODEV;
- goto err4;
+ goto err5;
}
return 0;
+err5:
+ platform_device_unregister(exynos->usb2_phy);
+ platform_device_unregister(exynos->usb3_phy);
err4:
regulator_disable(exynos->vdd10);
err3:
--
2.8.0.rc3.226.g39d4020
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:53:34PM +0200, Krzysztof Kozlowski wrote:
>> Which devm_clk_get() error are you talking about? The one with susp_clk?
> Now I saw your original report on Debian bugzilla. Let's stick to v4.5.
I'm actually developing on 4.6, but sure. The differences are small from what
I can see.
> exynos->clk = devm_clk_get(dev, "usbdrd30");
> if (IS_ERR(exynos->clk)) {
> + // On each error path since here we need to
> + // revert work done by dwc3_exynos_register_phys()
> dev_err(dev, "couldn't get clock\n");
> return -EINVAL;
> }
> clk_prepare_enable(exynos->clk);
OK, sounds like these should be changed to the common goto pattern to save on
the repeated cleanup. I'll have a stab at that later today.
>> That's an interesting case because a) nothing actually uses susp_clk
>> (it's dead code, presumably waiting for further patches),
> It does not look like dead code because it is enabled.
But not a single DT seems to set such a suspend clock, from what I can see?
> Yeah, but you did not send it to appropriate people. get_maintainer.pl
> will point you (Felipe Balbi handles the patches for this driver).
Ack.
> Apparently the s2mps11 regulator driver can be built as module... but is
> not a commonly tested configuration. In our testing configs (exynos and
> multi_v7) it is built-in. Actually most of PMICs are built in.
I don't have a lot of control over how Debian chooses to build kernels --
from what I gather from previous conversations, the kernel team are unhappy
about building things into the kernel if they can be modules. And in this
case, it wasn't even about the s2mps11 module, it was just that it didn't
have an I2C bus ready for init.
/* Steinar */
--
Homepage: https://www.sesse.net/
Re: Bug#569135: xserver-xorg-video-intel: corruption on external VGA display
I AFtat Amy Martin :)
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On 05/24/2016 05:26 PM, Steinar H. Gunderson wrote:
> On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote:
>> I looked quickly through the thread and I am not sure what is exactly
>> your problem.
>
> My immediate problem is that the repeated (deferred) probing is causing so
> much logging that the system doesn't actually boot. The root causes are a bit
> more complex and muddy (see my previous email for a breakdown).
Ah, I got it.
>
>> I understood that the Exynos dwc3 driver is leaking the
>> PHY. That is a good catch but your patch is not sufficient. You should
>> clean up starting from devm_clk_get() error. Unless you are fixing
>> this for different kernel version.
>
> I have zero idea how all of this is supposed to be connected, much less how
> DWC3 works or what the driver is supposed to do. I'm just an end user trying
> to figure out why my system didn't boot. :-)
>
> Which devm_clk_get() error are you talking about? The one with susp_clk?
Now I saw your original report on Debian bugzilla. Let's stick to v4.5.
The platform_device_alloc() is done in dwc3_exynos_register_phys(). So
on error paths you have clean up starting from next error:
ret = dwc3_exynos_register_phys(exynos);
if (ret) {
dev_err(dev, "couldn't register PHYs\n");
return ret;
}
exynos->dev = dev;
exynos->clk = devm_clk_get(dev, "usbdrd30");
if (IS_ERR(exynos->clk)) {
+ // On each error path since here we need to
+ // revert work done by dwc3_exynos_register_phys()
dev_err(dev, "couldn't get clock\n");
return -EINVAL;
}
clk_prepare_enable(exynos->clk);
> That's an interesting case because a) nothing actually uses susp_clk
> (it's dead code, presumably waiting for further patches),
It does not look like dead code because it is enabled.
> and b) there was a
> commit not too long ago (42f69a02) upgrading the message from dev_dbg to
> dev_info for reasons I don't understand, making the problem worse.
> (The commit message had an argument that I could accept for changing _to_
> dbg, but not the other way round.
I don't get the rationale behind that change neither...
>> Please send an appropriate separate patch for fixing this. Your email
>> did not reach people, I think.
>
> I only sent one patch so far, namely the leak fix.
Yeah, but you did not send it to appropriate people. get_maintainer.pl
will point you (Felipe Balbi handles the patches for this driver).
>
>> What other problems exactly do you have? Late binding of S2MPS11
>> regulator driver? That does not look like a problem. If it is built as
>> a module then it should be loaded, probably from initramfs because
>> these are regulators.
>
> In this specific case, Debian's initramfs has neglected to include the i2c
> driver in the initramfs, so the regulator doesn't come up until the boot is
> out of the initramfs. That's probably a bug in its own right, and fixing it
> reduces the amount of messages by a _lot_, but even so, it sounds to me like
> the kernel should be able to boot without that fix.
Apparently the s2mps11 regulator driver can be built as module... but is
not a commonly tested configuration. In our testing configs (exynos and
multi_v7) it is built-in. Actually most of PMICs are built in.
Additionally, if you look at the driver, its init was moved earlier from
module_init() to subsys_initcall(). This is kind of manual probe
ordering, used mostly because some depending drivers did not support
probe deferral.
Best regards,
Krzysztof
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:26:38PM +0200, Steinar H. Gunderson wrote: > On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > > Please send an appropriate separate patch for fixing this. Your email > > did not reach people, I think. > I only sent one patch so far, namely the leak fix. You buried it in the middle of another mail and didn't CC any of the maintainers - he's asking you to submit it using the process in SubmittingPatches, the USB maintainers won't have seen this discussion and may not notice a patch buried in the middle of a message in the middle of a thread even if they see it. signature.asc Description: PGP signature
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > What other problems exactly do you have? Late binding of S2MPS11 > regulator driver? That does not look like a problem. If it is built as > a module then it should be loaded, probably from initramfs because > these are regulators. AFAICT the fact that every time the dwc3-exynos driver probes it creates a new child device which successfully instantiates means that we end up constantly running deferred probes. It should only create the child devices if it managed to get the other resources, that way we don't get the constant deferred probe retries. signature.asc Description: PGP signature
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Tue, May 24, 2016 at 05:06:43PM +0200, Krzysztof Kozlowski wrote: > I looked quickly through the thread and I am not sure what is exactly > your problem. My immediate problem is that the repeated (deferred) probing is causing so much logging that the system doesn't actually boot. The root causes are a bit more complex and muddy (see my previous email for a breakdown). > I understood that the Exynos dwc3 driver is leaking the > PHY. That is a good catch but your patch is not sufficient. You should > clean up starting from devm_clk_get() error. Unless you are fixing > this for different kernel version. I have zero idea how all of this is supposed to be connected, much less how DWC3 works or what the driver is supposed to do. I'm just an end user trying to figure out why my system didn't boot. :-) Which devm_clk_get() error are you talking about? The one with susp_clk? That's an interesting case because a) nothing actually uses susp_clk (it's dead code, presumably waiting for further patches), and b) there was a commit not too long ago (42f69a02) upgrading the message from dev_dbg to dev_info for reasons I don't understand, making the problem worse. (The commit message had an argument that I could accept for changing _to_ dbg, but not the other way round.) > Please send an appropriate separate patch for fixing this. Your email > did not reach people, I think. I only sent one patch so far, namely the leak fix. > What other problems exactly do you have? Late binding of S2MPS11 > regulator driver? That does not look like a problem. If it is built as > a module then it should be loaded, probably from initramfs because > these are regulators. In this specific case, Debian's initramfs has neglected to include the i2c driver in the initramfs, so the regulator doesn't come up until the boot is out of the initramfs. That's probably a bug in its own right, and fixing it reduces the amount of messages by a _lot_, but even so, it sounds to me like the kernel should be able to boot without that fix. /* Steinar */ -- Homepage: https://www.sesse.net/
Processed: fixed 825209 in 4.6~rc3-1~exp1
Processing commands for cont...@bugs.debian.org: > fixed 825209 4.6~rc3-1~exp1 Bug #825209 [src:linux] Incomplete statistics to manage balloon effectively Bug #825213 [src:linux] Incomplete statistics to manage balloon effectively Marked as fixed in versions linux/4.6~rc3-1~exp1. Marked as fixed in versions linux/4.6~rc3-1~exp1. > thanks Stopping processing here. Please contact me if you need assistance. -- 825209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825209 825213: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825213 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 825211 in 3.19-1~exp1
Processing commands for cont...@bugs.debian.org: > fixed 825211 3.19-1~exp1 Bug #825211 [src:linux] OOM in Debian guests on balloon overinflation Marked as fixed in versions linux/3.19-1~exp1. > thanks Stopping processing here. Please contact me if you need assistance. -- 825211: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825211 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 825212 to src:linux, forcibly merging 825208 825212
Processing commands for cont...@bugs.debian.org: > reassign 825212 src:linux Bug #825212 [base] Ballooned memory is visible via proc Bug reassigned from package 'base' to 'src:linux'. Ignoring request to alter found versions of bug #825212 to the same values previously set Ignoring request to alter fixed versions of bug #825212 to the same values previously set > forcemerge 825208 825212 Bug #825208 [src:linux] Ballooned memory is visible via proc Bug #825212 [src:linux] Ballooned memory is visible via proc Merged 825208 825212 > thanks Stopping processing here. Please contact me if you need assistance. -- 825208: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825208 825212: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825212 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 825208 in 4.3~rc3-1~exp1
Processing commands for cont...@bugs.debian.org: > fixed 825208 4.3~rc3-1~exp1 Bug #825208 [src:linux] Ballooned memory is visible via proc Bug #825212 [src:linux] Ballooned memory is visible via proc Marked as fixed in versions linux/4.3~rc3-1~exp1. Marked as fixed in versions linux/4.3~rc3-1~exp1. > thanks Stopping processing here. Please contact me if you need assistance. -- 825208: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825208 825212: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825212 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 825211 to src:linux
Processing commands for cont...@bugs.debian.org: > reassign 825211 src:linux Bug #825211 [base] OOM in Debian guests on balloon overinflation Bug reassigned from package 'base' to 'src:linux'. Ignoring request to alter found versions of bug #825211 to the same values previously set Ignoring request to alter fixed versions of bug #825211 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 825211: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825211 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 825213 to src:linux, forcibly merging 825209 825213
Processing commands for cont...@bugs.debian.org: > reassign 825213 src:linux Bug #825213 [base] Incomplete statistics to manage balloon effectively Bug reassigned from package 'base' to 'src:linux'. Ignoring request to alter found versions of bug #825213 to the same values previously set Ignoring request to alter fixed versions of bug #825213 to the same values previously set > forcemerge 825209 825213 Bug #825209 [src:linux] Incomplete statistics to manage balloon effectively Bug #825213 [src:linux] Incomplete statistics to manage balloon effectively Merged 825209 825213 > thanks Stopping processing here. Please contact me if you need assistance. -- 825209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825209 825213: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825213 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#825209: Incomplete statistics to manage balloon effectively
Processing control commands: > reassign -1 src:linux Bug #825209 [kernel] Incomplete statistics to manage balloon effectively Warning: Unknown package 'kernel' Bug reassigned from package 'kernel' to 'src:linux'. Ignoring request to alter found versions of bug #825209 to the same values previously set Ignoring request to alter fixed versions of bug #825209 to the same values previously set -- 825209: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825209 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#823552: Endless "supply vcc not found, using dummy regulator"
On Mon, May 23, 2016 at 7:06 PM, Steinar H. Gunderson wrote: > On Mon, May 23, 2016 at 05:24:55PM +0100, Mark Brown wrote: Cc-ing Mark in case he has any insights (I hope I have the right email address). >> But nobody who works on probe deferral or made any of the suggestions I >> mentioned in the message you linked to, nor anyone who works on the >> driver you've identified a bug in... :( > > As for the former, I have no idea who they would be, sorry. For the latter, > isn't linux-samsung-soc@ the right place? MAINTAINERS said it was. I looked quickly through the thread and I am not sure what is exactly your problem. I understood that the Exynos dwc3 driver is leaking the PHY. That is a good catch but your patch is not sufficient. You should clean up starting from devm_clk_get() error. Unless you are fixing this for different kernel version. Please send an appropriate separate patch for fixing this. Your email did not reach people, I think. Just make a patch, test it, scripts/checkpatch and scripts/get_maintainers. It is a fix so also a candidate for this release cycle. if you do not plan to send a patch, I can prepare on my own with your "Reported-by" tag but actually this is your finding so credits (and effort) should go to you. :) What other problems exactly do you have? Late binding of S2MPS11 regulator driver? That does not look like a problem. If it is built as a module then it should be loaded, probably from initramfs because these are regulators. Best regards, Krzysztof
Processed: Re: Bug#825208: Ballooned memory is visible via proc
Processing control commands: > reassign -1 src:linux Bug #825208 [kernel] Ballooned memory is visible via proc Warning: Unknown package 'kernel' Bug reassigned from package 'kernel' to 'src:linux'. Ignoring request to alter found versions of bug #825208 to the same values previously set Ignoring request to alter fixed versions of bug #825208 to the same values previously set -- 825208: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825208 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Bug#825209: Incomplete statistics to manage balloon effectively
control: reassign -1 src:linux On Tue, May 24, 2016 at 02:53:53PM +, Anna Melekhova (Vorobyova) wrote: > Package: kernel > Version: Debian 7, Debian 8 as #825208, these are not valid headers, but reassigning nonetheless. > There is QEMU/KVM and a Linux OS running inside the guest. > Inside the Linux guest a balloon consumes memory in accordance with > commands performed on the host side in QEMU and reports some statistics > through memstat structure. > For the Linux guest reported “free” value doesn’t describe the guest memory > pressure at all. > The provided patch set in Linux kernel extends the stat with available field. > > The problem is addressed in mainstream Linux with the following patchset: > > commit > > 5057dcd0f1aaad57e07e728ba20a99e205c6b9de > > Author: Igor Redko mailto:red...@virtuozzo.com>> > Date: Thu Mar 17 15:09:34 2016 -0700 > virtio_balloon: export 'available' memory to balloon statistics > > Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory > statistics protocol, corresponding to 'Available' in /proc/meminfo. > > It indicates to the hypervisor how big the balloon can be inflated > without pushing the guest system to swap. > > Signed-off-by: Igor Redko mailto:red...@virtuozzo.com>> > Signed-off-by: Denis V. Lunev mailto:d...@openvz.org>> > Reviewed-by: Roman Kagan mailto:rka...@virtuozzo.com>> > Cc: Michael S. Tsirkin mailto:m...@redhat.com>> > Signed-off-by: Andrew Morton > mailto:a...@linux-foundation.org>> > Signed-off-by: Linus Torvalds > mailto:torva...@linux-foundation.org>> > > > commit d02bd27bd33dd7e8d22594cd568b81be0cb584cd > Author: Igor Redko mailto:red...@virtuozzo.com>> > Date: Thu Mar 17 15:09:34 2016 -0700 > mm/page_alloc.c: calculate 'available' memory in a separate function > > Add a new field, VIRTIO_BALLOON_S_AVAIL, to virtio_balloon memory > statistics protocol, corresponding to 'Available' in /proc/meminfo. > > It indicates to the hypervisor how big the balloon can be inflated > without pushing the guest system to swap. This metric would be very > useful in VM orchestration software to improve memory management of > different VMs under overcommit. > > This patch (of 2): > > Factor out calculation of the available memory counter into a separate > exportable function, in order to be able to use it in other parts of the > kernel. > > In particular, it appears a relevant metric to report to the hypervisor > via virtio-balloon statistics interface (in a followup patch). > > Signed-off-by: Igor Redko mailto:red...@virtuozzo.com>> > Signed-off-by: Denis V. Lunev mailto:d...@openvz.org>> > Reviewed-by: Roman Kagan mailto:rka...@virtuozzo.com>> > Cc: Michael S. Tsirkin mailto:m...@redhat.com>> > Signed-off-by: Andrew Morton > mailto:a...@linux-foundation.org>> > Signed-off-by: Linus Torvalds > mailto:torva...@linux-foundation.org>> > -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Bug#825208: Ballooned memory is visible via proc
control: reassign -1 src:linux On Tue, May 24, 2016 at 02:52:22PM +, Anna Melekhova (Vorobyova) wrote: > Package: kernel kernel is very much not an available debian package name > Version: Debian 7, Debian 8 and those are not valid versions.. Anyway, just reassigning to linux without setting a version. > There is QEMU/KVM and a Debian Linux running inside the guest. The amount > of memory available for guest could be adjusted by balloon for better > host scalability. The problem that this change is visible for end-user > actually using the guest. This could (potentially) result in lawsuite > from the end-user to hosting provides. > > Though there is a problem in this setup. The end-user and hosting provider > have signed SLA agreement in which some amount of memory is guaranted for > the guest. The good thing is that this memory will be given to the guest > when the guest will really need it (f.e. with OOM in guest and with > VIRTIO_BALLOON_F_DEFLATE_ON_OOM configuration flag set). The bad thing > is that end-user does not know this. > > Balloon by default reduce the amount of memory exposed to the end-user > each time when the page is stolen from guest or returned back by using > adjust_managed_page_count and thus /proc/meminfo shows reduced amount > of memory. > > Steps to Reproduce: > 1. inflate guest balloon > 2. amount of memory in /proc/meminfo in reduced in guest > > Expected results: > no changes in /proc/meminfo in guest if properly configured in host > > The problem is addressed in mainstream Linux with the following patchset: > > commit 997e120843e82609c8d99a9d5714e6cf91e14cbe > Author: Denis V. Lunev > Date: Thu Aug 20 00:49:49 2015 +0300 > virtio_balloon: do not change memory amount visible via /proc/meminfo > > Balloon device is frequently used as a mean of cooperative memory control > in between guest and host to manage memory overcommitment. This is the > typical case for any hosting workload when KVM guest is provided for > end-user. > > Though there is a problem in this setup. The end-user and hosting provider > have signed SLA agreement in which some amount of memory is guaranted for > the guest. The good thing is that this memory will be given to the guest > when the guest will really need it (f.e. with OOM in guest and with > VIRTIO_BALLOON_F_DEFLATE_ON_OOM configuration flag set). The bad thing > is that end-user does not know this. > > Balloon by default reduce the amount of memory exposed to the end-user > each time when the page is stolen from guest or returned back by using > adjust_managed_page_count and thus /proc/meminfo shows reduced amount > of memory. > > Fortunately the solution is simple, we should just avoid to call > adjust_managed_page_count with VIRTIO_BALLOON_F_DEFLATE_ON_OOM set. > > Signed-off-by: Denis V. Lunev > CC: Michael S. Tsirkin > Signed-off-by: Michael S. Tsirkin > > > commit b4d34037329f46ed818d3b0a6e1e23b9c8721f79 > Author: Denis V. Lunev > Date: Thu Aug 20 00:49:48 2015 +0300 > virtio_ballon: change stub of release_pages_by_pfn > > and rename it to release_pages_balloon. The function originally takes > arrays of pfns and now it takes pointer to struct virtio_ballon. > This change is necessary to conditionally call adjust_managed_page_count > in the next patch. > > Signed-off-by: Denis V. Lunev > CC: Michael S. Tsirkin > Signed-off-by: Michael S. Tsirkin -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: kernel 4.6-1~exp1 built for armel seems failed
On Tue, May 24, 2016 at 19:00:39 +0900, Roger Shimizu wrote: > Dear Ben, > > kernel 4.6-1~exp1 for experimental has been compiling for ARCH=armel > for nearly a week [0]. > Please kindly check what happened and restart the build if necessary. > Thank you! > > [0] https://buildd.debian.org/status/package.php?p=linux&suite=experimental > antheil has a broken fan, buildd is disabled; linux given back. Cheers, Julien
Re: kernel 4.6-1~exp1 built for armel seems failed
On Tue, 2016-05-24 at 19:00 +0900, Roger Shimizu wrote: > Dear Ben, > > kernel 4.6-1~exp1 for experimental has been compiling for ARCH=armel > for nearly a week [0]. > Please kindly check what happened and restart the build if necessary. > Thank you! > > [0] https://buildd.debian.org/status/package.php?p=linux&suite=experimental I have no power to do that. You need to contact ar...@buildd.debian.org Ben. -- Ben Hutchings Time is nature's way of making sure that everything doesn't happen at once. signature.asc Description: This is a digitally signed message part
kernel 4.6-1~exp1 built for armel seems failed
Dear Ben, kernel 4.6-1~exp1 for experimental has been compiling for ARCH=armel for nearly a week [0]. Please kindly check what happened and restart the build if necessary. Thank you! [0] https://buildd.debian.org/status/package.php?p=linux&suite=experimental Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
