Linux PARISC architecture development
 help / color / mirror / Atom feed
* [parisc-linux] evms-0.9.1 && hppa (follow ...)
@ 2002-03-06 18:57 Joël Soete
  2002-03-06 22:19 ` Grant Grundler
  0 siblings, 1 reply; 5+ messages in thread
From: Joël Soete @ 2002-03-06 18:57 UTC (permalink / raw)
  To: parisc-linux

[-- Attachment #1: Type: text/plain, Size: 6738 bytes --]

Hi all,

Awaiting the LKCD of Bruno, I try to figure out how to debug this bug
crashing the system without any other debuging then printk.

So with the help of a developper of evems (Kevin Corry) I put some printk
around ioctl code where crash occurs as follow:

...
int
evms_cs_allocate_memory(void **pp, int size)
{
        int rc = 0;

     printk(KERN_ERR "--evms: %s, %s call; size=%u.\n", __FILE__ ,
__FUNCTION__,  size );
     /* verify a valid size parameter was specified */
     if (size <= 0)
          /* return NULL on invalid size */
          *pp = NULL;
     else {
          *pp = kmalloc(size, GFP_KERNEL);
//        *pp = kmalloc(size, GFP_NOIO);
          if (*pp == NULL)
               rc = -ENOMEM;
          else {
               memset(*pp, 0, size);
               atomic_inc(&evms_allocs);
     printk(KERN_ERR "--evms: %s, %s call; size=%u, aft atomic_inc.\n",
__FILE__ , __FUNCTION__,  size );
          }
     }

        return(rc);
}
EXPORT_SYMBOL(evms_cs_allocate_memory);
...
#define MAX_IO_SIZE 128
static int
evms_ioctl_cmd_sector_io(void * arg)
{
        int rc;
     evms_sector_t io_size = MAX_IO_SIZE;
        evms_sector_io_t tmp, *user_parms;
        evms_logical_node_t *disk_node = NULL;
        evms_list_node_t *list_node;
        unsigned char *io_buffer;

     printk(KERN_ERR "--evms: %s, %s call.\n", __FILE__ , __FUNCTION__ );
     printk(KERN_ERR "io_buffer address: %u.\n", &io_buffer);
        rc = 0;
        list_node = NULL;
        io_buffer = NULL;

        user_parms = (evms_sector_io_t *)arg;
        /* copy user's parameters to kernel space */
        if (copy_from_user(&tmp, user_parms, sizeof(tmp)))
                rc = -EFAULT;

        /* check handle for validity */
        if (!rc) {
                rc = -EINVAL;
                disk_node = (evms_logical_node_t *)(tmp.disk_handle ^
EVMS_HANDLE_KEY);
                for (list_node = evms_global_device_list; list_node;
list_node = list_node->next)
                        if (list_node->item == disk_node) {
                                rc = 0;
                                break;
                        }
        }
        if (!rc) {
          /* allocate a io buffer upto 64Kbytes in size */
          if (tmp.sector_count < MAX_IO_SIZE)
               io_size = tmp.sector_count;

          /* allocate buffer large enough to hold a single sector */
                rc = evms_cs_allocate_memory(
               (void **)&io_buffer,
               io_size << EVMS_VSECTOR_SIZE_SHIFT);
     }
        /* perform io with specified disk */
        if (!rc) {
          evms_sector_t io_sector_offset, io_remaining;
          u_int64_t io_bytes;
          u_char *user_buffer_ptr;

          printk(KERN_ERR "--evms: %s, %s call, ckp6; rc=%i.\n", __FILE__ ,
__FUNCTION__, rc );
          io_remaining = tmp.sector_count;
          printk(KERN_ERR "--evms: %s, %s call, ckp7: io_remaining=%llu.
\n", __FILE__ , __FUNCTION__, io_remaining );
          io_sector_offset = 0;
          printk(KERN_ERR "--evms: %s, %s call, ckp7p: io_sector_offset
=%llu.\n", __FILE__ , __FUNCTION__, io_sector_offset );
          user_buffer_ptr = user_parms->buffer_address;
          printk(KERN_ERR "--evms: %s, %s call, ckp7pp.\n", __FILE__ ,
__FUNCTION__ );
          while(io_remaining) {
               /* compute the io_size for this pass */
               io_size = (io_remaining >= MAX_IO_SIZE) ?
                    MAX_IO_SIZE : io_remaining;

               io_bytes = io_size << EVMS_VSECTOR_SIZE_SHIFT;
                        /* for writes, copy a sector from user to kernel */
               printk(KERN_ERR "--evms: %s, %s call, ckp8; io_size=%i.\n",
__FILE__ , __FUNCTION__, io_size );
                        if (tmp.io_flag == 1) {
                                /* copy sector from user data buffer */
                                if (copy_from_user(io_buffer,
                                 user_buffer_ptr,
                                 io_bytes))
                                        rc = -EFAULT;
                        }
               printk(KERN_ERR "--evms: %s, %s call, ckp8; rc=%i.\n",
__FILE__ , __FUNCTION__, rc );
                        if (rc) break;

                        /* perform IO one sector at a time */
                        rc = INIT_IO(
                                disk_node,
                                tmp.io_flag,
                                io_sector_offset + tmp.starting_sector,
                                io_size,
                                io_buffer);
               printk(KERN_ERR "--evms: %s, %s call, ckp9; rc=%i.\n",
__FILE__ , __FUNCTION__, rc );

...

and here is what I obtain:
(capture with minicom on another system)

--ldev_mgr: scsi: Channel = 0, Id = 6, Lun = 0, Capacity = 17773524
--ldev_mgr: scsi: Channel = 0, Id = 3, Lun = 0, Capacity = 4194685
--evms: evms.c, evms_ioctl_cmd_sector_io call.
io_buffer address: 374884016.
--evms: evms.c, evms_cs_allocate_memory call; size=512.
--evms: evms.c, evms_cs_allocate_memory call; size=512, aft atomic_inc.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp6; rc=0.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp7: io_remaining=1.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp7p: io_sector_offset=0.
WARNING! Stack pointer and cr31 do not correspond!
Dumping virtual address stack instead
...

(I also attache the full log if interest)

So it seems to failled on the assignement: "user_buffer_ptr =
user_parms->buffer_address;" . That is over my understanding without much
help. Any idea ?

Thanks in advance for attention and help,
     Joel

PS1: I cast (size_t) in the call to evms_cs_allocate_memory because I
suspect
first a BigEndian problem in the conversion between a unsigned long long
and
unsigned int . But it is not (another simple test prove it).

PS2: I also suspect a problem of optimisation with gcc-3 (known bug) and I
recompile all kernel and tools with option -O1 but no more success.

PS3: I use here the precompile tools of Debian pakage but as I presume it
does
not help. (I still have to post a major bug report about it for this panic)

PS4: This tools works perfectly on my i386 with a ext3 fs for the dir I
used the most: /usr/src until two weeks without any problems

(See attached file: K-2.4-Evms.doc.gz)

**********************************************************************
This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient.  If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail.
Thank you for your co-operation.
**********************************************************************

[-- Attachment #2: K-2.4-Evms.doc.gz --]
[-- Type: application/octet-stream, Size: 7443 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [parisc-linux] evms-0.9.1 && hppa (follow ...)
@ 2002-03-07 14:32 Joël Soete
  2002-03-07 17:06 ` Grant Grundler
  0 siblings, 1 reply; 5+ messages in thread
From: Joël Soete @ 2002-03-07 14:32 UTC (permalink / raw)
  To: Grant Grundler; +Cc: parisc-linux

Hello Grant,

Thanks a lot.

I am not quiet sure to be absolutely right but for a first test, I only
change "user_parms->buffer_address" by "tmp.buffer_address"
and the system does not anymore crashes:

--ldev_mgr: scsi: Channel =3D 0, Id =3D 6, Lun =3D 0, Capacity =3D 17773524
--ldev_mgr: scsi: Channel =3D 0, Id =3D 3, Lun =3D 0, Capacity =3D 4194685
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp7pp.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp8; io_size=3D271570960.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp8; rc=3D0.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp9; rc=3D0.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp10.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp11.
evms_vgscan(267): unaligned access to 0x00022efe at ip=3D0x40207d8f
--ldev_mgr: unrecognized device major : 58

--ldev_mgr: unrecognized device major : 9
--ldev_mgr: found SCSI major : 66 - searching for disks
--ldev_mgr: scsi: major name =3D sd
--ldev_mgr: scsi: number of real devices =3D 0


--ldev_mgr: found SCSI major : 65 - searching for disks
--ldev_mgr: scsi: number of real devices =3D 0
--ldev_mgr: found SCSI major : 8 - searching for disks
--ldev_mgr: scsi: major name =3D sd
--ldev_mgr: scsi: number of real devices =3D 3
--ldev_mgr: scsi: Channel =3D 0, Id =3D 5, Lun =3D 0, Capacity =3D 17773524
--ldev_mgr: scsi: Channel =3D 0, Id =3D 6, Lun =3D 0, Capacity =3D 17773524
--ldev_mgr: scsi: Channel =3D 0, Id =3D 3, Lun =3D 0, Capacity =3D 4194685
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp7pp.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp8; io_size=3D271570960.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp8; rc=3D0.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp9; rc=3D0.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp10.
--evms: evms.c, evms_ioctl_cmd_sector_io call, ckp11.

As you can see it is not yes perfect because: "evms_vgscan(267): unaligned
access to 0x00022efe at ip=3D0x40207d8f"
and also logs a lot of data page fault:

Mar  7 14:56:03 palinux kernel: do_page_fault() pid=3D267 command
=3D'evms_vgscan' type=3D15 address=3D0x00000000
Mar  7 14:56:03 palinux kernel:
Mar  7 14:56:03 palinux kernel:      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Mar  7 14:56:03 palinux kernel: PSW: 00000000000001101111111100001111 Not
tainted
Mar  7 14:56:03 palinux kernel: r00-03  00000000 40070db4 4020910b faf00a80
Mar  7 14:56:03 palinux kernel: r04-07  4008572c 00000000 00000000 00024b00
Mar  7 14:56:03 palinux kernel: r08-11  40240174 000c0e10 000cdc20 000cdae0
Mar  7 14:56:03 palinux kernel: r12-15  00000000 000cdc30 00000000 00000000
Mar  7 14:56:03 palinux kernel: r16-19  00000000 000b2408 00017800 4008572c
Mar  7 14:56:03 palinux kernel: r20-23  40027392 40084dc4 4005f750 4023fc94
Mar  7 14:56:03 palinux kernel: r24-27  00000000 40070db4 00000009 00021b78
Mar  7 14:56:03 palinux kernel: r28-31  00000004 4022b7d4 faf00c40 4020910b
Mar  7 14:56:03 palinux kernel: sr0-3   000003c7 000003c7 00000000 000003c7
Mar  7 14:56:03 palinux kernel: sr4-7   000003c7 000003c7 000003c7 000003c7
Mar  7 14:56:03 palinux kernel:
Mar  7 14:56:03 palinux kernel: IASQ: 000003c7 000003c7 IAOQ: 4005f79b
4005f79f
Mar  7 14:56:03 palinux kernel:  IIR: 0ca01086    ISR: 000003c7  IOR:
00000000
Mar  7 14:56:03 palinux kernel:  CPU:        0   CR30: 16568000 CR31:
10398000
Mar  7 14:56:03 palinux kernel:  ORIG_R28: 00000000

But that is in user space and there gdb (or ddd) will help me.
I will transmit your discover to Kevin it will certainly also help for
i386.

Humm ... have you an idea why this problem did not appears for this i386 or
ppc (the two official supported till now)?

Thanks again for great help,
  Joel

PS: about "getting stack unwinds for problems like this would be really
nice...(hint hint)"
is there somewhere something like which could be modified to hppa (I do not
have a wide skill in programing in user space and none in kernel space, so
I am not sure to be helpfull)



                                                                           =
                                          =20
                    Grant Grundler                                         =
                                          =20
                    <grundler@dsl2.extern        To:     "Jo=EBl Soete" <js=
o@europay.com>                              =20
                    al.hp.com>                   cc:     parisc-linux@lists=
.parisc-linux.org                         =20
                                                 Subject:     Re: [parisc-l=
inux] evms-0.9.1 && hppa (follow ...)     =20
                    06-03-02 11:19 PM                                      =
                                          =20
                                                                           =
                                          =20
                                                                           =
                                          =20




"=3D?iso-8859-1?Q?Jo=3DEBl_Soete?=3D" wrote:

>           printk(KERN_ERR "--evms: %s, %s call, ckp7p: io_sector_offset
> =3D%llu.\n", __FILE__ , __FUNCTION__, io_sector_offset );
>           user_buffer_ptr =3D user_parms->buffer_address;
>           printk(KERN_ERR "--evms: %s, %s call, ckp7pp.\n", __FILE__ ,
> __FUNCTION__ );
....

> So it seems to failled on the assignement: "user_buffer_ptr =3D
> user_parms->buffer_address;" . That is over my understanding without much
> help. Any idea ?

Could it be that "user_parms->buffer_address" should really be
"tmp->buffer_address"?

Just wondering if the copy_from_user() higher up in the code means
arg points to something in userspace. getting stack unwinds
for problems like this would be really nice...(hint hint)

grant






**********************************************************************
This e-mail and any attachments to it may contain confidential information =
which is strictly intended for the use of the authorised recipient.  If you=
 have received this e-mail in error, please delete it and notify the sender=
 by replying to this e-mail.
Thank you for your co-operation.
**********************************************************************

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-03-07 23:26 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-06 18:57 [parisc-linux] evms-0.9.1 && hppa (follow ...) Joël Soete
2002-03-06 22:19 ` Grant Grundler
  -- strict thread matches above, loose matches on Subject: below --
2002-03-07 14:32 Joël Soete
2002-03-07 17:06 ` Grant Grundler
2002-03-07 23:25   ` Matthew Wilcox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox