Re: [SeaBIOS] Graphics card pass-through working with two pass pci-initialization
On 2011-05-26 23:19, André Weidemann wrote: On 27.05.2011 21:50, André Weidemann wrote: On 27.05.2011 21:40, André Weidemann wrote: If I am not mistaken then the graphics card needs 2 bars, one with 256MB and one with 128K. The sound card then needs 1 bar with 16K of PCI memory. How big is the PCI memory with seabios? Is there really not enough space to squeeze in those extra 16K? I obviously forgot to add up the other memory that is used... 32MB go to the standard VGA card. Running qemu-kvm with -vga none did not work, so I left it in. And the e1000 NIC needs another 128K. I'll see if I can get rid of the standard VGA card. I guess that should free enough memory for the sound card. I did some more testing by starting the VM with the paramter -vga none and passed both the VGA card and the sound card to it. With this option the VM did not boot, Where did it hang, ie. what IP was reported by info cpus? but I could use the monitor to take a look at the PCI bar assignment. Even though the memory for the standard VGA card is freed, the soundcard does not seem to get the 16K bar it needs. info pci for the sound card still looks like this: Bus 0, device 5, function 0: Audio controller: PCI device 8086:3a3e IRQ 10. BAR0: 32 bit memory at 0x [0x3ffe]. Does anyone have an idea why there was no bar assigned? Maybe Gerd's patches aren't sufficient and you still need to change BUILD_MAX_HIGHMEM. See the hacks in http://git.kiszka.org/?p=seabios.git;a=shortlog;h=refs/heads/vga-assign, either replacing Gerd's patches or combined with them (I haven't checked if the latter makes sense). Can the kernel be too old? (2.6.35.7.) It would be good to check the latest kvm kernel to see if that oops is still present. In that case, please try to collect the backtrace via serial console, hopefully complete then. We may have an resource cleanup issue there. Just to test whether or not two devices can be assigned, I passed through 2 sound cards. (There is an onbard sound card and the Radeon has one too). Each sound card gets its bar assigned as you can see: Bus 0, device 4, function 0: Audio controller: PCI device 1002:aa80 IRQ 10. BAR0: 32 bit memory at 0xfebf [0xfebf3fff]. id Bus 0, device 5, function 0: Audio controller: PCI device 8086:3a3e IRQ 10. BAR0: 32 bit memory at 0xfebf4000 [0xfebf7fff]. but the sound cards do not show inside the Windows VM. With both sound cards still passed to the VM I then booted an Ubuntu 10.10 image instead of Windows7. It got as far as starting gdm, but then the entire host and VM became very slow. The last message I saw on the terminal before gdm started was this: [ 23.030016 ] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f [ 29.290017 ] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x200f Likely some IRQ issue. Please check if latest qemu-kvm.git + http://thread.gmane.org/gmane.comp.emulators.qemu/102540 makes any difference. Jan signature.asc Description: OpenPGP digital signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
On Thu, May 26, 2011 at 11:39:51PM -0500, Marshall Buschman wrote: Hello: I was instructed to send mail to you by Carebear from #coreboot. I have some issues to report based on the Golden Image I received from him, which was created for the ASRock E350M1. The first is with hard drive detection - there is a reliability problem here - only once out of every 5 to 12 times the machine posts will it detect the hard drive successfully. The hard drive is a Corsair F120 SSD. I do have another, smaller 16GB Kingston SSD I can test with. Thanks for the report. Can you send the seabios log - see the directions at: http://www.coreboot.org/SeaBIOS#Trouble_reporting A log of a successful case and a failure case would be helpful. The second problem is that on booting, GRUB (I do not have the version on hand -- whatever gentoo is shipping as stable at this point) behaves very, very strangely with my USB keyboard. I should point out that it does not work 100% correctly on another machine under Fedora's grub, so this may bear further testing with another keyboard. The following video demonstrates the issue - this is very reproduceable (I gave exactly this input on the keyboard: down, e, hello there, test, one, two, three, and only once. You can hear the clicking of my keyboard.) http://www.lucidmachines.com/coreboot/weird-usb-in-grub.avi Okay - that's really odd. Can you change the dprintf in usb-hid.c:handle_key() to use a value of 8 instead of 9 and send the log as above? (If you need help with building SeaBIOS, let me know.) Also, if you can use tools/readserial.py to capture the log (so that we can see the relative timestamps), that would also help. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Issues with ASRock E350M1
On Fri, May 27, 2011 at 02:11:14AM -0500, Scott Duplichan wrote:
I also have USB keyboard problems, but my problem is different. For
each key I press, it repeats a couple dozen times. I solve the problem
by adding a 'break' to usb-hid.c:
for (;;) {
struct keyevent data;
int ret = usb_poll_intr(pipe, data);
if (ret)
break;
handle_key(data);
break; ==
Can you generate and send a log with debug level set to 8 and the
dprintf in usb-hid.c:handle_key() changed to 8? Getting timestamps on
the log (as with tools/readserial.py) would also help.
With this change, I am able to type well enough to get windbg started,
which is all I needed at the time. But typing is very sluggish. I
believe the sluggishness is due to use of 8254 periodic interrupt
polling to service the keyboard.
Yeah - since the loop was disabled there's no longer a queue on USB
key events. This means any keys pressed faster than 55ms are dropped.
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] Graphics card pass-through working with two pass pci-initialization
Hi, On 28.05.2011 10:18, Jan Kiszka wrote: On 2011-05-26 23:19, André Weidemann wrote: On 27.05.2011 21:50, André Weidemann wrote: On 27.05.2011 21:40, André Weidemann wrote: If I am not mistaken then the graphics card needs 2 bars, one with 256MB and one with 128K. The sound card then needs 1 bar with 16K of PCI memory. How big is the PCI memory with seabios? Is there really not enough space to squeeze in those extra 16K? I obviously forgot to add up the other memory that is used... 32MB go to the standard VGA card. Running qemu-kvm with -vga none did not work, so I left it in. And the e1000 NIC needs another 128K. I'll see if I can get rid of the standard VGA card. I guess that should free enough memory for the sound card. I did some more testing by starting the VM with the paramter -vga none and passed both the VGA card and the sound card to it. With this option the VM did not boot, Where did it hang, ie. what IP was reported by info cpus? I added some debug options and found out, that the VM hangs when trying to initialize the graphics card ROM. See here: http://pastebin.com/S9a8uQfU And some additional info here: http://pastebin.com/AC4rw8Ek (info cpus/registers) http://pastebin.com/yYkn8jL2 (info pci) but I could use the monitor to take a look at the PCI bar assignment. Even though the memory for the standard VGA card is freed, the soundcard does not seem to get the 16K bar it needs. info pci for the sound card still looks like this: Bus 0, device 5, function 0: Audio controller: PCI device 8086:3a3e IRQ 10. BAR0: 32 bit memory at 0x [0x3ffe]. Does anyone have an idea why there was no bar assigned? Maybe Gerd's patches aren't sufficient and you still need to change BUILD_MAX_HIGHMEM. See the hacks in http://git.kiszka.org/?p=seabios.git;a=shortlog;h=refs/heads/vga-assign, either replacing Gerd's patches or combined with them (I haven't checked if the latter makes sense). I do not have access to the machine until tomorrow. I'm curious to see if extending the PCI memory window will cure the problem. Can the kernel be too old? (2.6.35.7.) It would be good to check the latest kvm kernel to see if that oops is still present. In that case, please try to collect the backtrace via serial console, hopefully complete then. We may have an resource cleanup issue there. I will see if I can upgrade to the latest kernel tomorrow. Just to test whether or not two devices can be assigned, I passed through 2 sound cards. (There is an onbard sound card and the Radeon has one too). Each sound card gets its bar assigned as you can see: Bus 0, device 4, function 0: Audio controller: PCI device 1002:aa80 IRQ 10. BAR0: 32 bit memory at 0xfebf [0xfebf3fff]. id Bus 0, device 5, function 0: Audio controller: PCI device 8086:3a3e IRQ 10. BAR0: 32 bit memory at 0xfebf4000 [0xfebf7fff]. but the sound cards do not show inside the Windows VM. With both sound cards still passed to the VM I then booted an Ubuntu 10.10 image instead of Windows7. It got as far as starting gdm, but then the entire host and VM became very slow. The last message I saw on the terminal before gdm started was this: [ 23.030016 ] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x000f [ 29.290017 ] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x200f Likely some IRQ issue. Please check if latest qemu-kvm.git + http://thread.gmane.org/gmane.comp.emulators.qemu/102540 makes any difference. See above comments. I will try this tomorrow. Regards André ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
