lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Nov 2014 13:54:04 +0000
From:	One Thousand Gnomes <>
Subject: Re: dmesg spam: "PnPBIOS: pnp_dock_thread: unexpected status 0x5

On Fri, 7 Nov 2014 00:54:31 +0100 wrote:

> Hi, 
> on an ancient GX1 Geode embedded board (Evo T20/Wyse wt3235le Thin Client, which are cheap (<$10) and low power x86 embeded platform) , dmesg is getting constantly spammed with "PnPBIOS: pnp_dock_thread: unexpected status 0x5" during and after boot. 
> Any ideas what this means and how to stop that?
> It seems it comes from drivers/pnp/pnpbios/bioscalls.c -> pnpbios_print_status()  
> Tried adding pnpbios=off, but with that the system does not boot anymore.
> Being curious, why a non-existing docking-station is being "polled at regular intervals" (i.e. every 2 seconds - see drivers/pnp/pnpbios/core.c )

We poll for a dock, and if the BIOS reports that the function is not
supported we then exit the thread.

> >From   i read:  "Function 05h - Get Docking Status Information at page 251" 

The spec is available at:
> it  seems this is being the result of a "docking event" ? Does this mean, my system is erroneusly generating such docking events, even if there is no docking station at all?

Your BIOS appears to be making strange replies. Any error ought to have
the top bit set, so its reporting a nonsense value for some reason.

I've not seen other reports of pnp_dock_thread errors with a real dock.
The only reports at all are a couple of old ones in google that seem to
be similar and a Debian bug (294652) which appears to be your bug so I'd
suggest testing the following

Change the default to

                  pnpbios_print_status("pnp_dock..... etc)
	          printk(KERN_ERR "PnPBIOS: Disabling dock monitoring\n");
	          complete_and_exit(&unload_sem, 0);

that should produce you one error message, a warning that dock monitoring
is being disabled and then it should stfu.

If you can let us know if that does the trick then I can push it upstream.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists