Opened 14 years ago
Closed 14 years ago
#6233 closed defect (fixed)
PROBLEM: oops w/ bridge in 2.6.32.7
Reported by: | VBoxBridger | Owned by: | |
---|---|---|---|
Component: | network | Version: | VirtualBox 3.1.2 |
Keywords: | bridge | Cc: | |
Guest type: | Windows | Host type: | Linux |
Description
Hi
The problem has been reported thoroughly on the lkml list, reducing redundancy the link to the respective lkml report is posted here.
They say, it's virtualbox-business, however..
http://lkml.org/lkml/2010/2/8/331
I am sorry for the lack of vbox.log files. At the time the crash occurred I was ignorant that those files exist and I don't want to crash the machine right now.
Thank you.
Attachments (1)
Change History (6)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
To be more specific: I tried to reproduce this issue with a TAP device on Linux as described in the mail on Linux 2.6.32.9 but so far I had no success. The tap device does not have an IP and the VM is bound to the tap device. VM starts fine. Adding the TAP device to the bridge and starting the VM again, starts fine.
Can someone give us detailed instructions how to reproduce this oops?
comment:3 by , 14 years ago
priority: | blocker → major |
---|
Decreased priority as there is no feedback so far and we didn't find any related information from other users.
comment:4 by , 14 years ago
Hello,
Sorry for the huge delay. Busybusy.
Additionally, the situation seemed to be a one-timer. I've never been able to reproduce it, but this might be due to the fact I quickly switched to 2.6.33 kernels and using those everything is working.
Some flag would trigger the situation but it's yet unknown which configuration made it flinch.
In any case, some time _after_ switching to 2.6.33 I copied the Vbox.log for convenience. C.f. attachment.
Thank you for your fast response time.
by , 14 years ago
comment:5 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Thanks for the feedback. Let's close this ticket then. Reopen if you experience this problem again.
Any idea how to reproduce this oops? Could you attach a VBox.log file anyway? The VM session does not need to crash, just a VBox.log file of a session which would crash eventually so we can check your VM configuration. Thank you!