VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (2149 - 2151 of 16363)

Ticket Resolution Summary Owner Reporter
#10526 obsolete USB Memory Stick (SanDisk Cruzer 16GB) not recognized if VirtualBox Manager started micado
Description

Situation:
Host: Windows 64/7
Guest: no VM started
USB Stick: SanDisk Cruzer 16GB, FAT32

Description a)

  • Oracle VM VirtualBox Manager started (no VM started).
  • trying to connect USB SanDisk Cruzer 16 GB to host computer.

=> The stick is not recognized by Windows 7/64 but the connection sound appears. The volume letter is not present to the host system. The Windows Disk management utility does not show any information for minutes about any drive (tries continously to connect to the virtual disk management service). After a while the utility shows all information but the SanDisk Cruzer stated with "no Medium".

Trying to connect any other USB Memory Stick: no problem

Description b)

  • Oracle VM VirtualBox Manager not started (no VM started).
  • connect SanDisk Cruzer

=> no problem

=> no problem

It seems that the VM VirtualBox Manager disables the ability to proper connect the SanDisk Cruzer only. This happens to other VB releases too.

#10530 obsolete Installation of VirtualBox-4.1.14-77440-Win.exe fails when going from a prevous version. nighter
Description

Hi,

I use windows 7 x86_64 version. When started virtualbox I got an window that wanted me to update to 4.1.14 release of virtualbox.

I download and ran the msi package installation. Computer hangs under installation, and a rollback is performed and all files is removed. When try to install virtualbox again same issues happens agen. Is there a registry key that I need to remove to be able make an clean install now?

#10535 obsolete ehci_handle_endpoint_reclaimation panic in Solaris guest VM on VirtualBox 4.1.15 jayce
Description

Problem Description

I was trying to attach a Kingston USB memory stick into the guest VM (Solaris 11) when the guest VM panic'd.

Host O/S is MacOS 10.6.8 and running VirtualBox 4.1.15 after recent host O/S panic's upon guest O/S (Linux) reboots. VirtualBox was upgraded to 4.1.15 as per:

Ticket #9897 Synopsis: Frequent panics on Mac OS X when shutting down/starting VMs.

Extension pack is: Oracle VM VirtualBox Extension Pack 4.1.4r77440

... I didn't see a 4.1.15 extension pack.

Core Dump Analysis

The panic string is this:

> $C
ffffff0003ea7af0 ddi_get32+0x12()
ffffff0003ea7b30 ehci_handle_endpoint_reclaimation+0x91(ffffff0149379000)
ffffff0003ea7b70 ehci_intr+0x184(ffffff0149379000, 0)
ffffff0003ea7bc0 av_dispatch_autovect+0x74(13)
ffffff0003ea7c00 dispatch_hardint+0x33(13, 0)
ffffff0003e05a50 switch_sp_and_call+0x13()
ffffff0003e05aa0 do_interrupt+0xb6(ffffff0003e05ab0, 1)
ffffff0003e05ab0 _interrupt+0xba()
ffffff0003e05ba0 mach_cpu_idle+6()
ffffff0003e05bd0 cpu_idle+0xb2()
ffffff0003e05c00 idle+0x116()
ffffff0003e05c10 thread_start+8()

From msgbuf we see:

2012 May  9 09:07:13 ffffff0161aa3ac0 
WARNING: /pci@0,0/pci8086,265c@b (ehci0): Connecting device on port 1 failed
2012 May  9 09:08:07 ffffff0161ab3e00 
panic[cpu0]/thread=ffffff0003ea7c20: 
2012 May  9 09:08:07 ffffff0161aa3640 
BAD TRAP: type=e (#pf Page fault) rp=ffffff0003ea79c0 addr=ffffff023772af00
2012 May  9 09:08:07 ffffff015b93fa00 

2012 May  9 09:08:07 ffffff0167d940c0 sched: 
2012 May  9 09:08:07 ffffff0168024a00 #pf Page fault
2012 May  9 09:08:07 ffffff0161aa3100 Bad kernel fault at addr=0xffffff023772af00
2012 May  9 09:08:08 ffffff0168080200 
pid=0, pc=0xfffffffffb85ff32, sp=0xffffff0003ea7ab8, eflags=0x10246
2012 May  9 09:08:08 ffffff0161aa3e80 
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4: 6b8<xmme,fxsr,pge,pae,pse,de>
2012 May  9 09:08:08 ffffff0161aa3b80 cr2: ffffff023772af00
2012 May  9 09:08:08 ffffff0168080d40 cr3: 38a6000
2012 May  9 09:08:08 ffffff0168080ec0 cr8: c
2012 May  9 09:08:08 ffffff016807e840 
2012 May  9 09:08:08 ffffff0168024340 
        rdi: ffffff014bbe5bc0 rsi: ffffff023772af00 rdx:                c
2012 May  9 09:08:08 ffffff016807e300 
        rcx: ffffff014acfe300  r8:            2ceaf  r9:            2ceaf
2012 May  9 09:08:08 ffffff0161aa3400 
        rax: ffffff023772af00 rbx: ffffff014bb98800 rbp: ffffff0003ea7af0
2012 May  9 09:08:08 ffffff015c7959c0 
        r10: fffffffffbcb9ab0 r11: fffffffffb82d0bc r12: ffffff0149379000
2012 May  9 09:08:08 ffffff0161aa3d00 
        r13: ffffff023772af00 r14: ffffff014bb98854 r15: ffffff01466b4c30
2012 May  9 09:08:08 ffffff0161aa31c0 
        fsb:                0 gsb: fffffffffbc3ebc0  ds:               4b
2012 May  9 09:08:08 ffffff0168080800 
         es:               4b  fs:                0  gs:              1c3
2012 May  9 09:08:09 ffffff0161aa3340 
        trp:                e err:                0 rip: fffffffffb85ff32
2012 May  9 09:08:09 ffffff0168024580 
         cs:               30 rfl:            10246 rsp: ffffff0003ea7ab8
2012 May  9 09:08:09 ffffff0161ab3d40    ss:               38
2012 May  9 09:08:09 ffffff0161ab3c80 
2012 May  9 09:08:09 ffffff0161ab3bc0 ffffff0003ea78e0 unix:die+131 ()
2012 May  9 09:08:09 ffffff0161ab3b00 ffffff0003ea79b0 unix:trap+152b ()
2012 May  9 09:08:09 ffffff0161ab3a40 ffffff0003ea79c0 unix:cmntrap+e6 ()
2012 May  9 09:08:09 ffffff0161ab3980 ffffff0003ea7af0 unix:ddi_getl+12 ()
2012 May  9 09:08:09 ffffff0161ab38c0 
ffffff0003ea7b30 ehci:ehci_handle_endpoint_reclaimation+91 ()
2012 May  9 09:08:09 ffffff0161ab3800 ffffff0003ea7b70 ehci:ehci_intr+184 ()
2012 May  9 09:08:09 ffffff0161ab3740 ffffff0003ea7bc0 unix:av_dispatch_autovect+74 ()
2012 May  9 09:08:09 ffffff0161ab3680 ffffff0003ea7c00 unix:dispatch_hardint+33 ()
2012 May  9 09:08:09 ffffff0161ab35c0 ffffff0003e05a50 unix:switch_sp_and_call+13 ()
2012 May  9 09:08:09 ffffff0161ab3500 ffffff0003e05aa0 unix:do_interrupt+b6 ()
2012 May  9 09:08:10 ffffff0161ab3440 ffffff0003e05ab0 unix:cmnint+ba ()
2012 May  9 09:08:10 ffffff0161ab3380 ffffff0003e05ba0 unix:mach_cpu_idle+6 ()
2012 May  9 09:08:10 ffffff0161ab32c0 ffffff0003e05bd0 unix:cpu_idle+b2 ()
2012 May  9 09:08:10 ffffff0161ab3200 ffffff0003e05c00 unix:idle+116 ()
2012 May  9 09:08:10 ffffff0161ab3140 ffffff0003e05c10 unix:thread_start+8 ()
2012 May  9 09:08:10 ffffff0161ab3080 
2012 May  9 09:09:03 ffffff0161e85f00 
panic[cpu0]/thread=ffffff0003ea7c20: 
2012 May  9 09:09:03 ffffff0161e85e40 
BAD TRAP: type=e (#pf Page fault) rp=fffffffffbc879d0 addr=0 occurred in module "<unknown>" due to 
a NULL pointer dereference
2012 May  9 09:09:03 ffffff0161e85d80 
2012 May  9 09:09:03 ffffff0161e85cc0 syncing file systems...
2012 May  9 09:09:03 ffffff0161e85c00  done
2012 May  9 09:09:04 ffffff0161e85b40 
dumping to /dev/zvol/dsk/rpool/dump, offset 65536, content: kernel
2012 May  9 09:09:05 ffffff0161e85a80 NOTICE: ahci0: ahci_tran_reset_dport port 0 reset port

=> Interesting to see we couldn't attach the device on port 1

> *panic_thread::findstack -v
stack pointer for thread ffffff0003ea7c20: ffffff0003ea7730
  ffffff0003ea7870 0xffffff0003ea79c0()
  ffffff0003ea79c0 0x10000000e()
  ffffff0003ea7af0 ddi_get32+0x12()
  ffffff0003ea7b30 ehci_handle_endpoint_reclaimation+0x91(ffffff0149379000)
  ffffff0003ea7b70 ehci_intr+0x184(ffffff0149379000, 0)
  ffffff0003ea7bc0 av_dispatch_autovect+0x74(13)
  ffffff0003ea7c00 dispatch_hardint+0x33(13, 0)
  ffffff0003e05a50 switch_sp_and_call+0x13()
  ffffff0003e05aa0 do_interrupt+0xb6(ffffff0003e05ab0, 1)
  ffffff0003e05ab0 _interrupt+0xba()
  ffffff0003e05ba0 mach_cpu_idle+6()
  ffffff0003e05bd0 cpu_idle+0xb2()
  ffffff0003e05c00 idle+0x116()
  ffffff0003e05c10 thread_start+8()

=> Some confusion over whether we're running ddi_getl() or ddi_get32()

> ddi_get32::dis
ddi_get32:                      movl   0x68(%rdi),%edx
ddi_get32+3:                    cmpl   $0xa,%edx
ddi_get32+6:                    jne    +0x5     <ddi_get32+0xd>
ddi_get32+8:                    movq   %rsi,%rdx
ddi_get32+0xb:                  inl    (%dx)
ddi_get32+0xc:                  ret    
ddi_get32+0xd:                  cmpl   $0xc,%edx
ddi_get32+0x10:                 jne    +0x3     <ddi_get32+0x15>
ddi_get32+0x12:                 movl   (%rsi),%eax
ddi_get32+0x14:                 ret    
ddi_get32+0x15:                 jmp    *0x88(%rdi)

=> So we gell over at instruction offset 0x12 which was:

  movl   (%rsi),%eax

> ::regs
%rax = 0xffffff023772af00                 %r9  = 0x000000000002ceaf 
%rbx = 0xffffff014bb98800                 %r10 = 0xfffffffffbcb9ab0 lwpsleepq+0x3570
%rcx = 0xffffff014acfe300                 %r11 = 0xfffffffffb82d0bc dispatch_hardint
%rdx = 0x000000000000000c                 %r12 = 0xffffff0149379000 
%rsi = 0xffffff023772af00                 %r13 = 0xffffff023772af00 
%rdi = 0xffffff014bbe5bc0                 %r14 = 0xffffff014bb98854 
%r8  = 0x000000000002ceaf                 %r15 = 0xffffff01466b4c30 

%rip = 0xfffffffffb85ff32 ddi_get32+0x12
%rbp = 0xffffff0003ea7af0
%rsp = 0xffffff0003ea7ab8
%rflags = 0x00010246
  id=0 vip=0 vif=0 ac=0 vm=0 rf=1 nt=0 iopl=0x0
  status=<of,df,IF,tf,sf,ZF,af,PF,cf>

                        %cs = 0x0030    %ds = 0x004b    %es = 0x004b
%trapno = 0xe           %fs = 0x0000    %gs = 0x01c3
   %err = 0x0

The value of %rsi is 0xffffff023772af00, we're trying to dereference that and store
it into %eax

> 0xffffff023772af00/J
mdb: failed to read data from target: no mapping for address
0xffffff023772af00:             

And it sure looks bogus to me, plus it's the bogus address seen in the panic stack.
So this would have been passed upto us via ehci_handle_endpoint_reclaimation()
Looking at the illumos source code (which may be slightly different to the Solaris 11
source, which isn't publicly available):

    217 /*
    218  * ehci_handle_endpoint_reclamation:
    219  *
    220  * Reclamation of Host Controller (HC) Endpoint Descriptors (QH).
    221  */
    222 void
    223 ehci_handle_endpoint_reclaimation(ehci_state_t	*ehcip)
    224 {
    225 	usb_frame_number_t	current_frame_number;
    226 	usb_frame_number_t	endpoint_frame_number;
    227 	ehci_qh_t		*reclaim_qh;
    228 

> ffffff0149379000::print ehci_state_t
{
    ehci_dip = 0xffffff01466b4c30
    ehci_instance = 0
    ehci_hcdi_ops = 0xffffff0148486388
    ehci_cb_hdl = 0xffffff01466b4e90
    ehci_flags = 0x1e
    ehci_vendor_id = 0x8086
    ehci_device_id = 0x265c
    ehci_rev_id = 0
    ehci_caps_handle = 0xffffff014bbe5d00
    ehci_capsp = 0xffffff010272a000
    ehci_regsp = 0xffffff010272a020
    ehci_config_handle = 0xffffff014bbe5e40
    ehci_frame_interval = 0
    ehci_dma_attr = {
	.
	.
	.

    (truncated)

It's quite a long structure and I'm not 100% familiar with it, so not sure it's worth
reviewing it all.
Can I look at the device ID?

> 0xffffff01466b4c30::print struct dev_info  
{
    devi_parent = 0xffffff01466b8688
    devi_child = 0
    devi_sibling = 0xffffff01466b4960
    devi_binding_name = 0xffffff0146690b1c "pciclass,0c0320"
    devi_addr = 0xffffff014bbf3c00 "b"
	.
	.
	.
    devi_hw_prop_ptr = 0xffffff014b6b6418
    devi_node_name = 0xffffff0148832e48 "pci8086,265c"
    devi_compat_names = 0xffffff0146690b00 "pci8086,265c.0"


Hmmm, seems so.
How about the vendor id and device id?

0x8086	Intel Corporation

Device Id	Chip Description	Vendor Id	Vendor Name
0x265C		USB 2.0 EHCI Controller	0x8086		Intel Corporation

Well the structure itself looks reasonably sound from an initial review.
So where did we hand over to ddi_get32() ??

ehci_handle_endpoint_reclaimation+0x89: movq   %r12,%rsi
ehci_handle_endpoint_reclaimation+0x8c: call   -0x296d  <ehci_deallocate_qh>
ehci_handle_endpoint_reclaimation+0x91: movq   0x650(%r13),%r12

Interesting, the dis-assembly shows us calling ehci_deallocate_qh() and not ddi_get32()
Taking apart the stack:

> ffffff0003ea7730-0x60,100/nap
0xffffff0003ea76d0:             
0xffffff0003ea76d0:             0xd1            
0xffffff0003ea76d8:             0xd1            
0xffffff0003ea76e0:             0xe             
0xffffff0003ea76e8:             0xffffff0003ea77b0
0xffffff0003ea76f0:             kvseg           
0xffffff0003ea76f8:             0xffffff0003ea7778
0xffffff0003ea7700:             0xffffff0003ea7760
0xffffff0003ea7708:             avl_find+0x56   
0xffffff0003ea7710:             vpanic+0x22     
0xffffff0003ea7718:             0xfffffffffb957418
0xffffff0003ea7720:             0xffffff0003ea7830
0xffffff0003ea7728:             0xfffffffffb957698
0xffffff0003ea7730:             0xffffff0003ea7870
0xffffff0003ea7738:             0xffffff0003ea79c0
0xffffff0003ea7740:             0xffffff023772af00
0xffffff0003ea7748:             0xffffff0003ea7780

	.
	.
	.

0xffffff0003ea7a48:             0xffffff014bbe5d00
0xffffff0003ea7a50:             0xffffff0003ea7ac0
0xffffff0003ea7a58:             0x4b            
0xffffff0003ea7a60:             0x4b            
0xffffff0003ea7a68:             0               
0xffffff0003ea7a70:             0x1c3           
0xffffff0003ea7a78:             0xe             
0xffffff0003ea7a80:             0               
0xffffff0003ea7a88:             ddi_get32+0x12  
0xffffff0003ea7a90:             0x30            
0xffffff0003ea7a98:             0x10246         
0xffffff0003ea7aa0:             0xffffff0003ea7ab8
0xffffff0003ea7aa8:             0x38            
0xffffff0003ea7ab0:             0xffffff0003ea7af0
0xffffff0003ea7ab8:             ehci_deallocate_qh+0x57
0xffffff0003ea7ac0:             0xffffffffc002cea0
0xffffff0003ea7ac8:             0xffffff0149379000
0xffffff0003ea7ad0:             0xffffff014bb98800
0xffffff0003ea7ad8:             0x23a007        
0xffffff0003ea7ae0:             0xffffff014bb98800
0xffffff0003ea7ae8:             0xffffff0149379000
0xffffff0003ea7af0:             0xffffff0003ea7b30
0xffffff0003ea7af8:             ehci_handle_endpoint_reclaimation+0x91
0xffffff0003ea7b00:             0xffffff01466b4c30
0xffffff0003ea7b08:             0xffffff014b6d3298

... seems we do call ehci_deallocate_qh() before getting to ddi_get32()

> ehci_deallocate_qh::dis             
ehci_deallocate_qh:             pushq  %rbp
ehci_deallocate_qh+1:           movq   %rsp,%rbp
ehci_deallocate_qh+4:           subq   $0x10,%rsp
ehci_deallocate_qh+8:           movq   %rdi,-0x8(%rbp)
ehci_deallocate_qh+0xc:         movq   %rsi,-0x10(%rbp)
ehci_deallocate_qh+0x10:        pushq  %rbx
ehci_deallocate_qh+0x11:        pushq  %r12
ehci_deallocate_qh+0x13:        pushq  %r13
ehci_deallocate_qh+0x15:        subq   $0x8,%rsp
ehci_deallocate_qh+0x19:        movq   %rdi,%r12
ehci_deallocate_qh+0x1c:        movq   %rsi,%rbx
ehci_deallocate_qh+0x1f:        movq   0x128(%r12),%rdi
ehci_deallocate_qh+0x27:        leaq   0x10(%rbx),%rsi
ehci_deallocate_qh+0x2b:        call   +0x3ae00dc       <ddi_get32>
ehci_deallocate_qh+0x30:        andq   $0xffffffffffffffe0,%rax
ehci_deallocate_qh+0x34:        movq   %r12,%rdi
ehci_deallocate_qh+0x37:        movq   %rax,%rsi
ehci_deallocate_qh+0x3a:        call   +0x1671  <ehci_qtd_iommu_to_cpu>
ehci_deallocate_qh+0x3f:        movq   %rax,%r13
ehci_deallocate_qh+0x42:        testq  %r13,%r13
ehci_deallocate_qh+0x45:        je     +0x35    <ehci_deallocate_qh+0x7c>
ehci_deallocate_qh+0x47:        movq   0x160(%r12),%rdi
ehci_deallocate_qh+0x4f:        movq   %r13,%rsi
ehci_deallocate_qh+0x52:        call   +0x3ae00b5       <ddi_get32>
ehci_deallocate_qh+0x57:        movl   %eax,%esi
ehci_deallocate_qh+0x59:        movq   %r12,%rdi

... and the stack shows the call to ddi_get32() at ehci_deallocate_qh+0x57
It seems we're looking for an offset from %rbx to get our %rsi for the first
call to ddi_get32() then it's the value of %r13 being moved into %esi where
we then fall over.

In the source I see we're doing this:

   1330 	first_dummy_qtd = ehci_qtd_iommu_to_cpu(ehcip,
   1331 	    (Get_QH(old_qh->qh_next_qtd) & EHCI_QH_NEXT_QTD_PTR));

Where Get_QH() decodes as:

    870 #define	Get_QH(addr)		ddi_get32(ehcip->ehci_qh_pool_mem_handle, \
    871 					(uint32_t *)&addr)

... so this is where the ddi_get32() comes into play.
Alas there are a number of calls to Get_QH() in this ehci_deallocate_qh() function.

Summary

I suspect the failure to connect to the device port is causing some form of bogus/NULL address to appear in a structure here and we're tripping over it.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy