Hi Randy,
Sorry about the lag in replying, I have been away over the weekend.
In reply:
a. I haven't actually got a copy of 2.3.99 yet (I haven't got around to
patching up yet) but looking at 2.3.50 I don't think so.
Problem #1 is not a problem because the inode_operations structure no longer
contains a default_file_ops member, so not having it initialised is not an
issue (although I haven't tracked down exactly how it is that the file
operations are located now).
Problem #2 is also not a problem for similar reasons.
Problem #3 is not a problem because the build_proc_dir_entries function in
2.3.51 does not assume that the proc_dir entry in the scsi host template is
filled in (in fact it immediately overwrites it with a new value, even if it
did previously contain something).
It seems likely that all three of these problems crept in during the
backporting process.
b. Yes it does seem to work OK. I haven't done extensive testing (and in
particular I haven't tried to write a CD yet) but certainly just reading
CD's in my Iomega ZipCD does work quite well.
Regards,
Mike
----- Original Message -----
From: Dunlap, Randy <[EMAIL PROTECTED]>
To: 'Mike Harris' <[EMAIL PROTECTED]>; linux-usb <[EMAIL PROTECTED]>
Sent: Friday, April 07, 2000 9:09 PM
Subject: RE: [linux-usb] USB Backport: /proc/bus/usb empty and kernel oops
from scsi
| Hi Mike,
|
| Good work you've done on this.
|
| 2 questions (without looking at the patch too closely):
|
| a. Should these patches be applied only to the backport
| and not the 2.3.99++ source files?
|
| b. Does usb-storage work under 2.2 with these patches?
| For a while now it hasn't worked under 2.2 and it wasn't
| exactly a high priority to fix it.
|
| Thanks,
| Randy
| ___________________________________________________
| |Randy Dunlap Intel Corp., DAL Sr. SW Engr.|
| |randy.dunlap.at.intel.com 503-696-2055|
| |NOTE: Any views presented here are mine alone |
| |and may not represent the views of my employer. |
| |_________________________________________________|
|
| > -----Original Message-----
| > From: Mike Harris [mailto:[EMAIL PROTECTED]]
| > Sent: Thursday, April 06, 2000 2:49 PM
| > To: linux-usb; [EMAIL PROTECTED]
| > Subject: [linux-usb] USB Backport: /proc/bus/usb empty and kernel oops
| > from scsi
| >
| > Hi,
| >
| > I have discovered a few (easily fixed) faults with the USB backport:
| >
| > 1. Nothing in /proc/bus/usb even when usbdevfs mounted
| > ======================================================
| >
| > Symptoms: Even when usbdevfs is mounted on /proc/bus/usb, 'ls' shows
| > no files or directories. A simple test program that reads the
| > directory
| > entries using system calls reports error ENOTDIR from call to
| > sys_getdents.
| >
| > The problem is caused by usbdevfs_root_inode_operations and
| > usbdevfs_bus_inode_operations not having an initialised
| > default_file_ops member.
| >
| > 2. Can't read /proc/bus/usb/drivers or /proc/bus/usb/devices
| > ============================================================
| >
| > Symptoms: (After fixing #1 above) Attempts to 'cat' the above
| > mentioned files fails.
| >
| > The problem is caused by missing code in function
| > usbdevfs_read_inode. This
| > function should set the inode->i_ops field but does not do so
| > - it looks like
| > this code was deleted when the backport was done, due to
| > differences in the
| > way inode structs were set up in the later kernels.
| >
| > Under 2.2.14, inode structs contain an i_ops field that
| > points to an i_ops
| > struct; this struct in turn points to the fops struct that
| > describes file
| > operations that can be performed on the file.
| >
| > Under 2.3.xx kernels the inode struct directly contains a
| > pointer to the fops
| > struct, rather than indirectly via an i_ops struct.
| >
| >
| > 3. Kernel OOPS when mass storage device is connected
| > ====================================================
| >
| > Symptoms: A kernel oops 'Unable to handle kernel NULL pointer
| > dereference
| > at virtual address 00000014' when a mass storage device is
| > connected. I saw
| > it when connecting an Iomega ZIPCD USB CD Rewriter. The oops
| > message (when
| > decoded) points out build_proc_dir_entries in scsi.c as the offending
| > function.
| >
| > This problem is caused in the us_detect function, where the
| > proc_dir field in the
| > SCSI Host Template structure is set to NULL. This is OK in
| > 2.3.xx kernels
| > because in the build_proc_dir_entries function, the proc_dir
| > field is filled in.
| > However, in 2.2.14 this function assumes proc_dir already
| > contains a valid proc_dir_entry pointer.
| >
| > Patches to fix these problems are below.
| >
| > BTW, I have managed to get the ZIPCD drive working quite well
| > for reading CD's.
| > I haven't worked up the courage to try burning a CD yet! I
| > did try reading an
| > audio CD with cdparanoia - this failed miserably, I kept getting
| >
| > 'kernel: usb_control/bulk_msg: timeout'
| >
| > Any ideas??
| >
| > Regards,
| > Mike
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
