Custom Query (16363 matches)
Results (1729 - 1731 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #3067 | fixed | VBoxSDL's fixedmode commad line parameter seems to be wrongly handled | ||
| Description |
If I start VBoxSDL with the following command line I get a 768x32 window. $ VBoxSDL -fixedmode 1024 768 32 Looking at the source code, src/VBox/Frontends/VBoxSDL/VBoxSDL.cpp seems to be inconsistent with src/VBox/Frontends/VBoxSDL/Framebuffer.{cpp,h}. VBoxSDLFB's constructors takes 7 parameters, while VBosSDL.cpp passes only six of them, `bool fKeepHostRes' seems to be ignored by mistake. The fix should be trivial. A quick'n'dirty solution patch is attached. |
|||
| #3070 | fixed | BUG: soft lockup - CPU#0 stuck for 10s! | ||
| Description |
Host is 32-bit Solaris 10 (SunOS x3 5.10 Generic_138889-02 i86pc i386 i86pc), guest is CentOS 5.2 (Linux 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 12:03:43 EST 2008). Guest has divider=10 kernel parameter to keep the host CPU load low. Kernel oops in guest: BUG: soft lockup - CPU#0 stuck for 10s! [kjournald:1010] Pid: 1010, comm: kjournald EIP: 0060:[<c05c5a9a>] CPU: 0 EIP is at rt_run_flush+0x47/0x8f EFLAGS: 00000246 Tainted: G (2.6.18-92.1.22.el5 #1) EAX: c072c000 EBX: 00000698 ECX: 00000000 EDX: c072c000 ESI: 00000000 EDI: 000061a6 EBP: 00018698 DS: 007b ES: 007b CR0: 8005003b CR2: cc240100 CR3: 1d8f1000 CR4: 000006d0 [<c05c7cce>] rt_secret_rebuild+0x0/0x21 [<c05c7cdc>] rt_secret_rebuild+0xe/0x21 [<c042dbcf>] run_timer_softirq+0xfb/0x151 [<c042a712>] __do_softirq+0x5a/0xbb [<c0407461>] do_softirq+0x52/0x9d [<c04059bf>] apic_timer_interrupt+0x1f/0x24 [<c0609c88>] _spin_unlock_irqrestore+0x8/0x9 [<c04e0ec6>] cfq_set_request+0x1ed/0x31f [<c045816c>] mempool_alloc+0x28/0xc9 [<c04e0cd9>] cfq_set_request+0x0/0x31f [<c04d60c9>] elv_set_request+0x18/0x27 [<c04d8793>] get_request+0x167/0x2e7 [<c04d8e59>] get_request_wait+0x19/0x12f [<c04da6da>] __make_request+0x2bb/0x366 [<c04059bf>] apic_timer_interrupt+0x1f/0x24 [<c04d8139>] generic_make_request+0x248/0x258 [<c045816c>] mempool_alloc+0x28/0xc9 [<c04d9de5>] submit_bio+0xbf/0xc5 [<c04757bf>] bio_alloc_bioset+0x9b/0xf3 [<c0472879>] submit_bh+0xe8/0x106 [<f884be43>] journal_do_submit_data+0x23/0x2b [jbd] [<f884c329>] journal_commit_transaction+0x4c9/0xf18 [jbd] [<c042d992>] try_to_del_timer_sync+0x44/0x4a [<c042d992>] try_to_del_timer_sync+0x44/0x4a [<f884fc01>] kjournald+0xa1/0x1c2 [jbd] [<c0435f3b>] autoremove_wake_function+0x0/0x2d [<f884fb60>] kjournald+0x0/0x1c2 [jbd] [<c0435e79>] kthread+0xc0/0xeb [<c0435db9>] kthread+0x0/0xeb [<c0405c3b>] kernel_thread_helper+0x7/0x10 ======================= |
|||
| #3071 | fixed | Guest additions CDROM image not automatically mounted | ||
| Description |
This has been observed on a 32-bit XP host and 64-bit OpenSolaris host. Guest additions under 2.1 sometimes will not attach/mount on guests for which I had previously had 100% success. In experiments I have noticed that this problem is not limited to additions, but to any ISO image. When this DOES happen, it is when another ISO has first been attached. If I unmount or eject it from the guest, then unmount it from the VB screen's Devices menu, that last step will not always succeed as it did with previous VB versions, even though the guest no longer thinks it's there. There seems no pattern I can discover other than this. I have noticed that the Virtual Media Manager thinks the ISO image in question is attached to a guest, even though that guest can no longer see it. Every ISO image I subsequently attempt to mount to a running guest shows up as attached to that guest in the Media Manager. Using the Devices menu, I am unable to unmount or release the ISO image, even though the mount was never successful from the guest's perspective. If I shut down the OS, the media manager still thinks the ISO is attached and I still cannot detach the image from the guest that has been shut down. If I shut down all guests, stop VB, then restart VB, then all ISO images are again properly attached or detached. Restarting VB is all I need to do to "fix" the problem, but this is new with 2.1. I have been unable to reproduce the problem at will, but have seen reports of people having intermittent problems installing the additions in VB 2.1. I have now observed this problem with the following guests: 64-bit Ubuntu, 64-bit OpenSolaris, 32-bit and 64-bit Vista. |
|||

