From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

Description of problem:
 We have a Toshiba E3511 photocopier which makes a samba share of scanned documents available.  When the share is mounted, commands like rsync and ls work (mostly) to give a list of the files in the directory or copy them to other disks.  Today, i was faced with a directory containing 305 files, more than I have had to deal with before.  Simply cd'ing to the directory and typing ls gave a directory listing; attempting to cp the files from the photocopier to the local machine caused a hard kernel lockup on the local machine.  This occurred for kernels 2.6.10 (custom compiled) and the stock Fedora 2.6.11-1.27_FC3 and 2.6.11-1.35_FC3.  

Version-Release number of selected component (if applicable):
kernels 2.6.10,  2.6.11-1.27_FC3,  2.6.11-1.35_FC3

How reproducible:
Always

Steps to Reproduce:
1. mount -t smbfs \\\\physpr19\\FILE_SHARE /mnt/physpr19/
2. cd /mnt/physpr19/
3. <tab>, cp, ls ...
  

Actual Results:  system locks up hard. not even magic sysreq keys get a response. 

Expected Results:  list of available files in the directory should be displayed

Additional info:

I have tried this from two machines, both FC3, but with different kernel versions.  The only oops information I could capture was from a custom 2.6.10 kernel which confessed that it had called:
 dput
 kfree
 smb_setup_request
 smb_addrequest
 filldir64 several times
 smb_readdir(64? or long )
 and then mm/slab.c whinged about
   spin_is_locked on uninitialized spinlock, 
 Kernel Panic
and the system died.

That system was responsive for the sysreq keys and so syncing disks and so on worked.  My understanding of the sysreq-task list seemed to say that smbiod was taking all the CPU. When rebooted, I mounted the smb share, did an rsync of the data to the local disk, being careful to never ask for tab completion while typing the path, and the copy worked.  Immediately after the copy completed, i cd'ed to the mounted directory and pressed <tab> in bash to get an automagic file list and the system died.  Again a hard crash, no sysreq key response.

What is weird is that the simply `ls' of the directory didn't create a lockup directly all the time (did on one machine, but not on another: it is possible that the tab completion was involved in the first lockup).  Attempting tab completion, via bash, of any filename on the smb share, or simply to see the file list, caused immediate and catastrophic lockup.  

The photocopier providing the smb service is running linux 2.4.x.  The machines which crashed are UP machines.  This type of file access is commonly used here and has always been successful up 'til yesterday, but normally the directories on the smb server have less than 200 files.

The machines are in production environments, so I have only limited time to run any tests.  However, if specific testing is needed, I may be able to schedule it.