Re: [PATCH] PATCH: dpt_i2o memory leak comments

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[Randy.Dunlap]

| @@ -1318,7 +1318,9 @@
|  	while(*status == 0){
|  		if(time_after(jiffies,timeout)){
|  			printk(KERN_WARNING"%s: IOP Reset Timeout\n",pHba->name);
| -			kfree(status);
| +			/* We loose 4 bytes of "status" here, but we cannot
| +			   free these because controller may awake and corrupt
| +			   those bytes at any time */
s/loose/lose/

| @@ -1336,6 +1338,9 @@
|  			}
|  			if(time_after(jiffies,timeout)){
|  				printk(KERN_ERR "%s:Timeout waiting for IOP Reset.\n",pHba->name);
| +			/* We loose 4 bytes of "status" here, but we cannot
| +			   free these because controller may awake and corrupt
| +			   those bytes at any time */
s/loose/lose/

or is this a Brit vs. Amer difference?  (not that I know of)

--
~Randy

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[Richard B. Johnson]

On Tue, 1 Apr 2003, Randy.Dunlap wrote:

> | @@ -1318,7 +1318,9 @@
> |  	while(*status == 0){
> |  		if(time_after(jiffies,timeout)){
> |  			printk(KERN_WARNING"%s: IOP Reset Timeout\n",pHba->name);
> | -			kfree(status);
> | +			/* We loose 4 bytes of "status" here, but we cannot
> | +			   free these because controller may awake and corrupt
> | +			   those bytes at any time */
> s/loose/lose/
>
> | @@ -1336,6 +1338,9 @@
> |  			}
> |  			if(time_after(jiffies,timeout)){
> |  				printk(KERN_ERR "%s:Timeout waiting for IOP Reset.\n",pHba->name);
> | +			/* We loose 4 bytes of "status" here, but we cannot
> | +			   free these because controller may awake and corrupt
> | +			   those bytes at any time */
> s/loose/lose/
>
> or is this a Brit vs. Amer difference?  (not that I know of)
>
> --
> ~Randy
> -

Loose means that something is rattling around, not connected, or
not tied down. Lose is what happens on the Crap Tables (as above).

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[Nigel Cunningham]

On Wed, 2003-04-02 at 09:26, Richard B. Johnson wrote:
> Loose means that something is rattling around, not connected, or
> not tied down. Lose is what happens on the Crap Tables (as above).

Is it clearer to say: Loose is a state, lose is a verb?

Regards,

Nigel

-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

Be diligent to present yourself approved to God as a workman who does
not need to be ashamed, handling accurately the word of truth.
	-- 2 Timothy 2:14, NASB.

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[jw schultz]

On Wed, Apr 02, 2003 at 09:26:54AM +1200, Nigel Cunningham wrote:
> On Wed, 2003-04-02 at 09:26, Richard B. Johnson wrote:
> > Loose means that something is rattling around, not connected, or
> > not tied down. Lose is what happens on the Crap Tables (as above).
> 
> Is it clearer to say: Loose is a state, lose is a verb?

No, because loose is also a verb meaning to make loose or
remove restraints.  English is such a fun language.

To lose something implies the loss is unintended, either
real or pretense.  Unless the loss is unintentional you
really shouldn't be using the word "lose".  If it is
unintentional it should probably be past tense (lost).

At this point I cannot be sure of the context here but what
is probably meant would be clearer if we used the word
"discard".

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[Jörn Engel]

On Tue, 1 April 2003 13:15:04 +0000, Randy.Dunlap wrote:
> 
> | @@ -1318,7 +1318,9 @@
> |  	while(*status == 0){
> |  		if(time_after(jiffies,timeout)){
> |  			printk(KERN_WARNING"%s: IOP Reset Timeout\n",pHba->name);
> | -			kfree(status);
> | +			/* We loose 4 bytes of "status" here, but we cannot
> | +			   free these because controller may awake and corrupt
> | +			   those bytes at any time */
> s/loose/lose/
> 
> | @@ -1336,6 +1338,9 @@
> |  			}
> |  			if(time_after(jiffies,timeout)){
> |  				printk(KERN_ERR "%s:Timeout waiting for IOP Reset.\n",pHba->name);
> | +			/* We loose 4 bytes of "status" here, but we cannot
> | +			   free these because controller may awake and corrupt
> | +			   those bytes at any time */
> s/loose/lose/

It might also be nice to point out, that we lose the 4 bytes once per
*boot*, not continuously. Some people like me have a much easier time
to accept the loss then. :)

Jörn

-- 
It's just what we asked for, but not what we want!
-- anonymous

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[Alan Cox]

On Wed, 2003-04-02 at 00:12, jw schultz wrote:
> No, because loose is also a verb meaning to make loose or
> remove restraints.  English is such a fun language.

To make loose is "loosen", to set free can be "loose", although from
"let loose" I suspect.

> To lose something implies the loss is unintended, either
> real or pretense.  Unless the loss is unintentional you
> really shouldn't be using the word "lose".  If it is
> unintentional it should probably be past tense (lost).

Umm ?  "The annoyed team members set out to lose"

You can intentionally lose something. The difference is whether you
expect to be able to retrieve it.

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[Alan Cox]

On Tue, 2003-04-01 at 14:15, Randy.Dunlap wrote:
> s/loose/lose/
> 
> or is this a Brit vs. Amer difference?  (not that I know of)

Your corrections are right

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[scott]

Question/Help:
Our threading indexer routinely crashes our Adaptec 2400A. How can I 
duplicate that activity for the Adaptec team as they request below?
Scott Beane

-------- Original Message --------
Subject: 	RE: [Fwd: Re: dpt_i2o memory leak]
Date: 	Wed, 11 Jun 2003 13:49:27 -0400
From: 	Salyzyn, Mark <mark_salyzyn@adaptec.com>
To: 	'scott' <scott@dsbcpas.com>
CC: 	'tcallawa@redhat.com' <tcallawa@redhat.com>



Thanks, I believe this confirms my understanding at least regarding the
`leak'. I will try to `make it better' in the future.

The panic you forwarded is a source of consternation. It occurs in the
scsi_done command which takes it out of the driver making it difficult of
debug (remote as we are).

Being able to duplicate this problem locally becomes necessary. If you can
provide to me a simplified set of tools and description on how to duplicate
this, I will get this sent off to our software test team to bash on.

Sincerely -- Mark Salyzyn

Re: [PATCH] PATCH: dpt_i2o memory leak comments

[scott]

Adaptec 2400A

Hi Mark (mark_salyzyn@adaptec.com),

Sorry to report that the test rpm you sent me last week did not solve 
our high load kernel panic crash problem we are experiencing, RH 
distribution of kernel 2.4.20-13.7smp.

I have been keeping better score of what happens and I can recreate the 
problem by running our search engine indexer in thread mode. Ksymoops 
and screen dumps by most recent date follow.  My rookie observation is 
that the 6.3.2003 kernel panic is a bit different then the older 5.29.03 
crash, but he ksymoops are similar.

Thank you for looking at this.

Very Truly Yours,
Scott

Your RPM was applied 6.7.2003. System is an Athlon dual 1800 mps on an 
Asus A7M266-D main board.

*Crash of 6.7.2003 AFTER your rpm was applied:

*_/Ksymoops Report after reboot:/ (6.7.2003)_
ksymoops 2.4.4 on i686 2.4.20-13.7smp.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20-13.7smp/ (default)
     -m /boot/System.map-2.4.20-13.7smp (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (expand_objects): cannot stat(/lib/dpt_i2o.o) for dpt_i2o
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Error (pclose_local): find_objects pclose failed 0x100
Warning (map_ksym_to_module): cannot match loaded module ext3 to a 
unique module object.  Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module dpt_i2o to a 
unique module object.  Trace may not be reliable.
Reading Oops report from the terminal

_/Kernel panic screen dump: /__(6.7.2003)_

EIP is at __scsi_end_request [scsi_mod] 0xa4(2.4.20-13.7smp)

eax: d9e7dde0 ebx 00000008 ecx:00400000  edx: 00000000

esi:f7fc8268 edi: 00400000  ebp: 00000000  esp:f6a9feb0

ds:0018  es:0018 ss:0018
Process mysqld (pid: 1702, stackpage=f6a9f000)
Stack:     c3679618 f7fc8200 e3e52000 e3e52000 00000008
    f88154c8 f7fc8200 00000001 00000008 00000001
    00000001 f67ff234 00000000 f6a9ff3c
    f7fc82b8 c3679618 00000008 00000000 00000001
    00000008 00000000 f7fc8200 00000008 00000001

Call Trace: [<f88154c8>] scsi_io_completion_rsmp.6cd6
f415 [scsi_mod] 0x208 (0xf6a9fec4))

[<f8829de3>] rw_intr [sd_mod] 0x243 (0xf6a9ff10))
[<f8831155>] adpt_i2o_to_scsi [dpt_i2o] 0x3a5(0xf6a9ff2c))
[<f880e2ff>] scsi_finish_command [scsi_mod] 0xcf (0xf6a9ff44))
[<f880e08f>] scsi_bottom_half_handler [scsi_mod] 0xbf (0xf6a9ff5c))
[<c012110b>] bh_action [kernel] 0x4b (0xf6a9ff6c))
[<c0120fd0>] tasklet_hi_action [kernel] 0x60 (0xf6a9ff74))
[<c0120d6b>] do_softirq [kernel] 0x7b (0xf6z9ff8c))
[<c010a7de>] do_IRQ [kernel] 0xfe (0xf6a9ffa8))

Code:0f b7 41 08 66 c1 e8 09 0f b7 c0 39 c2 89 46 38 89 46 3c 73

<0> Kernel panic : Aiee, killing interupt handler!
In interupt handler - not syncing


*Crash of 6.3.2003 BEFORE your rpm was applied:*

_/Ksymoops Report after reboot:/ (6.3.2003)_
ksymoops 2.4.4 on i686 2.4.20-13.7smp.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.20-13.7smp/ (default)
     -m /boot/System.map-2.4.20-13.7smp (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Error (expand_objects): cannot stat(/lib/ext3.o) for ext3
Error (expand_objects): cannot stat(/lib/jbd.o) for jbd
Error (expand_objects): cannot stat(/lib/dpt_i2o.o) for dpt_i2o
Error (expand_objects): cannot stat(/lib/sd_mod.o) for sd_mod
Error (expand_objects): cannot stat(/lib/scsi_mod.o) for scsi_mod
Error (pclose_local): find_objects pclose failed 0x100
Warning (map_ksym_to_module): cannot match loaded module ext3 to a 
unique module object.  Trace may not be reliable.
Warning (map_ksym_to_module): cannot match loaded module dpt_i2o to a 
unique module object.  Trace may not be reliable.
Reading Oops report from the terminal

_/Kernel panic screen dump: /__(6.3.2003)_

EIP is at timer_bh [kernel] 0x1ff (2.4.20-13.7smp)
eax: c03a4584   ebx: c03a4584   ecx:d9fda278   edx: 00000000
esi: c03a454c   edi: f7a2223c   ebp: c03a436o   esp: f7fbdf00
ds: 0018   es: 0018   ss:0018
Process swapper (pidi 0, stackpage=f7fbd000)
Stack:  c023e914 f7fbdf0c 00000001 f7fbdf0c f7fbdf0c
    00000000 00000001 00000040 00000000 c012110b
    c03a3880 c0120fd0 00000000 00000001 c0377940
    fffffffe 00000001 c0120d6b c0377940 00000046
    00000001 c0370800 00000000 c03026c8

Call trace:     [<c012110b>] bh_action [kernel] 0x4b (0xf7fbdf24))
        [<c0120fd0>] tasklet_hi_action [kernel] ox6o (0xf7bdf2c))
        [<c0120d6b>] do_softirq [kernel] ox7b (oxf7fbdf44))
        [<c010a7de>] do_irq [kernel] 0xfe (0xf7fbdf60))
        [<c0106df0>] default_idle [kernel] 0x0 (0xf7fbdf68))
        [<c0106df0>] default_idle [kernel] 0x0 (0xf7fbdf74))
        [<c0106df0>] default_idle [kernel] 0x0 (0xf7fbdf7c))
        [<c0106df0>] default_idle [kernel] 0x0 (0xf7fbdf90))
        [<c0106df0>] default_idle [kernel] 0x2c (0xf7fbdfa4))
        [<c0106eb2>] cpu_idle [kernel] 0x52 (0xf7fbdfb0))
        [<c011c4e9>] call_console_drivers [kernel] oxe9 (0xf7fbdfe0))

Code:     8b 02 89 58 04 89 53 04 89 1a 89
    fb 39 f3 0f 85 2b ff

<0> kernel panic: Aiee, killing interrupt handler! 
In interrupt handler - not syncing