GoBook IX250 hangs at boot in ps2::init routine.

[siarzhuk]

Booting Haiku hrev41867 on GoBook IX250 notebook deadly locks at ps2 initialization stage. Removing ps2_hid driver binary from the image "solves" the problem but obviously makes the touchpad and keyboard unusable. Complete boot log is attached. Corresponding ps2 initialization tracing output looks like this:

ps2_hid: init_hardware
ps2_hid: init_driver
ps2: init
ps2: ps2_service_init
ps2: ps2_service_thread started
ps2: ps2_service_init done
ps2: ps2_command cmd 0x20, out 0, in 1
ps2: ps2_write_ctrl 0x20
ps2: ps2_interrupt ignoring, ctrl 0x1d (keyb)
ps2: ps2_command in 0x45
ps2: ps2_command result 0x00000000
ps2: get command byte: res 0x00000000, cmdbyte 0x45
ps2: ps2_command cmd 0x60, out 1, in 0
ps2: ps2_command out 0x47
ps2: ps2_write_ctrl 0x60
ps2: ps2_write_data 0x47
ps2: ps2_command result 0x00000000
ps2: set command byte: res 0x00000000, cmdbyte 0x47
ps2: ps2_command cmd 0xd3, out 1, in 1
ps2: ps2_command out 0xf0
ps2: ps2_write_ctrl 0xd3
ps2: ps2_write_data 0xf0
ps2: ps2_interrupt ignoring, ctrl 0x35 (aux)

That are the last lines in the syslog after system locks.

This notebook has stock ps2 keyboard,touchpad and additional ps2 extension slot at the back. Inserting external ps2 keyboard into this extension slot has no affect on described behavior.

[siarzhuk]

Boot log (updated)

[stargatefan]

​http://reviews.cnet.com/laptops/general-dynamics-itronix-gobook/1707-3121_7-30010176.html

this one here ?

Thats a really old and lowproduction machine. Lots of custom hardware in these machines. I think it must just be one of those things. Is there a way to enable IOAPIC in the settings ?

[siarzhuk]

Replying to stargatefan:

Lots of custom hardware in these machines.

Frankly speaking, there are nothing special inside. Besides Gunze USB Touchscreen. ;-)

Is there a way to enable IOAPIC in the settings ?

Looks like it is "missing" (line 169 of syslog):

165	apm_init()
166	  code32: 0xf000, 0xef50, length 0xffff
167	  code16: 0xf000, length 0x8100
168	  data: 0x40, length 0x100
169	disabling msi due to missing apic
170	slab memory manager: created area 0x80801000 (89)
171	initialize_commpage_syscall(): sysenter/sysexit supported
172	allocate_commpage_entry(3, 5) -> 0xffff0110
173	heap_add_area: area -1 added to port buffer heap 0x8215f400 - usable range 0x80185000 - 0x80578000
174	PCI: pci_module_init

[siarzhuk]

Just for Info:

it hangs in call ps2_setup_active_multiplexing() https://dev.haiku-os.org/browser/haiku/trunk/src/add-ons/kernel/bus_managers/ps2/ps2_common.cpp#L150 at first call of ps2_command

149	static status_t
150	ps2_setup_active_multiplexing(bool *enabled)
151	{
152	    status_t res;
153	    uint8 in, out;
154	
155	    out = 0xf0;
156	    res = ps2_command(0xd3, &out, 1, &in, 1); //<----- this call
157	    if (res)
158	        goto fail;

Hard-coding the multiplexing to "false" and completely disabling call of ps2_setup_active_multiplexing() workarounds the problem and let internal keyboard and touchpad on this system work.

Looks like multiplexing detection procedure must be improoved. Note that #4315 proposes the same "solution" by disabling this setup procedure call. And, I suspect, the #3594 can be related to this issue too.

[siarzhuk]

Well, I have investigated the problem a bit and found that the interrupt issued during processing this call of ps2_command and execution never come back to it. I have protected the ps2_command with usual disable_interrupts()/restore_interrupts() frame and have successfully loaded the system.

ps2_hid: init_hardware
ps2_hid: init_driver
ps2: init
ps2: ps2_service_init
ps2: ps2_service_thread started
ps2: ps2_service_init done
ps2: ps2_command cmd 0x20, out 0, in 1
ps2: ps2_write_ctrl 0x20
ps2: ps2_interrupt ignoring, ctrl 0x1d (keyb)
ps2: ps2_command in 0x45
ps2: ps2_command result 0x00000000
ps2: get command byte: res 0x00000000, cmdbyte 0x45
ps2: ps2_command cmd 0x60, out 1, in 0
ps2: ps2_command out 0x47
ps2: ps2_write_ctrl 0x60
ps2: ps2_write_data 0x47
ps2: ps2_command result 0x00000000
ps2: set command byte: res 0x00000000, cmdbyte 0x47
ps2: ps2_command cmd 0xd3, out 1, in 1
ps2: ps2_command out 0xf0
ps2: ps2_write_ctrl 0xd3
ps2: ps2_write_data 0xf0
ps2: ps2_interrupt ignoring, ctrl 0x35 (aux)
Last message repeated 543 times.
ps2: ps2_command in 0xf0
ps2: ps2_command result 0x00000000
ps2: ps2_command cmd 0xd3, out 1, in 1
ps2: ps2_command out 0x56
ps2: ps2_write_ctrl 0xd3
ps2: ps2_write_data 0x56
ps2: ps2_interrupt ignoring, ctrl 0x35 (aux)
Last message repeated 5420 times.
ps2: ps2_command in 0x56
ps2: ps2_command result 0x00000000
ps2: ps2_command cmd 0xd3, out 1, in 1
ps2: ps2_command out 0xa4
ps2: ps2_write_ctrl 0xd3
ps2: ps2_write_data 0xa4
ps2: ps2_interrupt ignoring, ctrl 0x31 (aux)
ps2: ps2_command in 0x10
ps2: ps2_command result 0x00000000
ps2: active multiplexing v1.0 enabled
ps2: ps2_command cmd 0xae, out 0, in 0
ps2: ps2_write_ctrl 0xae
ps2: ps2_command result 0x00000000

So active multiplexing v 1.0 was successfully found and activated - both the mouse and keyboard on additional ps/2 port are functional. But note the lines like this:

ps2: ps2_interrupt ignoring, ctrl 0x35 (aux)
Last message repeated 5420 times.

Does the KBC generated interrupts repeatedly during they were disabled? Or, probably, this is the normal reaction of this controller to the Multiplexing Activation Sequence? Note that other notebooks I have checked have no habit to generate interrupts during the Multiplexing Activation.

[siarzhuk]

Fixed in hrev42323.