Bug 119567 - passing ioctl to lower layer sd driver using ioctl_by_bdev does not work
Summary: passing ioctl to lower layer sd driver using ioctl_by_bdev does not work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brian Brock
URL: ioctl handling on AS 3 HUGEMEM
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-03-31 14:05 UTC by Arati Ranade
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-10-17 14:21:26 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
driver code (4.17 KB, text/plain)
2004-04-01 14:58 UTC, Arati Ranade
no flags Details
driver code, makefile, logs and dumps (18.52 KB, text/plain)
2004-04-01 14:59 UTC, Arati Ranade
no flags Details

Description Arati Ranade 2004-03-31 14:05:06 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)

Description of problem:
We are currently developing a driver over sd. This driver handles 
certain driver specific ioctls and the rest are passed down to the 
underlying sd device using ioctl_by_bdev.
On RedHat AS3.0 (2.4.21-9.0.1.EL) UP and SMP this is working 
correctly. However on the hugemem kernel there is a kernel panic. The 
hugemem kernel for AS3.0 has a 4GB-4GB split patch for the kernel and 
user memory. Can you please tell me if this is the reason for the 
crash and if so how I can avoid it. 
Please let me know if I am using the correct logic to pass the ioctls 
down to the lower layer.


Version-Release number of selected component (if applicable):
kernel-2.4.21-9.EL

How reproducible:
Always

Steps to Reproduce:
1. Use ioctl_by_bdev() to call underlying (sd) driver's ioctl
2.
3.
    

Actual Results:  kernel panic

Expected Results:  Info is obtained from underlying driver

Additional info:

Comment 1 Arjan van de Ven 2004-03-31 14:08:09 UTC
please provide an URL to the (GPL) source code of your driver so that
we can see what you are doing...

Comment 2 Arati Ranade 2004-04-01 14:58:18 UTC
Created attachment 99036 [details]
driver code

Comment 3 Arati Ranade 2004-04-01 14:59:30 UTC
Created attachment 99037 [details]
driver code, makefile, logs and dumps

Comment 4 Arati Ranade 2004-04-01 15:02:49 UTC
Driver code, makefile, logs and netdumps on both smp and HUGEMEM are 
attached. Run the scsi_unique_id /dev/sampledev command to get the 
output.

Comment 5 Doug Ledford 2005-10-17 14:21:26 UTC
This is a very old and obviously stale issue.  I'm assuming the reported found
the answer to their query sometime before now.  Closing this issue out.


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