Can you try instead the changes that I just committed to -current? I
think that the problem shows up when the controller is heavily loaded;
your patch will keep the load on the controller down, which may mask the
'real' bug.
Just recently (this evening), I was able to get our
Mike Smith wrote:
Just recently (this evening), I was able to get our controller to lock
up with the latest patch. Previously, with that patch installed, I
must not have been able to tickle the bug just right, and I believe
that Mike based his decision to make that mod based on my lack
I've played around changing the spinloop to using DELAY (like the Linux model),
but this didn't prevent the controller from either "just" locking up or
crashing the whole machine with it. Changing various other places in a similar
manner (like replacing the bcopy() in amr_quartz_get_work() with
* [EMAIL PROTECTED] [EMAIL PROTECTED] [000323 12:47] wrote:
I've played around changing the spinloop to using DELAY (like the Linux model),
but this didn't prevent the controller from either "just" locking up or
crashing the whole machine with it. Changing various other places in a similar
I've played around changing the spinloop to using DELAY (like the Linux model),
but this didn't prevent the controller from either "just" locking up or
crashing the whole machine with it. Changing various other places in a similar
manner (like replacing the bcopy() in amr_quartz_get_work()
I've found the easiest way to wedge the box is to perform a 'cvs up'
(not cvsup) from a local repository over /usr/src or /usr/ports, this
would always lockup my box with amr, if you have the time and disk
space that would be a much better stressor than just make world.
I have done a cvs
Can you try instead the changes that I just committed to -current? I
think that the problem shows up when the controller is heavily loaded;
your patch will keep the load on the controller down, which may mask the
'real' bug.
I tried your approach (that was what I described with "fiddling
Mike Smith wrote:
I've played around changing the spinloop to using DELAY (like the Linux model),
but this didn't prevent the controller from either "just" locking up or
crashing the whole machine with it. Changing various other places in a similar
manner (like replacing the bcopy() in
At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
Not that I consider this particuarly optimal; busy-waiting for the
controller is a terrible waste of the host CPU. A better solution would
probably defer the command and try again a short time later, but let's
see if this works first.
:At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
:
: Not that I consider this particuarly optimal; busy-waiting for the
: controller is a terrible waste of the host CPU. A better solution would
: probably defer the command and try again a short time later, but let's
: see if this works first.
At 7:25 PM -0800 2000/3/20, Mike Smith wrote:
Not that I consider this particuarly optimal; busy-waiting for the
controller is a terrible waste of the host CPU. A better solution would
probably defer the command and try again a short time later, but let's
see if this works first.
: For situations that aren't in the critical path and don't happen often,
: it may be beneficial to do a voluntary context switch inside the loop.
:
:Is it possible/legal to do this inside a strategy() routine?
Yes, though it isn't playing nice if the caller was trying to issue
We have a system with a new AMI card in it controlling a pair
of shelves from Dell (fbsd dated: 4.0-2313-SNAP).
The relevant dmesg output is below: (complete dmesg at end)
amr0: AMI MegaRAID mem 0xf6c0-0xf6ff irq 14 at device 10.1 on pci2
amr0: firmware 1.01 bios 1p00
The controller is new. Dell calls it a Perc2/dc and it has 128Meg
of memory installed in it. I'm not sitting infront of the
machine right now. More detailed information is available
when the machines is booted and you enter the bios setup
on the adapter card.
Ok. From some rumours
Hi,
The controller is new. Dell calls it a Perc2/dc and it has 128Meg
of memory installed in it. I'm not sitting infront of the
machine right now. More detailed information is available
when the machines is booted and you enter the bios setup
on the adapter card.
We have a system with a
A couple of clarifications on the last message:
Thus, when you see it printed as 0, somewhere between the test and the
printf the controller has updated the flag and indicated it's busy.
That should of course be "not busy".
I'd be guessing that the current loop (100k iterations) is
Hi,
We have a system with a new AMI card in it controlling a pair
of shelves from Dell (fbsd dated: 4.0-2313-SNAP).
The relevant dmesg output is below: (complete dmesg at end)
amr0: AMI MegaRAID mem 0xf6c0-0xf6ff irq 14 at device 10.1 on pci2
amr0: firmware 1.01 bios 1p00
On Sun, Mar 19, 2000 at 09:00:35PM -0500, John W. DeBoskey wrote:
amr0: AMI MegaRAID mem 0xf6c0-0xf6ff irq 14 at device 10.1 on pci2
amr0: firmware 1.01 bios 1p00 128MB memory
amrd0: MegaRAID logical drive on amr0
amrd0: 172780MB (353853440 sectors) RAID 5 (optimal)
The
18 matches
Mail list logo
