search

SerenityOS / serenity

The Serenity Operating System 🐞
https://serenityos.org
BSD 2-Clause "Simplified" License
29.87k stars 3.16k forks source link

Driver Issues #2162

Open supercomputer7 opened 4 years ago

supercomputer7 commented 4 years ago

From a test I conducted this week, I observed a problem with the HPET driver and the E1000 driver when trying to boot Serenity in VirtualBox. How to reproduce:

  1. Create a vdi image (https://docs.oracle.com/en/virtualization/virtualbox/6.1/user/vboxmanage-convertfromraw.html), after you created a grub image with build-image-grub.sh.
  2. To check if HPET is not working, create a new VM, import the image you created and in the settings of the machine, switch the Chipset to ICH9 instead of PIIX3. Run the machine, it should exit with an error. With the Chipset being set to PIIX3 there's no problem booting Serenity.
  3. To check if E1000 driver is not working, switch the chosen adapter type to be 82540EM. I booted with the same card type within Archlinux ISO, and I verified that this type corresponds to be PCI 8086:100e.

It is very possible that the QEMU variant of E1000 card is different from the one in VirtualBox (a different model in the E1000 cards' family).

Also, @jcs mentioned a problem with the HPET driver on his Thinkpad x61. Clearly, we have problems with both of these drivers.

supercomputer7 commented 4 years ago

From what I've observed, the problem with the HPET driver only halts the execution silently (no error, just a black screen), while the bug in the E1000 driver aborts the VM.

Also, I suspect that the problem with the HPET driver has to be with the minimum clock tick we have to use. On QEMU it's zero, in VirtualBox (according to the serial debug from it) it's 4096. https://github.com/SerenityOS/serenity/blob/85a3678b4fde901fde743c347a4847ef7e73ed20/Kernel/Time/HPET.cpp#L320-L321

supercomputer7 commented 4 years ago 
[Kernel]: x86: WP support enabled
[Kernel]: x86: PGE support enabled
[Kernel]: x86: NX support enabled
[Kernel]: x86: SMEP support not detected
[Kernel]: x86: SMAP support not detected
[Kernel]: x86: RDTSC support restricted
[Kernel]: x86: Using RDRAND for good randomness
[Kernel]: MM: boot_pdpt @ P0x00109000
[Kernel]: MM: boot_pd0 @ P0x0010a000
[Kernel]: MM: boot_pd3 @ P0x0010b000
[Kernel]: MM: Multiboot mmap: base_addr = 0x00000000, length = 0x0009fc00, type = 0x1
[Kernel]: MM: Multiboot mmap: base_addr = 0x0009fc00, length = 0x00000400, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0x000f0000, length = 0x00010000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0x00100000, length = 0x3fef0000, type = 0x1
[Kernel]: MM: Multiboot mmap: base_addr = 0x3fff0000, length = 0x00010000, type = 0x3
[Kernel]: MM: Multiboot mmap: base_addr = 0xfec00000, length = 0x00001000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfee00000, length = 0x00001000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfffc0000, length = 0x00040000, type = 0x2
[Kernel]: Installing Unhandled Handlers
[Kernel]: Early access to ACPI tables for interrupt setup
[Kernel]: ACPI: Probing EBDA, Segment 0x9fc0
[Kernel]: Interrupts: Switch to Legacy PIC mode
[Kernel]: PIC(i8259): cascading mode, vectors 0x50-0x5f
[Kernel]: Interrupts: Detected Dual i8259
[Kernel]: ACPI: Probing EBDA, Segment 0x9fc0
[Kernel]: ACPI: Using RSDP @ P0x000e0000
[Kernel]: ACPI: Main Description Table valid? true
[Kernel]: ACPI: Using XSDT, Enumerating tables @ P0x3fff0040
[Kernel]: ACPI: XSDT Revision 1, Total length - 76
[Kernel]: ACPI: Initializing Fixed ACPI data
[Kernel]: ACPI: Searching for the Fixed ACPI Data Table
[Kernel]: ACPI: Fixed ACPI data, Revision 4, Length 244 bytes
[Kernel]: ACPI: DSDT P0x3fff0530
[Kernel]: ACPI: Dynamic Parsing Enabled, Can parse AML
[Kernel]: PS2MouseDevice: Device detected
[Kernel]: PS2MouseDevice: Mouse wheel enabled!
[Kernel]: PS2MouseDevice: 5 buttons enabled!
[Kernel]: Starting SerenityOS...
[Kernel]: RTC: Year: 2020, month: 5, day: 9
[Kernel]: HPET @ P0x3fff02e0
[Kernel]: HPET: Minimum clock tick - 4096
[Kernel]: HPET: Timers count - 4
[Kernel]: HPET: frequency 1000000000 Hz (1000 MHz)
[Kernel]: HPET: Setting appropriate functions to timers.
[Kernel]: Time: Scanning for periodic timers
[Kernel]: Time: Scanning for non-periodic timers
[Kernel]: Reset timers
[Kernel]: VC: Switch to 0 (0xc02c4250)

The log output from VirtualBox. Not only that we have a minimum timer tick of 4096, the frequency is 1000 MHz, compared to 100 MHz in QEMU.

jcs commented 4 years ago

Here's the serial output booting on a Thinkpad X61 where it just spins forever in Scheduler::idle_loop:

[Kernel]: x86: SSE support enabled
[Kernel]: x86: WP support enabled
[Kernel]: x86: PGE support enabled
[Kernel]: x86: NX support enabled
[Kernel]: x86: SMEP support not detected
[Kernel]: x86: SMAP support not detected
[Kernel]: x86: RDTSC support restricted
[Kernel]: x86: No RDRAND support detected. Randomness will be shitty
[Kernel]: MM: boot_pdpt @ P0x00109000
[Kernel]: MM: boot_pd0 @ P0x0010a000
[Kernel]: MM: boot_pd3 @ P0x0010b000
[Kernel]: MM: Multiboot mmap: base_addr = 0x00000000, length = 0x0009d800, type = 0x1
[Kernel]: MM: Multiboot mmap: base_addr = 0x0009d800, length = 0x00002800, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0x000d2000, length = 0x00002000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0x000e0000, length = 0x00020000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0x00100000, length = 0xbf5b0000, type = 0x1
[Kernel]: MM: Multiboot mmap: base_addr = 0xbf6b0000, length = 0x0001c000, type = 0x3
[Kernel]: MM: Multiboot mmap: base_addr = 0xbf6cc000, length = 0x00034000, type = 0x4
[Kernel]: MM: Multiboot mmap: base_addr = 0xbf700000, length = 0x00900000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xf0000000, length = 0x04000000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfec00000, length = 0x00010000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfed00000, length = 0x00000400, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfed14000, length = 0x00006000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfed1c000, length = 0x00074000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xfee00000, length = 0x00001000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0xff000000, length = 0x01000000, type = 0x2
[Kernel]: MM: Multiboot mmap: base_addr = 0x00000000, length = 0x3c000000, type = 0x1
[Kernel]: Installing Unhandled Handlers
[Kernel]: Early access to ACPI tables for interrupt setup
[Kernel]: ACPI: Probing EBDA, Segment 0x9d80
[Kernel]: Interrupts: Switch to Legacy PIC mode
[Kernel]: PIC(i8259): cascading mode, vectors 0x50-0x5f
[Kernel]: Interrupts: Detected Dual i8259
[Kernel]: ACPI: Probing EBDA, Segment 0x9d80
[Kernel]: ACPI: Using RSDP @ P0x000f6950
[Kernel]: ACPI: Main Description Table valid? true
[Kernel]: ACPI: Using XSDT, Enumerating tables @ P0xbf6bd1b7
[Kernel]: ACPI: XSDT Revision 1, Total length - 164
[Kernel]: ACPI: Initializing Fixed ACPI data
[Kernel]: ACPI: Searching for the Fixed ACPI Data Table
[Kernel]: ACPI: Fixed ACPI data, Revision 3, Length 244 bytes
[Kernel]: ACPI: DSDT P0xbf6bd6db
[Kernel]: ACPI: Dynamic Parsing Enabled, Can parse AML
[Kernel]: PS2MouseDevice: Device detected
[Kernel]: PS2MouseDevice: No mouse wheel detected!
[Kernel]: Starting SerenityOS...
[Kernel]: RTC: Year: 2020, month: 5, day: 11
[Kernel]: HPET @ P0xbf6cbb60
[Kernel]: HPET: Minimum clock tick - 128
[Kernel]: HPET: Timers count - 3
[Kernel]: HPET: frequency 1000000000 Hz (1000 MHz)
[Kernel]: HPET: Setting appropriate functions to timers.
[Kernel]: Time: Scanning for periodic timers
[Kernel]: Time: Scanning for non-periodic timers
[Kernel]: Reset timers
[Kernel]: VC: Switch to 0 (0xc02c4250)
tomuta commented 4 years ago

Bochs is also failing with this:

[Kernel]: HPET @ P0x07ff0fc0
00691951632p[HPET  ] >>PANIC<< Unsupported HPET read at address 0x0000fed00100

Which means the registers aren't read in 4 or 8 byte sizes. Probably because of all the packed structures. Also, technically, the volatile keyword should to be used when reading/writing to these registers.

supercomputer7 commented 4 years ago

Bochs is also failing with this:

[Kernel]: HPET @ P0x07ff0fc0
00691951632p[HPET  ] >>PANIC<< Unsupported HPET read at address 0x0000fed00100

Which means the registers aren't read in 4 or 8 byte sizes. Probably because of all the packed structures. Also, technically, the volatile keyword should to be used when reading/writing to these registers.

Well, the removal of volatile keyword recently didn't help, I'm glad you fixed that :) Anyway, I'm suggesting to look at what actually happens with the HPET code when we try to use periodic timers. Maybe, we could force the HPET code to not to use periodic timers at all (with the appropriate kernel boot argument, hpet=nonperiodic) and see what's happening in VirtualBox. If we fix the problem with VirtualBox, we might've figured the problem for @jcs machine too :)