Hi,
Is there a possible simple trick to generate dummy interrupts in a
control fashion on an AMD system for testing?
So, that I could increase the constant level of interrupts that the
server would need to process per seconds as an example?
So, far it doesn't look like the problem is with i
Not sure if that mean anything what so ever.
But when the box rebooted itself, this time I got this in ddb. All
frozen, but the display show this:
Not sure for the end of the line here = 0. Could be something else, but
I can't see it.
kkeerrnneell:: pprrootteeccttiioonn f a u l t t r a
Stuart Henderson wrote:
save dmesg from the various different kernels and use diff to see what
changes between them.
I didn't see in your posts to this thread whether you've compared
with/without acpi? (recent snapshots should enable acpi automatically
if you have >1 cpu/core and you'll see seve
Stuart Henderson wrote:
On 2007/11/26 18:21, Daniel Ouellet wrote:
One more question for you if I may.
As far as you know, does this difference interrupt processing is also use
for UBS devices as well by any chance?
yes, and everything else that uses interrupts.
(/sys/arch/i386/config/GENERI
David Gwynne wrote:
what is the bug you're able to reproduce?
I posted it on misc@ and reply on an email with the same hardware
problem on tech@ and open a but report as well on it.
But the short story of it is that using amd64.mp kernel on Sun X4100 M2
I can crash the box at will by writin
On 2007/11/26 18:21, Daniel Ouellet wrote:
> One more question for you if I may.
>
> As far as you know, does this difference interrupt processing is also use
> for UBS devices as well by any chance?
yes, and everything else that uses interrupts.
(/sys/arch/i386/config/GENERIC.MP uses ioapic, ...
David Gwynne wrote:
what is the bug you're able to reproduce?
Also, just more details, this bug is in as far back as 4.0. I didn't
load a version before that, but with 4.0, 4.1, 4.2 and current of
November 20, it's all doing the same, with way more bugs that were fix
as well, but for this sp
Ted Unangst wrote:
On 11/26/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote:
My understanding's is that all drives are using an abstraction layer
between the kernel and the drivers itself.
Now, I don't know if there is a difference between drivers for a single
processor kernel and a multiple core
Ted Unangst wrote:
On 11/26/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote:
My understanding's is that all drives are using an abstraction layer
between the kernel and the drivers itself.
Now, I don't know if there is a difference between drivers for a single
processor kernel and a multiple core
On 27/11/2007, at 7:59 AM, Daniel Ouellet wrote:
Hi,
Please correct me if my understanding is wrong. I am trying to trace
a bug and I am not sure where it is really, but I got a possible
idea I want to check for if that make sense.
My understanding's is that all drives are using an abstra
On 11/26/07, Daniel Ouellet <[EMAIL PROTECTED]> wrote:
> My understanding's is that all drives are using an abstraction layer
> between the kernel and the drivers itself.
>
> Now, I don't know if there is a difference between drivers for a single
> processor kernel and a multiple core kernel. So, f
Hi,
Please correct me if my understanding is wrong. I am trying to trace a
bug and I am not sure where it is really, but I got a possible idea I
want to check for if that make sense.
My understanding's is that all drives are using an abstraction layer
between the kernel and the drivers itsel
12 matches
Mail list logo
