Re: mlx driver related kernel panic in Freebsd 5.2.1-RELEASE

> 
> Great to hear, thanks a lot for testing it.  It looks like the problem can
> manifest itself when a whole lot of I/O comes into the driver at once.  An
> easy way that I've found to generate a pattern like this is to turn
> softupdates off, then start 5-10 concurrent copies of large trees with
> lots of files.  Then when the pagedaemon does its 30-second interval run,
> it'll likely send 500-1000 i/o requests at once to the card.
> 
> Scott

Hi Scott,


Can you please backport the patch to 5.2.1?

Thanks,
Jonathan

> On Mon, 1 Mar 2004, Dexter McNeil wrote:
> 
>> Scott,
>> 
>> This patch seems to have fixed it. I've been trying for the past few
>> hours to crash the machine with massive file copies (both local and via
>> NFS) and it's stayed up! Many thanks!!
>> 
>> Cheers,
>> Dexter McNeil
>> 
>> On Sat, Feb 28, 2004 at 12:36:34PM -0700, Scott Long wrote:
>>> Dexter,
>>> 
>>> I sent out a patch earlier today that might help.  If not, I'll take you
>>> up on your offer for remote access to the machine.  The mlx driver
>>> underwent a massive structural overhaul over the summer, and I might
>>> have missed some edge cases.  Attached is the patch in case you missed
>>> it.
>>> 
>>> Scott
>>> 
>>> Dexter McNeil wrote:
>>>> Scott,
>>>> I can make remote access to the box and serial console port available
>>>> if it will help.
>>>> 
>>>> On Thu, Feb 26, 2004 at 04:42:05PM -0700, Scott Long wrote:
>>>> 
>>>>> Thanks for the report, I'll look at it.
>>>>> 
>>>>> Scott
>>>>> 
>>>>> Dexter McNeil wrote:
>>>>> 
>>>>>> OK, I seem to be able to get FreeBSD 5.2.1-RELEASE to reliably panic with
>>>>>> a "panic: free: address 0xd8d5e000(0xd8d5e000) has not been allocated."
>>>>>> on
>>>>>> the serial console when it crashes.
>>>>>> 
>>>>>> I'm doing two copies of the entire ports collection to seperate
>>>>>> subdirectories when the crash occurs. It seems to do this regardless of
>>>>>> 
>>>>>> The machine is an IBM Netfinity 5500 with 4 x 550Mhz P3 Xeon CPUS, 2gigs
>>>>>> of ram and a Mylex DAC1100 RAID controller. There are 6 73G disks
>>>>>> attached
>>>>>> to channel 0 of the controller, 5 disks are in a RAID 5 array, the sixth
>>>>>> is a hot spare.
>>>>>> 
>>>>>> Any ideas?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> A 'trace' at the db> prompt yields:
>>>>>> 
>>>>>> cpuid = 2;
>>>>>> Debugger("panic")
>>>>>> Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
>>>>>> db> trace
>>>>>> Debugger(c06d1f22,2,c06d07e3,e257dc30,100) at Debugger+0x55
>>>>>> panic(c06d07e3,d8d5e000,d8d5e000,0,c06d07a4) at panic+0x156
>>>>>> free(d8d5e000,c0705300,1,0,c0522975) at free+0xa3
>>>>>> mlx_enquire(c8277000,c,c,c04c3b60,d8) at mlx_enquire+0xef
>>>>>> mlx_periodic(c8277000,0,c06d2fed,d8,1) at mlx_periodic+0x174
>>>>>> softclock(0,0,c06cfc87,23a,c81d4a98) at softclock+0x1b8
>>>>>> ithread_loop(c42f1f00,e257dd48,c06cfaed,311,0) at ithread_loop+0x192
>>>>>> fork_exit(c0518350,c42f1f00,e257dd48) at fork_exit+0xb4
>>>>>> fork_trampoline() at fork_trampoline+0x8
>>>>>> --- trap 0x1, eip = 0, esp = 0xe257dd7c, ebp = 0 ---
>>>>>> 
>>>> 
>>>> 
>>> 
>> 
>>> Index: mlx.c
>>> ===================================================================
>>> RCS file: /usr/ncvs/src/sys/dev/mlx/mlx.c,v
>>> retrieving revision 1.44
>>> diff -u -r1.44 mlx.c
>>> --- mlx.c    22 Feb 2004 09:52:46 -0000    1.44
>>> +++ mlx.c    28 Feb 2004 17:48:59 -0000
>>> _at__at_ -1554,8 +1554,8 _at__at_
>>>      if ((mc->mc_complete == NULL) && (mc != NULL))
>>> mlx_releasecmd(mc);
>>>      /* we got an error, and we allocated a result */
>>> -    if ((error != 0) && (mc->mc_data != NULL)) {
>>> -    free(mc->mc_data, M_DEVBUF);
>>> +    if ((error != 0) && (result != NULL)) {
>>> +    free(result, M_DEVBUF);
>>> mc->mc_data = NULL;
>>>      }
>>>      return(result);
>> 
>> 
>> --
>> The ultimate destination on the journey of life is a hole 6 feet deep.
>> Enjoy the journey - the destination is nothing to write home about.
>> 
>> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>