Mailing List Archive

On Mon, Jul 1, 2013 at 12:35 PM, Frank Peters <frank.peters@comcast.net> wrote:
<SNIP>
> However, the main problem for me with kernel-3.20 is that the nvidia-drivers
> will fail to emerge. Here is the error:
>
> nvidia-drivers-319.32/work/kernel/nv-i2c.c: In function 'nv_i2c_del_adapter':
> nv-i2c.c:327:14: error: void value not ignored as it ought to be
>
> When I encountered this failure I expected that a huge outcry of bug reports
> would ensue, but so far things have been rather quiet. There are only a few
> postings of this problem with 3.10-rc1 and not much else.
>
> I should perhaps just patiently wait for the eventual rapid fix, because this
> error is a real show stopper, but I will make an inquiry nonetheless.
> Has anyone on the list encountered this error with nvidia and kernel-3.10?
>
> I hope it is not, again, some strange affliction peculiar to my machine.
>
> Frank Peters


Hi Frank,
I don't think the Gentoo devs pay much attention to that sort of
failure. I don't report them anymore.

My personal experience with major kernel revision jumps like this
is that it's best to give NVidia a few days and to watch their web
site for a new version. They typically update very quickly. (1-2 days)

HTH,
Mark

Mark Knecht wrote:
> On Mon, Jul 1, 2013 at 12:35 PM, Frank Peters <frank.peters@comcast.net> wrote:
> <SNIP>
>> However, the main problem for me with kernel-3.20 is that the nvidia-drivers
>> will fail to emerge. Here is the error:
>>
>> nvidia-drivers-319.32/work/kernel/nv-i2c.c: In function 'nv_i2c_del_adapter':
>> nv-i2c.c:327:14: error: void value not ignored as it ought to be
>>
>> When I encountered this failure I expected that a huge outcry of bug reports
>> would ensue, but so far things have been rather quiet. There are only a few
>> postings of this problem with 3.10-rc1 and not much else.
>>
>> I should perhaps just patiently wait for the eventual rapid fix, because this
>> error is a real show stopper, but I will make an inquiry nonetheless.
>> Has anyone on the list encountered this error with nvidia and kernel-3.10?
>>
>> I hope it is not, again, some strange affliction peculiar to my machine.
>>
>> Frank Peters
>
> Hi Frank,
> I don't think the Gentoo devs pay much attention to that sort of
> failure. I don't report them anymore.
>
> My personal experience with major kernel revision jumps like this
> is that it's best to give NVidia a few days and to watch their web
> site for a new version. They typically update very quickly. (1-2 days)
>
> HTH,
> Mark
>
>


I seem to recall that nvidia only supports 3.9 right now. As Mark says,
give them some time to update then try again.

Hope that helps.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

On Mon, Jul 1, 2013 at 12:51 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Jul 1, 2013 at 12:35 PM, Frank Peters <frank.peters@comcast.net> wrote:
> <SNIP>
>> However, the main problem for me with kernel-3.20 is that the nvidia-drivers
>> will fail to emerge. Here is the error:
>>
>> nvidia-drivers-319.32/work/kernel/nv-i2c.c: In function 'nv_i2c_del_adapter':
>> nv-i2c.c:327:14: error: void value not ignored as it ought to be
>>
>> When I encountered this failure I expected that a huge outcry of bug reports
>> would ensue, but so far things have been rather quiet. There are only a few
>> postings of this problem with 3.10-rc1 and not much else.
>>
>> I should perhaps just patiently wait for the eventual rapid fix, because this
>> error is a real show stopper, but I will make an inquiry nonetheless.
>> Has anyone on the list encountered this error with nvidia and kernel-3.10?
>>
>> I hope it is not, again, some strange affliction peculiar to my machine.
>>
>> Frank Peters
>
>
> Hi Frank,
> I don't think the Gentoo devs pay much attention to that sort of
> failure. I don't report them anymore.
>
> My personal experience with major kernel revision jumps like this
> is that it's best to give NVidia a few days and to watch their web
> site for a new version. They typically update very quickly. (1-2 days)
>
> HTH,
> Mark

Frank,
On the NVidia site they show a new beta driver released today, July
1st, 2013. The version number is 325.08. I just did a sync and that
revision does not appear to be in portage yet, at least on the server
I'm syncing to.

I suspect that's the driver you're looking for but that is just a guess.

HTH,
Mark

On Mon, Jul 1, 2013 at 4:30 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On the NVidia site they show a new beta driver released today, July
> 1st, 2013. The version number is 325.08. I just did a sync and that
> revision does not appear to be in portage yet, at least on the server
> I'm syncing to.
>

Nvidia not working with the latest kernel is a known issue. I have no
idea whether that new release fixes it but it is a good guess.

In general with these sorts of issues I would suggest just giving it a
day or two before logging a bug to give everybody a chance to catch
up. Apparently 3.10 changed significantly during the rcs and Nvidia
got tired of regular updates so they decided to just wait for final
release.

Rich

On Mon, 1 Jul 2013 12:51:55 -0700
Mark Knecht <markknecht@gmail.com> wrote:

>
> I don't think the Gentoo devs pay much attention to that sort of
> failure. I don't report them anymore.
>

They shouldn't be paying attention.

The nvidia folks are obviously lagging. The few reports I've encountered
about this problem go back to 3.10-r1 and the nvidia project should have
become involved back then.

But I suppose my impatience is getting the better of me. I like to
put these new releases behind me as quickly as I can.

Frank Peters

On Mon, 01 Jul 2013 19:57:48 -0500
B Vance <anonymous.pseudonym.88@gmail.com> wrote:

>
> http://comments.gmane.org/gmane.comp.video.dri.devel/85217 holds the
> solution to the problem. A nice simple patch.
>

Thanks for this. The patch works well and now I can use kernel-3.10
until nvidia provides the official fix.

Frank Peters

On Mon, 2013-07-01 at 15:04 -0500, Dale wrote:
> Mark Knecht wrote:
> > On Mon, Jul 1, 2013 at 12:35 PM, Frank Peters <frank.peters@comcast.net> wrote:
> > <SNIP>
> >> However, the main problem for me with kernel-3.20 is that the nvidia-drivers
> >> will fail to emerge. Here is the error:
> >>
> >> nvidia-drivers-319.32/work/kernel/nv-i2c.c: In function 'nv_i2c_del_adapter':
> >> nv-i2c.c:327:14: error: void value not ignored as it ought to be
> >>
> >> When I encountered this failure I expected that a huge outcry of bug reports
> >> would ensue, but so far things have been rather quiet. There are only a few
> >> postings of this problem with 3.10-rc1 and not much else.
> >>
> >> I should perhaps just patiently wait for the eventual rapid fix, because this
> >> error is a real show stopper, but I will make an inquiry nonetheless.
> >> Has anyone on the list encountered this error with nvidia and kernel-3.10?
> >>
> >> I hope it is not, again, some strange affliction peculiar to my machine.
> >>
> >> Frank Peters
> >
> > Hi Frank,
> > I don't think the Gentoo devs pay much attention to that sort of
> > failure. I don't report them anymore.
> >
> > My personal experience with major kernel revision jumps like this
> > is that it's best to give NVidia a few days and to watch their web
> > site for a new version. They typically update very quickly. (1-2 days)
> >
> > HTH,
> > Mark
> >
> >
>
>
> I seem to recall that nvidia only supports 3.9 right now. As Mark says,
> give them some time to update then try again.
>
> Hope that helps.
>
> Dale
>
> :-) :-)
>

http://comments.gmane.org/gmane.comp.video.dri.devel/85217 holds the
solution to the problem. A nice simple patch.

Frank Peters posted on Mon, 01 Jul 2013 15:35:42 -0400 as excerpted:

> Kernel-3.10 has just been released and I quickly grabbed the source and
> compiled. I usually have no problems with a new kernel but this time
> there were a few surprises.
>
> First, there is a new kernel option called "Kernel support for scripts
> starting with #!." This option seemed applicable only to boot scenarios
> involving initramfs but unchecking it caused my system to fail to boot.
> Because this may cause unexpected problems for others, I mention it
> here.

That's standard "shebang" (shell bang or hash-bang) support,
traditionally used to allow pointing to the interpreter used to interpret
a script-executable. It's actually used in a number of contexts,
including most *ix interpreters understanding it to allow pointing at a
different interpreter as necessary/desired. Bash will use this to invoke
the appropriate executable as interpreter, handing it the file it was
just sourcing itself to execute, if it encounters a shebang pointing to
say perl or python instead of sh or bash, for instance.

AFAIK the kernel has long had the option, enabled by default, but it
probably moved in the kernel config menu and/or was slightly reworded, so
it showed up as new.

And no, as you found out it's *NOT* initramfs-only. It's basic kernel
functionality that been assumed for (I guess) decades now. The wording
in the kconfig help text for that option simply explains that if the
support is compiled as a module rather than built-in, you won't be able
to run scripts until the module is loaded. Most binary-based distros
ship a modules based kernel with initial module loading in an initr*, and
often the init in the initr* is a script, thus the warning there.

But as you may have noticed, openrc, gentoo's default init system, uses
#!/sbin/runscript to point to runscript (part of openrc), as its script
interpreter, and it may well be that turning off kernel shebang support
screwed you up that way.

Regardless, it's basic enough Linux and Unix functionality that you'll
nearly always want it enabled and even built-in for any even semi-
traditional Linux install. Certain embedded cases may not need it,
however, and I'd guess android (now the largest linux kernel deployment
by far, well outnumbering traditional gnu/linux deployments) doesn't use
it either, tho I don't know enough about android to be sure. Thus the
option.

> Second, the RTC (real time clock) module option, which has been present
> for a long time as a basic kernel driver, has suddenly disappeared. To
> get the same functionality, one has to enable the new "PC-style CMOS"
> RTC driver, and because this builds a module with a different name
> (rtc-cmos vs. rtc) my custom start-up scripts suddenly were broken. It
> took a bit of searching to resolve the problem. I suppose that users of
> udev may not notice the change, but I mention it just in case others may
> experience something similar.

Good heads-up. =:^)

> However, the main problem for me with kernel-3.20 is that the
> nvidia-drivers will fail to emerge.

3.10 I think you mean, unless you're a time-traveler just arrived from
about two years in our future (the kernel release cycle's about 10 weeks,
roughly 5 releases a year), but anyway...

As the others have said, that's standard and expected behavior with new
kernels and out-of-tree drivers (including but not limited to the nVidia
graphics driver) that haven't updated to account for changes to the
latest mainline kernel code.

See the stable_api_nonsense.txt file in the kernel's Documentation subdir
for the official explanation, but it's simply a cost of choosing to keep
kernel code out of the main tree (as nvidia has to do due to their
refusal to fully open source their code).

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Tue, 2 Jul 2013 11:29:47 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> >
> > First, there is a new kernel option called "Kernel support for scripts
> > starting with #!."
> >

> And no, as you found out it's *NOT* initramfs-only. It's basic kernel
> functionality that been assumed for (I guess) decades now.

>
> But as you may have noticed, openrc, gentoo's default init system, uses
> #!/sbin/runscript to point to runscript (part of openrc), as its script
> interpreter, and it may well be that turning off kernel shebang support
> screwed you up that way.
>

I am entirely sure what is happening with this kernel "#!" option.

My boot scripts are very simple and customized for my specific machine
(as opposed to having a complex set of highly generalized scripts that
attempt to account for every possible situation).

Basically, once the kernel loads itself, it invokes the init binary
which then uses parameters in /etc/inittab to invoke appropriate
scripts (or other binaries). From my inittab, only a single
bash script is called for system initialization and this bash script
runs just fine _without_ the kernel "#!" option.

However, after this bash initialization script executes, the console
login process then begins. My inittab contains this line for login:

agetty -n -l /sbin/autologin 38400 tty1

Now /sbin/autologin is another bash script and it is *only at this point*
that the boot fails to complete without the kernel "#!" option.
IOW, my bash boot scripts succeed but the bash autologin script
fails w/o the kernel "#!" option.

I suspect, although I have not tested it, that if I substitute a normal
binary login (i.e. /bin/login) for the bash /sbin/autologin then
the boot will be completely successful w/o the kernel "#!" option.

So what does the "#!" option accomplish? Does it allow the kernel to
effect redirection based on "#!?" This should only be necessary if
bash itself is not invoked, but in boot-up based on init and inittab,
bash, I believe, is automatically invoked for all scripts. But yet
the agetty program, after boot-up is essentially complete, fails
to execute the bash script in its parameter list. At this point is
it agetty, or the kernel, that is responsible for executing the
autologin script?

I need to study this more.

Frank Peters

Frank Peters posted on Tue, 02 Jul 2013 12:54:54 -0400 as excerpted:

(Thanks for the insight into your more direct boot scripts. I've done
that with some things here, including with my own custom suspend/
hibernate scripts, but not with my bootscripts.)

> So what does the "#!" option accomplish? Does it allow the kernel to
> effect redirection based on "#!?"

Yes.

> This should only be necessary if bash
> itself is not invoked, but in boot-up based on init and inittab, bash, I
> believe, is automatically invoked for all scripts. But yet the agetty
> program, after boot-up is essentially complete, fails to execute the
> bash script in its parameter list. At this point is it agetty, or the
> kernel, that is responsible for executing the autologin script?

Given your customized setup I don't know for sure, but I can make an
educated guess that at the point that breaks in that setup, the already
running bootscript invokes a second script directly by name, as if it
were a binary. With the kernel shebang option, that works as long as
that second script is set executable. But without the kernel shebang
option, it fails.

The alternative that WOULD work, would be to call that second script
using an indirect invocation with bash as the command executed directly
by the kernel and the second script as a parameter to it, like so:

bash (bash options) /path/to/script (script arguments)

By doing it that way, the kernel invokes bash, which knows how to handle
it, and can (I believe) in fact handle #!/bin/perl and other foreign
interpreter shebangs as well, instead of the kernel attempting to execute
the script directly, and failing if the kernel doesn't have shebang
support loaded.

(Altho it'll be obvious to some, it's also worth mentioning that with
indirect script invocation via direct invocation of the interpreter,
feeding it the script by commandline, the script itself no longer needs
to have executable permissions, since bash is perfectly happy to execute
any file it is fed on the commandline as long as it can read it, while
the kernel refuses to execute files without the executable bit set.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

Am 01.07.2013 22:35, schrieb Frank Peters:
> When I encountered this failure I expected that a huge outcry of bug reports
> would ensue, but so far things have been rather quiet. There are only a few
> postings of this problem with 3.10-rc1 and not much else.

Well, read the messages on the screen when you try to emerge
nvidia-drivers. Doesn't it say, that Gentoo only supports the kernels
that NVIDIA supports and that you shall not report a bug nvidia-drivers
failing?

> I should perhaps just patiently wait for the eventual rapid fix, because this
> error is a real show stopper, but I will make an inquiry nonetheless.
> Has anyone on the list encountered this error with nvidia and kernel-3.10?

My interpretation of this message in the nvidia-drivers ebuild is that
the maintainers assume that you switch to nouveau. Nouveau works great
for office stuff. But when it comes to gaming I'm hitting a few
obstacles. For example, 32bit apps (like wine) are stuck with whatever
mesa version is supplied by the emul* packages (mesa 9.0.1 or whatever).
It's 2013, and Gentoo still doesn't have proper multilib support in the
portage tree. Gentoo is certainly to blame here, but I'd even go further
and blame autoconf.


Regards,
Sven

On Mon, Jul 1, 2013 at 1:30 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Mon, Jul 1, 2013 at 12:51 PM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Mon, Jul 1, 2013 at 12:35 PM, Frank Peters <frank.peters@comcast.net> wrote:
>> <SNIP>
>>> However, the main problem for me with kernel-3.20 is that the nvidia-drivers
>>> will fail to emerge. Here is the error:
<SNIP>
> Frank,
> On the NVidia site they show a new beta driver released today, July
> 1st, 2013. The version number is 325.08. I just did a sync and that
> revision does not appear to be in portage yet, at least on the server
> I'm syncing to.
>
> I suspect that's the driver you're looking for but that is just a guess.
>
> HTH,
> Mark

Hi Frank,
It's July 4th, 3 days later, and nvidia-drivers-325.08 is now in
portage. I don't know when it became available - today or yesterday -
but 1 day for NVidia to get the driver out & 3 days for Gentoo devs to
get it into portage isn't too bad in my mind.

Just curious if you've tried it yet?

Cheers,
Mark

On Thu, 4 Jul 2013 16:57:59 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> and nvidia-drivers-325.08 is now in
> portage.
>
> Just curious if you've tried it yet?
>

It doesn't work with kernel-3.10. A patch for 325.08 is available:

https://devtalk.nvidia.com/cmd/default/download-comment-attachment/58795/

As long as someone has a patch that's good enough for me.

Frank Peters

>
> My interpretation of this message in the nvidia-drivers ebuild is that
> the maintainers assume that you switch to nouveau.
>

I think it means that the problem occurs so frequently that they
do not want to be bothered with bug reports -- and rightly so.

My great disappointment is that xorg or nvidia or whoever was
responsible had decided to stop the legacy nv driver that was
part of xorg itself. I don't do gaming and I have no need for
ultra-high performance graphics. The nv driver was always good
enough for me.

But development stopped on nv a few years ago and it no longer
supports the newer Nvidia cards.

Frank Peters

Am 05.07.2013 04:28, schrieb Frank Peters:
>>
>> My interpretation of this message in the nvidia-drivers ebuild is that
>> the maintainers assume that you switch to nouveau.
>
> I think it means that the problem occurs so frequently that they
> do not want to be bothered with bug reports -- and rightly so.

Yes.

> My great disappointment is that xorg or nvidia or whoever was
> responsible had decided to stop the legacy nv driver that was
> part of xorg itself. I don't do gaming and I have no need for
> ultra-high performance graphics. The nv driver was always good
> enough for me.

Are you having problems with nouveau? I'm using nouveau for a while now,
and it works perfectly most of the time. It also allows you to use
modern desktop environments like Gnome 3.x or cinnamon. I use the
nouveau stuff that comes with the sources from kernel.org and the
corresponding Xorg driver from portage (~amd64). It's working fine.


Regards,
Sven