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.
On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett <[email protected]> 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
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.
On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
<[email protected]> 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.
On Tue, 5 Aug 2003 11:22:35 -0400 Gene Heskett <[email protected]> wrote:
| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
| <[email protected]> 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
On Tuesday 05 August 2003 11:45, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 11:22:35 -0400 Gene Heskett
<[email protected]> wrote:
>| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>|
>| <[email protected]> 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.
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
>
><[email protected]> wrote:
>>| On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>>| >On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
>>|
>>| <[email protected]> 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.
--On Tuesday, August 05, 2003 06:07:00 PM -0400 Gene Heskett
<[email protected]> 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
On Tuesday 05 August 2003 10:57, Randy.Dunlap wrote:
>On Tue, 5 Aug 2003 10:41:08 -0400 Gene Heskett
<[email protected]> 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.
On Tuesday 05 August 2003 20:26, Andrew McGregor wrote:
>--On Tuesday, August 05, 2003 06:07:00 PM -0400 Gene Heskett
>
><[email protected]> 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.
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 http://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.
On Tuesday 05 August 2003 22:08, [email protected] 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 http://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.
On Tuesday 05 August 2003 22:08, [email protected] 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 http://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.
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....
On Tuesday 05 August 2003 23:06, [email protected] 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.