On 20/09/2013 15:08, Guy Helmer wrote:
> On Sep 19, 2013, at 11:25 AM, Guy Helmer wrote:
>
>> Normally I build VMware ESXi servers with enterprise-class WD SATA drives
>> and I/O performance in FreeBSD VMs on the servers is fine.
>> Whenever I build a VMware ESXi serve
I'm experimenting with a new way to track -CURRENT
by using Crochet to build successive VMWare VM images.
Each new VM can then be used to build the next one.
I'm specifically using this with VMWare Fusion on Mac OS,
but it should work with Linux or FreeBSD VMWare hosts
as well.
Here&#x
On Sep 19, 2013, at 11:25 AM, Guy Helmer wrote:
> Normally I build VMware ESXi servers with enterprise-class WD SATA drives and
> I/O performance in FreeBSD VMs on the servers is fine.
> Whenever I build a VMware ESXi server with a RAID controller, IO performance
> is awful in
Normally I build VMware ESXi servers with enterprise-class WD SATA drives and
I/O performance in FreeBSD VMs on the servers is fine.
Whenever I build a VMware ESXi server with a RAID controller, IO performance is
awful in FreeBSD VMs. I've previously seen this effect with VMware ESXi
on 24/04/2013 02:03 Dimitry Andric said the following:
> Indeed, the DS segment was incorrect, the GDT should be loaded from the
> CS segment instead.
Very good catch! Indeed the segments at this point were set up for "user" data
while the "supervisor" data is needed.
Thank you!
--
Andriy Gapo
rian Chadd wrote:
> Hah, nice catch! You guys rock.
>
> Scratch one less weird shit thing with FreeBSD on VMWARE.
>
>
>
> Adrian
>
> On 23 April 2013 16:03, Dimitry Andric wrote:
>>
>> On Apr 24, 2013, at 00:03, Dimitry Andric wrote:
>>
>>&g
Hah, nice catch! You guys rock.
Scratch one less weird shit thing with FreeBSD on VMWARE.
Adrian
On 23 April 2013 16:03, Dimitry Andric wrote:
>
> On Apr 24, 2013, at 00:03, Dimitry Andric wrote:
>
>> On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
>>> on 23/04/2013
0x9a00 0x
>>
>> Nevertheless doing stepi leads to exactly the same triple fault.
>
>
> Is it because lgdt loads the GDT from the ds segment, and ds is now 33,
> not 0 (or equal to CS, I'm not sure which is correct here)?
Indeed, the DS segment was incorrect,
On Apr 23, 2013, at 23:46, Andriy Gapon wrote:
> on 23/04/2013 19:31 John Baldwin said the following:
>> On Tuesday, April 23, 2013 12:09:28 pm Andriy Gapon wrote:
...
>>> 0x90e8: lgdtl 0x95d0
>>> 0x90ef: ljmpw $0x18,$0x90f5
>>>
>>> Triple fault
>>> CPU Reset (CPU 0)
>
er, but it does not seem to ever make it there,
>>> at least not to the jump to f000:fff0. Maybe VMware intercepts the
>>> switching back to real mode in the previous part, and dies on that, I am
>>> not sure. It is of course rather tricky to print off any debug messages
On Tuesday, April 23, 2013 1:32:34 pm Andriy Gapon wrote:
> on 23/04/2013 19:09 Andriy Gapon said the following:
> >
> > IN:
> > 0x90d2: cli
> > 0x90d3: mov$0x1800,%esp
> > 0x90d8: mov%cr0,%eax
> > 0x90db: and$0x7f
t to the jump to f000:fff0. Maybe VMware intercepts the
> > switching back to real mode in the previous part, and dies on that, I am
> > not sure. It is of course rather tricky to print off any debug messages
> > at that point. :-)
>
> For the inquisitive minds here how last
on 23/04/2013 19:09 Andriy Gapon said the following:
>
> IN:
> 0x90d2: cli
> 0x90d3: mov$0x1800,%esp
> 0x90d8: mov%cr0,%eax
> 0x90db: and$0x7fff,%eax
> 0x90e0: mov%eax,%cr0
>
>
>
on 23/04/2013 17:36 Dimitry Andric said the following:
> I have tried to ascertain it actually arrives at this code when
> rebooting from the loader, but it does not seem to ever make it there,
> at least not to the jump to f000:fff0. Maybe VMware intercepts the
> switching back to
r 23, 2013 at 4:36 PM, Dimitry Andric wrote:
> On Apr 22, 2013, at 17:29, John Baldwin wrote:
> > On Saturday, April 20, 2013 7:51:06 am Joshua Isom wrote:
> >> On 4/19/2013 8:48 PM, Jeremy Chadwick wrote:
> >>> I'm happy to open up a ticket with VMware about
On Apr 22, 2013, at 17:29, John Baldwin wrote:
> On Saturday, April 20, 2013 7:51:06 am Joshua Isom wrote:
>> On 4/19/2013 8:48 PM, Jeremy Chadwick wrote:
>>> I'm happy to open up a ticket with VMware about the issue as I'm a
>>> customer, but I find it a li
On Saturday, April 20, 2013 7:51:06 am Joshua Isom wrote:
> On 4/19/2013 8:48 PM, Jeremy Chadwick wrote:
> > I'm happy to open up a ticket with VMware about the issue as I'm a
> > customer, but I find it a little odd that other operating systems do not
> > exhibit
On 4/19/2013 8:48 PM, Jeremy Chadwick wrote:
I'm happy to open up a ticket with VMware about the issue as I'm a
customer, but I find it a little odd that other operating systems do not
exhibit this problem, including another BSD. Ones which reboot just
fine from their bootloaders
On Fri, Apr 19, 2013 at 05:49:34PM -0500, Joshua Isom wrote:
> Basically, the loader finds a simple safe way to reboot that's
> worked since the 286, and VMWare doesn't like it. It's called a
> triple fault. FreeBSD and Linux even use it to reboot as a fail
>
Basically, the loader finds a simple safe way to reboot that's worked
since the 286, and VMWare doesn't like it. It's called a triple fault.
FreeBSD and Linux even use it to reboot as a fail safe. Read
sys/i386/i386/vm_machdep.c and cpu_reset_real to see how FreeBSD handles
(Please keep me CC'd as I'm not subscribed to -hackers)
When running FreeBSD under VMware Workstation (I'm using 9.0.1, but this
issue has existed for many years now, I remember it occurring on
Workstation 6.x), the following is reproducible:
1. Power on + boot FreeBSD VM
2.
hi,
as soon as I 'initialize' a virtual disk via gpart, even if nothing
is mounted, the pxeboot adds around 60s delay to show the boot menu,
- I don't know if the delay is in boot or pxeboot.
if I destroy the geom, the the boot menu appears inmediately.
any insight?
danny
__
On Mon, 01 Oct 2012 15:00:40 -0500, wrote:
Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): WRITE(10). CDB: 2a 0 5
ee 60 16 0 1 0 0
Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): CAM status: SCSI
Status Error
Sep 21 02:14:55 backups kernel: (da1:mpt0:0:1:0): SCSI status: Busy
Sep 21 0
On Wednesday, June 6, 2012 8:36:04 PM UTC-5, Mark Felder wrote:
> Hi guys I'm excitedly posting this from my phone. Good news for you guys, bad
> news for us -- we were building HA storage on vmware for a client and can now
> replicate the crash on demand. I'll be posting deta
On Thursday, September 13, 2012 12:14:49 pm Mark Felder wrote:
> On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon wrote:
>
> > Just curious - does VMWare provide a remote debugger support (gdb stub)?
>
> I'm not aware of one. What I have been able to successfully d
you retest 9 with the following
>> sysctlkern.timecounter.hardware=Acpi-fast
>
> Yes, I'll attempt that as soon as possible. We're under a tight deadline to
> migrate critical resources off of VMWare now so I don't know how soon I can
> test.
>
>> Also in esxi what setup opt
tight deadline
to migrate critical resources off of VMWare now so I don't know how soon I
can test.
Also in esxi what setup options do you have for the vm's ?
I'm not sure what ones I have off the top of my head, but VMWare support
has previously poured over ever o
On Sep 14, 2012, at 8:48 AM, Mark Felder wrote:
> Hi Mark,
>
> Here's the output of our VMs running on ESXi 4.1u1
>
> FreeBSD 7.4:
> # sysctl kern.timecounter.choice
> kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100)
> # sysctl kern.timecounter.hardware
> kern.timecou
Hi Mark,
Here's the output of our VMs running on ESXi 4.1u1
FreeBSD 7.4:
# sysctl kern.timecounter.choice
kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100)
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: ACPI-safe
FreeBSD 8.3:
# sysctl kern.timecounter.choi
hpet over acpi-fast/safe . I am not sure why or when thus was
done; or if this is a side effect of another change. Interestingly
centos/rhel/suse has made similar changes and VMware has odd issues with them
as well.
Can you boot up a 7 environment and get us the value sysctl kern.timecounter .
Changing timer source has not been tested. It doesn't crash in 7.x, so did
something timer related change in 8.x?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "fr
t.com/2007/04/debugging-linux-kernels-with.html
>>>
>>> -Kurt
>>
>> Interesting -- it looks like that's an option on ESX as well. The only
>> question
>> is: what do I do with that? It's going to give me the debugging entire VM,
>> not
>> the k
- it looks like that's an option on ESX as well. The only
> question
> is: what do I do with that? It's going to give me the debugging entire VM, not
> the kernel inside. Without being a VMWare developer I imagine its data will
> be a
> bit useless :-(
No, gdb stub is for d
oing to give me the debugging
entire VM, not the kernel inside. Without being a VMWare developer I
imagine its data will be a bit useless :-(
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To un
On Thu, Sep 13, 2012 at 11:14:49AM -0500, Mark Felder wrote:
> On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon wrote:
>
> > Just curious - does VMWare provide a remote debugger support (gdb stub)?
>
> I'm not aware of one. What I have been able to successfully do is brea
On Thu, 13 Sep 2012 10:11:28 -0500, Andriy Gapon wrote:
Just curious - does VMWare provide a remote debugger support (gdb stub)?
I'm not aware of one. What I have been able to successfully do is break
into the debugger during the hang but the info I've posted so far has not
bee
it back up.
>
> And for the record we can't reproduce this crash in Xen...
Just curious - does VMWare provide a remote debugger support (gdb stub)?
--
Andriy Gapon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/
On Wed, 12 Sep 2012 14:20:26 -0500, John Baldwin wrote:
Are you still seeing this, and if so can you get a crashdump? Also, I'm
curious if you only see this with SUJ or if plain UFS+SU works fine?
The crash on demand right now is producable on 8.x and 9.x, so SUJ isn't a
requirement. Also,
On Wednesday, June 06, 2012 9:34:02 pm Mark Felder wrote:
> Hi guys I'm excitedly posting this from my phone. Good news for you guys,
bad news for us -- we were building HA storage on vmware for a client and can
now replicate the crash on demand. I'll be posting details when I get h
Hi guys I'm excitedly posting this from my phone. Good news for you guys, bad
news for us -- we were building HA storage on vmware for a client and can now
replicate the crash on demand. I'll be posting details when I get home to my PC
tonight, but this hopefully is enough to rep
On Thursday, May 31, 2012 11:11:11 am Mark Felder wrote:
> So when this hang happens, there never is a real panic. It just sits in a
> state which I describe as like being in a deadlock. How would I go about
> getting a crashdump if it never panics? Is it possible to do the dump over
> a netw
So when this hang happens, there never is a real panic. It just sits in a
state which I describe as like being in a deadlock. How would I go about
getting a crashdump if it never panics? Is it possible to do the dump over
a network or something because I don't believe it can write through the
On Wednesday, May 30, 2012 3:56:02 pm Mark Felder wrote:
> On Wed, 30 May 2012 12:17:07 -0500, John Baldwin wrote:
>
> >
> > Humm, can you test it with 2 CPUs?
> >
>
> We primarily only run with 1 CPU. We have seen it crash on multiple CPU
> VMs. Also, Dane Foster appeared to have been using m
On Wed, 30 May 2012 12:17:07 -0500, John Baldwin wrote:
Humm, can you test it with 2 CPUs?
We primarily only run with 1 CPU. We have seen it crash on multiple CPU
VMs. Also, Dane Foster appeared to have been using multiple CPUs in his
video transcoding VMs.
Unfortunately I can't give
On Wednesday, May 30, 2012 12:07:50 pm Mark Felder wrote:
> On Wed, 30 May 2012 10:06:13 -0500, John Baldwin wrote:
>
> >
> > Do you only have one CPU in this VM? If not, do you know which threads
> > the other CPUs were running (e.g. do you have ps7.png, etc.)?
>
> correct, only one CPU in the
On Wed, 30 May 2012 10:06:13 -0500, John Baldwin wrote:
Do you only have one CPU in this VM? If not, do you know which threads
the other CPUs were running (e.g. do you have ps7.png, etc.)?
correct, only one CPU in the VM
___
freebsd-hackers@freebs
>
> I'd be glad to post a PR and assist in helping to get it permanently
> fixed. I certainly don't want this data to get lost and honestly our
> business uses FreeBSD on VMWare so much that we really need a permanent
> fix as much as anyone else :-)
>
> The re
Hi,
You guys now absolutely, positively have enough information for a PR.
It's still not clear whether it's a device/interrupt layer issue in
FreeBSD, or whether vmware is doing something wrong with how it
implements shared interrupts, or a bit of both..
Adrian
On 24 May 2012 1
be glad to post a PR and assist in helping to get it permanently fixed. I
> certainly don't want this data to get lost and honestly our business uses
> FreeBSD on VMWare so much that we really need a permanent fix as much as
> anyone else :-)
>
> The reason I've hesita
#x27;d be glad to post a PR and assist in helping to get it permanently fixed. I
> certainly don't want this data to get lost and honestly our business uses
> FreeBSD on VMWare so much that we really need a permanent fix as much as
> anyone else :-)
>
> The reason I'
to get lost and honestly our
business uses FreeBSD on VMWare so much that we really need a permanent
fix as much as anyone else :-)
The reason I've hesitated to post a PR so far is that I didn't have any
truly useful or concrete evidence of where the problem lies. After Dane
Fos
iate it if you and the other people who can reproduce
this could work with the em/mpt driver people and root cause why this
is going. I think having FreeBSD on vmware work stable out of the box
without these kinds of tweaks is the way to go - who knows what else
is lurking here..
I'm very v
On Mon, 21 May 2012 12:01:19 -0500, Andrew Boyer
wrote:
You could try switching mpt to MSI. MSI interrupts are never shared.
Add this to /boot/device.hints:
hint.mpt.0.msi_enable="1"
Currently implementing this on the known crashy servers. I've been looking
around and all of our VM
On May 21, 2012, at 12:41 PM, Mark Felder wrote:
> OK guys I've been talking with another user who can recreate this crash and
> the last bit of information we've learned seems to be leaning towards
> interrupts/IRQ issues like someone (bz@ perhaps?) suggested.
>
> I'm still trying to test thi
OK guys I've been talking with another user who can recreate this crash
and the last bit of information we've learned seems to be leaning towards
interrupts/IRQ issues like someone (bz@ perhaps?) suggested.
I'm still trying to test this myself, but the other user was able to
recreate my cra
build of ESXi in the past that had a
different setting for video memory when you selected FreeBSD?
Another change people might want to do as suggested to us by VMWare
Support:
- Change CPU/MMU Virtualization to the bottom option -- "Use Intel
VTx/AMD-V for instruction set virtualizatio
On Tue, 10 Apr 2012 03:04:10 -0500, Daniel Braniss
wrote:
no, I can't recreate it, could you?
We haven't seen this problem since FreeBSD 6.x. I can't recall how
reproducible it was.
___
freebsd-hackers@freebsd.org mailing list
http://lists.free
> On Sun, 08 Apr 2012 02:11:25 -0500, Daniel Braniss
> wrote:
>
> > Hi All
> > There was some mention before that time stops under vmware, and now it's
> > happened
> > to me :-)
> >
> > the clock stopped now, the system is responsive, but eg
On Sun, 08 Apr 2012 02:11:25 -0500, Daniel Braniss
wrote:
Hi All
There was some mention before that time stops under vmware, and now it's
happened
to me :-)
the clock stopped now, the system is responsive, but eg
sleep 1
never finishes.
Is there a solution?
btw, I'm r
Hi All
There was some mention before that time stops under vmware, and now it's
happened
to me :-)
the clock stopped now, the system is responsive, but eg
sleep 1
never finishes.
Is there a solution?
btw, I'm running 8.2-stable, i'll try 8
On 4/2/2012 3:59 PM, Joe Greco wrote:
>> On 4/2/2012 11:43 AM, Joe Greco wrote:
>>> As a user, you can't win. If you don't report
>>> a problem, you get criticized. If you report a problem but can't figure
>>> out how to reproduce it, you get criticized. If you can reproduce it
>>> but you don't
Guys,
The crash on my machine with debugging has evaded me for a few days. I'm
still looking for further suggestions of things I should grab from the DDB
when it happens again.
Thanks for the help everyone!
___
freebsd-hackers@freebsd.org mailing
> On 4/2/2012 11:43 AM, Joe Greco wrote:
> > As a user, you can't win. If you don't report
> > a problem, you get criticized. If you report a problem but can't figure
> > out how to reproduce it, you get criticized. If you can reproduce it
> > but you don't submit a workaround, you get criticize
On 4/2/2012 11:43 AM, Joe Greco wrote:
> As a user, you can't win. If you don't report
> a problem, you get criticized. If you report a problem but can't figure
> out how to reproduce it, you get criticized. If you can reproduce it
> but you don't submit a workaround, you get criticized. If you
t; these may serve to help shed light on where the
problem lies.
The interesting thing is that I took it and looked at it and came to a
conclusion that might have been wrong, though I think the trail of
reasoning I used was itself reasonable, given my exceedingly small (one
example of problem) samp
On 03/30/2012 07:41, Joe Greco wrote:
>> On 3/29/2012 7:01 AM, Joe Greco wrote:
On 3/28/2012 1:59 PM, Mark Felder wrote:
> FreeBSD 8-STABLE, 8.3, and 9.0 are untested
As much as I'm sensitive to your production requirements, realistically
it's not likely that you'll get a he
ning backup software (rsync, etc?) on my ESX nodes now so I can capture
these VM config files? How would I ever know what changed the VM files
when? I'm sure if I called up VMWare and said "HEY YOU GUYS YOU BROKE THIS
BY CHANGING THESE FILES" and then when they asked how I figur
There's no guarantee that upgarding a VM or rebooting it won't change
the config of said VM. Don't forget to diff the vm config file..
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsub
> Subsequent inspection suggested that it was happening during the
> periodic daily, though we never managed to get it to happen by manually
> forcing periodic daily, so that's only a theory.
Perhaps due to a bunch of VMs all running periodic daily at the same time?
> We had a perfectly functiona
Mark Felder wrote:
On Thu, 29 Mar 2012 12:24:30 -0500, wrote:
I just started reading this tread, but I am wondering if I missed
something here. What does this have to do with "Windows 7"?
I emailed him off-list but I'm guessing he thought this was on VMWare
Workstation or
On Fri, 30 Mar 2012 11:53:10 -0500, Joe Greco wrote:
On the same vmdk files? "Deleting the VM" makes it sound like not.
Fresh new VMDK files every time, and always thick provisioned.
None of the other VM's, even the VM's that had been abused in this
horribly insensitive manner of being pla
> On Fri, 30 Mar 2012 09:44:47 -0500, Joe Greco wrote:
> > Have you migrated these hosts, or were they installed in-place and
> > never moved?
> > fwiw the apparent integrity of things on the VM is consistent with
> > our experience too.
>
> VMMotion and StorageVMMotion does not seem to affect th
On Fri, 30 Mar 2012 09:44:47 -0500, Joe Greco wrote:
Have you migrated these hosts, or were they installed in-place and
never moved?
fwiw the apparent integrity of things on the VM is consistent with
our experience too.
VMMotion and StorageVMMotion does not seem to affect the stability. Even
> On Thu, 29 Mar 2012 19:27:31 -0500, Joe Greco wrote:
>
> > It also doesn't explain the experience here, where one VM basically
> > crapped out but only after a migration - and then stayed crapped out.
> > It would be interesting to hear about your datastore, how busy it is,
> > what technology,
> On 3/29/2012 7:01 AM, Joe Greco wrote:
> >> On 3/28/2012 1:59 PM, Mark Felder wrote:
> >>> FreeBSD 8-STABLE, 8.3, and 9.0 are untested
> >>
> >> As much as I'm sensitive to your production requirements, realistically
> >> it's not likely that you'll get a helpful result without testing a newer
>
isk - very important if you can't
run sysctl because your disk IO has locked up!) to see what the
current state of things.
It's likely that the BSD mpt(4) and other storage drivers, and/or our
interrupt handling code, is just slightly different enough to confuse
the snot out of VMWare. I
On Thu, 29 Mar 2012 19:27:31 -0500, Joe Greco wrote:
It also doesn't explain the experience here, where one VM basically
crapped out but only after a migration - and then stayed crapped out.
It would be interesting to hear about your datastore, how busy it is,
what technology, whether you're us
crashes now that I'm using
> LSI SAS emulated controller. If it still crashes, we'll see what happens
> after that with those loader.conf options enabled.
Um, if I may, that's something completely different.
VMDirectPath, or PCIe passthru, is making a hardware device on a VMwar
On 3/29/2012 7:01 AM, Joe Greco wrote:
>> On 3/28/2012 1:59 PM, Mark Felder wrote:
>>> FreeBSD 8-STABLE, 8.3, and 9.0 are untested
>>
>> As much as I'm sensitive to your production requirements, realistically
>> it's not likely that you'll get a helpful result without testing a newer
>> version. 8.
On Thu, 29 Mar 2012 15:53:52 -0500, Adam Vande More
wrote:
Doesn't VMWare offer different types of emulated disk controllers? If
so,
that might be the easiest way to narrow the field. Another thing maybe
to
try would be to backport the mpt
Yes, they offer Paravirtual
On Thu, Mar 29, 2012 at 1:22 PM, Mark Felder wrote:
>
> If we assume mpt is the culprit
>
Doesn't VMWare offer different types of emulated disk controllers? If so,
that might be the easiest way to narrow the field. Another thing maybe to
try would be to backport the mpt
On Thu, 29 Mar 2012 12:53:49 -0500, Dieter BSD
wrote:
FreeBSD ?? - 7.4 never crash
FreeBSD 8.0 - 8.2 crashes
Obvious short term workaround is to run production on 7.4 (assuming you
can)
until you figure out what is wrong with 8.x.
We're moving our most critical servers to 7.4 this week
> FreeBSD ?? - 7.4 never crash
> FreeBSD 8.0 - 8.2 crashes
Obvious short term workaround is to run production on 7.4 (assuming you can)
until you figure out what is wrong with 8.x.
What filesystem(s) are you running? UFS? ZFS? other?
> started randomly disconnecting people every morning
Due to
> On Thursday 29 March 2012 17:49:30 Joe Greco wrote:
> > > On Thursday 29 March 2012 15:42:42 Joe Greco wrote:
> > > > > Hi,
> > >
> > > Do both 32- and 64-bit versions of FreeBSD crash?
> >
> > We've only seen it happen on one virtual machine. That was a 32-bit
> > version. And it's not so mu
On Thu, 29 Mar 2012 11:53:02 -0500, Alan Cox wrote:
Not so long ago, VMware implemented a clever scheme for reducing the
overhead of virtualized interrupts that must be delivered by at least
some
(if not all) of their emulated storage controllers:
http://static.usenix.org/events/atc11
On Thu, 29 Mar 2012 12:24:30 -0500, wrote:
I just started reading this tread, but I am wondering if I missed
something here. What does this have to do with "Windows 7"?
I emailed him off-list but I'm guessing he thought this was on VMWare
Workstation or another pro
On Thu, 29 Mar 2012 12:05:30 -0500, Mark Atkinson
wrote:
If this is an interrupt problem with disk i/o, then you might want to
look into (DDB(4))
show intr
show intrcount
maybe
show allrman
Thank you! I really don't know what things we should be running in DDB to
diagnose this and we wi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/29/2012 07:03, Mark Felder wrote:
> Alright, new data. It happened to crash about 10 minutes after I
> came in this morning and I ran some stuff in the DDB. I have no
> idea what information is useful, but perhaps someone will see
> something out
74769460
> cpu0: timer 246571507400
> Total 550242125892
>
>
Not so long ago, VMware implemented a clever scheme for reducing the
overhead of virtualized interrupts that must be delivered by at least some
(if not all) of
se some
stuff on 8.3 for long term stability...)
ESXi: Confirmed ESXi 4.0 - 5.0 has this problem. Haven't tested on
others.
History:
Over the course of the last 2 years we've been banging our heads on
the wall. VMWare is done debugging this. They claim it's not a VMWare
issue. T
On Thu, 29 Mar 2012 10:49:30 -0500, Joe Greco wrote:
I explained it at the time to one of my VMware friends:
This is 100% identical to what we see, Joe! And we're so unlucky that we
have this happen on probably a dozen servers, but a handful are the really
bad ones. We've re
On Thu, 29 Mar 2012 10:55:36 -0500, Hans Petter Selasky
wrote:
It almost sounds like the lost interrupt issue I've seen with USB EHCI
devices, though disk I/O should have a retry timeout?
What does "wmstat -i" output?
--HPS
Here's a server that has a week uptime and is due for a crash any
On Thu, 29 Mar 2012 10:31:24 -0500, Eduardo Morras
wrote:
Don't know about ESXi but on others VM Managers i can change the chipset
emulation from ICH10 to ICH4. Can you change it to an older chipset too?
Unfortunately there's no setting in the GUI for that but I'll keep looking
to see
On Thursday 29 March 2012 17:49:30 Joe Greco wrote:
> > On Thursday 29 March 2012 15:42:42 Joe Greco wrote:
> > > > Hi,
> >
> > Do both 32- and 64-bit versions of FreeBSD crash?
>
> We've only seen it happen on one virtual machine. That was a 32-bit
> version. And it's not so much a crash as it
n the VM. I wasn't able to prove it. I tried a read-dd of the
entire disk - passed, flying. I tried several things to duplicate
the nightly periodic tasks where it seemed so prone to locking up.
They all ran fine. But if I left the machine run, it'd do it
again eventually.
I explaine
At 16:03 29/03/2012, you wrote:
Alright, new data. It happened to crash about 10 minutes after I came in
this morning and I ran some stuff in the DDB. I have no idea what
information is useful, but perhaps someone will see something out of the
ordinary?
http://feld.me/freebsd/esx_crash/
Don't
On Thu, 29 Mar 2012 09:58:16 -0500, Hans Petter Selasky
wrote:
Do both 32- and 64-bit versions of FreeBSD crash?
Correct, we see both i386 and amd64 flavors crash in the same way.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.o
> On 3/28/2012 1:59 PM, Mark Felder wrote:
> > FreeBSD 8-STABLE, 8.3, and 9.0 are untested
>
> As much as I'm sensitive to your production requirements, realistically
> it's not likely that you'll get a helpful result without testing a newer
> version. 8.2 came out over a year ago, many many thing
On Thursday 29 March 2012 15:42:42 Joe Greco wrote:
> > Hi,
Do both 32- and 64-bit versions of FreeBSD crash?
--HPS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "
gone
awry in the virtual machine, probably in the disk image, but I could
not identify it without significant digging that I had no particular
reason or inclination to do; since it appeared to be a VMware problem,
the "reload it and be done with it" seemed the quickest path to
resolution.
Th
1 - 100 of 372 matches
Mail list logo
