Re: [hpoj-devel] SMP Problems && ojpanel-on-steroids

[Burkhard K. <bu...@bu...>]

PASCHAL,DAVID (HP-Roseville,ex1)
> Hi, Damcha.  Sorry, I forgot you had indicated an interest in working on
> this.  The kernel driver code is begging for a better maintainer than me, so
> thanks for volunteering.  :-)  Burkhard also indicated an interest in this,
> but it sounds like you're more SMP-equipped than he is.  Anyway, I'll let
> the two of you decide how you want to go about working on this, and perhaps
> Gerhard can provide some technical guidance from time to time as well.  I
> shall look forward to your patches.  :-)

Hi David, Hi Damcha,

until now I did a quick and dirty patch to the hpoj kernel modules -
just substituted the xxx_bh_atomic primitives by their 2.4/SMP counter-
parts. I also adjusted the proto_ops struct to the changes which came
with the new 2.3 kernels. (Does someone know the exact 2.3.x version
where these changes were introduced?)
The kernel modules now look for the setting of CONFIG_SMP from 
<linux/config.h> and will define __SMP__ accordingly. Thus the 
modules will be compiled according to the SMP configuration 
of the main kernel.
To override this setting one may define FORCE_SMP with a value of 
"SMP".
(I also adjusted the indentation to make the sources a bit more
readable).

Someone really should look into the locking issue more 
carefully. I guess that spin_lock_bh could be substituted in a 
couple of places with a read_lock_bh or a write_lock_bh with these
primitives being less powerful(i.e. blocking) than locking with a 
spin_lock_bh.

Damcha, I would be glad to see the SMP/locking issues in your hands,
since I neither have a SMP system to test any patches nor am I 
familiar with SMP issues and you really sound like you want to
dig into it. 

With my patch the modules now compile smoothly against a 2.4.0-test7 
kernel and against a 2.2.14 SMP kernel.

But - unfortunately a test with 2.4.0-test7 showed that printing stops 
after a certain amount of data and that scanning failed resetting the 
device. I have attached the debug output from scanimage --test. As it 
stands my simple patch does not run properly on a 2.4.0 kernel and I
have to track down the reasons for failure.

Although it does not really work I thought I am going to post it in
a seperate mail so other people could look into it. I am especially 
curious to know wether the failure is 2.4 or locking related, i.e. 
does it run on a 2.2.x SMP system? 

Burkhard

------- Debug output from scanimage --test:
[sanei_debug] Setting debug level of hp to 128.
[hp] sane_init called
ptalInit(): debug level set to 5.
ptalInit()
ptalDeviceProbe: dev=<mlc:mlcpp0>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp0>): dev=0x0804E9A0.
ptalDeviceProbe: dev=<mlc:mlcpp1>.
ptalDeviceAdd(provider=<mlc>,name=<mlcpp1>): dev=0x0804E9D8.
[hp] sane_init will finish with Success
[hp] sane_get_devices called
[hp] hp_read_config: hp backend v0.91 starts reading config file
[hp] hp_read_config: processing line <mlc:mlcpp0>
[hp] hp_read_config: processing line <option connect-ptal>
[hp] hp_read_config: attach mlc:mlcpp0
[hp] hp_get_dev: New device mlc:mlcpp0, connect-ptal, scsi-request=0
ptalMlcDeviceOpen(name=<mlcpp0>): found matching dev=0x0804E9A0.
ptalChannelAllocate(dev=0x0804E9A0): chan=0x08052AA8.
ptalChannelSetRemoteService(chan=0x08052AA8,serviceType=2,socketID=0,serviceName=<>)
[hp] scsi_flush: writing 2 bytes:
[hp]  0x0000  1B 45                                            .E
ptalChannelOpen(chan=0x08052AA8): fd=5.
ptalChannelWrite(chan=0x08052AA8,buffer=0x08052276,count=2)
ptalChannelWrite(chan=0x08052AA8,buffer=0x08052276,count=2) returns -1.
[hp] hp_nonscsi_device_new: SCL reset failed
[hp] scsi_close: closing fd 5
ptalChannelClose(chan=0x08052AA8)
[hp] sane_get_devices will finish with Success
lt-scanimage: no SANE devices found
[hp] sane_exit called
[hp] sane_exit will finish

-- 
Burkhard Kohl			bu...@bu...