INT33FF error when installing slackware 14.2

stf92 · 07-03-2020, 04:25 PM

Aspire One Cloudbook 14 (A01-431-C8G8)

Slackware 14.2 32-bit

Hi: I'm trying to install slackware 14.2 32-bit on my laptop (which is a 64-bit machine). I boot from the USB stick and, the installer gives me a prompt, I log in and wait some minutes before beginning to type. But then the screen is suddenly filled with messages. They are of two types:

Code:

udevd[348]: worker[351]: failed while handling /devices/platform/INT33FF:01

Code:

udevd[348]: worker[357]: failed while handling /devices/LNXSYSTM:00/LNXSYBUS:00/INT33FF:01

Now I press Enter and get the prompt again. What is more: I was inside cfdisk and suddenly the messages again filled the screen. When I pressed Enter I found myself outside cfdisk. cfdisk had quited.

Alright. In this machine I have Debian 10. When I boot debian I can read as the first messages appearing on the screen error messages terminating in "INT33FF...Failed to get interrupt number" (I am not fast enough to read the entire line). What can all this mean?

BrunoLafleur · 07-04-2020, 03:44 AM

There is some referencies to INT33 here : https://linuxlists.cc/l/1/linux-kern...3/linux_5.4.29

May be the 4.4 kernel of the Slackware 14.2 is too old for this machine ?

Also why you put the 32 bit version. Is there a particular reason for that ?

BrunoLafleur · 07-04-2020, 03:47 AM

Also : is the battery good. Is it plugged ?

stf92 · 07-04-2020, 07:48 AM

I also have debian 10 on this machine and it also has problems with INT33FF at boot time. Also, the battery is fully charged when this happens.

If I use the 32-bit version it is because I have a 32-GB hard disk, actually an eMMC device, and the 32-bit I think is less bulky than the 64-bit version. Also, I have only 2GB RAM.

This is from your link:

Quote:

/*
- * Various HP X2 10 Cherry Trail models use an external
- * embedded-controller connected via I2C + an ACPI GPIO
- * event handler. The embedded controller generates various
- * spurious wakeup events when suspended. So disable wakeup
- * for its handler (it uses the only ACPI GPIO event handler).
- * This breaks wakeup when opening the lid, the user needs
+ * HP X2 10 models with Cherry Trail SoC + TI PMIC use an
+ * external embedded-controller connected via I2C + an ACPI GPIO
+ * event handler on INT33FF:01 pin 0, causing spurious wakeups.
+ * When suspending by closing the LID, the power to the USB
+ * keyboard is turned off, causing INT0002 ACPI events to
+ * trigger once the XHCI controller notices the keyboard is
+ * gone. So INT0002 events cause spurious wakeups too. Ignoring
+ * EC wakes breaks wakeup when opening the lid, the user needs
* to press the power-button to wakeup the system. The
* alternative is suspend simply not working, which is worse.
*/

It's all I could find about int33ff. But I think the spurious wakeups thing is what I am experimenting.

BrunoLafleur · 07-06-2020, 01:42 AM

That's what I saw. The patch below what you have found does what is said : ignore the spurious wakeups.

I don't know if this patch is also on the 4.4 kernel. Probably not. Some people which uses 14.2 Slackware put a more recent kernel on it. Or else other uses Slackware current which has the 5.4.50 kernel or Slackware current with the latest kernel (5.7).

Some hardware with the same age as a given distribution don't work with it. We should use a more recent kernel for those hardware.

Debian 10 uses kernel 4.19 probably too old also.