Kernel Panic after installation

Help with issues regarding installation of Debian

Kernel Panic after installation

Postby urukrama » 2018-11-16 14:00

I'm trying to install Debian on a Thinkpad X1 Carbon (1st gen), but after installation I always end up with a kernel panic immediately after installation, during the boot process.

The end of the error message reads:

end Kernel panic - not syncing: Can not allocate SWIOTLB buffer earlier and can't now provide you with the DMA bounce buffer


Initially I installed Debian Testing (both from netinstall and the weekly build of the CD1 iso), and then tried stable (9.6.0, CD1 iso), and I've received the same error message each time.

Is there a way to fix this?
urukrama
 
Posts: 8
Joined: 2008-12-30 12:08

Re: Kernel Panic after installation

Postby stevepusser » 2018-11-16 17:18

A lot of hits come up when I search for that error message on the Google. Maybe adding

iommu=soft swiotlb=soft

to the kernel command line at boot would solve the issue.
The MX Linux repositories: Backports galore! If we don't have something, just ask and we'll try--we like challenges. New packages: Flightgear 2018.2.2, 4.19.5 kernel, wine-staging 4.0~rc1, Pale Moon 28.2.2, Mesa 18.2.6, Midori 7.0
User avatar
stevepusser
 
Posts: 10276
Joined: 2009-10-06 05:53

Re: Kernel Panic after installation

Postby urukrama » 2018-11-16 17:35

stevepusser wrote:A lot of hits come up when I search for that error message on the Google. Maybe adding

iommu=soft swiotlb=soft

to the kernel command line at boot would solve the issue.


Thank you for the reply.

Unfortunately, this doesn't seem to have any effect on this problem. I still get the same error.
urukrama
 
Posts: 8
Joined: 2008-12-30 12:08

Re: Kernel Panic after installation

Postby urukrama » 2018-11-16 18:12

For the record, I also tried the following, which was suggested elsewhere for a similar error, with the same effect (kernel panic, as above):

intel_iommu=on
urukrama
 
Posts: 8
Joined: 2008-12-30 12:08

Re: Kernel Panic after installation

Postby bw123 » 2018-11-17 00:24

Sounds frustrating. I looked up https://duckduckgo.com/html/?q=linux+ke ... +X1+Carbon

I saw a few suggestions, didn't dig it though, maybe the acpi_osi= param mentioned in arch wiki? I use that on an HP acpi_osi=Linux and it seems to do something?

Don;t know where I got this, name in the file says aaron maxwell.

Code: Select all
acpi_osi=       [HW,ACPI] Modify list of supported OS interface strings
                        acpi_osi="string1"      # add string1
                        acpi_osi="!string2"     # remove string2
                        acpi_osi=!*             # remove all strings
                        acpi_osi=!              # disable all built-in OS vendor
                                                  strings
                        acpi_osi=!!             # enable all built-in OS vendor
                                                  strings
                        acpi_osi=               # disable all strings
   
                        'acpi_osi=!' can be used in combination with single or
                        multiple 'acpi_osi="string1"' to support specific OS
                        vendor string(s).  Note that such command can only
                        affect the default state of the OS vendor strings, thus
                        it cannot affect the default state of the feature group
                        strings and the current state of the OS vendor strings,
                        specifying it multiple times through kernel command line
                        is meaningless.  This command is useful when one do not
                        care about the state of the feature group strings which
                        should be controlled by the OSPM.
                        Examples:
                          1. 'acpi_osi=! acpi_osi="Windows 2000"' is equivalent
                             to 'acpi_osi="Windows 2000" acpi_osi=!', they all
                             can make '_OSI("Windows 2000")' TRUE.
 'acpi_osi=' cannot be used in combination with other
                        'acpi_osi=' command lines, the _OSI method will not
                        exist in the ACPI namespace.  NOTE that such command can
                        only affect the OSI support state, thus specifying it
                        multiple times through kernel command line is also
                        meaningless.
                        Examples:
                          1. 'acpiosi=' can make 'CondRefOf(_OSI, Local1)'
                             FALSE.

                        'acpi_osi=!' can be used in combination with single or
                        multiple 'acpi_osi="string1"' to support specific
                        string(s).  Note that such command can affect the
                        current state of both the OS vendor strings and the
                        feature group strings, thus specifying it multiple times
                        through kernel command line is meaningful.  But it may
                        still not able to affect the final state of a string if
                        there are quirks related to this string.  This command
                        is useful when one want to control the state of the
                        feature group strings to debug BIOS issues related to
                        the OSPM features.
                        Examples:
 1. 'acpi_osi="Module Device" acpi_osi=!' can make
                             'OSI("Module Device")' FALSE.
                          2. 'acpiosi=! acpi_osi="Module Device"' can make
                             'OSI("Module Device")' TRUE.
                          3. 'acpiosi=! acpi_osi=! acpi_osi="Windows 2000"' is
                             equivalent to
                             'acpi_osi=! acpi_osi=! acpi_osi="Windows 2000"'
                             and
                             'acpi_osi=! acpi_osi="Windows 2000" acpi_osi=!',
                             they all will make '_OSI("Windows 2000")' TRUE.
User avatar
bw123
 
Posts: 3578
Joined: 2011-05-09 06:02
Location: TN_USA

Re: Kernel Panic after installation

Postby debiman » 2018-11-17 07:19

searching gives many different results; a few of them indicate it could actually be about realtek WiFi?
maybe swiotlb=8192 or some of the other kernel options mentioned in the first result?

there's also https://www.thinkwiki.org/wiki/ThinkWiki - sure they also have a forum.

PS: is this the real urukrama? your blog has helped me a lot in my early linux days, and i still have some of your gtk2/openbox themes. respect.
User avatar
debiman
 
Posts: 3064
Joined: 2013-03-12 07:18


Return to Installation

Who is online

Users browsing this forum: No registered users and 6 guests

fashionable