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);

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.