Bug 104446 - LTC4523-ext3 code oopses when underlying hardware times out
LTC4523-ext3 code oopses when underlying hardware times out
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
2.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
:
: 79163 (view as bug list)
Depends On:
Blocks: 106054
  Show dependency treegraph
 
Reported: 2003-09-15 15:16 EDT by Neil Horman
Modified: 2010-10-21 22:25 EDT (History)
7 users (show)

See Also:
Fixed In Version: QU3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-08 19:29:17 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Neil Horman 2003-09-15 15:16:17 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Tracked in issue tracker as #27154.  When customer disconnects storage array
connnection from server, occasionally ext3 module hits BUG() in transaction.c:


Aug 28 15:08:24 cluster2 kernel: ------------[ cut here ]------------
Aug 28 15:08:24 cluster2 kernel: kernel BUG at transaction.c:731!
Aug 28 15:08:24 cluster2 kernel: invalid operand: 0000
Aug 28 15:08:24 cluster2 kernel: Kernel 2.4.9-e.27
Aug 28 15:08:24 cluster2 kernel: CPU:    0
Aug 28 15:08:24 cluster2 kernel: EIP:   
0010:[e1000:__insmod_e1000_O/lib/modules/2.4.9-e.27/kernel/drivers/addo+-840233/96]
   Not tainted
Aug 28 15:08:24 cluster2 kernel: EIP:    0010:[<e083bdd7>]    Not tainted
Aug 28 15:08:24 cluster2 kernel: EFLAGS: 00010282
Aug 28 15:08:24 cluster2 kernel: EIP is at do_get_write_access [jbd] 0x567
Aug 28 15:08:24 cluster2 kernel: eax: 00000024   ebx: dee0b9c0   ecx: c02ca784 
 edx: 006f4a26
Aug 28 15:08:24 cluster2 kernel: esi: d76a0e00   edi: 00000001   ebp: d76a0e00 
 esp: d622ba28
Aug 28 15:08:24 cluster2 kernel: ds: 0018   es: 0018   ss: 0018
Aug 28 15:08:24 cluster2 kernel: Process a.out (pid: 1409, stackpage=d622b000)
Aug 28 15:08:24 cluster2 kernel: Stack: e0844230 000002db 00000001 00000000
00000000 dee0b840 d76a0e94 d76a0e00
Aug 28 15:08:24 cluster2 kernel:        dbc3ab00 dd023640 e083bee6 dbc3ab00
dd023640 00000000 dbc3ab00 00000002
Aug 28 15:08:24 cluster2 kernel:        df452800 00000025 e084a0df dbc3ab00
d5e7ea80 d622baa4 00000000 00000000 


Version-Release number of selected component (if applicable):


How reproducible:
Didn't try


Additional info:

I haven't looked too closely yet, but it appears that issuetracker #27670 is
related.
Comment 1 Arjan van de Ven 2003-09-15 15:23:44 EDT
this backtrace is missing a lot of stuff, and also missing is what device driver
is in use for storage (version, is it RH's binary or some IHV installed one etc etc)
Comment 2 Neil Horman 2003-09-15 15:30:33 EDT
Sorry, I don't have system dumps to back this up, but the customer claims it
occurs with a megaraid card attached to an external storage box (using the red
hat megaraid driver).  They also claim the problem can be reproduced by using an
external usb hard drive, and usb-storage.o.  According to the ticket:
Steps to Reproduce:
1. # zsh
2. # mkfs -j /dev/sdb3 (/dev/sdb3 is on the external storage)
3. # mount -t ext3 /dev/sdb3 /mnt
4. # for i in {1..30} ; echo "dd of=/mnt/$i-test if=/dev/zero bs=1024k count=10
 &" >> /tmp/test.sh
5. # /tmp/test.sh
6. unplug the SCSI/FC/USB cable from the external storage.
7. kernel panic

Comment 3 Need Real Name 2003-09-22 08:25:08 EDT
I have the same problem on one customer machine that we have received in the
lab. The machine is an x255 with a ServeRAID 4H controller. 2x 73.4GB HDD's on
ID 0 and 10 (ID 0 is on one backplane and ID 10 on another backplane). We are
using 2 channels on the ServeRAID controller, and the drives are configured in
RAID 1. The ServeRAID controller is at code level 6.10, and the driver has been
compiled using e.27 source and inserted onto the module tree.

The system also have 1GB memory, it used to have 6GB, but due to limitaions with
netdump and time of each dump I have limited the amount of memory in the system.

I am using the LTP test suite to test the filesystem on the server, which after
a short time produces the following panic dump:

EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block -
inode=1677686, block=3375108
EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure
EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block -
inode=1677686, block=3375108
EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure
EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block -
inode=1677686, block=3375108
EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure
EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block -
inode=25, block=4
EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure
EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block -
inode=25, block=4
EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure
EXT3-fs error (device sd(8,2)): ext3_get_inode_loc: unable to read inode block -
inode=25, block=4
EXT3-fs error (device sd(8,2)) in ext3_reserve_inode_write: IO failure
Assertion failure in do_get_write_access() at transaction.c:731:
"(((jh2bh(jh))->b_state & (1UL << BH_Uptodate)) != 0)"
------------[ cut here ]------------
kernel BUG at transaction.c:731!
invalid operand: 0000
Kernel 2.4.9-e.27enterprise
CPU:    5
EIP:    0010:[<f9049e23>]    Not tainted
EFLAGS: 00010286
EIP is at do_get_write_access [jbd] 0x5a3 
eax: 00000024   ebx: f5e171a0   ecx: c02f7884   edx: 000dbbf1
esi: f7463200   edi: 00000001   ebp: f7463200   esp: f5a59bf0
ds: 0018   es: 0018   ss: 0018
Process growfiles (pid: 1720, stackpage=f5a59000)
Stack: f9052f10 000002db 00000001 00000000 00000000 f72f5460 f7463294 f7463200 
       f6319e40 f64d0370 f9049f47 f6319e40 f64d0370 00000000 f5310000 f5228600 
       00000600 f7660c00 f905a7fc f6319e40 f5228600 00003fa0 00000606 f5a59cc4 
Call Trace: [<f9052f10>] .LC7 [jbd] 0x0 
[<f9049f47>] journal_get_write_access_Rsmp_a7d05437 [jbd] 0x37 
[<f905a7fc>] ext3_new_inode [ext3] 0x2ec 
[<c011cbeb>] call_console_drivers [kernel] 0xeb 
[<c01863a1>] add_timer_randomness [kernel] 0xd1 
[<f8ff8e84>] __scsi_end_request [scsi_mod] 0x1a4 
[<f8ff970f>] scsi_request_fn [scsi_mod] 0x27f 
[<f9014580>] sd_template [sd_mod] 0x0 
[<c019a37e>] generic_unplug_device [kernel] 0x2e 
[<c012136d>] __run_task_queue [kernel] 0x5d 
[<c0147dee>] __wait_on_buffer [kernel] 0x8e 
[<f906317f>] ext3_commit_super [ext3] 0x4f 
[<f9061269>] ext3_handle_error [ext3] 0x99 
[<f9067854>] .LC54 [ext3] 0x0 
[<f906137a>] __ext3_std_error [ext3] 0x3a 
[<f9065d20>] .LC57 [ext3] 0x960 
[<f9067854>] .LC54 [ext3] 0x0 
[<f9067abb>] .LC10 [ext3] 0x1c3 
[<f9052f00>] .rodata.str1.1 [jbd] 0x0 
[<f904fcd7>] __jbd_kmalloc [jbd] 0x27 
[<f904911e>] get_transaction [jbd] 0xbe 
[<f90491c6>] start_this_handle [jbd] 0x66 
[<f9049285>] start_this_handle [jbd] 0x125 
[<f904938f>] journal_start_Rsmp_ec53be73 [jbd] 0xbf 
[<f905f941>] ext3_create [ext3] 0x81 
[<f905c946>] ext3_commit_write [ext3] 0x236 
[<c012bdda>] zap_page_range [kernel] 0x4ba 
[<c0152eef>] vfs_create [kernel] 0x12f 
[<c0151c80>] cached_lookup [kernel] 0x10 
[<c0152c5a>] lookup_hash [kernel] 0x4a 
[<c01530bc>] open_namei [kernel] 0x15c 
[<f9059cd2>] ext3_file_write [ext3] 0x22 
[<c01462b6>] filp_open [kernel] 0x36 
[<c01465b6>] sys_open [kernel] 0x36 
[<c01073c3>] system_call [kernel] 0x33 


Code: 0f 0b 5b 5e 8b 44 24 28 8b 10 b8 00 e0 ff ff 21 e0 8b 72 34 
CPU#4 is frozen.
CPU#6 is frozen.
CPU#7 is frozen.
CPU#0 is frozen.
CPU#1 is frozen.
CPU#2 is frozen.
CPU#3 is frozen.
< netdump activated - performing handshake with the client. >

Process: 1720, {           growfiles}
Kernel 2.4.9-e.27enterprise
EIP: 0010:[<f9049e23>] CPU: 5EIP is at do_get_write_access [jbd] 0x5a3 
 EFLAGS: 00010286    Not tainted
EAX: 00000024 EBX: f5e171a0 ECX: c02f7884 EDX: 000dbbf1
ESI: f7463200 EDI: 00000001 EBP: f7463200 DS: 0018 ES: 0018
CR0: 80050033 CR2: 40109000 CR3: 363f0f40 CR4: 000006f0
Call Trace: [<f9052f10>] .LC7 [jbd] 0x0 
[<f9049f47>] journal_get_write_access_Rsmp_a7d05437 [jbd] 0x37 
[<f905a7fc>] ext3_new_inode [ext3] 0x2ec 
[<c011cbeb>] call_console_drivers [kernel] 0xeb 
[<c01863a1>] add_timer_randomness [kernel] 0xd1 
[<f8ff8e84>] __scsi_end_request [scsi_mod] 0x1a4 
[<f8ff970f>] scsi_request_fn [scsi_mod] 0x27f 
[<f9014580>] sd_template [sd_mod] 0x0 
[<c019a37e>] generic_unplug_device [kernel] 0x2e 
[<c012136d>] __run_task_queue [kernel] 0x5d 
[<c0147dee>] __wait_on_buffer [kernel] 0x8e 
[<f906317f>] ext3_commit_super [ext3] 0x4f 
[<f9061269>] ext3_handle_error [ext3] 0x99 
[<f9067854>] .LC54 [ext3] 0x0 
[<f906137a>] __ext3_std_error [ext3] 0x3a 
[<f9065d20>] .LC57 [ext3] 0x960 
[<f9067854>] .LC54 [ext3] 0x0 
[<f9067abb>] .LC10 [ext3] 0x1c3 
[<f9052f00>] .rodata.str1.1 [jbd] 0x0 
[<f904fcd7>] __jbd_kmalloc [jbd] 0x27 
[<f904911e>] get_transaction [jbd] 0xbe 
[<f90491c6>] start_this_handle [jbd] 0x66 
[<f9049285>] start_this_handle [jbd] 0x125 
[<f904938f>] journal_start_Rsmp_ec53be73 [jbd] 0xbf 
[<f905f941>] ext3_create [ext3] 0x81 
[<f905c946>] ext3_commit_write [ext3] 0x236 
[<c012bdda>] zap_page_range [kernel] 0x4ba 
[<c0152eef>] vfs_create [kernel] 0x12f 
[<c0151c80>] cached_lookup [kernel] 0x10 
[<c0152c5a>] lookup_hash [kernel] 0x4a 
[<c01530bc>] open_namei [kernel] 0x15c 
[<f9059cd2>] ext3_file_write [ext3] 0x22 
[<c01462b6>] filp_open [kernel] 0x36 
[<c01465b6>] sys_open [kernel] 0x36 
[<c01073c3>] system_call [kernel] 0x33 


                         free                        sibling
  task             PC    stack   pid father child younger older
init          R 00000000  2836     1      0   811      10       (NOTLB)
Call Trace: [<c0125664>] schedule_timeout [kernel] 0x84 
[<c01255d0>] process_timeout [kernel] 0x0 
[<c015759e>] do_select [kernel] 0x20e 
[<c0157949>] sys_select [kernel] 0x339 
[<c01073c3>] system_call [kernel] 0x33 

keventd       S F7F63F68  5784     2      1             3S F7F61F68  5964     3
     1        (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd                   4     2 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd       S C213FF68  5784     4      1             5     3 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd       S C213DF68  5964     5      1             6     4 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd       S C213BF68  5784     6      1             7     5 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd       S C2139F68  5844     7      1             8     6 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd       S C2135F68  5964     8      1             9     7 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

keventd       S C2133F68  5784     9      1            23     8 (L-TLB)
Call Trace: [<c0129b3c>] context_thread [kernel] 0x13c 
[<c0107376>] ret_from_fork [kernel] 0x6 
[<c0105000>] stext [kernel] 0x0 
[<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0129a00>] context_thread [kernel] 0x0 

ksoftirqd_CPU S FFFFFFFE  5808    10      0            11     1 (L-TLB)
Call Trace: [<c012142f>] ksoftirqd [kernel] 0xaf 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0121380>] ksoftirqd [kernel] 0x0 

ksoftirqd_CPU S FFFFFFFE  5740    11      0            12    10 (L-TLB)
Call Trace: [<c012142f>] ksoftirqd [kernel] 0xaf 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0121380>] ksoftirqd [kernel] 0x0 

ksoftirqd_CPU S FFFFFFFE  5804    12      0            13    11 (L-TLB)
Call Trace: [<c012142f>] ksoftirqd [kernel] 0xaf 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0121380>] ksoftirqd [kernel] 0x0 

ksoftirqd_CPU S FFFFFFFE  5760    13      0            14    12 (L-TLB)
Call Trace: [<c012142f>] ksoftirqd [kernel] 0xaf 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c0121380>] ksoftirqd [kernel] 0x0 

[<c0105836>] arch_kernel_thread [kernel] 0x26 
S[<c01255d0>] process_timeout [kernel] 0x0 
Call Trace: [<c0105000>] stext [kernel] 0x0 
[<c0105836>] arch_kernel_thread [kernel] 0x26 
[<c013dd10>] kreclaimd [kernel] 0x0 
[<c0267dca>] .rodata.str1.1 [kernel] 0x2ca5 
[<c0267dca>] .rodata.str1.1 [kernel] 0x2ca5 
    20Call Trace: Call Trace: 
[<f904b8dc>] journal_commit_transaction [jbd] 0x3dc 
[<c0247689>] call_apic_timer_interrupt [kernel] 0x5 
[<c0239840>] stext_lock [kernel] 0x840 
[<f927e7ec>] khubd_wait [usbcore] 0x4 
   111[<c018fb53>] con_write [kernel] 0x23 
[<c024765a>] call_call_function_interrupt [kernel] 0x5 
[<c023d210>] stext_lock [kernel] 0x4210 
[<c0146fb4>] do_readv_writev [kernel] 0x204 
[<c0147143>] sys_writev [kernel] 0x43 
[<c021d56f>] unix_wait_for_peer [kernel] 0xaf 
[<c021e047>] unix_dgram_sendmsg [kernel] 0x337 
[<c0247689>] call_apic_timer_interrupt [kernel] 0x5 
[<c01d7af7>] sock_write [kernel] 0xa7 
      [<c01073c3>] system_call [kernel] 0x33 
[<c015759e>] do_select [kernel] 0x20e 
Call Trace: [<c0125664>] schedule_timeout [kernel] 0x84 
[<c0125664>] schedule_timeout [kernel] 0x84 
Call Trace:    806 (NOTLB)
Call Trace: [<c01255f4>] schedule_timeout [kernel] 0x14 
[<c018fb9d>] con_put_char [kernel] 0x3d 
[<c0183ef2>] write_chan [kernel] 0x1e2 
[<c012fd83>] sys_munmap [kernel] 0x33 
[<c0183ef2>] write_chan [kernel] 0x1e2 
[<c012fd83>] sys_munmap [kernel] 0x33 
[<c0183944>] read_chan [kernel] 0x3a4 
[<c0146c06>] sys_read [kernel] 0x96 
[<c01255f4>] schedule_timeout [kernel] 0x14 
[<c0146c06>] sys_read [kernel] 0x96 
Call Trace: [<c017f8a7>] tty_read [kernel] 0xd7 
bash          
      Free pages:      748596kB (  2040kB HighMem)
2038*8kB 4869*16kB 4123*32kB 3615*64kB 1303*128kB 335*256kB 40*512kB 0*1024kB
1*2048kB 0*4096kB = 734284kB
  active: 6017, inactive_dirty: 17498, inactive_clean: 0, free: 183571 (255 510 765)
1*16kB 1*32kB 1*64kB   active: 3770, inactive_dirty: 25940, inactive_clean: 0,
free: 510 (255 510 765)
Page cache size: 47483
2*4kB 0*8kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 2040kB
Swap cache: add 1379, delete 433, find 562/562
Buffer mem: 5760
Free swap:       4188688kB
Ramdisk pages: 0
262118 pages of RAM
32742 pages of HIGHMEM
5217 reserved pages
49428 pages shared
946 pages swap cached
28 pages in page table cache
3694 pages in slab cache
Buffer memory:    23040kB
    CLEAN: 48114 buffers, 192414 kbyte, 49 used (last=48114), 0 locked, 0
protected, 0 dirty
   LOCKED: 4 buffers, 16 kbyte, 4 used (last=4), 0 locked, 0 protected, 0 dirty


I also have another x255 using the same config with only 512MB memory, which is
running the e.27smp kernel, this machine is also panic'ing, but on
transactionc:612, this machine is using ServeRAID code 6.0, and driver shipped
with the kernel (6.00.26), I will install the e.27enterprise kerenel and rerun
test on this machine to see if the panic message changes. There was no
controller reset logged in the log.
Note that I do not get the ext-3 errors on the second x255.
I can send you the netdump log file for the second x255 if you require it.

I've tried kernels e.24, e.25 and e.27, enterprise kernels on customer system,
and smp kernels on test system.

If you require any files from any system. I will foward as required.
Comment 4 Stephen Tweedie 2003-09-26 07:29:13 EDT
The problem here is that we're hitting a debug trap which is usually valid, but
which is violated when there's an underlying IO error (due to the way in which
the block device layer marks buffers as non-uptodate when a write error occurs.)

The fix in later upstream kernels is to downgrade the panic into a kernel
warning (unless you enable the panic as a debugging compile-time option.)  I
have started testing the AS-2.1 backport of this patch.
Comment 5 Stephen Tweedie 2003-10-02 18:04:22 EDT
*** Bug 79163 has been marked as a duplicate of this bug. ***
Comment 8 Stephen Tweedie 2003-10-08 11:57:47 EDT
An unsupported engineering kernel containing this fix is now available for
testing and evaluation at

http://people.redhat.com/~jbaron/.private/testing/2.4.9-e.27.18.test/
Comment 9 Need Real Name 2003-10-10 05:07:20 EDT
I have been running the test on both servers for 40+ hours, and neither of them
has paniced yet.
The customer machine was showing IO errors as before, though the system never
paniced as it used to do. The system started showing these IO errors around 17:30
last night, and was running all night until 9:30 when I rebooted it.
The lab machine is still going strong.

I have to investigate the IO errors further, as they are almost as bad as the
panics.
Comment 10 Need Real Name 2003-10-15 07:10:22 EDT
The test has been running continously on the lab server since last friday with no
failure.

The customer machine still has IO errors, which I've not had the chance to look
into.
Comment 11 Need Real Name 2003-10-22 05:40:35 EDT
I've moved part around in the systemm, and here's the result:
1. Moving RAID controller between systems, the IO error was still present on the
customer system.
2. Moving Disks between machines, no IO error was seen on either machine.
3. Moving Controller and disks back to original state, the IO error reappeared on
customer system.

Recommended that parts be replaced in the following order:
1. SCSI Csbles.
2. Backplane.

Any outlook for kernel release ?
Comment 12 Stephen Tweedie 2003-10-22 06:11:19 EDT
Yes, it's scheduled for the U3 update.
Comment 19 mark wisner 2003-11-25 01:45:39 EST
------ Additional Comments From khoa@us.ibm.com  2003-25-11 01:45 -------
Fix is available (unsupported engineering kernel) and tested by IBM --> moving
this bug to Tested state.

We will close this bug once QU3 is out and we can verify that the fix is there.
Thanks. 
Comment 24 Brian Lin 2003-12-22 23:09:59 EST
brian.lin@innoag.com
Comment 25 Don Howard 2004-01-08 19:29:17 EST
The original bug reported here (kernel BUG at transaction.c:731!) 
has been corrected in AS2.1 QU3.    
 
Please reopen this ticket if you find evidence that the issue 
persists in the QU3 release. 
 
If there are other outstanding issues in this ticket, please open a 
new BZ ticket to address them. 
 
Comment 26 IBM Bug Proxy 2004-10-29 18:34:06 EDT
----- Additional Comments From khoa@us.ibm.com  2004-10-29 18:33 EDT -------
Please verify and close this bug report if possible.  Thanks. 
Comment 27 IBM Bug Proxy 2005-03-02 16:05:57 EST
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          QAContact|khoa@us.ibm.com             |corryk@us.ibm.com




------- Additional Comments From corryk@us.ibm.com(prefers email via kevcorry@us.ibm.com)  2005-03-02 16:01 EST -------
Hi Edward,

Please verify that this fix is available in the latest Redhat release. If so, go
ahead and close this bug. Thanks! 
Comment 28 IBM Bug Proxy 2005-04-01 10:29:09 EST
changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ACCEPTED                    |CLOSED
             Impact|------                      |Functionality




------- Additional Comments From corryk@us.ibm.com(prefers email via kevcorry@us.ibm.com)  2005-04-01 10:21 EST -------
Closing this bug since it's been inactive for a year or so. 

Note You need to log in before you can comment on or make changes to this bug.