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]
