From: David P. <pa...@rc...> - 2000-09-10 23:38:49
|
> ieee12844.c:1541: warning: initialization from incompatible pointer type > ieee12844.c:1542: warning: initialization from incompatible pointer type > ieee12844.c:1545: warning: initialization from incompatible pointer type > ieee12844.c:1547: warning: excess elements in struct initializer > ieee12844.c:1547: warning: (near initialization for `mlc_proto_ops') <snip> > When I try to insmod ieee12844.o I obtain: ieee12844 unresolved symbol > end_bh_atomic, ieee12844.o: unresolved symbol start_bh_atomic. <snip> > uname -a > Linux guizmo 2.4.0-test1 #10 SMP Sat Sep 9 16:51:13 CEST 2000 i686 > unknown Hi, Damcha. It appears that something changed in kernel 2.3/2.4 that broke the ieee12844 and ieee12844pp drivers. Since I'm not a kernel expert and don't have a 2.4 machine, I'm not sure how to fix this right now, but I'll look into it at some point. Does anyone else have any ideas here? > The apps compile without errors (except xojpanel -- I don't have QT > installed), ojlib also, ptal gives me some warnings (end of non void > functions and unused variables (cbd,dev,chan)) but compiles. The warnings in the ptal directory result from currently unused functions I started but haven't finished writing yet. David |
From: Damcha <da...@cy...> - 2000-09-13 18:47:45
|
Hello all, > Hi, Damcha. It appears that something changed in kernel 2.3/2.4 that broke > the ieee12844 and ieee12844pp drivers. You're right David, I've hacked for a few hours since my last messages, and I've found that (apparently) the function start_bh_atomic and end_bh_atomic don't exist any more since 2.3.43. So I just commented out these functions, and it compiled. I can insmod the modules, and run hpo devid without errors. But hpo get OID_STATUS_MSG_LINE1_PART1 replies: Error 11 (system error 22) in file pml.c, line 283: I got the same error for trap but in line 381, and for scan at line 246... If you want, I think I can go more indepth into this, and try to make hpoj 2.4-kernel compatible, or is there already someone working on this ? Damcha -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d--(+) s: a-- C++ UL+++ P+>++ L+++ E(+) W++ N+ o? K- w-- O? M V? PS++ PE- Y+ PGP t+ 5 X++ R(+) tv-(+) b+ DI D++ G e+++ h--- r++ y+++* ------END GEEK CODE BLOCK------ See http://www.geekcode.com |
From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2000-09-13 21:22:56
|
> You're right David, I've hacked for a few hours since my last > messages, > and I've found that (apparently) the function start_bh_atomic and > end_bh_atomic don't exist any more since 2.3.43. > So I just commented out these functions, and it compiled. > I can insmod the modules, and run hpo devid without errors. Hi, Damcha. I'm glad you got it working, but I would be a little concerned about just removing these calls altogether as opposed to trying to find out if there's a proper replacement in the newer kernels. > But hpo get OID_STATUS_MSG_LINE1_PART1 replies: > Error 11 (system error 22) in file pml.c, line 283: > I got the same error for trap but in line 381, This OID isn't supported on the PSC500. I don't remember if this is the right error or if it's failing for some other reason. Try some of the others, like OID_DEV_MODEL_NAME. > and for scan at line 246... Please try downloading version 0.6. It contains a patch to SANE 1.0.3 to allow scanning on some of the OfficeJets (including the PSC500). > If you want, I think I can go more indepth into this, and try to make > hpoj 2.4-kernel compatible, or is there already someone > working on this > ? If you're willing and able to do some kernel-level hacking like this, I would certainly appreciate it. I'm familiar with the communication protocols but rather ignorant when it comes to kernel issues. :-) It also seems that the kernel-mode drivers are broken for SMP. I'll forward the e-mails I've been exchanging about that, in hopes that you or somebody else might be able to figure it out. David |
From: Burkhard K. <bu...@bu...> - 2000-09-16 05:40:16
|
PASCHAL,DAVID (HP-Roseville,ex1) > > You're right David, I've hacked for a few hours since my last > > messages, > > and I've found that (apparently) the function start_bh_atomic and > > end_bh_atomic don't exist any more since 2.3.43. > > So I just commented out these functions, and it compiled. > > I can insmod the modules, and run hpo devid without errors. > > Hi, Damcha. I'm glad you got it working, but I would be a little concerned > about just removing these calls altogether as opposed to trying to find out > if there's a proper replacement in the newer kernels. From looking at newer 2.4.0-test kernels I noticed that all references to start_bh_atomic and end_bh_atomic have been removed. Both functions where inlines with start_bh_atomic calling synchronize_irq() which is a #define to barrier() in <asm/softirq.h> which in turn is a #define barrier() __asm__ __volatile__("": : :"memory") in <linux/kernel.h>. It seems that bottom halves synchronisation in 2.4.0 now is resolved in some automatted way. Maybe both functions should be renamed and defined in "ieee12844.h" somehow like: static void inline x_start_bh_atomic() { #if LINUX_VERSION_CODE > KERNEL_VERSION(2,3,xxx) #define x_start_bh_atomic() else #define x_start_bh_atomic() start_bh_atomic() #endif } Inclusion of start_bh_atomic and end_bh_atomic headers in ieee12844.c and ieee12844pp.c is not done directly from <asm/softirq.h> thus no particular treatment should be necessary. BTW: I am not familiar with socket programming, why is/was it necessary to explicitly synchronize bottom_halves? I would have expected (maybe naively) that this issue gets handled by lower layers. The parport driver does not use bh handlers. Burkhard -- Burkhard Kohl buk at/auf buks.ipn.de |