Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
> > On Thu, 26 Jan 2023, Howard Spoelstra wrote:
> > > Mac OS X
> > > #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> > > mouse. No recognition as HID device.
> > > #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
> > kbd
> > > pcap shows normal interrupt operation and recognition as HID device
> > > #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point
> > kbd
> > > pcap shows normal interrupt operation and recognition as HID device
> > > #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb
> > > mouse. pcap shows no recognition as HID device.
> > > #10.0 in both cases apple system profiler shows 2 usb buses but no
> > devices.
> >
> > These are all the logs I get booting a 10.0 install iso with  mac99,via=pmu
> >
> > > > =============================================================
> > > > OpenBIOS 1.1 [May 25 2022 20:04]
> > > > Configuration device id QEMU version 1 machine id 1
> > > > CPUs: 1
> > > > Memory: 256M
> > > > UUID: 00000000-0000-0000-0000-000000000000
> > > > CPU type PowerPC,G4
> > milliseconds isn't unique.
> > > > switching to new context:
> > > > call-method slw_update_keymap failed with error ffffffdf
> > > > call-method slw_update_keymap failed with error ffffffdf
> > usb_ohci_reset pci-ohci
> > usb_ohci_stop pci-ohci: USB Suspended
> > usb_ohci_set_ctl pci-ohci: new state 0x0
> > usb_ohci_stop pci-ohci: USB Suspended
> > usb_ohci_port_detach port #0
> > usb_ohci_port_attach port #0
> > usb_ohci_port_detach port #1
> > usb_ohci_port_attach port #1
> > dbdma_unassigned_flush: use of unassigned channel 0
> > dbdma_unassigned_flush: use of unassigned channel 0
> > usb_ohci_mem_write_bad_offset 0x30
> > usb_ohci_set_ctl pci-ohci: new state 0x80
> > usb_ohci_start pci-ohci: USB Operational
> > usb_ohci_hub_power_up powered up all ports
> > usb_ohci_hub_power_up powered up all ports
> > usb_ohci_set_ctl pci-ohci: new state 0xc0
> > usb_ohci_stop pci-ohci: USB Suspended
> > usb_ohci_hub_power_up powered up all ports
> > usb_ohci_hub_power_up powered up all ports
> > usb_ohci_port_reset port #0
> >
> > It's probably OK until it restarts but the seems to be stopped. Anybody
> > wants to have a look? Maybe start with finding what the states mean.
> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS
> 9.0.4:
>
> usb_ohci_set_ctl pci-ohci: new state 0x80
> usb_ohci_start pci-ohci: USB Operational
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_hub_power_up powered up all ports
> usb_ohci_port_reset port #0
> usb_ohci_port_reset port #0
>
> So both usb mouse and kbd do not work.
>
> the pcap file for the mouse stalls here:
> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response

Maybe the driver gets something from the emulated HID device that it 
cannot handle and stops during init? Can you reproduce the same with OS X 
10.0 and try to correlate the events you see in pcap and trace with the 
driver source or find out how to enable and read the messages in the 
driver (unless these are stripped from the binary in Mac OS X but maybe 
there's something in the guest logs; ave you checked those?) In QEMU the 
usb-kbd and mouse are implemented in hw/usb/dev-hid.c but this file does 
not have any debuging or traces. You might try to add some printfs for 
testing.

> However, when I use the usb probe tool from the USB DDK, to probe the buses
> I see the host emit a get descriptor
>
> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE
> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE
> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request
> etc. and this time the mouse is recognised as HID device, the host starts
> polling it and mouse and kbd start to work.

It could be possible that the driver did not get to this point but once 
something else get's past that it recognises the device but I have no idea 
how this works and not even sure which OS you had this result with. Is 
this still 9.0.4? That's hard to debug because we don't know what its 
driver is doing.

Is there a Darwin, OpenDarwin or whatever was that called during the years 
iso that boots on this machine (also on the real one)? That should be 
fully open source and probably have the same drivers as Mac OS X so 
reproducing with that could give some more info or maybe its driver is 
more verbose about errors and has debugging. So you could try to find an 
early Darwin version that's about the same time as early OS X versions or 
look at the IOHIDFamily and try to find what part of it is running when 
you see the logs (as this driver is quite complex it may not be easy).

Regards,
BALATON Zoltan