Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
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.
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.
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.
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?