Bug#872664: linux-image-4.9.0-3-686-pae: Resume from hibernate fails on Thinkpad T60

[Holger Wansing]

Package: src:linux
Version: 4.9.30-2
Severity: normal


Hi,
since upgrading from Jessie to Stretch, I'm unable to use suspend/resume 
feature on my IBM T60 Thinkpad. Before it worked perfectly for years.

The symptoms are exactly as described in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843609:
When resuming I get the grub menu, then some initial kernel messages 
(output from fsck for example), the harddisk is working a lot, and then only 
a blinking cursor, that's it.
Switching to virtual consoles is not possible, and no X.
Performing a hibernate when the system is running in recovery mode
(single user mode, init 1) gives the same result.

I tried with the 4.11 kernel from unstable, the same problem.
I also tried with the 3.16 kernel from jessie, which is also still installed
here, the same problem.

Thus it's probably not a kernel problem, but I have no clue what package to
report this against instead ...


Holger

-- 

Created with Sylpheed 3.2.0 under the new
D E B I A N   L I N U X   7 . 0   W H E E Z Y !

Registered Linux User #311290 - https://linuxcounter.net/

Processed: Re: Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Debian Bug Tracking System]

Processing control commands:

> tag -1 moreinfo
Bug #872644 [src:linux] linux-image-4.12.0-1-686-pae: 
Olinux-imag-4.12.0-1-686-pae sends crash messags at boot
Added tag(s) moreinfo.

-- 
872644: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872644
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Ben Hutchings]

Control: tag -1 moreinfo

On Sat, 2017-08-19 at 19:03 +0200, Hans-J. Ullrich wrote:
> Package: src:linux
> Version: 4.12.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
> my debian/testing system got /usr, /var and /home luks encrypted. At
> boot, as soon as I entered the passwort for the first partition to
> decrypt (which is always /usr), I get a bunch of messages, that
> something is crashed. However, this is not destructive and I can get
> booting on by decrypting /var and /home.
> 
> I would like to send the messages to you, but I see no way, to file
> these messages, as they are in a too early state, when a kernekl log
> or a boot log is yet not written.
[...]

The kernel log always gets written to /var/log/messages.  I think these
messages relate to later parts of the boot process and are not produced
by the kernel.  Please ask for help in one of the Debian support
channels to identify the correct package for this bug.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



signature.asc
Description: This is a digitally signed message part

Re: Bug#870185: armel/marvell kernel size

[Ben Hutchings]

On Sun, 2017-08-20 at 02:35 +0900, Roger Shimizu wrote:
> On Sun, Aug 20, 2017 at 12:55 AM, Ian Campbell 
> wrote:
> > On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
> > > I know for bug #870185, Robert fixed his device by modify uboot
> > > params, but I guess it's still possible to keep uboot params and
> > > only
> > > change the boot addresses of kernel/initrd in flash-kernel db
> > > file.
> > 
> > In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185#35 I
> > concluded it wasn't, perhaps I'm wrong though.
> 
> You may read my previous research:
> - https://bugs.debian.org/809476#49
> 
> > Can someone confirm whether the issue is that the u-boot load
> > addresses
> >  for kernel and initrd are conflicting or if it is the kernel's
> > target/decompression address and u-boot's initrd address which are
> > conflicting? The symptoms seem to suggest the kernel is being
> > decompressed over the initrd.
> 
> The real problem is kernel size (after decompression) increased from
> 5MB to 8MB. (detail is in my previous post)
> This looks like a bug, since usually kernel size grows gradually, not
> in +3MB way this time.

Some things to check:

- If you build 4.10 with the config used for 4.11 (whichever is the
first larger one), is the size 5 MB or 8 MB?

- If not, try bisecting the upstream source to find a jump in size.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



signature.asc
Description: This is a digitally signed message part

[PATCH] sh: Do not use hyphen in exported variable names

[Ben Hutchings]

arch/sh/Makefile defines and exports ld-bfd to be used by
arch/sh/boot/Makefile and arch/sh/boot/compressed/Makefile.  Similarly
arch/sh/boot/Makefile defines and exports suffix-y to be used by
arch/sh/boot/compressed/Makefile.  However some shells, including
dash, will not pass through environment variables whose name includes
a hyphen.  Usually GNU make does not use a shell to recurse, but if
e.g. $(srctree) contains '~' it will use a shell here.

Rename these variables to ld_bfd and suffix_y.

References: 
https://buildd.debian.org/status/fetch.php?pkg=linux=sh4=4.13%7Erc5-1%7Eexp1=1502943967=0
Fixes: ef9b542fce00 ("sh: bzip2/lzma uImage support.")
Signed-off-by: Ben Hutchings 
---
 arch/sh/Makefile | 10 +-
 arch/sh/boot/Makefile| 16 
 arch/sh/boot/compressed/Makefile |  6 +++---
 arch/sh/boot/romimage/Makefile   |  4 ++--
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/arch/sh/Makefile b/arch/sh/Makefile
index 280bbff12102..496525557b60 100644
--- a/arch/sh/Makefile
+++ b/arch/sh/Makefile
@@ -116,16 +116,16 @@ KBUILD_DEFCONFIG  := cayman_defconfig
 endif
 
 ifdef CONFIG_CPU_LITTLE_ENDIAN
-ld-bfd := elf32-$(UTS_MACHINE)-linux
-LDFLAGS_vmlinux+= --defsym jiffies=jiffies_64 --oformat 
$(ld-bfd)
+ld_bfd := elf32-$(UTS_MACHINE)-linux
+LDFLAGS_vmlinux+= --defsym jiffies=jiffies_64 --oformat 
$(ld_bfd)
 LDFLAGS+= -EL
 else
-ld-bfd := elf32-$(UTS_MACHINE)big-linux
-LDFLAGS_vmlinux+= --defsym jiffies=jiffies_64+4 --oformat 
$(ld-bfd)
+ld_bfd := elf32-$(UTS_MACHINE)big-linux
+LDFLAGS_vmlinux+= --defsym jiffies=jiffies_64+4 --oformat 
$(ld_bfd)
 LDFLAGS+= -EB
 endif
 
-export ld-bfd BITS
+export ld_bfd BITS
 
 head-y := arch/sh/kernel/head_$(BITS).o
 
diff --git a/arch/sh/boot/Makefile b/arch/sh/boot/Makefile
index 58592dfa5cb6..296b25474395 100644
--- a/arch/sh/boot/Makefile
+++ b/arch/sh/boot/Makefile
@@ -19,12 +19,12 @@ CONFIG_ZERO_PAGE_OFFSET ?= 0x1000
 CONFIG_ENTRY_OFFSET?= 0x1000
 CONFIG_PHYSICAL_START  ?= $(CONFIG_MEMORY_START)
 
-suffix-y := bin
-suffix-$(CONFIG_KERNEL_GZIP)   := gz
-suffix-$(CONFIG_KERNEL_BZIP2)  := bz2
-suffix-$(CONFIG_KERNEL_LZMA)   := lzma
-suffix-$(CONFIG_KERNEL_XZ) := xz
-suffix-$(CONFIG_KERNEL_LZO):= lzo
+suffix_y := bin
+suffix_$(CONFIG_KERNEL_GZIP)   := gz
+suffix_$(CONFIG_KERNEL_BZIP2)  := bz2
+suffix_$(CONFIG_KERNEL_LZMA)   := lzma
+suffix_$(CONFIG_KERNEL_XZ) := xz
+suffix_$(CONFIG_KERNEL_LZO):= lzo
 
 targets := zImage vmlinux.srec romImage uImage uImage.srec uImage.gz \
   uImage.bz2 uImage.lzma uImage.xz uImage.lzo uImage.bin
@@ -106,10 +106,10 @@ OBJCOPYFLAGS_uImage.srec := -I binary -O srec
 $(obj)/uImage.srec: $(obj)/uImage
$(call if_changed,objcopy)
 
-$(obj)/uImage: $(obj)/uImage.$(suffix-y)
+$(obj)/uImage: $(obj)/uImage.$(suffix_y)
@ln -sf $(notdir $<) $@
@echo '  Image $@ is ready'
 
 export CONFIG_PAGE_OFFSET CONFIG_MEMORY_START CONFIG_BOOT_LINK_OFFSET \
CONFIG_PHYSICAL_START CONFIG_ZERO_PAGE_OFFSET CONFIG_ENTRY_OFFSET \
-   KERNEL_MEMORY suffix-y
+   KERNEL_MEMORY suffix_y
diff --git a/arch/sh/boot/compressed/Makefile b/arch/sh/boot/compressed/Makefile
index c4c47ea9fa94..40fcc3d1a9c0 100644
--- a/arch/sh/boot/compressed/Makefile
+++ b/arch/sh/boot/compressed/Makefile
@@ -32,7 +32,7 @@ ORIG_CFLAGS := $(KBUILD_CFLAGS)
 KBUILD_CFLAGS = $(subst -pg, , $(ORIG_CFLAGS))
 endif
 
-LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext $(IMAGE_OFFSET) -e startup \
+LDFLAGS_vmlinux := --oformat $(ld_bfd) -Ttext $(IMAGE_OFFSET) -e startup \
   -T $(obj)/../../kernel/vmlinux.lds
 
 #
@@ -74,7 +74,7 @@ $(obj)/vmlinux.bin.lzo: $(vmlinux.bin.all-y) FORCE
 
 OBJCOPYFLAGS += -R .empty_zero_page
 
-LDFLAGS_piggy.o := -r --format binary --oformat $(ld-bfd) -T
+LDFLAGS_piggy.o := -r --format binary --oformat $(ld_bfd) -T
 
-$(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix-y) FORCE
+$(obj)/piggy.o: $(obj)/vmlinux.scr $(obj)/vmlinux.bin.$(suffix_y) FORCE
$(call if_changed,ld)
diff --git a/arch/sh/boot/romimage/Makefile b/arch/sh/boot/romimage/Makefile
index 43c41191de5d..8002c3ee2cac 100644
--- a/arch/sh/boot/romimage/Makefile
+++ b/arch/sh/boot/romimage/Makefile
@@ -12,7 +12,7 @@ mmcif-obj-$(CONFIG_CPU_SUBTYPE_SH7724):= 
$(obj)/mmcif-sh7724.o
 load-$(CONFIG_ROMIMAGE_MMCIF)  := $(mmcif-load-y)
 obj-$(CONFIG_ROMIMAGE_MMCIF)   := $(mmcif-obj-y)
 
-LDFLAGS_vmlinux := --oformat $(ld-bfd) -Ttext $(load-y) -e romstart \
+LDFLAGS_vmlinux := --oformat $(ld_bfd) -Ttext $(load-y) -e romstart \
   -T $(obj)/../../kernel/vmlinux.lds
 
 $(obj)/vmlinux: $(obj)/head.o $(obj-y) $(obj)/piggy.o FORCE
@@ -23,7 +23,7 @@ OBJCOPYFLAGS += -j .empty_zero_page
 $(obj)/zeropage.bin: vmlinux FORCE
  

[PATCH v2] kbuild: Do not use hyphen in exported variable name

[Ben Hutchings]

This definition in Makefile.dtbinst:

export dtbinst-root ?= $(obj)

should define and export dtbinst-root when handling the root dts
directory, and do nothing in the subdirectories.  However some shells,
including dash, will not pass through environment variables whose name
includes a hyphen.  Usually GNU make does not use a shell to recurse,
but if e.g. $(srctree) contains '~' it will use a shell here.

Rename the variable to dtbinst_root.

References: https://bugs.debian.org/833561
Fixes: 323a028d39cdi ("dts, kbuild: Implement support for dtb vendor subdirs")
Signed-off-by: Ben Hutchings 
---
v2: Revised the commit message to explain exactly how the hyphenated
variable can be lost.

 scripts/Makefile.dtbinst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/Makefile.dtbinst b/scripts/Makefile.dtbinst
index 34614a48b717..993fb85982df 100644
--- a/scripts/Makefile.dtbinst
+++ b/scripts/Makefile.dtbinst
@@ -14,7 +14,7 @@ src := $(obj)
 PHONY := __dtbs_install
 __dtbs_install:
 
-export dtbinst-root ?= $(obj)
+export dtbinst_root ?= $(obj)
 
 include include/config/auto.conf
 include scripts/Kbuild.include
@@ -27,7 +27,7 @@ dtbinst-dirs  := $(dts-dirs)
 quiet_cmd_dtb_install =INSTALL $<
   cmd_dtb_install =mkdir -p $(2); cp $< $(2)
 
-install-dir = $(patsubst $(dtbinst-root)%,$(INSTALL_DTBS_PATH)%,$(obj))
+install-dir = $(patsubst $(dtbinst_root)%,$(INSTALL_DTBS_PATH)%,$(obj))
 
 $(dtbinst-files): %.dtb: $(obj)/%.dtb
$(call cmd,dtb_install,$(install-dir))


signature.asc
Description: Digital signature

Re: [PATCH] kbuild: Do not use hyphen in exported variable name

[Ben Hutchings]

On Sun, 2017-08-20 at 02:37 +0900, Masahiro Yamada wrote:
[...]
> I did "grep SHELL" in kernel sources, but I could not
> find suspicious line.
> 
> 
> Is there anyone that sets SHELL
> in debian specific patches?

No, there isn't.  But I finally worked out the trigger conditions:

1. Source directory name includes a shell special character.  This is
true in Debian whenever we build a release candidate, because the
source directory is named after the package version, and we use ~ to
represent a pre-release version (e.g. 4.13~rc5 sorts before 4.13).

2. Object directory is outside the source directory, or at least two
levels below it (see the definition of srctree in the top level
Makefile).  This is always true in Debian package builds.

Shell comamnds to reproduce this:

rsync --archive --exclude /.git/ . /tmp/linux~/
cd /tmp/linux~
make mrproper
make O=one/two ARCH=arm64 defconfig
make -C one/two ARCH=arm64 dtbs
make -C one/two ARCH=arm64 INSTALL_DTBS_PATH=dtbs~ dtbs_install

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou


signature.asc
Description: This is a digitally signed message part

Bug#872650: linux-image-4.12.0-1-amd64: Please enable CONFIG_MEDIA_CEC_RC

[Hans Verkuil]

Package: src:linux
Version: 4.12.6-1
Severity: normal

Dear Maintainer,

In bug 868511 I requested that some CEC drivers were enabled in the kernel
(they are, and thank you very much for doing this).

Unfortunately I forgot to mention that CONFIG_MEDIA_CEC_RC should also
be enabled to integrate CEC with the remote control subsystem.

Can you enable that as well?

Thank you,

Hans Verkuil
CEC subsystem maintainer


-- Package-specific info:
** Version:
Linux version 4.12.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.12.0-1-amd64 
root=UUID=6db3c566-9220-4a46-9bac-74b586336f5d ro console=tty0 
console=ttyS0,38400

** Tainted: PO (4097)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.

** Kernel log:
[  200.172079] pulse8-cec serio0: Firmware build date 2015.01.27 16:14:39
[  896.983212] NET: Unregistered protocol family 40
[  897.623528] Guest personality initialized and is inactive
[  897.639759] VMCI host device registered (name=vmci, major=10, minor=57)
[  897.659568] Initialized host personality
[  897.699766] NET: Registered protocol family 40
[  900.471051] NET: Unregistered protocol family 40
[  948.751813] Guest personality initialized and is inactive
[  948.768030] VMCI host device registered (name=vmci, major=10, minor=57)
[  948.787842] Initialized host personality
[  948.822309] NET: Registered protocol family 40
[  966.560362] NET: Unregistered protocol family 40
[  966.930247] Guest personality initialized and is inactive
[  966.946508] VMCI host device registered (name=vmci, major=10, minor=57)
[  966.966337] Initialized host personality
[  967.005735] NET: Registered protocol family 40
[  975.303946] NET: Unregistered protocol family 40
[  975.653733] Guest personality initialized and is inactive
[  975.670002] VMCI host device registered (name=vmci, major=10, minor=57)
[  975.689809] Initialized host personality
[  975.728061] NET: Registered protocol family 40
[ .726315] NET: Unregistered protocol family 40
[ 1112.318799] Guest personality initialized and is inactive
[ 1112.335088] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1112.354903] Initialized host personality
[ 1112.396797] NET: Registered protocol family 40
[ 1115.178131] NET: Unregistered protocol family 40
[ 1155.417492] Guest personality initialized and is inactive
[ 1155.433729] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1155.453552] Initialized host personality
[ 1155.489508] NET: Registered protocol family 40
[ 1172.539782] NET: Unregistered protocol family 40
[ 1172.878231] Guest personality initialized and is inactive
[ 1172.894515] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1172.914341] Initialized host personality
[ 1172.952831] NET: Registered protocol family 40
[ 1182.075389] NET: Unregistered protocol family 40
[ 1182.464403] Guest personality initialized and is inactive
[ 1182.480683] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1182.500512] Initialized host personality
[ 1182.545352] NET: Registered protocol family 40
[ 1212.882112] NET: Unregistered protocol family 40
[ 1213.212129] Guest personality initialized and is inactive
[ 1213.228382] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1213.248192] Initialized host personality
[ 1213.285168] NET: Registered protocol family 40
[ 1308.934160] NET: Unregistered protocol family 40
[ 1309.246158] /dev/vmmon[17854]: Module vmmon: registered with major=10 
minor=165
[ 1309.246161] /dev/vmmon[17854]: Using tsc_khz as TSC frequency: 2709937
[ 1309.246162] /dev/vmmon[17854]: Module vmmon: initialized
[ 1309.258333] Guest personality initialized and is inactive
[ 1309.274604] VMCI host device registered (name=vmci, major=10, minor=57)
[ 1309.294405] Initialized host personality
[ 1309.329458] NET: Registered protocol family 40
[ 1309.561632] /dev/vmnet: open called by PID 17969 (vmnet-bridge)
[ 1309.561637] /dev/vmnet: hub 0 does not exist, allocating memory.
[ 1309.561650] /dev/vmnet: port on hub 0 successfully opened
[ 1309.561658] bridge-enp132s0: up
[ 1309.561662] bridge-enp132s0: attached
[ 1310.594413] /dev/vmnet: open called by PID 17976 (vmnet-netifup)
[ 1310.594419] /dev/vmnet: hub 1 does not exist, allocating memory.
[ 1310.594439] /dev/vmnet: port on hub 1 successfully opened
[ 1310.670130] /dev/vmnet: open called by PID 17979 (vmnet-dhcpd)
[ 1310.670139] /dev/vmnet: port on hub 1 successfully opened
[ 1310.676410] /dev/vmnet: open called by PID 17991 (vmnet-natd)
[ 1310.676419] /dev/vmnet: hub 8 does not exist, allocating memory.
[ 1310.676445] /dev/vmnet: port on hub 8 successfully opened
[ 1310.677780] userif-3: sent link down event.
[ 1310.680277] /dev/vmnet: open called by PID 17992 (vmnet-netifup)
[ 1310.680295] /dev/vmnet: port on hub 8 successfully opened
[ 1310.690820] userif-3: sent link up 

Re: [PATCH] kbuild: Do not use hyphen in exported variable name

[Masahiro Yamada]

Hi Ben,

Thanks for useful info.


2017-08-19 10:13 GMT+09:00 Ben Hutchings :
> On Sun, 2017-04-30 at 15:49 +0100, Ben Hutchings wrote:
>> On Sun, 2017-04-30 at 23:14 +0900, Masahiro Yamada wrote:
>> > Hi Ben,
>> >
>> >
>> > > 2017-04-23 16:23 GMT+09:00 Ben Hutchings :
>> > > On Sun, 2017-04-23 at 15:47 +0900, Masahiro Yamada wrote:
>> > > [...]
>> > > > I tested dtbs_install once again by myself, but
>> > > > dtbinst-root is exported to the sub make
>> > > > and the vendor directories are created correctly.
>> > > >
>> > > >
>> > > > I checked the debian's forum you gave
>> > > > > References: https://bugs.debian.org/833561
>> > > >
>> > > > In there, you mentioned:
>> > > > "This looks like a bug in make, but we can at least work around it by
>> > > > using a non-hyphenated variable name."
>> > > >
>> > > >
>> > > > Does this issue happen on a specific Make version?
>> > > >
>> > > > I tested GNU make 3.81, 3.82, 4.0, 4.1, 4.2,
>> > > > but I was not hit by the problem.
>> > >
>> > > I don't think this is make version dependent.  I can't reproduce the
>> > > issue today with make 4.1.  But I would have been using the same
>> > > version in August when I wrote that.
>> > >
>> > > What more can I say?  Clearly the hyphenated variable gets passed to
>> > > the sub-make in most cases.  But it's not totally reliable because last
>> > > year it wasn't working for us.
>> > >
>> > > > In the last post in the thread, you concluded:
>> > > > "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."
>> > >
>> > > I didn't write that, it's a standard message generated for bugs marked
>> > > as closed in a package changelog. :-)
>> > >
>> > > > If so, why is this patch here?
>> > > > How is the dtbs_install procedure different in the Debian package?
>> > >
>> > > This is the patch I applied to the package.
>> > >
>> >
>> > Do you still need this patch for Debian?
>> [...]
>>
>> I don't think so.  I just don't know for sure.
>
> I've now seen a similar problem with the suffix-y variable exported
> from arch/sh/boot/Makefile to arch/sh/boot/compressed/Makefile:
> https://buildd.debian.org/status/fetch.php?pkg=linux=sh4=4.13%7Erc5-1%7Eexp1=1502943967=0
>
> Those Makefiles haven't changed recently, so there must be some
> difference in the build environment.  Here's a Makefile that
> demonstrates the difference in behaviour between bash and dash:
>
> --- BEGIN ---
> ifdef WANTED_SHELL
> SHELL := $(WANTED_SHELL)
> endif
>
> test:
> @WANTED_SHELL=/bin/bash $(MAKE) test2
> @WANTED_SHELL=/bin/dash $(MAKE) test2
> @WANTED_SHELL= $(MAKE) test2
>
> test2: export foo_bar := foo_bar
> test2: export foo-bar := foo-bar
> test2:
> @echo SHELL=$(SHELL)
> @$(MAKE) test3
>
> test3:
> @echo foo_bar=$(foo_bar)
> @echo foo-bar=$(foo-bar)
>
> .PHONY: test test2 test3
> --- END ---
>
> For me, this produces:
>
> $ make -s
> SHELL=/bin/bash
> foo_bar=foo_bar
> foo-bar=foo-bar
> SHELL=/bin/dash
> foo_bar=foo_bar
> foo-bar=
> SHELL=/bin/sh
> foo_bar=foo_bar
> foo-bar=foo-bar
>
> Note that the last two cases are different even though /bin/sh is dash
> here.  It turns out that make avoids using the shell for simple
> commands, unless it has been changed from the default:
> https://sources.debian.net/src/make-dfsg/4.1-9.1/job.c/#L2575


Yes.  This is also explained in O'Reilly GNU Make:

http://www.oreilly.com/openbook/make3/book/ch05.pdf

--->8--
Commands are essentially one-line shell scripts.
In effect, make grabs each line and passes it to a
subshell for execution. In fact, make can optimize this
(relatively) expensive fork/exec algorithm if it can
guarantee that omitting the shell will not change the
behavior of the program. It checks this by scanning each
command line for shell special characters, such as
wildcard characters and i/o redirection. If none are
found, make directly executes the command without
passing it to a subshell. By default, /bin/sh is used
for the shell. This shell is controlled by the make
variable SHELL but it is not inherited from the
environment. When make starts, it imports all the
variables from the user’s environment as make variables,
except SHELL. This is because the user’s choice of shell
should not cause a makefile (possibly included in some
downloaded software package) to fail. If a user really
wants to change the default shell used by make, he can
set the SHELL variable explicitly in the makefile.
We will discuss this issue in the section
“Which Shell to Use” later in this chapter
--->8--



>From your test case (the third one),
if SHELL is unset, it should work
whether /bin/sh is dash, bash, or whatever.
(I use Ubuntu, and /bin/sh is dash.  I see no problem
for installing dtbs.)


We see the problem only when SHELL is set to /bin/dash.

Bug#872644: linux-image-4.12.0-1-686-pae: Olinux-imag-4.12.0-1-686-pae sends crash messags at boot

[Hans-J. Ullrich]

Package: src:linux
Version: 4.12.6-1
Severity: normal

Dear Maintainer,

my debian/testing system got /usr, /var and /home luks encrypted. At boot, as 
soon as I entered the passwort for the first partition to decrypt (which is 
always /usr), I get a bunch of messages, that something is crashed. However, 
this is not destructive and I can get booting on by decrypting /var and /home.

I would like to send the messages to you, but I see no way, to file these 
messages, as they are in a too early state, when a kernekl log or a boot log is 
yet not written.

If you can tell me a way, to file down the messages as soon as the kernel 
starts (maybe there is a kernel command or a grub command, which let me do 
this), then I would be happy to send you the messages. I suppose, the message 
is related to my bios. I am running an EEEPC 1005HGO with an intel N270 cpu. 
Most messqages, which are generated are intel oriented and named, and added 
with hex addresses.

Please drop me a line, if you are interested in more. If not, I will just wait 
for the next kernel version. 

As I said, it is weired, but not destroyable.

Best regards

Hans  


 Package-specific info:
** Version:
Linux version 4.12.0-1-686-pae (debian-kernel@lists.debian.org) (gcc version 
6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)

** Command line:
BOOT_IMAGE=/vmlinuz-4.12.0-1-686-pae 
root=UUID=da2bbacb-1b05-461e-8b72-9eef666b9bf6 ro net.ifnames=0 quiet 
acpi_osi=Linux

** Tainted: W (512)
 * Taint on warning.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information

** Loaded modules:
rfcomm
fuse
xt_multiport
iptable_filter
irda
crc_ccitt
decnet
appletalk
ax25
ipx
p8023
p8022
psnap
llc
ctr
ccm
snd_hrtimer
snd_seq_midi
snd_seq_midi_event
snd_rawmidi
snd_seq
snd_seq_device
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
bnep
binfmt_misc
iTCO_wdt
iTCO_vendor_support
option
usb_wwan
usbserial
arc4
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_core
btusb
btrtl
btbcm
btintel
bluetooth
ecdh_generic
coretemp
joydev
evdev
serio_raw
snd_hda_codec_realtek
snd_hda_codec_generic
ath9k
ath9k_common
sg
snd_hda_intel
ath9k_hw
ath
i915
snd_hda_codec
snd_hda_core
snd_hwdep
snd_pcm_oss
snd_mixer_oss
lpc_ich
mfd_core
mac80211
snd_pcm
drm_kms_helper
snd_timer
snd
rng_core
soundcore
cfg80211
drm
wmi
eeepc_laptop
i2c_algo_bit
sparse_keymap
rfkill
shpchp
ac
acpi_cpufreq
button
video
battery
gspca_sn9c20x
gspca_main
v4l2_common
videodev
media
loop
atl1
mii
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
mbcache
ecb
lrw
gf128mul
algif_skcipher
af_alg
uas
usb_storage
hid_generic
usbhid
hid
dm_crypt
dm_mod
crypto_simd
cryptd
aes_i586
sd_mod
psmouse
ahci
libahci
libata
scsi_mod
uhci_hcd
ehci_pci
ehci_hcd
usbcore
usb_common
atl1c
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 945GSE Express Memory 
Controller Hub [8086:27ac] (rev 03)
Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Memory 
Controller Hub [1043:8340]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE 
Express Integrated Graphics Controller [8086:27ae] (rev 03) (prog-if 00 [VGA 
controller])
Subsystem: ASUSTeK Computer Inc. Mobile 945GSE Express Integrated 
Graphics Controller [1043:8340]
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: i915
Kernel modules: i915

00:02.1 Display controller [0380]: Intel Corporation Mobile 945GM/GMS/GME, 
943/940GML Express Integrated Graphics Controller [8086:27a6] (rev 03)
Subsystem: ASUSTeK Computer Inc. Mobile 945GM/GMS/GME, 943/940GML 
Express Integrated Graphics Controller [1043:8340]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:1b.0 Audio device [0403]: Intel Corporation NM10/ICH7 Family High Definition 
Audio Controller [8086:27d8] (rev 02)
Subsystem: ASUSTeK Computer Inc. NM10/ICH7 Family High Definition Audio 
Controller [1043:8398]
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: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation NM10/ICH7 Family PCI Express Port 
1 [8086:27d0] (rev 02) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 

Bug#870185: armel/marvell kernel size

[Roger Shimizu]

On Sun, Aug 20, 2017 at 12:55 AM, Ian Campbell  wrote:
> On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
>> I know for bug #870185, Robert fixed his device by modify uboot
>> params, but I guess it's still possible to keep uboot params and only
>> change the boot addresses of kernel/initrd in flash-kernel db file.
>
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185#35 I
> concluded it wasn't, perhaps I'm wrong though.

You may read my previous research:
- https://bugs.debian.org/809476#49

> Can someone confirm whether the issue is that the u-boot load addresses
>  for kernel and initrd are conflicting or if it is the kernel's
> target/decompression address and u-boot's initrd address which are
> conflicting? The symptoms seem to suggest the kernel is being
> decompressed over the initrd.

The real problem is kernel size (after decompression) increased from
5MB to 8MB. (detail is in my previous post)
This looks like a bug, since usually kernel size grows gradually, not
in +3MB way this time.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#872641: firmware-misc-nonfree: Missing nvidia firmware for GeForce GTX 1050i (gp107)

[robert]

Package: firmware-misc-nonfree
Version: 20161130-3
Severity: normal

Dear Maintainer,


   * What led up to the situation?

Booting the system after upgrading to kernel 4.12. A review of the system logs
reports loading errors.

$ journalctl --system

(...)

kernel: pci :01:00.0: optimus capabilities: enabled, status dynamic power,
hda bios codec supported
kernel: VGA switcheroo: detected Optimus DSM method \_SB_.PCI0.PEG0.PEGP handle
kernel: nouveau: detected PR support, will not use DSM
kernel: nouveau :01:00.0: NVIDIA GP107 (137000a1)

(...)

kernel: nouveau :01:00.0: bios: version 86.07.2b.00.15
kernel: nouveau :01:00.0: firmware: failed to load
nvidia/gp107/gr/sw_nonctx.bin (-2)
kernel: nouveau :01:00.0: Direct firmware load for
nvidia/gp107/gr/sw_nonctx.bin failed with error -2
kernel: nouveau :01:00.0: gr: failed to load gr/sw_nonctx
kernel: nouveau :01:00.0: gr ctor failed, -2
kernel: nouveau: probe of :01:00.0 failed with error -2

(...)

Leaving apart that the "noveau" driver cannot interact with the discrete Nvidia
card nothing else seems to be working well, so only reporting.

I guess it will be solved adding the firmware when available.

Regards,

robert



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=ca_ES:ca (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.130

-- no debconf information

Re: Bug#870185: armel/marvell kernel size

[Ian Campbell]

On Sat, 2017-08-19 at 12:57 +0900, Roger Shimizu wrote:
> I know for bug #870185, Robert fixed his device by modify uboot
> params, but I guess it's still possible to keep uboot params and only
> change the boot addresses of kernel/initrd in flash-kernel db file.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870185#35 I
concluded it wasn't, perhaps I'm wrong though.

Can someone confirm whether the issue is that the u-boot load addresses
 for kernel and initrd are conflicting or if it is the kernel's
target/decompression address and u-boot's initrd address which are
conflicting? The symptoms seem to suggest the kernel is being
decompressed over the initrd.

Since we don't want to change the u-boot we can't easily influence the
initrd address (since it doesn't use a u-boot header on this platform).
So it would seem the only possibility (other than shrinking the kernel)
would be to change the address at which it decompresses itself so it
doesn't conflict with the initrd.

Not sure how hard that would be -- it might be as simple as tweaking a
constant in the source or a Kconfig option, but I suspect it might
involve changing early boot assembly...

Ian.

Processed: Move to src:linux

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 872263 src:linux 4.11.6-1
Bug #872263 [linux-image-4.11.0-1-amd64-dbg] linux-image-4.11.0-1-amd64-dbg: 
file overwrite error upgrading from stretch-backports
Warning: Unknown package 'linux-image-4.11.0-1-amd64-dbg'
Bug reassigned from package 'linux-image-4.11.0-1-amd64-dbg' to 'src:linux'.
No longer marked as found in versions linux/4.11.6-1.
Ignoring request to alter fixed versions of bug #872263 to the same values 
previously set
Bug #872263 [src:linux] linux-image-4.11.0-1-amd64-dbg: file overwrite error 
upgrading from stretch-backports
Marked as found in versions linux/4.11.6-1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
872263: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=872263
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems