HP ProBook 6550b, serial port uart0 missing

The laptop has one serial port, but it shows up nowhere. Nothing special visible with boot -v and nothing by inb:ing from 0x3F8...F, just 0xFF. BIOS settings checked (I think) thoroughly. I've read about acpidump but that path frightens me.

Anyone know if it's worthwhile to study the ASL, DSDT etc, or to get a copy of Windows and hope for a non-volatile setting therein.

Juha

Ugly solution in laptop compat thread https://forums.freebsd.org/threads/17308/page-5#post-304594
 
Last edited:
It would not appear as a device or sysctl called uart0 on FreeBSD, it would be /dev/cuau0.

Is the port enabled in the BIOS? What does sysctl dev.uart show?
 
Code:
FreeBSD 10.1-RELEASE-p10 #0: ...  i386
Something that should have been said in the first post.
Code:
none0@pci0:0:22:0:  class=0x078000 card=0x146d103c chip=0x3b648086 rev=0x06 hdr=0x00
  vendor  = 'Intel Corporation'
  device  = '5 Series/3400 Series Chipset HECI Controller'
  class  = simple comms
  bar  [10] = type Memory, range 64, base 0xd4824000, size 16, enabled
isab0@pci0:0:31:0:  class=0x060100 card=0x146d103c chip=0x3b0b8086 rev=0x05 hdr=0x00
  vendor  = 'Intel Corporation'
  device  = 'Mobile 5 Series Chipset LPC Interface Controller'
  class  = bridge
  subclass  = PCI-ISA
I don't know what the first one is, but googling HECI didn't look promising. Second one, LPC, contains the serial port, I think. Paralllel port does show up. There's no physical LPT connector though without a dock :)

Code:
hopo # sysctl -a |grep uart
device  uart_ns8250
device  uart

Ah... I have not yet tried to use the driver as a module.

All BIOS settings that even remotely look like affecting serial ports have been tried.
It is possible that I missed one permutation, though.

I think (in a rut?) there's some non-standard knob in the DSDT, which must be enabled for the uart to function.
acpidump asl and company just look so ugly, that I prefer a nicely working laptop without uart to a brick. I should have looked around in the pre-installed Windows first, instead of immediately overwriting it.

There is also a module acpi_hp and device /dev/hpcmi which might be related. Reading hpcmi takes about 5 seconds, 5 seconds busy in the read system call, and result is 169 newlines and nothing else.

Thanks,
Juha
 
Back
Top