2.4 vs 2.6 versions of include/linux/ioport.h

2.4 vs 2.6 versions of include/linux/ioport.h

[Gene Heskett]

Greetings;

In the 2.4 includes, find this in ioport.h
----
/* Compatibility cruft */
#define check_region(start,n)   __check_region(&ioport_resource, 
(start), (n))
[snip]
extern int __check_region(struct resource *, unsigned long, unsigned 
long);
----
But in the 2.6 version, find this:
----
/* Compatibility cruft */
[snip]
extern int __check_region(struct resource *, unsigned long, unsigned 
long);
[snip]
static inline int __deprecated check_region(unsigned long s, unsigned 
long n)
{
        return __check_region(&ioport_resource, s, n);
}
----
First, the define itself is missing in the 2.6 version.

Many drivers seem to use this call, and in that which I'm trying to 
build, the nforce and advansys modules use it.  And while the modules 
seem to build, they do not run properly.

I cannot run 2.6.x for extended tests because of the advansys breakage 
this causes.  I also haven't even tried to run X because of the 
nforce error reported when its built, the same error as attacks the 
advansys code.

Can I ask why this change was made, and is there a suitable 
replacement call available that these drivers could use instead of 
check_region(), as shown here in a snip from advansys.c?
----
if (check_region(iop, ASC_IOADR_GAP) != 0) {
...
if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
...

Hopeing for some hints here.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Randy.Dunlap]

On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett <gene.heskett@verizon.net> wrote:

| Greetings;
| 
| In the 2.4 includes, find this in ioport.h
| ----
| /* Compatibility cruft */
| #define check_region(start,n)   __check_region(&ioport_resource, 
| (start), (n))
| [snip]
| extern int __check_region(struct resource *, unsigned long, unsigned 
| long);
| ----
| But in the 2.6 version, find this:
| ----
| /* Compatibility cruft */
| [snip]
| extern int __check_region(struct resource *, unsigned long, unsigned 
| long);
| [snip]
| static inline int __deprecated check_region(unsigned long s, unsigned 
| long n)
| {
|         return __check_region(&ioport_resource, s, n);
| }
| ----
| First, the define itself is missing in the 2.6 version.
| 
| Many drivers seem to use this call, and in that which I'm trying to 
| build, the nforce and advansys modules use it.  And while the modules 
| seem to build, they do not run properly.
| 
| I cannot run 2.6.x for extended tests because of the advansys breakage 
| this causes.  I also haven't even tried to run X because of the 
| nforce error reported when its built, the same error as attacks the 
| advansys code.
| 
| Can I ask why this change was made, and is there a suitable 
| replacement call available that these drivers could use instead of 
| check_region(), as shown here in a snip from advansys.c?
| ----
| if (check_region(iop, ASC_IOADR_GAP) != 0) {
| ...
| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
| ...
| 
| Hopeing for some hints here.

check_region() was racy.  Use request_region() instead.

   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
   ...

   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
   ...

Of course, if successful, this assigns the region to the driver,
while check_region() didn't do this, so release_region() should be
used as needed to return the resources.

--
~Randy

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Gene Heskett]

On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett 
<gene.heskett@verizon.net> wrote:
>| Greetings;
>|
>| In the 2.4 includes, find this in ioport.h
>| ----
>| /* Compatibility cruft */
>| #define check_region(start,n)   __check_region(&ioport_resource,
>| (start), (n))
>| [snip]
>| extern int __check_region(struct resource *, unsigned long,
>| unsigned long);
>| ----
>| But in the 2.6 version, find this:
>| ----
>| /* Compatibility cruft */
>| [snip]
>| extern int __check_region(struct resource *, unsigned long,
>| unsigned long);
>| [snip]
>| static inline int __deprecated check_region(unsigned long s,
>| unsigned long n)
>| {
>|         return __check_region(&ioport_resource, s, n);
>| }
>| ----
>| First, the define itself is missing in the 2.6 version.
>|
>| Many drivers seem to use this call, and in that which I'm trying
>| to build, the nforce and advansys modules use it.  And while the
>| modules seem to build, they do not run properly.
>|
>| I cannot run 2.6.x for extended tests because of the advansys
>| breakage this causes.  I also haven't even tried to run X because
>| of the nforce error reported when its built, the same error as
>| attacks the advansys code.
>|
>| Can I ask why this change was made, and is there a suitable
>| replacement call available that these drivers could use instead of
>| check_region(), as shown here in a snip from advansys.c?
>| ----
>| if (check_region(iop, ASC_IOADR_GAP) != 0) {
>| ...
>| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>| ...
>|
>| Hopeing for some hints here.
>
>check_region() was racy.  Use request_region() instead.
>
>   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
>   ...
>
>   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
>   ...
>
>Of course, if successful, this assigns the region to the driver,
>while check_region() didn't do this, so release_region() should be
>used as needed to return the resources.

Oops... I have a test compile going that changed those to 
check_mem_region.  And while I didn't change the i2c stuff, which 
still reports the error, advansys.o built w/o error this time.

Ok, so I can change that to !request_region, but I have NDI when to go 
about releasing it, if ever, for a kernel driver thats either there, 
and the hardware is used, or not because the hardware isn't present.  
It seems to me that if its allocated to this driver, and capable of 
being re-used at anytime, then the allocation should, once made, 
stand.  Or is my view of the world skewed and it should be done at 
the bottom of whatever conditional is involved?  Inquiring minds want 
to know.  I guess it all depends on what happens if the call is 
repeated.  Will it assign a new buffer each time?, thereby causeing a 
memory leak, or will it find its been done once and return success 
anyway?


Thanks very much for the quick response.

>--
>~Randy

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Randy.Dunlap]

On Tue, 5 Aug 2003 11:22:35 -0400 Gene Heskett <gene.heskett@verizon.net> wrote:

| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett 
| <gene.heskett@verizon.net> wrote:
| >| ----
| >| First, the define itself is missing in the 2.6 version.
| >|
| >| Many drivers seem to use this call, and in that which I'm trying
| >| to build, the nforce and advansys modules use it.  And while the
| >| modules seem to build, they do not run properly.
| >|
| >| I cannot run 2.6.x for extended tests because of the advansys
| >| breakage this causes.  I also haven't even tried to run X because
| >| of the nforce error reported when its built, the same error as
| >| attacks the advansys code.
| >|
| >| Can I ask why this change was made, and is there a suitable
| >| replacement call available that these drivers could use instead of
| >| check_region(), as shown here in a snip from advansys.c?
| >| ----
| >| if (check_region(iop, ASC_IOADR_GAP) != 0) {
| >| ...
| >| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
| >| ...
| >|
| >| Hopeing for some hints here.
| >
| >check_region() was racy.  Use request_region() instead.
| >
| >   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
| >   ...
| >
| >   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
| >   ...
| >
| >Of course, if successful, this assigns the region to the driver,
| >while check_region() didn't do this, so release_region() should be
| >used as needed to return the resources.
| 
| Oops... I have a test compile going that changed those to 
| check_mem_region.  And while I didn't change the i2c stuff, which 
| still reports the error, advansys.o built w/o error this time.
| 
| Ok, so I can change that to !request_region, but I have NDI when to go 
| about releasing it, if ever, for a kernel driver thats either there, 
| and the hardware is used, or not because the hardware isn't present.  

release_region() is already done for the normal case.
It needs to be added for the error cases in advansys_detect()
[wow, what a long function].
For your kernel(s) and known hardware, it may not be much of an
issue.  However, the in-kernel driver needs to be repaired, but
it seems that not many people have the hardware...

| It seems to me that if its allocated to this driver, and capable of 
| being re-used at anytime, then the allocation should, once made, 
| stand.

Yes, request_region() should keep the region assigned until the driver
is exiting (unloading).  release_region() is already done in
advansys_release().

| Or is my view of the world skewed and it should be done at 
| the bottom of whatever conditional is involved?  Inquiring minds want 
| to know.  I guess it all depends on what happens if the call is 
| repeated.  Will it assign a new buffer each time?, thereby causeing a 
| memory leak, or will it find its been done once and return success 
| anyway?

advansys_detect() should call release_region() if it encounters errors
[after it has called request_region() and returns an error].

request_region() doesn't assign buffers, it allocates IO resources,
as seen in /proc/ioports or /proc/iomem.  I don't know what happens
on repeated calls by the same driver|module, but in general a second
call will fail if the region is already allocated.

--
~Randy

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Gene Heskett]

On Tuesday 05 August 2003 11:45, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 11:22:35 -0400 Gene Heskett 
<gene.heskett@verizon.net> wrote:
>| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>|
>| <gene.heskett@verizon.net> wrote:
>| >| ----
>| >| First, the define itself is missing in the 2.6 version.
>| >|
>| >| Many drivers seem to use this call, and in that which I'm
>| >| trying to build, the nforce and advansys modules use it.  And
>| >| while the modules seem to build, they do not run properly.
>| >|
>| >| I cannot run 2.6.x for extended tests because of the advansys
>| >| breakage this causes.  I also haven't even tried to run X
>| >| because of the nforce error reported when its built, the same
>| >| error as attacks the advansys code.
>| >|
>| >| Can I ask why this change was made, and is there a suitable
>| >| replacement call available that these drivers could use instead
>| >| of check_region(), as shown here in a snip from advansys.c?
>| >| ----
>| >| if (check_region(iop, ASC_IOADR_GAP) != 0) {
>| >| ...
>| >| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>| >| ...
>| >|
>| >| Hopeing for some hints here.
>| >
>| >check_region() was racy.  Use request_region() instead.
>| >
>| >   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
>| >   ...
>| >
>| >   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
>| >   ...
>| >
>| >Of course, if successful, this assigns the region to the driver,
>| >while check_region() didn't do this, so release_region() should
>| > be used as needed to return the resources.
>|
>| Oops... I have a test compile going that changed those to
>| check_mem_region.  And while I didn't change the i2c stuff, which
>| still reports the error, advansys.o built w/o error this time.
>|
>| Ok, so I can change that to !request_region, but I have NDI when
>| to go about releasing it, if ever, for a kernel driver thats
>| either there, and the hardware is used, or not because the
>| hardware isn't present.
>
>release_region() is already done for the normal case.
>It needs to be added for the error cases in advansys_detect()
>[wow, what a long function].
>For your kernel(s) and known hardware, it may not be much of an
>issue.  However, the in-kernel driver needs to be repaired, but
>it seems that not many people have the hardware...
>
>| It seems to me that if its allocated to this driver, and capable
>| of being re-used at anytime, then the allocation should, once
>| made, stand.
>
>Yes, request_region() should keep the region assigned until the
> driver is exiting (unloading).  release_region() is already done in
> advansys_release().
>
>| Or is my view of the world skewed and it should be done at
>| the bottom of whatever conditional is involved?  Inquiring minds
>| want to know.  I guess it all depends on what happens if the call
>| is repeated.  Will it assign a new buffer each time?, thereby
>| causeing a memory leak, or will it find its been done once and
>| return success anyway?
>
>advansys_detect() should call release_region() if it encounters
> errors [after it has called request_region() and returns an error].
>
>request_region() doesn't assign buffers, it allocates IO resources,
>as seen in /proc/ioports or /proc/iomem.  I don't know what happens
>on repeated calls by the same driver|module, but in general a second
>call will fail if the region is already allocated.
>
>--
>~Randy

All that code is loosely bundled under the heading of advansys_init, 
and from the useage of a header constant in the code to control the 
"for (i = CONSTANT" loop above it, would appear to be looped 11 
times.  Thats not the correct syntax of course, but you get the idea 
I hope.

I've built it that way now, without any errors, so its time to go fire 
up a weed eater acording to the missus, and I'll do a test reboot 
later tonight just for any grins it might generate.  I also took all 
the i2c stuff out, and might try building that once I'm rebooted, but 
I think a name change was made from "modversions" in the 
lib/modules/version tree, so that will probably fail until I fix the 
&^%$@() makefile.

I'll let you know how it goes later.  Many thanks for the help, I 
figured I was dead and would have to go buy a (spit) adaptec card.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.4 vs 2.6 ver# extra configure info CONFIGURE_ARGS += --disable-debug --enable-final --with-java=/usr/java/j2re1.4.1sions of include/linux/ioport.h

[Gene Heskett]

On Tuesday 05 August 2003 15:08, Gene Heskett wrote:
>On Tuesday 05 August 2003 11:45, Randy.Dunlap wrote:
>>On Tue, 5 Aug 2003 11:22:35 -0400 Gene Heskett
>
><gene.heskett@verizon.net> wrote:
>>| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>>| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>>|
>>| <gene.heskett@verizon.net> wrote:
>>| >| ----
>>| >| First, the define itself is missing in the 2.6 version.
>>| >|
>>| >| Many drivers seem to use this call, and in that which I'm
>>| >| trying to build, the nforce and advansys modules use it.  And
>>| >| while the modules seem to build, they do not run properly.
>>| >|
>>| >| I cannot run 2.6.x for extended tests because of the advansys
>>| >| breakage this causes.  I also haven't even tried to run X
>>| >| because of the nforce error reported when its built, the same
>>| >| error as attacks the advansys code.
>>| >|
>>| >| Can I ask why this change was made, and is there a suitable
>>| >| replacement call available that these drivers could use
>>| >| instead of check_region(), as shown here in a snip from
>>| >| advansys.c? ----
>>| >| if (check_region(iop, ASC_IOADR_GAP) != 0) {
>>| >| ...
>>| >| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>>| >| ...
>>| >|
>>| >| Hopeing for some hints here.
>>| >
>>| >check_region() was racy.  Use request_region() instead.
>>| >
>>| >   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
>>| >   ...
>>| >
>>| >   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
>>| >   ...
>>| >
>>| >Of course, if successful, this assigns the region to the driver,
>>| >while check_region() didn't do this, so release_region() should
>>| > be used as needed to return the resources.
>>|
>>| Oops... I have a test compile going that changed those to
>>| check_mem_region.  And while I didn't change the i2c stuff, which
>>| still reports the error, advansys.o built w/o error this time.
>>|
>>| Ok, so I can change that to !request_region, but I have NDI when
>>| to go about releasing it, if ever, for a kernel driver thats
>>| either there, and the hardware is used, or not because the
>>| hardware isn't present.
>>
>>release_region() is already done for the normal case.
>>It needs to be added for the error cases in advansys_detect()
>>[wow, what a long function].
>>For your kernel(s) and known hardware, it may not be much of an
>>issue.  However, the in-kernel driver needs to be repaired, but
>>it seems that not many people have the hardware...
>>
>>| It seems to me that if its allocated to this driver, and capable
>>| of being re-used at anytime, then the allocation should, once
>>| made, stand.
>>
>>Yes, request_region() should keep the region assigned until the
>> driver is exiting (unloading).  release_region() is already done
>> in advansys_release().
>>
>>| Or is my view of the world skewed and it should be done at
>>| the bottom of whatever conditional is involved?  Inquiring minds
>>| want to know.  I guess it all depends on what happens if the call
>>| is repeated.  Will it assign a new buffer each time?, thereby
>>| causeing a memory leak, or will it find its been done once and
>>| return success anyway?
>>
>>advansys_detect() should call release_region() if it encounters
>> errors [after it has called request_region() and returns an
>> error].
>>
>>request_region() doesn't assign buffers, it allocates IO resources,
>>as seen in /proc/ioports or /proc/iomem.  I don't know what happens
>>on repeated calls by the same driver|module, but in general a
>> second call will fail if the region is already allocated.
>>
>>--
>>~Randy
>
>All that code is loosely bundled under the heading of advansys_init,
>and from the useage of a header constant in the code to control the
>"for (i = CONSTANT" loop above it, would appear to be looped 11
>times.  Thats not the correct syntax of course, but you get the idea
>I hope.
>
>I've built it that way now, without any errors, so its time to go
> fire up a weed eater acording to the missus, and I'll do a test
> reboot later tonight just for any grins it might generate.  I also
> took all the i2c stuff out, and might try building that once I'm
> rebooted, but I think a name change was made from "modversions" in
> the
>lib/modules/version tree, so that will probably fail until I fix the
>&^%$@() makefile.
>
>I'll let you know how it goes later.  Many thanks for the help, I
>figured I was dead and would have to go buy a (spit) adaptec card.

Yeah, I know, its poor form to answer ones own posts, but here goes...

I built it as a module, rebooted to it, modprobed it in without 
incident, exercised it a bit too, so I changed the CONFIG_ADVANSYS 
from an m to a y and rebuilt it again while booted to 
2.6.0-test2(-mm2? dunno), then rebooted again.  I watched the memory 
with top, but the compile ate far more unused ram, as did setiathome, 
than the driver seemed to be useing so I couldn't tell if I have a 
leak or not.

Is there a utility for watching a given device drivers memory useage?

Now, the factory nvidia drivers will not build for 2.6, so I don't 
have any X.  Whats the status of the kernel versions vis-a-vis 
running a gforce2 MMX 32 megger?  I did run them for a while but the 
OpenGL stuff was missing.  If I can get that going, then lm_sensors 
is next.  I think.  In the meantime I'll see if I can figure out how 
to run a diff and submit it.  At this point, the diff will be against 
the 3.3GJ driver in the 2.4 kernel unless someone has some 
objections???

Many Thanks for the hand holding Randy, it was much appreciated.  
Sometimes I've been said to be vapor locked, needing a little choking 
to get me started. ;-)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.4 vs 2.6 ver# extra configure info CONFIGURE_ARGS += --disable-debug --enable-final --with-java=/usr/java/j2re1.4.1sions of include/linux/ioport.h

[Andrew McGregor]

[-- Attachment #1: Type: text/plain, Size: 406 bytes --]



--On Tuesday, August 05, 2003 06:07:00 PM -0400 Gene Heskett 
<gene.heskett@verizon.net> wrote:

> Now, the factory nvidia drivers will not build for 2.6, so I don't
> have any X.  Whats the status of the kernel versions vis-a-vis
> running a gforce2 MMX 32 megger?

http://www.minion.de/

Patches for several recent NVidia driver versions.  Works for me on a 
GeForce2go.

Andrew





[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Gene Heskett]

On Tuesday 05 August 2003 20:26, Andrew McGregor wrote:
>--On Tuesday, August 05, 2003 06:07:00 PM -0400 Gene Heskett
>
><gene.heskett@verizon.net> wrote:
>> Now, the factory nvidia drivers will not build for 2.6, so I don't
>> have any X.  Whats the status of the kernel versions vis-a-vis
>> running a gforce2 MMX 32 megger?
>
>http://www.minion.de/
>
>Patches for several recent NVidia driver versions.  Works for me on
> a GeForce2go.
>
>Andrew

Thank you.  Patch instructions would have been nice as the patch is 
against the archives own unpacked usr/src/nv directory, not readily 
determined at a glance.  Took me 15 minutes to find the magic twanger 
to play that song, erroniously patching the root makefile many times. 
:)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

2.5/2.6 NVidia (was Re: 2.4 vs 2.6 ver#

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]

On Tue, 05 Aug 2003 18:07:00 EDT, you said:

> Now, the factory nvidia drivers will not build for 2.6, so I don't 
> have any X.  Whats the status of the kernel versions vis-a-vis 
> running a gforce2 MMX 32 megger?

(Sorry for replying to the list, but let's get this into the archives in case
people actually search before asking... (yeah right ;))

I'm running the NVidia 4496 drivers right now on 2.6.0-test2-mm4.

Do the following (can be done on a 2.4 kernel if needed)

1) Get the 4496 drivers from NVidia
2) './NVIDIA-Linux-x86-1.0-4496-pkg2.run --extract-only'
3) Go to www.minion.de and get the patch: NVIDIA_kernel-1.0-4496-2.5.diff
4) cd NVIDIA-Linux-x86-1.0-4496-pkg2/usr/src/nv
5)  patch -p1 < NVIDIA_kernel-1.0-4496-2.5.diff
6) cp Makefile.kbuild Makefile

Now *as root*, while running the 2.6 kernel you want support for:
(either single-user or runlevel 3 (No X) are OK here - reboot if needed)

7) cd NVIDIA-Linux-x86-1.0-4496-pkg2/usr/src/nv   if you're not there already.
8) make     this will build the nvidia.ko, copy to /lib/modules, and insmod it for you.
9) cd ../../..      back to the 4496-pgk2 directory
10) 'make install' to put the /usr/lib parts in place.
11) Start X in the usual manner - you've probably got an XFconfig file with the right
NVidia pieces in it already (or you'd not be asking ;)

Hope this helps...
You should be ready to go at that point (note that you will need to do (7) and (8)
each time you do a 'make modules_install', but 9/10 only need doing if/when you
upgrade from 4496 to a new version.




[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.5/2.6 NVidia (was Re: 2.4 vs 2.6 ver#

[Gene Heskett]

On Tuesday 05 August 2003 22:08, Valdis.Kletnieks@vt.edu wrote:
>On Tue, 05 Aug 2003 18:07:00 EDT, you said:
>> Now, the factory nvidia drivers will not build for 2.6, so I don't
>> have any X.  Whats the status of the kernel versions vis-a-vis
>> running a gforce2 MMX 32 megger?
>
>(Sorry for replying to the list, but let's get this into the
> archives in case people actually search before asking... (yeah
> right ;))
>
>I'm running the NVidia 4496 drivers right now on 2.6.0-test2-mm4.
>
>Do the following (can be done on a 2.4 kernel if needed)
>
>1) Get the 4496 drivers from NVidia
>2) './NVIDIA-Linux-x86-1.0-4496-pkg2.run --extract-only'
>3) Go to www.minion.de and get the patch:
> NVIDIA_kernel-1.0-4496-2.5.diff 4) cd
> NVIDIA-Linux-x86-1.0-4496-pkg2/usr/src/nv
>5)  patch -p1 < NVIDIA_kernel-1.0-4496-2.5.diff
>6) cp Makefile.kbuild Makefile
>
>Now *as root*, while running the 2.6 kernel you want support for:
>(either single-user or runlevel 3 (No X) are OK here - reboot if
> needed)
>
>7) cd NVIDIA-Linux-x86-1.0-4496-pkg2/usr/src/nv   if you're not
> there already. 8) make     this will build the nvidia.ko, copy to
> /lib/modules, and insmod it for you. 9) cd ../../..      back to
> the 4496-pgk2 directory
>10) 'make install' to put the /usr/lib parts in place.
>11) Start X in the usual manner - you've probably got an XFconfig
> file with the right NVidia pieces in it already (or you'd not be
> asking ;)
>
>Hope this helps...
>You should be ready to go at that point (note that you will need to
> do (7) and (8) each time you do a 'make modules_install', but 9/10
> only need doing if/when you upgrade from 4496 to a new version.

I just made a script out of that, thanks, now I'm off to reboot and 
try it. :)

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.5/2.6 NVidia (was Re: 2.4 vs 2.6 ver#

[Gene Heskett]

On Tuesday 05 August 2003 22:08, Valdis.Kletnieks@vt.edu wrote:
>On Tue, 05 Aug 2003 18:07:00 EDT, you said:
>> Now, the factory nvidia drivers will not build for 2.6, so I don't
>> have any X.  Whats the status of the kernel versions vis-a-vis
>> running a gforce2 MMX 32 megger?
>
>(Sorry for replying to the list, but let's get this into the
> archives in case people actually search before asking... (yeah
> right ;))
>
>I'm running the NVidia 4496 drivers right now on 2.6.0-test2-mm4.
>
>Do the following (can be done on a 2.4 kernel if needed)
>
>1) Get the 4496 drivers from NVidia

check

>2) './NVIDIA-Linux-x86-1.0-4496-pkg2.run --extract-only'

check

>3) Go to www.minion.de and get the patch:
> NVIDIA_kernel-1.0-4496-2.5.diff

check
 
>4) cd NVIDIA-Linux-x86-1.0-4496-pkg2/usr/src/nv

check

>5)  patch -p1 < NVIDIA_kernel-1.0-4496-2.5.diff

check

>6) cp Makefile.kbuild Makefile

check

>Now *as root*, while running the 2.6 kernel you want support for:
>(either single-user or runlevel 3 (No X) are OK here - reboot if
> needed)
>
>7) cd NVIDIA-Linux-x86-1.0-4496-pkg2/usr/src/nv   if you're not
> there already.

check, in the script

> 8) make     this will build the nvidia.ko, copy to
> /lib/modules, and insmod it for you.

check, in the script

> 9) cd ../../..      back to
> the 4496-pgk2 directory

check, in the script

>10) 'make install' to put the /usr/lib parts in place.

check, its rather verbose, even complained about something but I 
didn't capture it :(

>11) Start X in the usual manner - you've probably got an XFconfig
> file with the right NVidia pieces in it already (or you'd not be
> asking ;)

check.  Just one problem, went to black screen about the time the NV 
logo should have popped up, and locked the machine up tight, had to 
use the hardware reset button.

Here is the script:
--------
#!/bin/bash
cd usr/src/nv
make
cd ../../..
make install
--------
which is executed from within that *4496-pkg2 directory

Next time I'll redirect the output of the makes to a scratch file, but 
thats tommorrow now.
>Hope this helps...
>You should be ready to go at that point (note that you will need to
> do (7) and (8) each time you do a 'make modules_install', but 9/10
> only need doing if/when you upgrade from 4496 to a new version.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.5/2.6 NVidia (was Re: 2.4 vs 2.6 ver#

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On Tue, 05 Aug 2003 22:53:57 EDT, Gene Heskett said:

> >10) 'make install' to put the /usr/lib parts in place.
> 
> check, its rather verbose, even complained about something but I 
> didn't capture it :(

This is almost certainly the cause of...

> >11) Start X in the usual manner - you've probably got an XFconfig
> > file with the right NVidia pieces in it already (or you'd not be
> > asking ;)
> 
> check.  Just one problem, went to black screen about the time the NV 
> logo should have popped up, and locked the machine up tight, had to 
> use the hardware reset button.

this hang here.  Things to check:

1) what it complained about when doing the 'make install' of the userspace.
2) What /var/log/XFree86.log (or wherever your X server output goes) says - it's
usually pretty good about logging what it's upset about.
3) Make sure you have a sane setting for "Option NvAGP" in your XF86Config that
matches what your kernel has.  It's documented in Appendix D of the README....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: 2.5/2.6 NVidia (was Re: 2.4 vs 2.6 version of ioport.h)

[Gene Heskett]

On Tuesday 05 August 2003 23:06, Valdis.Kletnieks@vt.edu wrote:
>On Tue, 05 Aug 2003 22:53:57 EDT, Gene Heskett said:
>> >10) 'make install' to put the /usr/lib parts in place.
>>
>> check, its rather verbose, even complained about something but I
>> didn't capture it :(
>
>This is almost certainly the cause of...
>
>> >11) Start X in the usual manner - you've probably got an XFconfig
>> > file with the right NVidia pieces in it already (or you'd not be
>> > asking ;)
>>
>> check.  Just one problem, went to black screen about the time the
>> NV logo should have popped up, and locked the machine up tight,
>> had to use the hardware reset button.
>
>this hang here.  Things to check:
>
>1) what it complained about when doing the 'make install' of the
> userspace. 2) What /var/log/XFree86.log (or wherever your X server
> output goes) says - it's usually pretty good about logging what
> it's upset about.

chicken and egg, no valid log till X is started, no machine after X is 
started.  Humm, look at log before restarting X after the reboot.  
Now, why didn't I think of that :(

>3) Make sure you have a sane setting for "Option NvAGP" in your
> XF86Config that matches what your kernel has.  It's documented in
> Appendix D of the README....

If this belongs in the 'Device' section, it wasn't there.  According 
to the README, the default is 3, which=try all options.  I put it in.

I note that in my present 2.4.22-pre10 boot, the only reference to 
this in the log is:
(II) NVIDIA(0): AGP 4X successfully initialized
IIRC, but possibly not the case in the 2.6 .config yet, is that any 
references to AGP are 'is not set'.

But on checking, thats not the case, I have this:
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD_8151 is not set
# CONFIG_AGP_INTEL is not set
CONFIG_AGP_NVIDIA=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
CONFIG_AGP_VIA=y
CONFIG_DRM=y
-----
so I need to shut that off and let it use the nvidia version.  None of 
that is set in this 2.4.22-pre10 boot...  And its now turned off in 
the 2.6 .config too.  Its rebuilding.

Then I've been down for a couple of hours, it seems somebody took out 
a pole or something and my ups worked as expected, allowing me to do 
a gracefull shutdown in the dark.  Nice.

Thanks Valdis.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Gene Heskett]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett 
<gene.heskett@verizon.net> wrote:
>| Greetings;
>|
>| In the 2.4 includes, find this in ioport.h
>| ----
>| /* Compatibility cruft */
>| #define check_region(start,n)   __check_region(&ioport_resource,
>| (start), (n))
>| [snip]
>| extern int __check_region(struct resource *, unsigned long,
>| unsigned long);
>| ----
>| But in the 2.6 version, find this:
>| ----
>| /* Compatibility cruft */
>| [snip]
>| extern int __check_region(struct resource *, unsigned long,
>| unsigned long);
>| [snip]
>| static inline int __deprecated check_region(unsigned long s,
>| unsigned long n)
>| {
>|         return __check_region(&ioport_resource, s, n);
>| }
>| ----
>| First, the define itself is missing in the 2.6 version.
>|
>| Many drivers seem to use this call, and in that which I'm trying
>| to build, the nforce and advansys modules use it.  And while the
>| modules seem to build, they do not run properly.
>|
>| I cannot run 2.6.x for extended tests because of the advansys
>| breakage this causes.  I also haven't even tried to run X because
>| of the nforce error reported when its built, the same error as
>| attacks the advansys code.
>|
>| Can I ask why this change was made, and is there a suitable
>| replacement call available that these drivers could use instead of
>| check_region(), as shown here in a snip from advansys.c?
>| ----
>| if (check_region(iop, ASC_IOADR_GAP) != 0) {
>| ...
>| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>| ...
>|
>| Hopeing for some hints here.
>
>check_region() was racy.  Use request_region() instead.
>
>   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
>   ...
>
>   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
>   ...
>
>Of course, if successful, this assigns the region to the driver,
>while check_region() didn't do this, so release_region() should be
>used as needed to return the resources.

Randy, look the attached patch over & see if its suitable.  Its 
against the driver in the 2.6.0-test2 archive, and was done from 
within the drivers/scsi directory.  Its working fine here, booting 
and accessing my tape drive just fine with the advansys driver 
incorporated into the kernel, or as a module.  I didn't see any 
memory leakage, but my test method isn't definitive.

If its suitable, pass it on to Linus.  It will add one more card to 
the NOT broken by 2.6 list.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

[-- Attachment #2: patch-advansys.c-for-2.6 --]
[-- Type: text/x-diff, Size: 3769 bytes --]

--- advansys.c-orig	2003-07-27 12:59:39.000000000 -0400
+++ advansys.c	2003-08-05 20:28:37.000000000 -0400
@@ -1,5 +1,5 @@
-#define ASC_VERSION "3.3GJ"    /* AdvanSys Driver Version */
+#define ASC_VERSION "3.4MGH"    /* AdvanSys Driver Version */
 
 /*
  * advansys.c - Linux Host Driver for AdvanSys SCSI Adapters
  *
@@ -24,8 +24,15 @@
  *  ftp://ftp.connectcom.net/pub/linux/linux.tgz
  *
  * Please send questions, comments, bug reports to:
  *  support@connectcom.net
+ *  
+ *  Unforch, connectcom seems to have been bankrupt, and a new
+ *  company has bought some, but not all, of the advansys line.
+ *  What they, Initio I think it is, bought, did not include
+ *  the ABP-930 family, so this hardware is officially in the
+ *  orphaned state now.  This per a message Initio returned to me
+ *  Gene Heskett on about 08/03/2003.
  */
 
 /*
 
@@ -676,8 +683,12 @@
      3.3GJD (10/14/02):
          1. change select_queue_depths to slave_configure
 	 2. make cmd_per_lun be sane again
 
+     3.4MGH (08/05/2003)
+	 1. change check_region calls to request_region in an attempt
+	 to 2.6-ify this driver.  I'm 100% hacking in the dark here folks.
+
   I. Known Problems/Fix List (XXX)
 
      1. Need to add memory mapping workaround. Test the memory mapping.
         If it doesn't work revert to I/O port access. Can a test be done
@@ -741,8 +752,14 @@
 
      Andy Kellner <AKellner@connectcom.net> continues the Advansys SCSI
      driver development for ConnectCom (Version > 3.3F).
 
+     But he has now denied any interest in further support for obsolete
+     cards.  They'd be glad to sell me a new card, but I could
+     not find a scsi-2 FAST, 20mhz/sec card in their lineup.  I've
+     changed the version string to append MEH to the 3.4, and will
+     attempt to keep it going for a while yet.
+     
   K. ConnectCom (AdvanSys) Contact Information
 
      Mail:                   ConnectCom Solutions, Inc.
                              1150 Ringwood Court
@@ -753,8 +770,13 @@
      Tech Support E-Mail:    linux@connectcom.net
      FTP Site:               ftp.connectcom.net (login: anonymous)
      Web Site:               http://www.connectcom.net
 
+     I'll leave the above in just in case someone wants to follow
+     the trail.
+
+     I can usually be reached at <gene.heskett@verizon.net>
+
 */
 
 
 /*
@@ -775,9 +797,9 @@
     (LINUX_VERSION_CODE > ASC_LINUX_VERSION(2,3,0) && \
      LINUX_VERSION_CODE < ASC_LINUX_VERSION(2,4,0))
 #error "AdvanSys driver supported only in 2.2 and 2.4 or greater kernels."
 #endif
-
+ 
 /*
  * --- Linux Include Files
  */
 
@@ -4618,9 +4640,9 @@
                     if (iop) {
                         ASC_DBG1(1,
                                 "advansys_detect: probing I/O port 0x%x...\n",
                             iop);
-                        if (check_region(iop, ASC_IOADR_GAP) != 0) {
+                        if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
                             printk(
 "AdvanSys SCSI: specified I/O Port 0x%X is busy\n", iop);
                             /* Don't try this I/O port twice. */
                             asc_ioport[ioport] = 0;
@@ -10000,11 +10022,11 @@
         }
     }
     for (; i < ASC_IOADR_TABLE_MAX_IX; i++) {
         iop_base = _asc_def_iop_base[i];
-        if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
+        if (!request_region(iop_base, ASC_IOADR_GAP, "advansys")) {
             ASC_DBG1(1,
-               "AscSearchIOPortAddr11: check_region() failed I/O port 0x%x\n",
+               "AscSearchIOPortAddr11: request_region() failed I/O port 0x%x\n",
                      iop_base);
             continue;
         }
         ASC_DBG1(1, "AscSearchIOPortAddr11: probing I/O port 0x%x\n", iop_base);

advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Randy.Dunlap]

On Tue, 5 Aug 2003 20:50:07 -0400 Gene Heskett <gene.heskett@verizon.net> wrote:

| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett 
| <gene.heskett@verizon.net> wrote:
| >| Greetings;
| >|
| >| In the 2.4 includes, find this in ioport.h
| >| ----
| >| /* Compatibility cruft */
| >| #define check_region(start,n)   __check_region(&ioport_resource,
| >| (start), (n))
| >| [snip]
| >| extern int __check_region(struct resource *, unsigned long,
| >| unsigned long);
| >| ----
| >| But in the 2.6 version, find this:
| >| ----
| >| /* Compatibility cruft */
| >| [snip]
| >| extern int __check_region(struct resource *, unsigned long,
| >| unsigned long);
| >| [snip]
| >| static inline int __deprecated check_region(unsigned long s,
| >| unsigned long n)
| >| {
| >|         return __check_region(&ioport_resource, s, n);
| >| }
| >| ----
| >| First, the define itself is missing in the 2.6 version.
| >|
| >| Many drivers seem to use this call, and in that which I'm trying
| >| to build, the nforce and advansys modules use it.  And while the
| >| modules seem to build, they do not run properly.
| >|
| >| I cannot run 2.6.x for extended tests because of the advansys
| >| breakage this causes.  I also haven't even tried to run X because
| >| of the nforce error reported when its built, the same error as
| >| attacks the advansys code.
| >|
| >| Can I ask why this change was made, and is there a suitable
| >| replacement call available that these drivers could use instead of
| >| check_region(), as shown here in a snip from advansys.c?
| >| ----
| >| if (check_region(iop, ASC_IOADR_GAP) != 0) {
| >| ...
| >| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
| >| ...
| >|
| >| Hopeing for some hints here.
| >
| >check_region() was racy.  Use request_region() instead.
| >
| >   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
| >   ...
| >
| >   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
| >   ...
| >
| >Of course, if successful, this assigns the region to the driver,
| >while check_region() didn't do this, so release_region() should be
| >used as needed to return the resources.
| 
| Randy, look the attached patch over & see if its suitable.  Its 
| against the driver in the 2.6.0-test2 archive, and was done from 
| within the drivers/scsi directory.  Its working fine here, booting 
| and accessing my tape drive just fine with the advansys driver 
| incorporated into the kernel, or as a module.  I didn't see any 
| memory leakage, but my test method isn't definitive.
| 
| If its suitable, pass it on to Linus.  It will add one more card to 
| the NOT broken by 2.6 list.

First, I've moved this to the linux-scsi mailing list for more/better
comments.

Second, (minor nit) part of your patch[1] contained a line that only
added a trailing space.

But most importantly, if I'm reading it correctly, the driver now does
request_region() 2 times for an IO region (note: for CONFIG_ISA only;
is your Advansys adapter PCI or ISA?).

I'm not terribly interested in spending much time on this driver,
so the simplest thing to do IMO is to emulate check_region() with
pairs of request_region() and release_region() calls.  Yes, this
is still racy, just like check_region() was.  Is that a problem
in your machine environment?

Below is a patch that uses request_region/release_region pairs
instead of check_region().  Does it work for you?

[1] http://lkml.org/lkml/2003/8/5/304

--
~Randy				For Linux-2.6, see:
http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-halloween-2.5.txt


patch_name:	advansys_regions_260.patch
patch_version:	2003-08-06.10:27:17
author:		Randy.Dunlap <rddunlap@osdl.org>
description:	convert check_region() to request/release
product:	Linux
product_versions: linux-260-test2
diffstat:	=
 drivers/scsi/advansys.c |   11 ++++++++---
 1 files changed, 8 insertions(+), 3 deletions(-)


diff -Naurp ./drivers/scsi/advansys.c~advans ./drivers/scsi/advansys.c
--- ./drivers/scsi/advansys.c~advans	2003-07-27 09:59:39.000000000 -0700
+++ ./drivers/scsi/advansys.c	2003-08-06 10:24:45.000000000 -0700
@@ -4619,17 +4619,19 @@ advansys_detect(Scsi_Host_Template *tpnt
                         ASC_DBG1(1,
                                 "advansys_detect: probing I/O port 0x%x...\n",
                             iop);
-                        if (check_region(iop, ASC_IOADR_GAP) != 0) {
+                        if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
                             printk(
 "AdvanSys SCSI: specified I/O Port 0x%X is busy\n", iop);
                             /* Don't try this I/O port twice. */
                             asc_ioport[ioport] = 0;
+			    release_region(iop, ASC_IOADR_GAP);
                             goto ioport_try_again;
                         } else if (AscFindSignature(iop) == ASC_FALSE) {
                             printk(
 "AdvanSys SCSI: specified I/O Port 0x%X has no adapter\n", iop);
                             /* Don't try this I/O port twice. */
                             asc_ioport[ioport] = 0;
+			    release_region(iop, ASC_IOADR_GAP);
                             goto ioport_try_again;
                         } else {
                             /*
@@ -4647,6 +4649,7 @@ advansys_detect(Scsi_Host_Template *tpnt
                                   * 'ioport' past this board.
                                   */
                                  ioport++;
+				 release_region(iop, ASC_IOADR_GAP);
                                  goto ioport_try_again;
                             }
                         }
@@ -10001,16 +10004,18 @@ AscSearchIOPortAddr11(
     }
     for (; i < ASC_IOADR_TABLE_MAX_IX; i++) {
         iop_base = _asc_def_iop_base[i];
-        if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
+        if (!request_region(iop_base, ASC_IOADR_GAP, "advansys")) {
             ASC_DBG1(1,
-               "AscSearchIOPortAddr11: check_region() failed I/O port 0x%x\n",
+               "AscSearchIOPortAddr11: request_region() failed I/O port 0x%x\n",
                      iop_base);
             continue;
         }
         ASC_DBG1(1, "AscSearchIOPortAddr11: probing I/O port 0x%x\n", iop_base);
         if (AscFindSignature(iop_base)) {
+	    release_region(iop_base, ASC_IOADR_GAP);
             return (iop_base);
         }
+	release_region(iop_base, ASC_IOADR_GAP);
     }
     return (0);
 }

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Matthew Wilcox]

On Wed, Aug 06, 2003 at 10:40:41AM -0700, Randy.Dunlap wrote:
> | On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
> | >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett 
> | <gene.heskett@verizon.net> wrote:
> | >| Greetings;
> | >|
> | >| In the 2.4 includes, find this in ioport.h
> | >| ----
> | >| /* Compatibility cruft */
> | >| #define check_region(start,n)   __check_region(&ioport_resource,
> | >| (start), (n))
> | >| [snip]
> | >| extern int __check_region(struct resource *, unsigned long,
> | >| unsigned long);
> | >| ----
> | >| But in the 2.6 version, find this:
> | >| ----
> | >| /* Compatibility cruft */
> | >| [snip]
> | >| extern int __check_region(struct resource *, unsigned long,
> | >| unsigned long);
> | >| [snip]
> | >| static inline int __deprecated check_region(unsigned long s,
> | >| unsigned long n)
> | >| {
> | >|         return __check_region(&ioport_resource, s, n);
> | >| }
> | >| ----
> | >| First, the define itself is missing in the 2.6 version.

What define?  check_region() is still there, just as an inline function,
not a macro.

> | >| Many drivers seem to use this call, and in that which I'm trying
> | >| to build, the nforce and advansys modules use it.  And while the
> | >| modules seem to build, they do not run properly.

Explain?  Has someone broken check_region?

> I'm not terribly interested in spending much time on this driver,
> so the simplest thing to do IMO is to emulate check_region() with
> pairs of request_region() and release_region() calls.  Yes, this
> is still racy, just like check_region() was.  Is that a problem
> in your machine environment?

I think this is the wrong thig to do.  Leaving the check_region()
calls there indicate this driver still needs to be fixed properly.
Replacing them with unsafe uses of request & release_region leaves the
driver racy and removes the indication.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Randy.Dunlap]

On Wed, 6 Aug 2003 18:59:54 +0100 Matthew Wilcox <willy@debian.org> wrote:

| On Wed, Aug 06, 2003 at 10:40:41AM -0700, Randy.Dunlap wrote:
| > | On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
| > | >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett 
| > | <gene.heskett@verizon.net> wrote:
| > | >| Greetings;
| > | >|
| > | >| In the 2.4 includes, find this in ioport.h
| > | >| ----
| > | >| /* Compatibility cruft */
| > | >| #define check_region(start,n)   __check_region(&ioport_resource,
| > | >| (start), (n))
| > | >| [snip]
| > | >| extern int __check_region(struct resource *, unsigned long,
| > | >| unsigned long);
| > | >| ----
| > | >| But in the 2.6 version, find this:
| > | >| ----
| > | >| /* Compatibility cruft */
| > | >| [snip]
| > | >| extern int __check_region(struct resource *, unsigned long,
| > | >| unsigned long);
| > | >| [snip]
| > | >| static inline int __deprecated check_region(unsigned long s,
| > | >| unsigned long n)
| > | >| {
| > | >|         return __check_region(&ioport_resource, s, n);
| > | >| }
| > | >| ----
| > | >| First, the define itself is missing in the 2.6 version.
| 
| What define?  check_region() is still there, just as an inline function,
| not a macro.

and it's "__deprecated", so there is some desire not to use it.

| > | >| Many drivers seem to use this call, and in that which I'm trying
| > | >| to build, the nforce and advansys modules use it.  And while the
| > | >| modules seem to build, they do not run properly.
| 
| Explain?  Has someone broken check_region?

Just deprecated it, so it gives compile warnings when it's used.

| > I'm not terribly interested in spending much time on this driver,
| > so the simplest thing to do IMO is to emulate check_region() with
| > pairs of request_region() and release_region() calls.  Yes, this
| > is still racy, just like check_region() was.  Is that a problem
| > in your machine environment?
| 
| I think this is the wrong thig to do.  Leaving the check_region()
| calls there indicate this driver still needs to be fixed properly.
| Replacing them with unsafe uses of request & release_region leaves the
| driver racy and removes the indication.

Yes, I see your point, and it will work that way as well as it ever did.

Think it will ever be fixed?  Maybe after more 2.6.x users show up...?

--
~Randy				For Linux-2.6, see:
http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-halloween-2.5.txt


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Wednesday 06 August 2003 13:59, Matthew Wilcox wrote:
>On Wed, Aug 06, 2003 at 10:40:41AM -0700, Randy.Dunlap wrote:
>> | On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>> | >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>> |
>> | <gene.heskett@verizon.net> wrote:
>> | >| Greetings;
>> | >|
>> | >| In the 2.4 includes, find this in ioport.h
>> | >| ----
>> | >| /* Compatibility cruft */
>> | >| #define check_region(start,n)  
>> | >| __check_region(&ioport_resource, (start), (n))
>> | >| [snip]
>> | >| extern int __check_region(struct resource *, unsigned long,
>> | >| unsigned long);
>> | >| ----
>> | >| But in the 2.6 version, find this:
>> | >| ----
>> | >| /* Compatibility cruft */
>> | >| [snip]
>> | >| extern int __check_region(struct resource *, unsigned long,
>> | >| unsigned long);
>> | >| [snip]
>> | >| static inline int __deprecated check_region(unsigned long s,
>> | >| unsigned long n)
>> | >| {
>> | >|         return __check_region(&ioport_resource, s, n);
>> | >| }
>> | >| ----
>> | >| First, the define itself is missing in the 2.6 version.
>
>What define?  check_region() is still there, just as an inline
> function, not a macro.
>
I found that later.

>> | >| Many drivers seem to use this call, and in that which I'm
>> | >| trying to build, the nforce and advansys modules use it.  And
>> | >| while the modules seem to build, they do not run properly.
>
>Explain?  Has someone broken check_region?

Its now marked __deprecated.  The module builds while indicating the 
errors, but gets into a bus reset loop and hangs in the second 
iteration of it.

>
>> I'm not terribly interested in spending much time on this driver,
>> so the simplest thing to do IMO is to emulate check_region() with
>> pairs of request_region() and release_region() calls.  Yes, this
>> is still racy, just like check_region() was.  Is that a problem
>> in your machine environment?
>
>I think this is the wrong thig to do.  Leaving the check_region()
>calls there indicate this driver still needs to be fixed properly.
>Replacing them with unsafe uses of request & release_region leaves
> the driver racy and removes the indication.

What do you suggest doing?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Randy.Dunlap]

On Wed, 6 Aug 2003 14:35:43 -0400 Gene Heskett <gene.heskett@verizon.net> wrote:

...
| >> | >| ----
| >> | >| First, the define itself is missing in the 2.6 version.
| >
| >What define?  check_region() is still there, just as an inline
| > function, not a macro.
| >
| I found that later.
| 
| >> | >| Many drivers seem to use this call, and in that which I'm
| >> | >| trying to build, the nforce and advansys modules use it.  And
| >> | >| while the modules seem to build, they do not run properly.
| >
| >Explain?  Has someone broken check_region?
| 
| Its now marked __deprecated.  The module builds while indicating the 
| errors, but gets into a bus reset loop and hangs in the second 
| iteration of it.

So the kernel driver, without mods, is broken?
I didn't realize this earlier.

| >> I'm not terribly interested in spending much time on this driver,
| >> so the simplest thing to do IMO is to emulate check_region() with
| >> pairs of request_region() and release_region() calls.  Yes, this
| >> is still racy, just like check_region() was.  Is that a problem
| >> in your machine environment?
| >
| >I think this is the wrong thig to do.  Leaving the check_region()
| >calls there indicate this driver still needs to be fixed properly.
| >Replacing them with unsafe uses of request & release_region leaves
| > the driver racy and removes the indication.

--
~Randy				For Linux-2.6, see:
http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-halloween-2.5.txt

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Wednesday 06 August 2003 14:50, Randy.Dunlap wrote:
>On Wed, 6 Aug 2003 14:35:43 -0400 Gene Heskett
> <gene.heskett@verizon.net> wrote:
>
>...
>
>| >> | >| ----
>| >> | >| First, the define itself is missing in the 2.6 version.
>| >
>| >What define?  check_region() is still there, just as an inline
>| > function, not a macro.
>|
>| I found that later.
>|
>| >> | >| Many drivers seem to use this call, and in that which I'm
>| >> | >| trying to build, the nforce and advansys modules use it. 
>| >> | >| And while the modules seem to build, they do not run
>| >> | >| properly.
>| >
>| >Explain?  Has someone broken check_region?
>|
>| Its now marked __deprecated.  The module builds while indicating
>| the errors, but gets into a bus reset loop and hangs in the second
>| iteration of it.
>
>So the kernel driver, without mods, is broken?
>I didn't realize this earlier.

Yes.  I've said as much 2-3 times although it could have been 
ambiguous once the translation from WV to english was made. :-)

My patch I sent worked 'nominally' in that ANAICT, all functions were 
restored,  and the memory useage wandered around mainly because 
setiathome is also running, started in rc.local here.  I did not seem 
to successively lose 50k for everytime I accessed something thru the 
patched driver, but I've now added the release_region calls as you 
suggested.  I'll test it later today.

>| >> I'm not terribly interested in spending much time on this
>| >> driver, so the simplest thing to do IMO is to emulate
>| >> check_region() with pairs of request_region() and
>| >> release_region() calls.  Yes, this is still racy, just like
>| >> check_region() was.  Is that a problem in your machine
>| >> environment?
>| >
>| >I think this is the wrong thig to do.  Leaving the check_region()
>| >calls there indicate this driver still needs to be fixed
>| > properly. Replacing them with unsafe uses of request &
>| > release_region leaves the driver racy and removes the
>| > indication.
>
>--
>~Randy				For Linux-2.6, see:
>http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-hallow
>een-2.5.txt

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Wednesday 06 August 2003 13:59, Matthew Wilcox wrote:

This is a resend.

>On Wed, Aug 06, 2003 at 10:40:41AM -0700, Randy.Dunlap wrote:
>> | On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>> | >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>> |
>> | <gene.heskett@verizon.net> wrote:
>> | >| Greetings;
>> | >|
>> | >| In the 2.4 includes, find this in ioport.h
>> | >| ----
>> | >| /* Compatibility cruft */
>> | >| #define check_region(start,n)  
>> | >| __check_region(&ioport_resource, (start), (n))
>> | >| [snip]
>> | >| extern int __check_region(struct resource *, unsigned long,
>> | >| unsigned long);
>> | >| ----
>> | >| But in the 2.6 version, find this:
>> | >| ----
>> | >| /* Compatibility cruft */
>> | >| [snip]
>> | >| extern int __check_region(struct resource *, unsigned long,
>> | >| unsigned long);
>> | >| [snip]
>> | >| static inline int __deprecated check_region(unsigned long s,
>> | >| unsigned long n)
>> | >| {
>> | >|         return __check_region(&ioport_resource, s, n);
>> | >| }
>> | >| ----
>> | >| First, the define itself is missing in the 2.6 version.
>
>What define?  check_region() is still there, just as an inline
> function, not a macro.
>
I found that later.

>> | >| Many drivers seem to use this call, and in that which I'm
>> | >| trying to build, the nforce and advansys modules use it.  And
>> | >| while the modules seem to build, they do not run properly.
>
>Explain?  Has someone broken check_region?

Its now marked __deprecated.  The module builds while indicating the 
errors, but gets into a bus reset loop and hangs in the second 
iteration of it.

>
>> I'm not terribly interested in spending much time on this driver,
>> so the simplest thing to do IMO is to emulate check_region() with
>> pairs of request_region() and release_region() calls.  Yes, this
>> is still racy, just like check_region() was.  Is that a problem
>> in your machine environment?
>
>I think this is the wrong thig to do.  Leaving the check_region()
>calls there indicate this driver still needs to be fixed properly.
>Replacing them with unsafe uses of request & release_region leaves
> the driver racy and removes the indication.

What do you suggest doing?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Wednesday 06 August 2003 13:40, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 20:50:07 -0400 Gene Heskett 
<gene.heskett@verizon.net> wrote:
>| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>|
>| <gene.heskett@verizon.net> wrote:
>| >| Greetings;
>| >|
>| >| In the 2.4 includes, find this in ioport.h
>| >| ----
>| >| /* Compatibility cruft */
>| >| #define check_region(start,n)  
>| >| __check_region(&ioport_resource, (start), (n))
>| >| [snip]
>| >| extern int __check_region(struct resource *, unsigned long,
>| >| unsigned long);
>| >| ----
>| >| But in the 2.6 version, find this:
>| >| ----
>| >| /* Compatibility cruft */
>| >| [snip]
>| >| extern int __check_region(struct resource *, unsigned long,
>| >| unsigned long);
>| >| [snip]
>| >| static inline int __deprecated check_region(unsigned long s,
>| >| unsigned long n)
>| >| {
>| >|         return __check_region(&ioport_resource, s, n);
>| >| }
>| >| ----
>| >| First, the define itself is missing in the 2.6 version.
>| >|
>| >| Many drivers seem to use this call, and in that which I'm
>| >| trying to build, the nforce and advansys modules use it.  And
>| >| while the modules seem to build, they do not run properly.
>| >|
>| >| I cannot run 2.6.x for extended tests because of the advansys
>| >| breakage this causes.  I also haven't even tried to run X
>| >| because of the nforce error reported when its built, the same
>| >| error as attacks the advansys code.
>| >|
>| >| Can I ask why this change was made, and is there a suitable
>| >| replacement call available that these drivers could use instead
>| >| of check_region(), as shown here in a snip from advansys.c?
>| >| ----
>| >| if (check_region(iop, ASC_IOADR_GAP) != 0) {
>| >| ...
>| >| if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>| >| ...
>| >|
>| >| Hopeing for some hints here.
>| >
>| >check_region() was racy.  Use request_region() instead.
>| >
>| >   if (!request_region(iop, ASC_IOADR_GAP, "advansys")) {
>| >   ...
>| >
>| >   if (!request_region(iop_base, ASC_IOADR, "advansys")) {
>| >   ...
>| >
>| >Of course, if successful, this assigns the region to the driver,
>| >while check_region() didn't do this, so release_region() should
>| > be used as needed to return the resources.
>|
>| Randy, look the attached patch over & see if its suitable.  Its
>| against the driver in the 2.6.0-test2 archive, and was done from
>| within the drivers/scsi directory.  Its working fine here, booting
>| and accessing my tape drive just fine with the advansys driver
>| incorporated into the kernel, or as a module.  I didn't see any
>| memory leakage, but my test method isn't definitive.
>|
>| If its suitable, pass it on to Linus.  It will add one more card
>| to the NOT broken by 2.6 list.
>
>First, I've moved this to the linux-scsi mailing list for
> more/better comments.
>
>Second, (minor nit) part of your patch[1] contained a line that only
>added a trailing space.

Probably my editors word wrap at work. :(

>But most importantly, if I'm reading it correctly, the driver now
> does request_region() 2 times for an IO region (note: for
> CONFIG_ISA only; is your Advansys adapter PCI or ISA?).

Its pci.  And isa adaptor would be bus speed limited.

>I'm not terribly interested in spending much time on this driver,
>so the simplest thing to do IMO is to emulate check_region() with
>pairs of request_region() and release_region() calls.  Yes, this
>is still racy, just like check_region() was.  Is that a problem
>in your machine environment?

It hasn't been when using check_region.

>Below is a patch that uses request_region/release_region pairs
>instead of check_region().

>From my perusal of that code, its all in the init category, and 
requests a total of 11 buffers of UNK size (not without rechecking 
the constant defines anyway), which would appear to be assigned for 
the duration of the uptime.  That would appear to me that its 
reserving working room it should never release as long as the drive 
is powered up.  Or did I read it wrong?

>[1] http://lkml.org/lkml/2003/8/5/304
>
>Does it work for you?
>--
>~Randy				For Linux-2.6, see:
>http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-hallow
>een-2.5.txt
>
>
>patch_name:	advansys_regions_260.patch
>patch_version:	2003-08-06.10:27:17
>author:		Randy.Dunlap <rddunlap@osdl.org>
>description:	convert check_region() to request/release
>product:	Linux
>product_versions: linux-260-test2
>diffstat:	=
> drivers/scsi/advansys.c |   11 ++++++++---
> 1 files changed, 8 insertions(+), 3 deletions(-)
>
>
>diff -Naurp ./drivers/scsi/advansys.c~advans
> ./drivers/scsi/advansys.c ---
> ./drivers/scsi/advansys.c~advans	2003-07-27 09:59:39.000000000
> -0700 +++ ./drivers/scsi/advansys.c	2003-08-06 10:24:45.000000000
> -0700 @@ -4619,17 +4619,19 @@ advansys_detect(Scsi_Host_Template
> *tpnt ASC_DBG1(1,
>                                 "advansys_detect: probing I/O port
> 0x%x...\n", iop);
>-                        if (check_region(iop, ASC_IOADR_GAP) != 0)
> { +                        if (!request_region(iop, ASC_IOADR_GAP,
> "advansys")) { printk(
> "AdvanSys SCSI: specified I/O Port 0x%X is busy\n", iop);
>                             /* Don't try this I/O port twice. */
>                             asc_ioport[ioport] = 0;
>+			    release_region(iop, ASC_IOADR_GAP);
>                             goto ioport_try_again;
>                         } else if (AscFindSignature(iop) ==
> ASC_FALSE) { printk(
> "AdvanSys SCSI: specified I/O Port 0x%X has no adapter\n", iop);
>                             /* Don't try this I/O port twice. */
>                             asc_ioport[ioport] = 0;
>+			    release_region(iop, ASC_IOADR_GAP);
>                             goto ioport_try_again;
>                         } else {
>                             /*
>@@ -4647,6 +4649,7 @@ advansys_detect(Scsi_Host_Template *tpnt
>                                   * 'ioport' past this board.
>                                   */
>                                  ioport++;
>+				 release_region(iop, ASC_IOADR_GAP);
>                                  goto ioport_try_again;
>                             }
>                         }
>@@ -10001,16 +10004,18 @@ AscSearchIOPortAddr11(
>     }
>     for (; i < ASC_IOADR_TABLE_MAX_IX; i++) {
>         iop_base = _asc_def_iop_base[i];
>-        if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>+        if (!request_region(iop_base, ASC_IOADR_GAP, "advansys")) {
>             ASC_DBG1(1,
>-               "AscSearchIOPortAddr11: check_region() failed I/O
> port 0x%x\n", +               "AscSearchIOPortAddr11:
> request_region() failed I/O port 0x%x\n", iop_base);
>             continue;
>         }
>         ASC_DBG1(1, "AscSearchIOPortAddr11: probing I/O port
> 0x%x\n", iop_base); if (AscFindSignature(iop_base)) {
>+	    release_region(iop_base, ASC_IOADR_GAP);
>             return (iop_base);
>         }
>+	release_region(iop_base, ASC_IOADR_GAP);
>     }
>     return (0);
> }

Thanks, I've patched my copy, and will try it later today, submitting 
a new diff if it works.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Christoph Hellwig]

On Wed, Aug 06, 2003 at 10:40:41AM -0700, Randy.Dunlap wrote:
> I'm not terribly interested in spending much time on this driver,
> so the simplest thing to do IMO is to emulate check_region() with
> pairs of request_region() and release_region() calls.  Yes, this
> is still racy, just like check_region() was.  Is that a problem
> in your machine environment?
> 
> Below is a patch that uses request_region/release_region pairs
> instead of check_region().  Does it work for you?

What the heck?  Just continue using check_region if you don't want
to spend the time fixing it.  At least we get a warning in that
case.

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Thursday 07 August 2003 03:36, Christoph Hellwig wrote:
>On Wed, Aug 06, 2003 at 10:40:41AM -0700, Randy.Dunlap wrote:
>> I'm not terribly interested in spending much time on this driver,
>> so the simplest thing to do IMO is to emulate check_region() with
>> pairs of request_region() and release_region() calls.  Yes, this
>> is still racy, just like check_region() was.  Is that a problem
>> in your machine environment?
>>
>> Below is a patch that uses request_region/release_region pairs
>> instead of check_region().  Does it work for you?
>
>What the heck?  Just continue using check_region if you don't want
>to spend the time fixing it.  At least we get a warning in that
>case.

But I'm getting tired of repeating myself here Christoph, the driver 
as built in the 2.6.0-test2-mm2, whether built as a module, or in the 
kernel, IS BROKEN!  It gets into a bus reset loop during the init, 
doing 2 of them, AND LOCKS THE MACHINE UP TIGHT REQUIRING A HARDWARE 
RESET TO RECOVER, which of course is by rebooting back to a 2.4 
kernel.

The diff between this driver in kernel-2.4.22-pre10 and the one in 
test2-mm2 is several kilobytes, so *somebody* has been working on it, 
but they not leaving much of a trail, or even apparently adding their 
names to the roll call.

Frankly, from the lack of support by Advansys turned Connectcom turned 
now by way of a bankruptcy into Initio, and the well meaning but 
don't always work suggestions from this group, I'm about to import 
the 2.4.22-pre10 version, header and all, and see what pukes because 
the 2.2-2.4 version has worked flawlessly for quite some time, at 
least 5 or 6 years and I've worn out several tape drives with it.

I even posted a patch here that MADE IT WORK, based on Randy Dunlaps 
first suggestion, but its not been propagated to Linus that I know 
of.  I guess it wasn't a proper patch, but when I tried the next 
suggestions to "make it better", I was then 2 steps short of square 
one in that it was broken again, and this time it couldn't even find 
my tape drive and its robot in between bus resets.

You could say I'm frustrated.  Like everyone else on this list, I'm 
tired of the machine, when not doing anything else except munching on 
a seti packet, has a half a gig of ram xosview says isn't all used 
and it still takes 20 to 30 seconds to launch mozilla when running a 
2.4 kernel.  This is after all, an athlon running at 1400 mhz and 
seti is running at a nice of 20.  2.4 has turned this machine into a 
one legged sick dog, one that needs to be put out of its misery.

IE on a 1.2 ghz winderz box is up and running in 1 second flat.  I saw 
it yesterday at the neighbors.

Does anyone know what became of Bob Frey?  He was at turbolinux.com.?? 
at one time, but google finds no references < 2 years old.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Christoph Hellwig]

On Thu, Aug 07, 2003 at 05:33:10AM -0400, Gene Heskett wrote:
> But I'm getting tired of repeating myself here Christoph, the driver 
> as built in the 2.6.0-test2-mm2, whether built as a module, or in the 
> kernel, IS BROKEN!  It gets into a bus reset loop during the init, 
> doing 2 of them, AND LOCKS THE MACHINE UP TIGHT REQUIRING A HARDWARE 
> RESET TO RECOVER, which of course is by rebooting back to a 2.4 
> kernel.

So how do you think replacing check_region by it's opencoded version
is going to help you?

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Thursday 07 August 2003 05:47, Christoph Hellwig wrote:
>On Thu, Aug 07, 2003 at 05:33:10AM -0400, Gene Heskett wrote:
>> But I'm getting tired of repeating myself here Christoph, the
>> driver as built in the 2.6.0-test2-mm2, whether built as a module,
>> or in the kernel, IS BROKEN!  It gets into a bus reset loop during
>> the init, doing 2 of them, AND LOCKS THE MACHINE UP TIGHT
>> REQUIRING A HARDWARE RESET TO RECOVER, which of course is by
>> rebooting back to a 2.4 kernel.
>
>So how do you think replacing check_region by it's opencoded version
>is going to help you?

I have no idea if request_region is the proper replacement call 
Christoph.  But in tests here, it did restore what appears to be 
normal operation.

Randy Dunlop says check_region is "racy".  And I'm no kernel coder 
unless I have complete hardware specs in front of me, which I do not.
Which is why I'm "pestering" this list for help and hopefully some 
nuggets of wisdom.
 
-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Randy.Dunlap]

On Thu, 7 Aug 2003 14:34:21 -0400 Gene Heskett <gene.heskett@verizon.net> wrote:

| On Thursday 07 August 2003 05:47, Christoph Hellwig wrote:
| >On Thu, Aug 07, 2003 at 05:33:10AM -0400, Gene Heskett wrote:
| >> But I'm getting tired of repeating myself here Christoph, the
| >> driver as built in the 2.6.0-test2-mm2, whether built as a module,
| >> or in the kernel, IS BROKEN!  It gets into a bus reset loop during
| >> the init, doing 2 of them, AND LOCKS THE MACHINE UP TIGHT
| >> REQUIRING A HARDWARE RESET TO RECOVER, which of course is by
| >> rebooting back to a 2.4 kernel.
| >
| >So how do you think replacing check_region by it's opencoded version
| >is going to help you?
| 
| I have no idea if request_region is the proper replacement call 
| Christoph.  But in tests here, it did restore what appears to be 
| normal operation.
| 
| Randy Dunlop says check_region is "racy".  And I'm no kernel coder 
| unless I have complete hardware specs in front of me, which I do not.
| Which is why I'm "pestering" this list for help and hopefully some 
| nuggets of wisdom.

The real problem to be solved is why you are having problems
with the stock 2.6.0-test driver.  It uses check_region(), which
is deprecated, but that shouldn't stop it from working.
Do you have any logs of the "bus reset loop" during init?
You shouldn't have to change check_region() in the driver to
make it work.

--
~Randy				For Linux-2.6, see:
http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-halloween-2.5.txt

Re: advansys regions [Re: 2.4 vs 2.6 versions of include/linux/ioport.h]

[Gene Heskett]

On Thursday 07 August 2003 14:42, Randy.Dunlap wrote:
>On Thu, 7 Aug 2003 14:34:21 -0400 Gene Heskett 
<gene.heskett@verizon.net> wrote:
>| On Thursday 07 August 2003 05:47, Christoph Hellwig wrote:
>| >On Thu, Aug 07, 2003 at 05:33:10AM -0400, Gene Heskett wrote:
>| >> But I'm getting tired of repeating myself here Christoph, the
>| >> driver as built in the 2.6.0-test2-mm2, whether built as a
>| >> module, or in the kernel, IS BROKEN!  It gets into a bus reset
>| >> loop during the init, doing 2 of them, AND LOCKS THE MACHINE UP
>| >> TIGHT REQUIRING A HARDWARE RESET TO RECOVER, which of course is
>| >> by rebooting back to a 2.4 kernel.
>| >
>| >So how do you think replacing check_region by it's opencoded
>| > version is going to help you?
>|
>| I have no idea if request_region is the proper replacement call
>| Christoph.  But in tests here, it did restore what appears to be
>| normal operation.
>|
>| Randy Dunlop says check_region is "racy".  And I'm no kernel coder
>| unless I have complete hardware specs in front of me, which I do
>| not. Which is why I'm "pestering" this list for help and hopefully
>| some nuggets of wisdom.
>
>The real problem to be solved is why you are having problems
>with the stock 2.6.0-test driver.  It uses check_region(), which
>is deprecated, but that shouldn't stop it from working.
>Do you have any logs of the "bus reset loop" during init?
>You shouldn't have to change check_region() in the driver to
>make it work.
>
>--
>~Randy				For Linux-2.6, see:
>http://www.kernel.org/pub/linux/kernel/people/davej/misc/post-hallow
>een-2.5.txt

I do have some logs,  and I note that anytime I try to boot a 2.6, I 
get this:
----
Jul 31 10:42:41 coyote kernel: No module found in object
Jul 31 10:42:47 coyote wall[1242]: wall: user root broadcasted 1 lines 
(50 chars)
Jul 31 10:42:48 coyote kernel: warning: process `update' used the 
obsolete bdflush system call
Jul 31 10:42:48 coyote kernel: Fix your initscripts?
Jul 31 10:42:53 coyote kernel: warning: process `update' used the 
obsolete bdflush system call
Jul 31 10:42:53 coyote kernel: Fix your initscripts?

And here is one from after I built the stocker as a module:
----
Jul 30 19:15:35 coyote kernel: scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: 
IO 0xD000-0xD00F, IRQ 0xB
Jul 30 19:15:41 coyote kernel: advansys: advansys_reset: board 0: SCSI 
bus reset started...
Jul 30 19:15:41 coyote kernel: advansys: advansys_reset: board 0: SCSI 
bus reset successful.
Jul 30 19:15:52 coyote kernel: scsi: Device offlined - not ready after 
error recovery: host 0 channel 0 id 0 lun 0
Jul 30 19:15:52 coyote kernel:   Vendor: ARCHIVE   Model: Python 
28849-XXX  Rev: 4.CM
Jul 30 19:15:52 coyote kernel:   Type:   Sequential-Access                  
ANSI SCSI revision: 02
Jul 30 19:15:52 coyote kernel: Attached scsi tape st0 at scsi0, 
channel 0, id 1, lun 0
Jul 30 19:15:52 coyote kernel: st0: try direct i/o: yes, max page 
reachable by HBA 131056
Jul 30 19:15:52 coyote kernel: Attached scsi generic sg0 at scsi0, 
channel 0, id 1, lun 0,  type 1
Jul 30 19:15:52 coyote kernel:   Vendor: ARCHIVE   Model: Python 
28849-XXX  Rev: 4.CM
Jul 30 19:15:52 coyote kernel:   Type:   Medium Changer                     
ANSI SCSI revision: 02
Jul 30 19:15:52 coyote kernel: Attached scsi generic sg1 at scsi0, 
channel 0, id 1, lun 1,  type 8
Jul 30 19:16:00 coyote kernel: advansys: advansys_reset: board 0: SCSI 
bus reset started...
Jul 30 19:16:00 coyote kernel: advansys: advansys_reset: board 0: SCSI 
bus reset successful.
Jul 30 19:16:20 coyote kernel: scsi: Device offlined - not ready after 
error recovery: host 0 channel 0 id 6 lun 0
### there is no device at this---^^^^ address.  Now back to your 
### regularly scheduled program
Jul 30 19:17:28 coyote su(pam_unix)[3556]: session opened for user 
amanda by root(uid=0)
Jul 30 19:18:38 coyote login(pam_unix)[1235]: session opened for user 
root by LOGIN(uid=0)
Jul 30 19:18:38 coyote  -- root[1235]: ROOT LOGIN ON tty2
Jul 30 19:19:16 coyote kernel: advansys: asc_isr_callback: scp 
0xc045ac80 has bad host pointer, host 0x0
Jul 30 19:19:16 coyote kernel: st0: Block limits 1 - 16777215 bytes.
Jul 30 19:20:00 coyote su(pam_unix)[3556]: session closed for user 
amanda
Jul 30 19:30:31 coyote shutdown: shutting down for system reboot
=====

And here is the log from when I had put in request_region and built it 
as a module:
----
Aug  5 16:36:38 coyote kernel: scsi0 : AdvanSys SCSI 3.3GJ: PCI Ultra: 
IO 0xD000-0xD00F, IRQ 0xB
Aug  5 16:36:38 coyote kernel:   Vendor: ARCHIVE   Model: Python 
28849-XXX  Rev: 4.CM
Aug  5 16:36:38 coyote kernel:   Type:   Sequential-Access                  
ANSI SCSI revision: 02
Aug  5 16:36:38 coyote kernel: Attached scsi tape st0 at scsi0, 
channel 0, id 1, lun 0
Aug  5 16:36:38 coyote kernel: st0: try direct i/o: yes, max page 
reachable by HBA 131056
Aug  5 16:36:38 coyote kernel: Attached scsi generic sg0 at scsi0, 
channel 0, id 1, lun 0,  type 1
Aug  5 16:36:38 coyote kernel:   Vendor: ARCHIVE   Model: Python 
28849-XXX  Rev: 4.CM
Aug  5 16:36:38 coyote kernel:   Type:   Medium Changer                     
ANSI SCSI revision: 02
Aug  5 16:36:38 coyote kernel: Attached scsi generic sg1 at scsi0, 
channel 0, id 1, lun 1,  type 8
====
And here is where I had built that same module into the kernel, after 
I had updated the version strings and some comments in it:
----
Aug  5 17:30:16 coyote kernel: scsi0 : AdvanSys SCSI 3.4MGH: PCI 
Ultra: IO 0xD000-0xD00F, IRQ 0xB
Aug  5 17:30:16 coyote kernel:   Vendor: ARCHIVE   Model: Python 
28849-XXX  Rev: 4.CM
Aug  5 17:30:16 coyote kernel:   Type:   Sequential-Access                  
ANSI SCSI revision: 02
Aug  5 17:30:16 coyote kernel:   Vendor: ARCHIVE   Model: Python 
28849-XXX  Rev: 4.CM
Aug  5 17:30:16 coyote kernel:   Type:   Medium Changer                     
ANSI SCSI revision: 02
Aug  5 17:30:16 coyote kernel: st: Version 20030622, fixed bufsize 
32768, s/g segs 256
Aug  5 17:30:16 coyote kernel: Attached scsi tape st0 at scsi0, 
channel 0, id 1, lun 0
Aug  5 17:30:16 coyote kernel: st0: try direct i/o: yes, max page 
reachable by HBA 131056
Aug  5 17:30:16 coyote kernel: Attached scsi generic sg0 at scsi0, 
channel 0, id 1, lun 0,  type 1
Aug  5 17:30:16 coyote kernel: Attached scsi generic sg1 at scsi0, 
channel 0, id 1, lun 1,  type 8

After this particular boot I repeatedly exersized the amanda and mt 
related stuff trying to break it, but I could not.

That is the total of the 2.6.0-test2-mm2 logging as most of the time 
it hung the machine before it could generate a syslog entry and flush 
it to the media.  I presume there is a var in the headers I could set 
that would make it do a much more verbose init?

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

Re: 2.4 vs 2.6 versions of include/linux/ioport.h

[Gene Heskett]

On Tuesday 05 August 2003 10:41, Gene Heskett wrote:
>Greetings;
>
>In the 2.4 includes, find this in ioport.h
>----
>/* Compatibility cruft */
>#define check_region(start,n)   __check_region(&ioport_resource,
>(start), (n))
>[snip]
>extern int __check_region(struct resource *, unsigned long, unsigned
>long);
>----
>But in the 2.6 version, find this:
>----
>/* Compatibility cruft */
>[snip]
>extern int __check_region(struct resource *, unsigned long, unsigned
>long);
>[snip]
>static inline int __deprecated check_region(unsigned long s,
> unsigned long n)
>{
>        return __check_region(&ioport_resource, s, n);
>}
>----
>First, the define itself is missing in the 2.6 version.

My mistake above, its been moved to a position above the comment and 
redefined as check_mem_region.

>
>Many drivers seem to use this call, and in that which I'm trying to
>build, the nforce and advansys modules use it.  And while the
> modules seem to build, they do not run properly.
>
>I cannot run 2.6.x for extended tests because of the advansys
> breakage this causes.  I also haven't even tried to run X because
> of the nforce error reported when its built, the same error as
> attacks the advansys code.
>
>Can I ask why this change was made, and is there a suitable
>replacement call available that these drivers could use instead of
>check_region(), as shown here in a snip from advansys.c?
>----
>if (check_region(iop, ASC_IOADR_GAP) != 0) {
>...
>if (check_region(iop_base, ASC_IOADR_GAP) != 0) {
>...
>
>Hopeing for some hints here.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.