Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #74475 > unrolled thread

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

Started bySalvatore Bonaccorso <carnil@debian.org>
First post2022-02-21 15:10 +0100
Last post2022-03-06 00:50 +0100
Articles 5 — 4 participants

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads Salvatore Bonaccorso <carnil@debian.org> - 2022-02-21 15:10 +0100
    Processed: Re: Bug#1006149: linux-image-5.16.0-1-686: Fails to  boot on T41 Thinkpads "Debian Bug Tracking System" <owner@bugs.debian.org> - 2022-02-21 15:10 +0100
    Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads Petra Rübe-Pugliese <debml@prp.in-berlin.de> - 2022-02-21 17:30 +0100
      Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads Diederik de Haas <didi.debian@cknow.org> - 2022-03-05 18:30 +0100
        Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads Diederik de Haas <didi.debian@cknow.org> - 2022-03-06 00:50 +0100

#74475 — Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

FromSalvatore Bonaccorso <carnil@debian.org>
Date2022-02-21 15:10 +0100
SubjectBug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Message-ID<DThy1-3lY4-7@gated-at.bofh.it>
Control: tags -1 + moreinfo

Hi

On Sat, Feb 19, 2022 at 10:04:14PM +0100, Petra R.-P. wrote:
> Package: src:linux
> Version: 5.16.7-2
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> This new kernel version does not boot on two fairly similar
> old IBM T41 Thinkpads.
> 
> What reproducibly happens is as follows:
> 
> After the lines
> 
>    Loading Linux 5.16.0-1-686 ...
>    Loading initial ramdisk ...
> 
> the screen gets flushed, and I see:
>    
>    [  4.xxxxxx] ata1.00: Read log 0x00 page 0x00 failed  Emask 0x1
>    <blinking cursur>
> 
> The "xxxxxx" vary for every try.
> 
> Then nothing else happens.
> Ctrl-Alt-Del has no effect.
> I have to reset the computer by pressing the button.
> 
> On an old PC running the same kernel the same message "ata1.00: Read log ..."
> appears, but then the boot process continues normally.
> 
> linux-image-5.15.0-3-686, which I am using to write this
> message, runs fine.

Are you booting in quite mode? if yes, can you remote if from the
kernel command line and see if you get more information on the screen?

Got off-bug a report from someone with similar Hardware with similar
symptoms.

From the failed boot, can you extract the kernel logs produced?

Regards,
Salvatore

[toc] | [next] | [standalone]


#74476 — Processed: Re: Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

From"Debian Bug Tracking System" <owner@bugs.debian.org>
Date2022-02-21 15:10 +0100
SubjectProcessed: Re: Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Message-ID<DThy1-3lY4-9@gated-at.bofh.it>
In reply to#74475
Processing control commands:

> tags -1 + moreinfo
Bug #1006149 [src:linux] linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads
Added tag(s) moreinfo.

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

[toc] | [prev] | [next] | [standalone]


#74477

FromPetra Rübe-Pugliese <debml@prp.in-berlin.de>
Date2022-02-21 17:30 +0100
Message-ID<DTjJv-3nA5-9@gated-at.bofh.it>
In reply to#74475
Hello Salvatore,

Am Mo., 21. Feb. 2022, um 14:56 +0100 schrieb Salvatore Bonaccorso <carnil@debian.org>:
> Control: tags -1 + moreinfo
[...]
> Are you booting in quite mode?

I do not think so.
I usually get _heaps_ of output scrolling away on the screen,
but in this case absolutely _nothing_ happens after the
first line of output.

> if yes, can you remote if from the kernel command line and see
> if you get more information on the screen?

How would that be done?
 
> Got off-bug a report from someone with similar Hardware with similar
> symptoms.

I'm glad to hear that it's not just me ...
> 
> >From the failed boot, can you extract the kernel logs produced?

I did the following:

 -> Start the notebook with the "bad" kernel at about 16:56 today.
    (The notebook had not run before today.)
 -> Press the button at around 16:58 to stop it.
 -> Restart the "good" kernel at 16:59:xx

Here is the corresponding passage from /var/log/kern.log :

Feb 20 10:24:42 localhost kernel: [ 2220.772792] sd 2:0:0:0: [sdb] Attached SCSI removable disk
Feb 20 10:24:43 localhost kernel: [ 2221.424423] sd 2:0:0:0: [sdb] 15753215 512-byte logical blocks: (8.07 GB/7.51 GiB)
Feb 20 10:24:43 localhost kernel: [ 2221.425660] sdb: detected capacity change from 0 to 15753215
Feb 20 10:24:43 localhost kernel: [ 2221.426455]  sdb: sdb1
Feb 20 10:24:54 localhost kernel: [ 2232.992583] EXT4-fs (sdb1): mounting ext2 file system using the ext4 subsystem
Feb 20 10:24:54 localhost kernel: [ 2233.011371] EXT4-fs (sdb1): mounted filesystem without journal. Opts: (null). Quota mode: none.
Feb 20 10:29:11 localhost kernel: [ 2489.270389] usb 1-4: USB disconnect, device number 8
Feb 21 17:00:53 localhost kernel: [    0.000000] Linux version 5.15.0-3-686 (debian-kernel@lists.debian.org) (gcc-11 (Debian 11.2.0-14) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37.90.20220123) #1 SMP Debian 5.15.15-2 (2022-01-30)
Feb 21 17:00:53 localhost kernel: [    0.000000] x86/fpu: x87 FPU will use FXSAVE
Feb 21 17:00:53 localhost kernel: [    0.000000] signal: max sigframe size: 1440
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-provided physical RAM map:
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] reserved
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000000d2000-0x00000000000d3fff] reserved
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000000dc000-0x00000000000fffff] reserved
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000001ff5ffff] usable
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x000000001ff60000-0x000000001ff76fff] ACPI data
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x000000001ff77000-0x000000001ff78fff] ACPI NVS
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x000000001ff80000-0x000000001fffffff] reserved
Feb 21 17:00:53 localhost kernel: [    0.000000] BIOS-e820: [mem 0x00000000ff800000-0x00000000ffffffff] reserved
Feb 21 17:00:53 localhost kernel: [    0.000000] Notice: NX (Execute Disable) protection missing in CPU!



That is:  Nothing whatever got recorded between
Feb 20 10:29:11 localhost kernel: [ 2489.270389] usb 1-4: USB disconnect, device number 8
(last activity yesterday)
and
Feb 21 17:00:53 localhost kernel: [    0.000000] Linux version 5.15.0-3-686 (debian-kernel@lists.debian.org) (
(start of the "good" kernel today).

I'm afraid that is not much in the way of "more information" ...  :-\


    Best regards,
        Petra

[toc] | [prev] | [next] | [standalone]


#74610

FromDiederik de Haas <didi.debian@cknow.org>
Date2022-03-05 18:30 +0100
Message-ID<DXGo9-64RY-3@gated-at.bofh.it>
In reply to#74477

[Multipart message — attachments visible in raw view] — view raw

On Monday, 21 February 2022 17:25:33 CET Petra Rübe-Pugliese wrote:
> > if yes, can you remote if from the kernel command line and see
> > if you get more information on the screen?
> 
> How would that be done?

If you do "cat /proc/cmdline" and see the word 'quiet' in there, then it's not 
as verbose as it could be on screen.

If you're using GRUB and the system boots up and you see the GRUB menu, press 
'e' to edit the line and remove the 'quiet' word. That way it will not be 
quiet for that boot.

If you want to remove it by default, look in /etc/default/grub and there you 
should see (f.e.):
GRUB_CMDLINE_LINUX_DEFAULT="quiet"

So if you remove the 'quiet' word there and do an update-grub, then the boot 
will be 'noisier' by default (on every boot).

HTH,
  Diederik

[toc] | [prev] | [next] | [standalone]


#74613

FromDiederik de Haas <didi.debian@cknow.org>
Date2022-03-06 00:50 +0100
Message-ID<DXMjU-68lO-5@gated-at.bofh.it>
In reply to#74610

[Multipart message — attachments visible in raw view] — view raw

Hi Petra,

On Saturday, 5 March 2022 21:12:12 CET Petra R.-P. wrote:
> On Sat 05 Mar 2022 at 18:23:52 +0100  Diederik de Haas
> <didi.debian@cknow.org> wrote:
> > On Monday, 21 February 2022 17:25:33 CET Petra Rübe-Pugliese wrote:
>  [...]
> 
> > So if you remove the 'quiet' word there and do an update-grub, then the
> > boot will be 'noisier' by default (on every boot).
> 
> This is what I have done, for the time being.
> 
> As a result, there was a lot of output on the screen.
> I am attaching a foto of the final state, where it stopped.

I didn't see an obvious clue as to why it didn't continue ...

> However, I cannot find any trace of this in /var/log/kern.log.
> Whereas "grep 5.15.0  /var/log/kern.log" gives loads of output,
> "grep 5.16.0  /var/log/kern.log" does not produce anything at
> all. 

How about in /var/log/kern.log.1 (f.e.) ? Because on my system the very first 
message of a boot in that file begins with:
[    0.000000] Linux version 5.16.0-3-amd64 ...

> Also manual inspection of the file does not show any relevant passage.

So far, *I* haven't found a direct clue as to why things fail, so if you do 
have _a_ log of a boot with the 5.16 kernel, then having that could help.
Especially if you could provide a similar log of a boot with the 5.15 kernel. 
Doesn't need to be the whole log, but knowing a couple of lines which happen 
thereafter on 5.15 but not on 5.16 could provide a clue.

I saw that the 5.16.11-1 kernel transitioned to testing and it is useful to 
know if the issue is still present with that version.
In the upstream kernel in drivers/gpu/drm/amd I saw a number of commits since 
version 5.16.7 (and also several other commits which are part of 5.16.12 which 
is present in salsa, but not yet released).

When I look at the photo from https://bugs.debian.org/1006149#44 (from Axel), 
I do notice an important difference:
He has various [drm] messages, whereas I see none of those with you.
Do you have [drm] messages when booting with the 5.15 kernel?

That bug message also has the following which is different from yours:
ii  firmware-amd-graphics     20210818-1
...
ii  firmware-linux-nonfree    20210818-1
ii  firmware-misc-nonfree     20210818-1

So it would be interesting to know whether installing any of those packages 
makes a difference. I'd suggest first installing the firmware-amd-graphics 
package.

HTH,
  Diederik

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.kernel


csiph-web