Hello,
I build new kernels when they become available. Now I have a problem.
After I install new kernel I have to run NVidia setup script. Starting
from git15 it fails, see attached file. The error line is here:
/tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c: At top level:
/tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: error:
unknown field ‘ioctl’ specified in initializer
/tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: warning:
initialization from incompatible pointer type
In git14 everything was OK, but now it is not, also with the Git synced
kernel. Has something changed from git14 times? I hope that it changed
in Linux because it will be fixed earlier than NVidia source.
My graphic card is 01:00.0 VGA compatible controller: nVidia Corporation
G96 [GeForce 9400 GT] (rev a1)
Regards,
Piotr Hosowicz
--
Muller wiedział, że Rosjanie, zamieszawszy cukier, zostawiają łyżkę w
szklance z herbatą. Chcąc sprawdzić Stirlitza, zaprosił go do siebie
na herbatę. Stirlitz wsypał cukier do szklanki, zamieszał go, wyjął
łyżeczkę, położył ją na spodeczku, po czym pokazał Mullerowi język.
NP: Peter Green Splinter Group - There's A River
NB: 2.6.35-git14
On Sat, Aug 14, 2010 at 10:53:17PM +0200, Piotr Hosowicz wrote:
> Hello,
>
> I build new kernels when they become available. Now I have a problem.
> After I install new kernel I have to run NVidia setup script. Starting
> from git15 it fails, see attached file. The error line is here:
>
> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c: At top level:
> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: error:
> unknown field ‘ioctl’ specified in initializer
> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: warning:
> initialization from incompatible pointer type
The likely culprint is:
b19dd42faf413b4705d4adb38521e82d73fa4249
(bkl: Remove locked .ioctl file operation)
This commit finally killed ioctl from file_operations, as part of the
bkl removal project.
Sam
On 14.08.2010 22:53, Piotr Hosowicz wrote:
> Hello,
>
> I build new kernels when they become available. Now I have a problem.
> After I install new kernel I have to run NVidia setup script. Starting
> from git15 it fails, see attached file. The error line is here:
>
> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c: At top level:
> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: error:
> unknown field ‘ioctl’ specified in initializer
> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: warning:
> initialization from incompatible pointer type
>
> In git14 everything was OK, but now it is not, also with the Git synced
> kernel. Has something changed from git14 times? I hope that it changed
> in Linux because it will be fixed earlier than NVidia source.
>
> My graphic card is 01:00.0 VGA compatible controller: nVidia Corporation
> G96 [GeForce 9400 GT] (rev a1)
The latest driver is here:
ftp://download.nvidia.com/XFree86/Linux-x86_64/256.44/
To unpack execute it with --extract-only option.
Regards,
Piotr Hosowicz
--
Na przyjęciu chłopak pyta blondynkę:
- Czy mogę cię prosić do walca?
- Zgłupiałeś? To już nie miałeś czym przyjechać?
NP: Peter Green Splinter Group - I Can't Help Myself
NB: 2.6.35-git14
On 14.08.2010 23:00, Sam Ravnborg wrote:
> On Sat, Aug 14, 2010 at 10:53:17PM +0200, Piotr Hosowicz wrote:
>> Hello,
>>
>> I build new kernels when they become available. Now I have a problem.
>> After I install new kernel I have to run NVidia setup script. Starting
>> from git15 it fails, see attached file. The error line is here:
>>
>> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c: At top level:
>> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: error:
>> unknown field ‘ioctl’ specified in initializer
>> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: warning:
>> initialization from incompatible pointer type
>
> The likely culprint is:
> b19dd42faf413b4705d4adb38521e82d73fa4249
> (bkl: Remove locked .ioctl file operation)
>
> This commit finally killed ioctl from file_operations, as part of the
> bkl removal project.
Yes, this was it. I made git pull and git revert and now I am up and
kicking. But how will I manage with it not by git but by kernel org
provioded files? And even if I used git all the time will I have to
revert it each time and what's the worse I will become more and more out
of sync because people will write their code as if I did not revert.
Thanks for your help. Regards,
Piotr Hosowicz
--
- Jaka jest największa anomalia fizjologiczno-polityczna?
- Członek wysunięty z ramienia na czoło.
NP: Peter Green Splinter Group - Big Change Is Gonna Come
NB: 2.6.35-20100814-2310+
On 14.08.2010 23:02, Piotr Hosowicz wrote:
> On 14.08.2010 22:53, Piotr Hosowicz wrote:
>> Hello,
>>
>> I build new kernels when they become available. Now I have a problem.
>> After I install new kernel I have to run NVidia setup script. Starting
>> from git15 it fails, see attached file. The error line is here:
>>
>> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c: At top level:
>> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: error:
>> unknown field ‘ioctl’ specified in initializer
>> /tmp/selfgz6622/NVIDIA-Linux-x86_64-256.35/kernel/nv.c:426: warning:
>> initialization from incompatible pointer type
>>
>> In git14 everything was OK, but now it is not, also with the Git synced
>> kernel. Has something changed from git14 times? I hope that it changed
>> in Linux because it will be fixed earlier than NVidia source.
>>
>> My graphic card is 01:00.0 VGA compatible controller: nVidia Corporation
>> G96 [GeForce 9400 GT] (rev a1)
>
>
> The latest driver is here:
>
> ftp://download.nvidia.com/XFree86/Linux-x86_64/256.44/
>
> To unpack execute it with --extract-only option.
http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
Regards,
Piotr Hosowicz
--
TV: "Gruchała jest taka, że cieszy się z każdego pchnięcia."
NP: Van Halen - Cabo Wabo/You Really Got Me
NB: 2.6.35-git16
On 14.08.2010 23:20, Hagen Paul Pfeifer wrote:
> * Piotr Hosowicz | 2010-08-14 23:02:48 [+0200]:
>
>> The latest driver is here:
>>
>> ftp://download.nvidia.com/XFree86/Linux-x86_64/256.44/
>>
>> To unpack execute it with --extract-only option.
>
> remove line 426 of kernel/nv.c:
>
> .ioctl = nv_kern_ioctl,
>
>
> ... and try again. ;)
Sorry, I was wrong when I wrote yesterday. I tried again and it works.
Thank you a lot. It will be my standard way to deal with this.
Cheers,
Piotr Hosowicz
--
Skarga z 1983 roku: Zamiast 3 kg cukru ekspedientka sprzeda?a
mi 3 kg mr?wek faraona (podpis nieczytelny). Dopisek kierowni-
czki: Klient by? w stanie nietrze?wym.
NP: Peter Green Splinter Group - Big Change Is Gonna Come
NB: 2.6.35-git16
I resend, I dont know why it didn't appear on LKML. Thanks.
Piotr Hosowicz
On 14.08.2010 23:20, Hagen Paul Pfeifer wrote:
> * Piotr Hosowicz | 2010-08-14 23:02:48 [+0200]:
>
>> The latest driver is here:
>>
>> ftp://download.nvidia.com/XFree86/Linux-x86_64/256.44/
>>
>> To unpack execute it with --extract-only option.
>
> remove line 426 of kernel/nv.c:
>
> .ioctl = nv_kern_ioctl,
>
>
> ... and try again. ;)
Sorry, I was wrong when I wrote yesterday. I tried again and it works.
Thank you a lot. It will be my standard way to deal with this.
Cheers,
Piotr Hosowicz
--
Skarga z 1983 roku: Zamiast 3 kg cukru ekspedientka sprzeda?a
mi 3 kg mr?wek faraona (podpis nieczytelny). Dopisek kierowni-
czki: Klient by? w stanie nietrze?wym.
NP: Peter Green Splinter Group - Big Change Is Gonna Come
NB: 2.6.35-git16
On Sunday 15 August 2010 00:10:29 Piotr Hosowicz wrote:
> Yes, this was it. I made git pull and git revert and now I am up and
> kicking. But how will I manage with it not by git but by kernel org
> provioded files? And even if I used git all the time will I have to
> revert it each time and what's the worse I will become more and more out
> of sync because people will write their code as if I did not revert.
Just fix your driver code to no longer rely on the big kernel lock
and then make it use the unlocked_ioctl operation.
Arnd
On 16.08.2010 08:58, Arnd Bergmann wrote:
> On Sunday 15 August 2010 00:10:29 Piotr Hosowicz wrote:
>> Yes, this was it. I made git pull and git revert and now I am up and
>> kicking. But how will I manage with it not by git but by kernel org
>> provioded files? And even if I used git all the time will I have to
>> revert it each time and what's the worse I will become more and more out
>> of sync because people will write their code as if I did not revert.
>
> Just fix your driver code to no longer rely on the big kernel lock
Now I know how to do it.
> and then make it use the unlocked_ioctl operation.
This I do not know. Can You help me?
Regards,
Piotr Hosowicz
--
"[Oleksy] dotkn?? naszych dom?w, naszych ?on, naszych dzieci,
naszych ps?w, naszych ?WINEK MORSKICH, on po prostu wkroczy?
swoim g?upim gadaniem w sfer? prywatn?, kt?ra musi by? chro-
niona dla dobra ka?dego z nas" - powiedzia? Kwa?niewski.
NP: Patrick O'Hearn - Night Becomes Her
NB: 2.6.35-git16
On Monday 16 August 2010 09:11:33 Piotr Hosowicz wrote:
> > and then make it use the unlocked_ioctl operation.
>
> This I do not know. Can You help me?
>
Just take a look at all the other patches that went into the
kernel to do this for other drivers. You only really
need to change the line with .ioctl=... to .unlocked_ioctl=
and change the prototype of the referenced function to
static long foo_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
Arnd
On 16.08.2010 09:17, Arnd Bergmann wrote:
> On Monday 16 August 2010 09:11:33 Piotr Hosowicz wrote:
>>> and then make it use the unlocked_ioctl operation.
>>
>> This I do not know. Can You help me?
>>
>
> Just take a look at all the other patches that went into the
> kernel to do this for other drivers. You only really
> need to change the line with .ioctl=... to .unlocked_ioctl=
> and change the prototype of the referenced function to
>
> static long foo_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
int nv_kern_ioctl(struct inode *, struct file *, unsigned int,
unsigned long);
It seems different. How to change it? Now it works, I built it without
your remarks, exactly how I described on my blog:
http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
Regards,
Piotr Hosowicz
--
Polsat: ogl?dasz z rodzink? reklamy, a tu nagle - trach! - film!
NP: Patrick O'Hearn - Chance
NB: 2.6.36-rc1
On 16.08.2010 09:59, Piotr Hosowicz wrote:
> On 16.08.2010 09:17, Arnd Bergmann wrote:
>> On Monday 16 August 2010 09:11:33 Piotr Hosowicz wrote:
>>>> and then make it use the unlocked_ioctl operation.
>>>
>>> This I do not know. Can You help me?
>>>
>>
>> Just take a look at all the other patches that went into the
>> kernel to do this for other drivers.
I do not know how to find them. :-(
> You only really
>> need to change the line with .ioctl=... to .unlocked_ioctl=
Ok, this is simple.
>> and change the prototype of the referenced function to
>>
>> static long foo_ioctl(struct file *file, unsigned int cmd, unsigned
>> long arg)
>
> int nv_kern_ioctl(struct inode *, struct file *, unsigned int, unsigned
> long);
>
> It seems different. How to change it? Now it works, I built it without
> your remarks, exactly how I described on my blog:
>
> http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
Ok, as I wrote the prototypes differ. What should I do with the inode
parameter?
Regards,
Piotr Hosowicz
--
- Za moich czas?w to w sklepach by? tylko ocet i denaturat!
- Tato, przesta?, ?e w ca?ym Tesco by? tylko ocet i denaturat!
NP: -
NB: 2.6.36-rc1
On Tuesday 17 August 2010, Piotr Hosowicz wrote:
> >> Just take a look at all the other patches that went into the
> >> kernel to do this for other drivers.
>
> I do not know how to find them. :-(
git log -p -S"unlocked_ioctl"
> > It seems different. How to change it? Now it works, I built it without
> > your remarks, exactly how I described on my blog:
> >
> > http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
>
> Ok, as I wrote the prototypes differ. What should I do with the inode
> parameter?
It's normally not needed.
If you do need it, use file->f_path.dentry->d_inode.
Arnd
On 17.08.2010 15:18, Arnd Bergmann wrote:
> On Tuesday 17 August 2010, Piotr Hosowicz wrote:
>>>> Just take a look at all the other patches that went into the
>>>> kernel to do this for other drivers.
>>
>> I do not know how to find them. :-(
>
> git log -p -S"unlocked_ioctl"
Thanks a lot.
>>> It seems different. How to change it? Now it works, I built it without
>>> your remarks, exactly how I described on my blog:
>>>
>>> http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
>>
>> Ok, as I wrote the prototypes differ. What should I do with the inode
>> parameter?
>
> It's normally not needed.
It seems so because the implementation nowwhere refers to the inode
parameter. But I guess it won't be OK to just remove this parameter from
the declaraion and the implemetation because some other NVidia code may
refer to this parameter, pass it and so on. Potentially scrambling
(spoiling) the parameter stack.
Regards,
Piotr Hosowicz
> If you do need it, use file->f_path.dentry->d_inode.
Ok, as I said - it is nowhere used. So this is not a problem.
Regards,
Piotr Hosowicz
--
Na przyj?ciu ch?opak pyta blondynk?:
- Czy mog? ci? prosi? do walca?
- Zg?upia?e?? To ju? nie mia?e? czym przyjecha??
NP: -
NB: 2.6.36-rc1
On 17.08.2010 15:51, Piotr Hosowicz wrote:
> On 17.08.2010 15:18, Arnd Bergmann wrote:
>> On Tuesday 17 August 2010, Piotr Hosowicz wrote:
>>>>> Just take a look at all the other patches that went into the
>>>>> kernel to do this for other drivers.
>>>
>>> I do not know how to find them. :-(
>>
>> git log -p -S"unlocked_ioctl"
>
> Thanks a lot.
>
>>>> It seems different. How to change it? Now it works, I built it without
>>>> your remarks, exactly how I described on my blog:
>>>>
>>>> http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
>>>
>>> Ok, as I wrote the prototypes differ. What should I do with the inode
>>> parameter?
>>
>> It's normally not needed.
>
> It seems so because the implementation nowwhere refers to the inode
> parameter. But I guess it won't be OK to just remove this parameter from
> the declaraion and the implemetation because some other NVidia code may
> refer to this parameter, pass it and so on. Potentially scrambling
> (spoiling) the parameter stack.
This is as I said, I just commented inode parameter and it wont build:
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c: At top level:
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:426: warning:
initialization from incompatible pointer type
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c: In function
‘nv_kern_unlocked_ioctl’:
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:3062: warning:
passing argument 1 of ‘nv_kern_ioctl’ from incompatible pointer type
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:2876: note: expected
‘struct file *’ but argument is of type ‘struct inode *’
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:3062: warning:
passing argument 2 of ‘nv_kern_ioctl’ makes integer from pointer without
a cast
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:2876: note: expected
‘unsigned int’ but argument is of type ‘struct file *’
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:3062: error: too
many arguments to function ‘nv_kern_ioctl’
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c: In function
‘nv_kern_compat_ioctl’:
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:3071: warning:
passing argument 1 of ‘nv_kern_ioctl’ from incompatible pointer type
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:2876: note: expected
‘struct file *’ but argument is of type ‘struct inode *’
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:3071: warning:
passing argument 2 of ‘nv_kern_ioctl’ makes integer from pointer without
a cast
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:2876: note: expected
‘unsigned int’ but argument is of type ‘struct file *’
/root/nvidia/NVIDIA-Linux-x86_64-256.44/kernel/nv.c:3071: error: too
many arguments to function ‘nv_kern_ioctl’
Regards,
Piotr Hosowicz
--
Zatrzymuje się samochód na sejmowym parkingu. Podchodzi do niego
ochroniarz i mówi:
- Pan tu parkuje?! Tu Sejm ... Ministrowie, politycy, posłowiei ...
- Dzięki, włączę alarm.
NP: -
NB: 2.6.36-rc1
On 17.08.2010 15:59, Piotr Hosowicz wrote:
> On 17.08.2010 15:51, Piotr Hosowicz wrote:
>> On 17.08.2010 15:18, Arnd Bergmann wrote:
>>> On Tuesday 17 August 2010, Piotr Hosowicz wrote:
>>>>>> Just take a look at all the other patches that went into the
>>>>>> kernel to do this for other drivers.
>>>>
>>>> I do not know how to find them. :-(
>>>
>>> git log -p -S"unlocked_ioctl"
>>
>> Thanks a lot.
>>
>>>>> It seems different. How to change it? Now it works, I built it without
>>>>> your remarks, exactly how I described on my blog:
>>>>>
>>>>> http://phosowicz.jogger.pl/2010/08/15/nvidia-graphics-in-fresh-kernels/
>>>>>
>>>>
>>>> Ok, as I wrote the prototypes differ. What should I do with the inode
>>>> parameter?
>>>
>>> It's normally not needed.
>>
>> It seems so because the implementation nowwhere refers to the inode
>> parameter. But I guess it won't be OK to just remove this parameter from
>> the declaraion and the implemetation because some other NVidia code may
>> refer to this parameter, pass it and so on. Potentially scrambling
>> (spoiling) the parameter stack.
>
> This is as I said, I just commented inode parameter and it wont build:
I appeared when I examined the code that they prepared for this and :
#define HAVE_UNLOCKED_IOCTL 1
... in nv.c almost suffices. ;-) They defined this like that:
static struct file_operations nv_fops = {
.owner = THIS_MODULE,
.poll = nv_kern_poll,
// .ioctl = nv_kern_ioctl,
#if defined(HAVE_UNLOCKED_IOCTL)
.unlocked_ioctl = nv_kern_unlocked_ioctl,
#endif
#if defined(NVCPU_X86_64) && defined(HAVE_COMPAT_IOCTL)
.compat_ioctl = nv_kern_compat_ioctl,
#endif
#ifndef NV_USER_MAP
.mmap = nv_kern_mmap,
#endif /* NV_USER_MAP */
.open = nv_kern_open,
.release = nv_kern_close,
};
Regards and thanks,
Piotr Hosowicz
--
- Jaka jest najwi?ksza anomalia fizjologiczno-polityczna?
- Cz?onek wysuni?ty z ramienia na czo?o.
NP: Dream Theater - Pull Me Under
NB: 2.6.36-rc1