freenode/#mezzano - IRC Chatlog
Search
14:43:39
fitzsim
that should mean that hardware_rev_id follows directly after creator_revision in memory?
15:03:11
froggey
what's the value of configuration register for timers 0 & 1? offsets 0x100 and 0x120
15:26:01
froggey
doesn't look like qemu is doing anything with the HPET. it probably emulates a real PIT
15:50:47
froggey
can you get the full output of dmesg from linux when booted with the three nofoo options?
15:54:52
fitzsim
could this be some piece of hardware misconfigured on boot, that issues interrupts?
15:55:55
fitzsim
the i8259 is configured to receive interrupts, but it's receiving one that it doesn't know about?
15:56:48
fitzsim
I'm just wondering if I should open the laptop up and unplug the wireless card, for example
15:58:28
fitzsim
the interrupt controller (i8259) delivers an interrupt to the CPU, but it (the controller) forgot which interrupt needed to be delivered
16:05:42
froggey
in this case what's being reported as IRQ 7 isn't a real IRQ 7. the device attached to IRQ 7 didn't do anything and is uninvolved
16:07:19
froggey
in fact, at this point IRQ 7 is masked at the PIC, so even if there was a real IRQ 7 being generated the PIC wouldn't interrupt the CPU
16:09:36
froggey
what I think is happening is that one of the IRQ lines (probably IRQ 0, as it's the only one unmasked during our tests) is going high, causing the PIC to signal an interrut
16:10:25
froggey
when the CPU gets around to handle it, it asks the PIC which interrupt it is, and the PIC determines this by looking at the active interrupt lines (after masking, I think)
16:13:25
froggey
but I have no idea how this could be happening. this is how it all worked on the original IBM PC, but modern PCs only emulate this behaviour. they don't have real i8259 chips
18:07:32
fitzsim
when I comment out (when (zerop accept-count) (debug-print-line "No handler accepted IRQ " irq))
18:41:28
froggey
I wouldn't be surprised if Linux takes an IRQ via the PIC during boot for some reason
19:12:33
jmercouris
that will be quite a challenge I am sure, I had mezzano crash within a few minutes of launching for me :-D
19:15:46
froggey
you'll definitely want to build it yourself if you do. demo 4 is pretty outdated at this point
19:20:10
froggey
you'll want a machine with either legacy IDE disks (or a SATA controller in legacy mode) or AHCI-attached disks and a PS/2 keyboard & mouse
19:26:39
froggey
and I'm impressed, usually people run off when I tell them they'll have to write their own bootloader
19:29:02
fitzsim
I saw the message about the mouse being found, or getting E8 during the probe or something like that
19:29:29
froggey
linux is reporting that there's a PS/2 controller, so it should be fine to unconditionally probe it
19:29:37
fitzsim
(on the non-working ones, I think it "got something" during the probe, like E8 or something)
19:32:52
froggey
a simple way to debug that would be to add printfs to qemu's ps/2 emulation and log all port accesses, see where the two differ
19:33:35
fitzsim
I'll try a few times on target as well, to try to get a boot where the probe succeeds
19:33:54
fitzsim
again, I'm using a kboot-dumped-snapshot on target, since that's what's got me the farthest
19:35:22
fitzsim
I guess I could do a static network kboot QEMU setup that matches the DHCP settings
19:36:20
fitzsim
and then I wouldn't get the DHCP failure on startup, so it'd be a cleaner base on which to try to get the mouse working
19:36:48
fitzsim
however, you mentioned before that the restart won't affect the mouse pointer's operation
19:40:47
froggey
I'm not sure why you'd be getting a DHCP crash in the first place, it'd be nice to get a more complete backtrace
19:42:42
fitzsim
I assumed it was because the network driver isn't working yet, bubbling up to the DHCP operations getting nil values
20:45:45
fitzsim
I was actually surprised that a snapshot taken on kboot/QEMU worked as well as it does on target
21:46:53
froggey
you're welcome to fiddle with the PS/2 initialization sequence. I don't really want to touch it, it's not my favourite device
22:32:38
fitzsim
one idea I had was to write an FTDI driver, to enable a USB-to-serial console as early in boot as possible
22:41:08
froggey
another problem... your device has a UHCI controller, there are only drivers for OHCI & EHCI controllers
22:42:59
fitzsim
I've poked around the Linux USB internals and spec before; it's quite hairy as I remember