Bug#856474: [PATCH] Kbuild.include: addtree: Remove quotes before matching path
Hi Sam, 2017-04-04 5:20 GMT+09:00 Sam Ravnborg : > On Mon, Apr 03, 2017 at 03:25:10PM +0200, Michal Marek wrote: >> On 2017-04-03 09:42, Masahiro Yamada wrote: >> > Each Makefile knows it wants to see >> > additional headers in the source tree, or objtree. >> > >> > I am guessing the right approach in a long run is, >> > we require -I to specify $(srctree) or $(objtree) explicitly. >> > >> > ccflags-y := -I$(srctree)/foo/bar/baz >> > >> > or >> > >> > ccflags-y := -I$(objtree)/foo/bar/baz >> > >> > >> > (For the latter, we can omit $(objtree)/ as it is ./) >> > >> > >> > Then, delete $(call flags,_c_flags) after the conversion. >> >> Agreed. The addtree function is more of a hack to make things just work >> with O=, but AFAIK there is no clean way to implement VPATH for -I >> arguments. So it's sensible to get rid of the hack. It looks like it's >> going to be lot of work though: >> >> $ git grep -e '-I' -- '*Makefile*' | wc -l >> 732 >> $ git grep -e '-I *\$(\(src\|obj\)tree)' -- '*Makefile*' | wc -l >> 166 > > There was a goal long time ago that moving the kernel source should > not trigger a rebuild. > Any hardcoded path would violate this (like $(srctree), $(objtree)) Even if we avoid hard-coding $(srctree) in each Makefile, "addtree" will modify the -I paths and the modified paths will be recorded in .*.cmd files. If we really want to achieve the goal, my old patch seemed to have a point: https://patchwork.kernel.org/patch/4511991/ This was rejected due to side effects, anyway. -- Best Regards Masahiro Yamada
[PATCH 4/4] rtc: s35390a: improve irq handling
commit 3bd32722c827d00eafe8e6d5b83e9f3148ea7c7e upstream.
On some QNAP NAS devices the rtc can wake the machine. Several people
noticed that once the machine was woken this way it fails to shut down.
That's because the driver fails to acknowledge the interrupt and so it
keeps active and restarts the machine immediatly after shutdown. See
https://bugs.debian.org/794266 for a bug report.
Doing this correctly requires to interpret the INT2 flag of the first read
of the STATUS1 register because this bit is cleared by read.
Note this is not maximally robust though because a pending irq isn't
detected when the STATUS1 register was already read (and so INT2 is not
set) but the irq was not disabled. But that is a hardware imposed problem
that cannot easily be fixed by software.
Signed-off-by: Uwe Kleine-König
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-s35390a.c | 48 ++-
1 file changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index c7c1fce69635..00662dd28d66 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -35,10 +35,14 @@
#define S35390A_ALRM_BYTE_HOURS1
#define S35390A_ALRM_BYTE_MINS 2
+/* flags for STATUS1 */
#define S35390A_FLAG_POC 0x01
#define S35390A_FLAG_BLD 0x02
+#define S35390A_FLAG_INT2 0x04
#define S35390A_FLAG_24H 0x40
#define S35390A_FLAG_RESET 0x80
+
+/* flag for STATUS2 */
#define S35390A_FLAG_TEST 0x01
#define S35390A_INT2_MODE_MASK 0xF0
@@ -408,11 +412,11 @@ static struct i2c_driver s35390a_driver;
static int s35390a_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
- int err;
+ int err, err_reset;
unsigned int i;
struct s35390a *s35390a;
struct rtc_time tm;
- char buf[1], status1;
+ char buf, status1;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
err = -ENODEV;
@@ -441,29 +445,35 @@ static int s35390a_probe(struct i2c_client *client,
}
}
- err = s35390a_reset(s35390a, &status1);
- if (err < 0) {
+ err_reset = s35390a_reset(s35390a, &status1);
+ if (err_reset < 0) {
+ err = err_reset;
dev_err(&client->dev, "error resetting chip\n");
goto exit_dummy;
}
- err = s35390a_disable_test_mode(s35390a);
- if (err < 0) {
- dev_err(&client->dev, "error disabling test mode\n");
- goto exit_dummy;
- }
-
- err = s35390a_get_reg(s35390a, S35390A_CMD_STATUS1, buf, sizeof(buf));
- if (err < 0) {
- dev_err(&client->dev, "error checking 12/24 hour mode\n");
- goto exit_dummy;
- }
- if (buf[0] & S35390A_FLAG_24H)
+ if (status1 & S35390A_FLAG_24H)
s35390a->twentyfourhour = 1;
else
s35390a->twentyfourhour = 0;
- if (s35390a_get_datetime(client, &tm) < 0)
+ if (status1 & S35390A_FLAG_INT2) {
+ /* disable alarm (and maybe test mode) */
+ buf = 0;
+ err = s35390a_set_reg(s35390a, S35390A_CMD_STATUS2, &buf, 1);
+ if (err < 0) {
+ dev_err(&client->dev, "error disabling alarm");
+ goto exit_dummy;
+ }
+ } else {
+ err = s35390a_disable_test_mode(s35390a);
+ if (err < 0) {
+ dev_err(&client->dev, "error disabling test mode\n");
+ goto exit_dummy;
+ }
+ }
+
+ if (err_reset > 0 || s35390a_get_datetime(client, &tm) < 0)
dev_warn(&client->dev, "clock needs to be set\n");
device_set_wakeup_capable(&client->dev, 1);
@@ -476,6 +486,10 @@ static int s35390a_probe(struct i2c_client *client,
err = PTR_ERR(s35390a->rtc);
goto exit_dummy;
}
+
+ if (status1 & S35390A_FLAG_INT2)
+ rtc_update_irq(s35390a->rtc, 1, RTC_AF);
+
return 0;
exit_dummy:
--
2.11.0
[PATCH 2/4] rtc: s35390a: make sure all members in the output are set
The rtc core calls the .read_alarm with all fields initialized to 0. As
the s35390a driver doesn't touch some fields the returned date is
interpreted as a date in January 1900. So make sure all fields are set
to -1; some of them are then overwritten with the right data depending
on the hardware state.
In mainline this is done by commit d68778b80dd7 ("rtc: initialize output
parameter for read alarm to "uninitialized"") in the core. This is
considered to dangerous for stable as it might have side effects for
other rtc drivers that might for example rely on alarm->time.tm_sec
being initialized to 0.
Signed-off-by: Uwe Kleine-König
---
drivers/rtc/rtc-s35390a.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index 6507a01cf9ad..47b88bbe4ce7 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -267,6 +267,20 @@ static int s35390a_read_alarm(struct i2c_client *client,
struct rtc_wkalrm *alm)
char buf[3], sts;
int i, err;
+ /*
+* initialize all members to -1 to signal the core that they are not
+* defined by the hardware.
+*/
+ alm->time.tm_sec = -1;
+ alm->time.tm_min = -1;
+ alm->time.tm_hour = -1;
+ alm->time.tm_mday = -1;
+ alm->time.tm_mon = -1;
+ alm->time.tm_year = -1;
+ alm->time.tm_wday = -1;
+ alm->time.tm_yday = -1;
+ alm->time.tm_isdst = -1;
+
err = s35390a_get_reg(s35390a, S35390A_CMD_STATUS2, &sts, sizeof(sts));
if (err < 0)
return err;
--
2.11.0
[PATCH 1/4] rtc: s35390a: fix reading out alarm
commit f87e904ddd8f0ef120e46045b0addeb1cc88354e upstream.
There are several issues fixed in this patch:
- When alarm isn't enabled, set .enabled to zero instead of returning
-EINVAL.
- Ignore how IRQ1 is configured when determining if IRQ2 is on.
- The three alarm registers have an enable flag which must be
evaluated.
- The chip always triggers when the seconds register gets 0.
Note that the rtc framework however doesn't handle the result correctly
because it doesn't check wday being initialized and so interprets an
alarm being set for 10:00 AM in three days as 10:00 AM tomorrow (or
today if that's not over yet).
Signed-off-by: Uwe Kleine-König
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-s35390a.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index f40afdd0e5f5..6507a01cf9ad 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -242,6 +242,8 @@ static int s35390a_set_alarm(struct i2c_client *client,
struct rtc_wkalrm *alm)
if (alm->time.tm_wday != -1)
buf[S35390A_ALRM_BYTE_WDAY] = bin2bcd(alm->time.tm_wday) | 0x80;
+ else
+ buf[S35390A_ALRM_BYTE_WDAY] = 0;
buf[S35390A_ALRM_BYTE_HOURS] = s35390a_hr2reg(s35390a,
alm->time.tm_hour) | 0x80;
@@ -269,23 +271,43 @@ static int s35390a_read_alarm(struct i2c_client *client,
struct rtc_wkalrm *alm)
if (err < 0)
return err;
- if (bitrev8(sts) != S35390A_INT2_MODE_ALARM)
- return -EINVAL;
+ if ((bitrev8(sts) & S35390A_INT2_MODE_MASK) != S35390A_INT2_MODE_ALARM)
{
+ /*
+* When the alarm isn't enabled, the register to configure
+* the alarm time isn't accessible.
+*/
+ alm->enabled = 0;
+ return 0;
+ } else {
+ alm->enabled = 1;
+ }
err = s35390a_get_reg(s35390a, S35390A_CMD_INT2_REG1, buf, sizeof(buf));
if (err < 0)
return err;
/* This chip returns the bits of each byte in reverse order */
- for (i = 0; i < 3; ++i) {
+ for (i = 0; i < 3; ++i)
buf[i] = bitrev8(buf[i]);
- buf[i] &= ~0x80;
- }
- alm->time.tm_wday = bcd2bin(buf[S35390A_ALRM_BYTE_WDAY]);
- alm->time.tm_hour = s35390a_reg2hr(s35390a,
- buf[S35390A_ALRM_BYTE_HOURS]);
- alm->time.tm_min = bcd2bin(buf[S35390A_ALRM_BYTE_MINS]);
+ /*
+* B0 of the three matching registers is an enable flag. Iff it is set
+* the configured value is used for matching.
+*/
+ if (buf[S35390A_ALRM_BYTE_WDAY] & 0x80)
+ alm->time.tm_wday =
+ bcd2bin(buf[S35390A_ALRM_BYTE_WDAY] & ~0x80);
+
+ if (buf[S35390A_ALRM_BYTE_HOURS] & 0x80)
+ alm->time.tm_hour =
+ s35390a_reg2hr(s35390a,
+ buf[S35390A_ALRM_BYTE_HOURS] & ~0x80);
+
+ if (buf[S35390A_ALRM_BYTE_MINS] & 0x80)
+ alm->time.tm_min = bcd2bin(buf[S35390A_ALRM_BYTE_MINS] & ~0x80);
+
+ /* alarm triggers always at s=0 */
+ alm->time.tm_sec = 0;
dev_dbg(&client->dev, "%s: alm is mins=%d, hours=%d, wday=%d\n",
__func__, alm->time.tm_min, alm->time.tm_hour,
--
2.11.0
[PATCH 3/4] rtc: s35390a: implement reset routine as suggested by the reference
commit 8e6583f1b5d1f5f129b873f1428b7e414263d847 upstream.
There were two deviations from the reference manual: you have to wait
half a second when POC is active and you might have to repeat
initialization when POC or BLD are still set after the sequence.
Note however that as POC and BLD are cleared by read the driver might
not be able to detect that a reset is necessary. I don't have a good
idea how to fix this.
Additionally report the value read from STATUS1 to the caller. This
prepares the next patch.
Signed-off-by: Uwe Kleine-König
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-s35390a.c | 65 +++
1 file changed, 55 insertions(+), 10 deletions(-)
diff --git a/drivers/rtc/rtc-s35390a.c b/drivers/rtc/rtc-s35390a.c
index 47b88bbe4ce7..c7c1fce69635 100644
--- a/drivers/rtc/rtc-s35390a.c
+++ b/drivers/rtc/rtc-s35390a.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#define S35390A_CMD_STATUS10
#define S35390A_CMD_STATUS21
@@ -94,19 +95,63 @@ static int s35390a_get_reg(struct s35390a *s35390a, int
reg, char *buf, int len)
return 0;
}
-static int s35390a_reset(struct s35390a *s35390a)
+/*
+ * Returns <0 on error, 0 if rtc is setup fine and 1 if the chip was reset.
+ * To keep the information if an irq is pending, pass the value read from
+ * STATUS1 to the caller.
+ */
+static int s35390a_reset(struct s35390a *s35390a, char *status1)
{
- char buf[1];
+ char buf;
+ int ret;
+ unsigned initcount = 0;
- if (s35390a_get_reg(s35390a, S35390A_CMD_STATUS1, buf, sizeof(buf)) < 0)
- return -EIO;
+ ret = s35390a_get_reg(s35390a, S35390A_CMD_STATUS1, status1, 1);
+ if (ret < 0)
+ return ret;
- if (!(buf[0] & (S35390A_FLAG_POC | S35390A_FLAG_BLD)))
+ if (*status1 & S35390A_FLAG_POC)
+ /*
+* Do not communicate for 0.5 seconds since the power-on
+* detection circuit is in operation.
+*/
+ msleep(500);
+ else if (!(*status1 & S35390A_FLAG_BLD))
+ /*
+* If both POC and BLD are unset everything is fine.
+*/
return 0;
- buf[0] |= (S35390A_FLAG_RESET | S35390A_FLAG_24H);
- buf[0] &= 0xf0;
- return s35390a_set_reg(s35390a, S35390A_CMD_STATUS1, buf, sizeof(buf));
+ /*
+* At least one of POC and BLD are set, so reinitialise chip. Keeping
+* this information in the hardware to know later that the time isn't
+* valid is unfortunately not possible because POC and BLD are cleared
+* on read. So the reset is best done now.
+*
+* The 24H bit is kept over reset, so set it already here.
+*/
+initialize:
+ *status1 = S35390A_FLAG_24H;
+ buf = S35390A_FLAG_RESET | S35390A_FLAG_24H;
+ ret = s35390a_set_reg(s35390a, S35390A_CMD_STATUS1, &buf, 1);
+
+ if (ret < 0)
+ return ret;
+
+ ret = s35390a_get_reg(s35390a, S35390A_CMD_STATUS1, &buf, 1);
+ if (ret < 0)
+ return ret;
+
+ if (buf & (S35390A_FLAG_POC | S35390A_FLAG_BLD)) {
+ /* Try up to five times to reset the chip */
+ if (initcount < 5) {
+ ++initcount;
+ goto initialize;
+ } else
+ return -EIO;
+ }
+
+ return 1;
}
static int s35390a_disable_test_mode(struct s35390a *s35390a)
@@ -367,7 +412,7 @@ static int s35390a_probe(struct i2c_client *client,
unsigned int i;
struct s35390a *s35390a;
struct rtc_time tm;
- char buf[1];
+ char buf[1], status1;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
err = -ENODEV;
@@ -396,7 +441,7 @@ static int s35390a_probe(struct i2c_client *client,
}
}
- err = s35390a_reset(s35390a);
+ err = s35390a_reset(s35390a, &status1);
if (err < 0) {
dev_err(&client->dev, "error resetting chip\n");
goto exit_dummy;
--
2.11.0
[PATCH 0/4] rtc: s35390a: add fixes from v4.8-rc1 to stable
Hello
I suggest to add the four patches in this series to the stable releases
for stable kernels before 4.8. Three of them can be directly
cherry-picked from the commits from 4.8-rc1 as indicated in the
respective commits[1]. One patch however corresponds to a more invasive
patch (d68778b80dd7 ("rtc: initialize output parameter for read alarm to
"uninitialized"") that when I discussed that with Ben Hutchings some
time ago we considered safer to only apply it to the s35390a driver. So
this one doesn't match a mainline commit.
Best regards
Uwe
[1] f87e904ddd8f0ef120e46045b0addeb1cc88354e
8e6583f1b5d1f5f129b873f1428b7e414263d847
3bd32722c827d00eafe8e6d5b83e9f3148ea7c7e
Uwe Kleine-König (4):
rtc: s35390a: fix reading out alarm
rtc: s35390a: make sure all members in the output are set
rtc: s35390a: implement reset routine as suggested by the reference
rtc: s35390a: improve irq handling
drivers/rtc/rtc-s35390a.c | 167 --
1 file changed, 131 insertions(+), 36 deletions(-)
--
2.11.0
Bug#856474: [PATCH] Kbuild.include: addtree: Remove quotes before matching path
On Mon, Apr 03, 2017 at 03:25:10PM +0200, Michal Marek wrote: > On 2017-04-03 09:42, Masahiro Yamada wrote: > > Each Makefile knows it wants to see > > additional headers in the source tree, or objtree. > > > > I am guessing the right approach in a long run is, > > we require -I to specify $(srctree) or $(objtree) explicitly. > > > > ccflags-y := -I$(srctree)/foo/bar/baz > > > > or > > > > ccflags-y := -I$(objtree)/foo/bar/baz > > > > > > (For the latter, we can omit $(objtree)/ as it is ./) > > > > > > Then, delete $(call flags,_c_flags) after the conversion. > > Agreed. The addtree function is more of a hack to make things just work > with O=, but AFAIK there is no clean way to implement VPATH for -I > arguments. So it's sensible to get rid of the hack. It looks like it's > going to be lot of work though: > > $ git grep -e '-I' -- '*Makefile*' | wc -l > 732 > $ git grep -e '-I *\$(\(src\|obj\)tree)' -- '*Makefile*' | wc -l > 166 There was a goal long time ago that moving the kernel source should not trigger a rebuild. Any hardcoded path would violate this (like $(srctree), $(objtree)) I dunno if this is really something to aim for today. I have personally from time to time renamed the directory where I have kernel soruce (which is seen like moving the kernel source), and would not be happy if this always triggered a full rebuild. But this is frankly a corner case. Sam
Bug#859435: linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen
guy@debian:~$ apt list firmware-amd-graphics -a En train de lister... Fait firmware-amd-graphics/testing,testing,now 20161130-2 all [installé]
Re: Bug#854854: qcontrol: reboot/poweroff
Hi, On 16/03/2017 at 09:45:07 +0100, Uwe Kleine-König wrote: > Back then I prepared a backport to jessie (which still sits in a topic > branch in the debian-kernel repo[2]) but it seems I forgot to merge it into > the jessie kernel. > > I wonder if the better fix would be to fix this in linux-stable instead. > What do you think? > I agree that this should be backported to any stable kernel that is used by a distribution. I can ack the patch if you send one to stable@ -- Alexandre Belloni, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Bug#858731: Doesn't this fix loose the bug?
On Mon, 2017-04-03 at 11:44 -0400, Lennart Sorensen wrote: > I was under the impression stretch would release with 4.9 kernel. Correct. > So fixing it in 4.10 and marking it done seems like it might loose the > bug report without ever getting it actually included in stretch. > > Will the config change in the 4.10 experimental automatically be included > in any updates to the 4.9 kernel going in unstable/testing? > > Just wondering. I still have this flagged for attention in my mailbox and will probably make the same change in the next upload to unstable. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Processed: Re: Bug#859435: linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen
Processing control commands: > tag -1 moreinfo Bug #859435 [linux-image-4.9.0-2-amd64] linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen Added tag(s) moreinfo. -- 859435: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: notfound 859435 in linux-image-4.9.0-2-amd64, found 859435 in 4.9.13-1
Processing commands for cont...@bugs.debian.org: > notfound 859435 linux-image-4.9.0-2-amd64 Bug #859435 [src:linux] linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen The source 'linux' and version 'linux-image-4.9.0-2-amd64' do not appear to match any binary packages No longer marked as found in versions linux/linux-image-4.9.0-2-amd64. > # assume current testing version > found 859435 4.9.13-1 Bug #859435 [src:linux] linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen Marked as found in versions linux/4.9.13-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 859435: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: reassign 859435 to src:linux, found 859435 in linux-image-4.9.0-2-amd64
Processing commands for cont...@bugs.debian.org: > reassign 859435 src:linux linux-image-4.9.0-2-amd64 Bug #859435 [linux-image-4.9.0-2-amd64] linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen Bug reassigned from package 'linux-image-4.9.0-2-amd64' to 'src:linux'. No longer marked as found in versions linux-image-4.9.0-2-amd64. Ignoring request to alter fixed versions of bug #859435 to the same values previously set Bug #859435 [src:linux] linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen The source 'linux' and version 'linux-image-4.9.0-2-amd64' do not appear to match any binary packages Marked as found in versions linux/linux-image-4.9.0-2-amd64. > found 859435 linux-image-4.9.0-2-amd64 Bug #859435 [src:linux] linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen The source 'linux' and version 'linux-image-4.9.0-2-amd64' do not appear to match any binary packages Ignoring request to alter found versions of bug #859435 to the same values previously set > thanks Stopping processing here. Please contact me if you need assistance. -- 859435: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859435 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#859435: linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen
Control: tag -1 moreinfo On Mon, 2017-04-03 at 15:36 +0200, GT wrote: > Package: linux-image-4.9.0-2-amd64 > Version: linux-image-4.9.0-2-amd64 > Severity: normal > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > > * What led up to the situation? > Use of linux-image-4.9.0-2-amd64 , other things equal on the PC except linux- > image-3.16.0-4-amd64 > * What exactly did you do (or not do) that was effective (or > ineffective)? > just boot on kernel linux-image-4.9.0-2-amd6 > * What was the outcome of this action? > Total freeze of the PC. keyboard and mouse unusable. Need to power off/ power > on the PC and use the kernel linux-image-3.16.0-4-amd64 > * What outcome did you expect instead? > To be able to give the password of user in lightdm screen > *** End of the template - remove these template lines *** Which version of firmware-amd-graphics is installed? Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Bug#855094: [pkg-cryptsetup-devel] Bug#855094: initramfs-tools-core: Error on upgrade if cryptsetup is installed, but a current busybox isn't
Hi intigeri, hi Guilhem, Am 02.04.2017 um 10:10 schrieb Guilhem Moulin: > On Sun, 02 Apr 2017 at 09:50:55 +0200, intrigeri wrote: >> So at this point, I suggest this bug is reassigned to cryptsetup, and >> option 3 is implemented there. But downgrading to non-RC and leaving >> things as-is seems acceptable to me as well. >> >> Thoughts? > > I think the proper fix would be to split cryptsetup's initramfs bits to > a separate package (depending on busybox), cf. #783297. It's > unfortunate that we didn't implement that in time for Stretch, but > considering the impact of this, I'd favor downgrading the severity and > merging the bugs for the time being. I fully agree with Guilhem here. We should split out cryptsetup-initramfs as soon as Stretch is released and make it depend on initramfs-tools and busybox. Cheers, jonas signature.asc Description: OpenPGP digital signature
Avaya/Nortel/Mitel/VoIP Clients Records
Hi, I hope you are doing fine. Would you be interested in acquiring *Cisco users*, *ShoreTel users*, *Mitel users* and *Nortel users *contact information for your sales and marketing campaigns? *Information fields*: Contact First Name, Last Name, Job Title, Company, Address and Primary Industry, SIC Code, Employees size, Email Address, Revenue, web Address and technology details Also, we can connect you to the key IT decision makers across globe or let me know if you are targeting set of accounts, we will help you with it. Let me know your interest in receiving more information on this. Thanks and look forward to your response. Best Regards, *Edith Briggs* Marketing Executive Data Coverage: *North America, APAC, EMEA and LATAM* *If you wish to not to receive further emails, change the subject line to Unsubscribe*
Bug#858731: Doesn't this fix loose the bug?
I was under the impression stretch would release with 4.9 kernel. So fixing it in 4.10 and marking it done seems like it might loose the bug report without ever getting it actually included in stretch. Will the config change in the 4.10 experimental automatically be included in any updates to the 4.9 kernel going in unstable/testing? Just wondering. -- Len Sorensen
Bug#856474: [PATCH] Kbuild.include: addtree: Remove quotes before matching path
On 2017-04-03 09:42, Masahiro Yamada wrote: > Each Makefile knows it wants to see > additional headers in the source tree, or objtree. > > I am guessing the right approach in a long run is, > we require -I to specify $(srctree) or $(objtree) explicitly. > > ccflags-y := -I$(srctree)/foo/bar/baz > > or > > ccflags-y := -I$(objtree)/foo/bar/baz > > > (For the latter, we can omit $(objtree)/ as it is ./) > > > Then, delete $(call flags,_c_flags) after the conversion. Agreed. The addtree function is more of a hack to make things just work with O=, but AFAIK there is no clean way to implement VPATH for -I arguments. So it's sensible to get rid of the hack. It looks like it's going to be lot of work though: $ git grep -e '-I' -- '*Makefile*' | wc -l 732 $ git grep -e '-I *\$(\(src\|obj\)tree)' -- '*Makefile*' | wc -l 166 Michal
Bug#859435: linux-image-4.9.0-2-amd64: Total freeze of the PC at lightdm connexion screen
Package: linux-image-4.9.0-2-amd64 Version: linux-image-4.9.0-2-amd64 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Use of linux-image-4.9.0-2-amd64 , other things equal on the PC except linux- image-3.16.0-4-amd64 * What exactly did you do (or not do) that was effective (or ineffective)? just boot on kernel linux-image-4.9.0-2-amd6 * What was the outcome of this action? Total freeze of the PC. keyboard and mouse unusable. Need to power off/ power on the PC and use the kernel linux-image-3.16.0-4-amd64 * What outcome did you expect instead? To be able to give the password of user in lightdm screen *** End of the template - remove these template lines *** -- System Information: Debian Release: 9.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) *** /home/guy/resul-inxi.txt System:Host: debian Kernel: 3.16.0-4-amd64 x86_64 (64 bit gcc: 4.8.4) Desktop: Xfce 4.12.3 (Gtk 2.24.30) Distro: Debian GNU/Linux 9 (stretch) Machine: Device: laptop System: Hewlett-Packard product: HP Pavilion dv7 Notebook PC v: 058B11242B1020100 serial: CNF1138XTH Mobo: Hewlett-Packard model: 1443 v: 67.33 serial: PL8B0011Z0701I BIOS: Hewlett-Packard v: F.29 date: 02/25/2013 BatteryBAT0: charge: 47.7 Wh 100.0% condition: 47.7/47.7 Wh (100%) model: Hewlett-Packard Primary status: Full CPU: Dual core AMD Athlon II P340 (-MCP-) cache: 1024 KB bmips: 8777 clock speeds: max: 2200 MHz 1: 1600 MHz 2: 2200 MHz CPU Flags: 3dnow 3dnowext 3dnowprefetch abm apic clflush cmov cmp_legacy constant_tsc cr8_legacy cx16 cx8 de extapic extd_apicid fpu fxsr fxsr_opt ht hw_pstate ibs lahf_lm lbrv lm mca mce mmx mmxext monitor msr mtrr nodeid_msr nonstop_tsc nopl npt nrip_save nx osvw pae pat pdpe1gb pge pni popcnt pse pse36 rdtscp rep_good sep skinit sse sse2 sse4a svm svm_lock syscall tsc vme vmmcall wdt Memory:Array-1 capacity: 8 GB devices: 2 EC: None Device-1: Bottom - Slot 1 (top) size: 2 GB speed: 1066 MHz type: DDR3 part: 8JSF25664HZ-1G4D1 Device-2: Bottom - Slot 2 (under) size: 2 GB speed: 1066 MHz type: DDR3 part: 8JSF25664HZ-1G4D1 Graphics: Card-1: Advanced Micro Devices [AMD/ATI] RS880M [Mobility Radeon HD 4225/4250] bus-ID: 01:05.0 Card-2: Advanced Micro Devices [AMD/ATI] Park [Mobility Radeon HD 5430/5450/5470] bus-ID: 02:00.0 Display Server: X.org 1.19.2 drivers: ati,radeon (unloaded: modesetting,fbdev,vesa) tty size: 80x24 Advanced Data: N/A for root Audio: Card-1 Advanced Micro Devices [AMD/ATI] Cedar HDMI Audio [Radeon HD 5400/6300/7300 Series] driver: snd_hda_intel bus-ID: 02:00.1 Card-2 Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA) driver: snd_hda_intel bus-ID: 00:14.2 Sound: Advanced Linux Sound Architecture v: k3.16.0-4-amd64 Network: Card-1: Broadcom Limited BCM4313 802.11bgn Wireless Network Adapter driver: wl bus-ID: 03:00.0 IF: wlan0 state: up mac: cc:52:af:5a:a2:b5 Card-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169 v: 2.3LK-NAPI port: 2000 bus-ID: 04:00.0 IF: eth0 state: down mac: 98:4b:e1:c6:c4:7b Drives:HDD Total Size: 320.1GB (56.7% used) ID-1: /dev/sda model: Hitachi_HTS72503 size: 320.1GB temp: 0C Optical: /dev/sr0 model: hp CDDVDW TS-L633R rev: 0300 dev-links: cdrom,cdrw,dvd,dvdrw Features: speed: 24x multisession: yes audio: yes dvd: yes rw: cd-r,cd-rw,dvd-r,dvd-ram state: running Partition: ID-1: / size: 9.1G used: 6.3G (74%) fs: ext4 dev: /dev/sda1 label: debian uuid: 78ec612e-d1d9-4c88-88ec-17d9b0815a8f ID-2: /home size: 263G used: 156G (63%) fs: ext4 dev: /dev/sda6 label: data uuid: 0231cd69-6248-497c-a18c-4d5c92666f35 ID-3: swap-1 size: 8.04GB used: 0.00GB (0%) fs: swap dev: /dev/sda5 label: N/A uuid: 60e41088-15f8-4d62-93ba-4bfcbf36c48f Unmounted: ID-1: /dev/sda7 size: 15.73G fs: ext4 label: primtux uuid: 1848dba2-60df-4ddb-a632-a49f0e08de96 Sensors: System Temperatures: cpu: 65.4C mobo: N/A gpu: N/A Fan Speeds (in rpm): cpu: N/A Repos: Active apt sources in file: /etc/apt/sources.list deb http://security.debian.org/debian-security/ jessie/updates contrib main non-free deb http://security.debian.org/debian-security/ stretch/updates contrib main non-free deb http://ftp.uk.debian.org/debian/ stretch c
linux_4.10.7-1~exp1_multi.changes ACCEPTED into experimental, experimental
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 31 Mar 2017 00:41:15 +0100 Source: linux Binary: linux-source-4.10 linux-support-4.10.0-trunk linux-doc-4.10 linux-manual-4.10 linux-kbuild-4.10 linux-cpupower libcpupower1 libcpupower-dev linux-perf-4.10 libusbip-dev usbip hyperv-daemons linux-headers-4.10.0-trunk-common linux-libc-dev linux-headers-4.10.0-trunk-all linux-headers-4.10.0-trunk-all-alpha kernel-image-4.10.0-trunk-alpha-generic-di nic-modules-4.10.0-trunk-alpha-generic-di nic-wireless-modules-4.10.0-trunk-alpha-generic-di nic-shared-modules-4.10.0-trunk-alpha-generic-di serial-modules-4.10.0-trunk-alpha-generic-di usb-serial-modules-4.10.0-trunk-alpha-generic-di ppp-modules-4.10.0-trunk-alpha-generic-di pata-modules-4.10.0-trunk-alpha-generic-di cdrom-core-modules-4.10.0-trunk-alpha-generic-di scsi-core-modules-4.10.0-trunk-alpha-generic-di scsi-modules-4.10.0-trunk-alpha-generic-di loop-modules-4.10.0-trunk-alpha-generic-di btrfs-modules-4.10.0-trunk-alpha-generic-di ext4-modules-4.10.0-trunk-alpha-generic-di isofs-modules-4.10.0-trunk-alpha-generic-di jfs-modules-4.10.0-trunk-alpha-generic-di xfs-modules-4.10.0-trunk-alpha-generic-di fat-modules-4.10.0-trunk-alpha-generic-di md-modules-4.10.0-trunk-alpha-generic-di multipath-modules-4.10.0-trunk-alpha-generic-di usb-modules-4.10.0-trunk-alpha-generic-di usb-storage-modules-4.10.0-trunk-alpha-generic-di fb-modules-4.10.0-trunk-alpha-generic-di input-modules-4.10.0-trunk-alpha-generic-di event-modules-4.10.0-trunk-alpha-generic-di mouse-modules-4.10.0-trunk-alpha-generic-di nic-pcmcia-modules-4.10.0-trunk-alpha-generic-di pcmcia-modules-4.10.0-trunk-alpha-generic-di nic-usb-modules-4.10.0-trunk-alpha-generic-di sata-modules-4.10.0-trunk-alpha-generic-di crc-modules-4.10.0-trunk-alpha-generic-di crypto-modules-4.10.0-trunk-alpha-generic-di crypto-dm-modules-4.10.0-trunk-alpha-generic-di ata-modules-4.10.0-trunk-alpha-generic-di nbd-modules-4.10.0-trunk-alpha-generic-di squashfs-modules-4.10.0-trunk-alpha-generic-di virtio-modules-4.10.0-trunk-alpha-generic-di zlib-modules-4.10.0-trunk-alpha-generic-di fuse-modules-4.10.0-trunk-alpha-generic-di srm-modules-4.10.0-trunk-alpha-generic-di linux-image-4.10.0-trunk-alpha-generic linux-headers-4.10.0-trunk-alpha-generic linux-image-4.10.0-trunk-alpha-generic-dbgsym linux-image-4.10.0-trunk-alpha-smp linux-headers-4.10.0-trunk-alpha-smp linux-image-4.10.0-trunk-alpha-smp-dbgsym linux-headers-4.10.0-trunk-all-amd64 linux-image-4.10.0-trunk-amd64-unsigned linux-headers-4.10.0-trunk-amd64 linux-image-4.10.0-trunk-amd64-dbgsym linux-headers-4.10.0-trunk-all-arm64 linux-image-4.10.0-trunk-arm64-unsigned linux-headers-4.10.0-trunk-arm64 linux-image-4.10.0-trunk-arm64-dbgsym linux-headers-4.10.0-trunk-all-armel kernel-image-4.10.0-trunk-marvell-di nic-modules-4.10.0-trunk-marvell-di nic-shared-modules-4.10.0-trunk-marvell-di usb-serial-modules-4.10.0-trunk-marvell-di ppp-modules-4.10.0-trunk-marvell-di cdrom-core-modules-4.10.0-trunk-marvell-di scsi-core-modules-4.10.0-trunk-marvell-di loop-modules-4.10.0-trunk-marvell-di ipv6-modules-4.10.0-trunk-marvell-di btrfs-modules-4.10.0-trunk-marvell-di ext4-modules-4.10.0-trunk-marvell-di isofs-modules-4.10.0-trunk-marvell-di jffs2-modules-4.10.0-trunk-marvell-di jfs-modules-4.10.0-trunk-marvell-di fat-modules-4.10.0-trunk-marvell-di minix-modules-4.10.0-trunk-marvell-di md-modules-4.10.0-trunk-marvell-di multipath-modules-4.10.0-trunk-marvell-di usb-modules-4.10.0-trunk-marvell-di usb-storage-modules-4.10.0-trunk-marvell-di fb-modules-4.10.0-trunk-marvell-di input-modules-4.10.0-trunk-marvell-di event-modules-4.10.0-trunk-marvell-di mouse-modules-4.10.0-trunk-marvell-di nic-usb-modules-4.10.0-trunk-marvell-di sata-modules-4.10.0-trunk-marvell-di crc-modules-4.10.0-trunk-marvell-di crypto-modules-4.10.0-trunk-marvell-di crypto-dm-modules-4.10.0-trunk-marvell-di mmc-modules-4.10.0-trunk-marvell-di nbd-modules-4.10.0-trunk-marvell-di squashfs-modules-4.10.0-trunk-marvell-di uinput-modules-4.10.0-trunk-marvell-di zlib-modules-4.10.0-trunk-marvell-di leds-modules-4.10.0-trunk-marvell-di udf-modules-4.10.0-trunk-marvell-di fuse-modules-4.10.0-trunk-marvell-di mtd-modules-4.10.0-trunk-marvell-di linux-image-4.10.0-trunk-marvell linux-headers-4.10.0-trunk-marvell linux-image-4.10.0-trunk-marvell-dbgsym linux-headers-4.10.0-trunk-all-armhf linux-image-4.10.0-trunk-armmp-unsigned linux-headers-4.10.0-trunk-armmp linux-image-4.10.0-trunk-armmp-dbgsym linux-image-4.10.0-trunk-armmp-lpae-unsigned linux-headers-4.10.0-trunk-armmp-lpae linux-image-4.10.0-trunk-armmp-lpae-dbgsym linux-headers-4.10.0-trunk-all-hppa kernel-image-4.10.0-trunk-parisc-di nic-modules-4.10.0-trunk-parisc-di nic-shared-modules-4.10.0-trunk-parisc-di serial-modules-4.10.0-trunk-parisc-di usb-serial-modules-4.10.0-trunk-parisc-di ppp-modules-4.10.0-trunk-parisc-di pata-modules-4.10.0-trunk-p
Bug#858897: marked as done (linux-image-4.10.0-trunk-amd64-unsigned: NETFILTER_XT_MATCH_SOCKET and NF_SOCKET_IPV4 are disabled: IP_TRANSPARENT does not work)
Your message dated Mon, 03 Apr 2017 12:00:18 + with message-id and subject line Bug#858897: fixed in linux 4.10.7-1~exp1 has caused the Debian Bug report #858897, regarding linux-image-4.10.0-trunk-amd64-unsigned: NETFILTER_XT_MATCH_SOCKET and NF_SOCKET_IPV4 are disabled: IP_TRANSPARENT does not work to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 858897: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858897 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: src:linux Version: 4.10-1~exp1 Severity: normal NETFILTER_XT_MATCH_SOCKET and NF_SOCKET_IPV4 are disabled in the kernel config. As a result, IP_TRENSPARENT server can not be set up: $ sudo iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT > iptables: No chain/target/match by that name. NF_SOCKET_IPV4 is a new config option in the linux-4.10; NETFILTER_XT_MATCH_SOCKET depends on it. -- Package-specific info: ** Version: Linux version 4.10.0-trunk-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170221 (Debian 6.3.0-8) ) #1 SMP Debian 4.10-1~exp1 (2017-02-22) ** Command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-trunk-amd64 root=UUID=c5078393-d2ff-435d-82e8-e85990b3c9e2 ro net.ifnames=0 console=tty1 console=ttyS1,115200n8 intel_iommu=on intel_pstate=disable nmi_watchdog=nopanic intel_idle.max_cstate=0 idle=poll ** Tainted: POE (12289) * Proprietary module has been loaded. * Out-of-tree module has been loaded. * Unsigned module has been loaded. ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Dell Inc. product_name: PowerEdge R220 product_version: 01 chassis_vendor: Dell Inc. chassis_version: 01 bios_vendor: Dell Inc. bios_version: 1.4.0 board_vendor: Dell Inc. board_name: 05Y15N board_version: A04 ** Loaded modules: team_mode_activebackup(E) team(E) onload(OE) onload_cplane(POE) sfc_char(OE) sfc_resource(OE) sfc_affinity(OE) sfc(OE) iptable_raw(E) iptable_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) nf_nat(E) nf_conntrack(E) libcrc32c(E) iptable_mangle(E) mtd(E) mdio(E) hwmon_vid(E) crc32_generic(E) mii(E) autofs4(E) cpufreq_userspace(E) cpufreq_powersave(E) cpufreq_conservative(E) iptable_filter(E) ip_tables(E) x_tables(E) hmac(E) cbc(E) cts(E) nfsv4(E) dns_resolver(E) rpcsec_gss_krb5(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) nfs(E) lockd(E) grace(E) fscache(E) sunrpc(E) 8021q(E) garp(E) mrp(E) stp(E) llc(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) ipmi_watchdog(E) loop(E) intel_rapl(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) mgag200(E) crc32_pclmul(E) ttm(E) ghash_clmulni_intel(E) drm_kms_helper(E) intel_cstate(E) ppdev(E) drm(E) efi_pstore(E) i2c_algo_bit(E) intel_uncore(E) dcdbas(E) joydev(E) intel_rapl_perf(E) evdev(E) efivars(E) sg(E) pcspkr(E) intel_vbtn(E) acpi_als(E) winbond_cir(E) kfifo_buf(E) battery(E) ie31200_edac(E) sparse_keymap(E) industrialio(E) rc_core(E) parport_pc(E) ipmi_si(E) soc_button_array(E) edac_core(E) ac(E) parport(E) ipmi_devintf(E) acpi_cpufreq(E) ipmi_msghandler(E) video(E) lpc_ich(E) tpm_tis(E) shpchp(E) mfd_core(E) tpm_tis_core(E) button(E) tpm(E) ext4(E) crc16(E) jbd2(E) crc32c_generic(E) fscrypto(E) ecb(E) mbcache(E) hid_generic(E) usbhid(E) hid(E) sd_mod(E) tg3(E) ptp(E) crc32c_intel(E) aesni_intel(E) ahci(E) aes_x86_64(E) libahci(E) crypto_simd(E) libata(E) cryptd(E) xhci_pci(E) pps_core(E) ehci_pci(E) xhci_hcd(E) ehci_hcd(E) glue_helper(E) i2c_i801(E) libphy(E) scsi_mod(E) usbcore(E) usb_common(E) thermal(E) fan(E) fjes(E) ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3 Processor DRAM Controller [8086:0c08] (rev 06) Subsystem: Dell Xeon E3-1200 v3 Processor DRAM Controller [1028:05e5] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: ie31200_edac 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: Kernel driver in use: pcieport 00:14.0 USB controller [0c03]: Intel Corporation 8 Seri
Bug#858731: marked as done (Please bump CONFIG_NR_CPUS to 256 on s390x)
Your message dated Mon, 03 Apr 2017 12:00:18 + with message-id and subject line Bug#858731: fixed in linux 4.10.7-1~exp1 has caused the Debian Bug report #858731, regarding Please bump CONFIG_NR_CPUS to 256 on s390x to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 858731: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858731 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: linux Version: 3.16.39-1 Currently linux's kconfig in stable/testing/unstable sets CONFIG_NR_CPUS=32 on s390x. This is unhelpful when you have more cores than that assigned to a VM/LPAR. Reportedly all of SUSE, RedHat, and Ubuntu set it to 256 these days. Our amd64 config sets it to 512. I'd suggest bumping it at least to 256 in the Debian package. (This actually came up as a problem on the LINUX-360 mailing list.) Kind regards and thanks for considering the change Philipp Kern signature.asc Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Source: linux Source-Version: 4.10.7-1~exp1 We believe that the bug you reported is fixed in the latest version of linux, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 858...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Ben Hutchings (supplier of updated linux package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Fri, 31 Mar 2017 00:41:15 +0100 Source: linux Binary: linux-source-4.10 linux-support-4.10.0-trunk linux-doc-4.10 linux-manual-4.10 linux-kbuild-4.10 linux-cpupower libcpupower1 libcpupower-dev linux-perf-4.10 libusbip-dev usbip hyperv-daemons linux-headers-4.10.0-trunk-common linux-libc-dev linux-headers-4.10.0-trunk-all linux-headers-4.10.0-trunk-all-alpha kernel-image-4.10.0-trunk-alpha-generic-di nic-modules-4.10.0-trunk-alpha-generic-di nic-wireless-modules-4.10.0-trunk-alpha-generic-di nic-shared-modules-4.10.0-trunk-alpha-generic-di serial-modules-4.10.0-trunk-alpha-generic-di usb-serial-modules-4.10.0-trunk-alpha-generic-di ppp-modules-4.10.0-trunk-alpha-generic-di pata-modules-4.10.0-trunk-alpha-generic-di cdrom-core-modules-4.10.0-trunk-alpha-generic-di scsi-core-modules-4.10.0-trunk-alpha-generic-di scsi-modules-4.10.0-trunk-alpha-generic-di loop-modules-4.10.0-trunk-alpha-generic-di btrfs-modules-4.10.0-trunk-alpha-generic-di ext4-modules-4.10.0-trunk-alpha-generic-di isofs-modules-4.10.0-trunk-alpha-generic-di jfs-modules-4.10.0-trunk-alpha-generic-di xfs-modules-4.10.0-trunk-alpha-generic-di fat-modules-4.10.0-trunk-alpha-generic-di md-modules-4.10.0-trunk-alpha-generic-di multipath-modules-4.10.0-trunk-alpha-generic-di usb-modules-4.10.0-trunk-alpha-generic-di usb-storage-modules-4.10.0-trunk-alpha-generic-di fb-modules-4.10.0-trunk-alpha-generic-di input-modules-4.10.0-trunk-alpha-generic-di event-modules-4.10.0-trunk-alpha-generic-di mouse-modules-4.10.0-trunk-alpha-generic-di nic-pcmcia-modules-4.10.0-trunk-alpha-generic-di pcmcia-modules-4.10.0-trunk-alpha-generic-di nic-usb-modules-4.10.0-trunk-alpha-generic-di sata-modules-4.10.0-trunk-alpha-generic-di crc-modules-4.10.0-trunk-alpha-generic-di crypto-modules-4.10.0-trunk-alpha-generic-di crypto-dm-modules-4.10.0-trunk-alpha-generic-di ata-modules-4.10.0-trunk-alpha-generic-di nbd-modules-4.10.0-trunk-alpha-generic-di squashfs-modules-4.10.0-trunk-alpha-generic-di virtio-modules-4.10.0-trunk-alpha-generic-di zlib-modules-4.10.0-trunk-alpha-generic-di fuse-modules-4.10.0-trunk-alpha-generic-di srm-modules-4.10.0-trunk-alpha-generic-di linux-image-4.10.0-trunk-alpha-generic linux-headers-4.10.0-trunk-alpha-generic linux-image-4.10.0-trunk-alpha-generic-dbgsym linux-image-4.10.0-trunk-alpha-smp linux-headers-4.10.0-trunk-alpha-smp linux-image-4.10.0-trunk-alpha-smp-dbgsym linux-headers-4.10.0-trunk-all-amd64 linux-image-4.10.0-trunk-amd64-unsigned linux-headers-4.10.0-trunk-amd64 linux-image-4.10.0-trunk-amd64-dbgsym linux-headers-4.10.0-trunk-all-arm64 linux-image-4.10.0-trunk-arm64-unsigned linux-headers-4.10.0-trunk-arm64 linux-image-4.10.0-trunk-arm64-dbgsym linux-headers-4.10.0-trunk-all-armel kernel-image
[release-notes/stretch] Release notes sign-off from the kernel team
Hi, There is a kernel team related item in the release checklist where we need input from the you[1]: Items are: * release-notes: KernelTeam signoff for specials with the Kernel Please review the release notes and file bugs for the missing items (if any) and let us know once this has been done. Thanks, ~Niels [1]: https://wiki.debian.org/Teams/ReleaseTeam/ReleaseCheckList/StretchCheckList
Bug#845302:
On Sun, 2017-04-02 at 20:49 -0300, Gerardo Malazdrewicz wrote: > Got bit by this in and old laptop. > > Have LVM on it, with /usr in its own partitition, and /usr/lib in its own > partition. > > Fixed by adding > > dep_add_modules_mount /usr/lib > > to hook_functions, and > > if read_fstab_entry /usr/lib; then > log_begin_msg "Mounting /usr/lib file system" > mountfs /usr/lib > log_end_msg > fi > > to init. > But I'm afraid any update will throw that away. > > Any idea on how to fix in a more permanent fashion? Combine the two partitions. Given that you can use LVM to grow partitions and to add temporary storage while moving data around, this shouldn't be too painful. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest. signature.asc Description: This is a digitally signed message part
Bug#845382: BUG: soft lockup when radeon modesetting
On Thu, Mar 30, 2017 at 12:40:46AM +0200, Dominik George wrote: > I can confirm this issue. > > I found a workaround by setting radeon.hard_reset=1, which resets the > PCI bus after loading the firmware. Both Audio and KMS work with this > option set. Please, what kernel version and hardware? I tried Debian kernel 4.9.18-1 (package 4.9.0-2-amd64) and with enabled HDMI audio in BIOS of Asus M2A-VM HDMI the lockup shows :(. vdr:~# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.9.0-2-amd64 root=UUID=632652f0-7f3c-4316-a74d-d05f2fd4b3ae ro radeon.hard_reset=1 netconsole=@192.168.1.50/,@192.168.1.120/ -- Zito
Bug#853122: [Regression] Changes to i2c-piix4.c initialisation prevent loading of sp5100_tco watchdog driver on AMD SB800 chipset
Hi, 2017-04-03 08:34 keltezéssel, Paul Menzel írta: Dear Zoltán, Am Samstag, den 01.04.2017, 12:13 +0200 schrieb Boszormenyi Zoltan: […] and have split the patch into three pieces now (USB quirks, i2c-piix4 and sp5100_tco) and they were sent to the relevant mailing lists. Could you please add me to the receiver list of these patches, so that I can test them? Maybe also Christian (the commit author introducing the regression), Tim (bug reporter), and Nehal from AMD? If you uploaded them to the Kernel.org Bugtracker, that’d also work for me. did both. Best regards, Zoltán Böszörményi Thanks, Paul
Bug#856474: [PATCH] Kbuild.include: addtree: Remove quotes before matching path
+To Arnd
+To Michal
2017-03-19 6:58 GMT+09:00 Ben Hutchings :
> systemtap currently fails to build modules when the kernel source and
> object trees are separate.
>
> systemtap adds something like -I"/usr/share/systemtap/runtime" to
> EXTRA_CFLAGS, and addtree should not adjust this as it's specifying an
> absolute directory. But since make has no understanding of shell
> quoting, it does anyway.
>
> For a long time this didn't matter, because addtree would still emit
> the original -I option after the adjusted one. However, commit
> db547ef19064 ("Kbuild: don't add obj tree in additional includes")
> changed it to remove the original -I option.
>
> Remove quotes (both double and single) before matching against the
> excluded patterns.
>
> References: https://bugs.debian.org/856474
> Reported-and-tested-by: Jack Henschel
> Reported-and-tested-by: Ritesh Raj Sarraf
> Fixes: db547ef19064 ("Kbuild: don't add obj tree in additional includes")
> Cc: sta...@vger.kernel.org # 4.8+
> Signed-off-by: Ben Hutchings
> ---
> --- a/scripts/Kbuild.include
> +++ b/scripts/Kbuild.include
> @@ -207,7 +207,7 @@ hdr-inst := -f $(srctree)/scripts/Makefi
> # Prefix -I with $(srctree) if it is not an absolute path.
> # skip if -I has no parameter
> addtree = $(if $(patsubst -I%,%,$(1)), \
> -$(if $(filter-out -I/% -I./% -I../%,$(1)),$(patsubst
> -I%,-I$(srctree)/%,$(1)),$(1)))
> +$(if $(filter-out -I/% -I./% -I../%,$(subst $(quote),,$(subst
> $(squote),,$(1,$(patsubst -I%,-I$(srctree)/%,$(1)),$(1)))
>
> # Find all -I options and call addtree
> flags = $(foreach o,$($(1)),$(if $(filter -I%,$(o)),$(call
> addtree,$(o)),$(o)))
I have been thinking about this patch.
We touched addtree every time a new problem popped up.
It would be easy to pick up this patch,
but it looks like a crazy idea
to play pattern-matching in the addtree even more.
[1] -Ifoo/bar/baz
[2] -I"foo/bar/baz"
[3] -I foo/bar/baz(whitespace(s) after -I)
All of these are valid notation,
and should be handled in the same way.
However, addtree expects only [1],
(then this patch is going to add [2] in the soup).
Each Makefile knows it wants to see
additional headers in the source tree, or objtree.
I am guessing the right approach in a long run is,
we require -I to specify $(srctree) or $(objtree) explicitly.
ccflags-y := -I$(srctree)/foo/bar/baz
or
ccflags-y := -I$(objtree)/foo/bar/baz
(For the latter, we can omit $(objtree)/ as it is ./)
Then, delete $(call flags,_c_flags) after the conversion.
Any comments?
--
Best Regards
Masahiro Yamada
