(solved) rt2570 CVS compilation error

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=4908

hedser

23-07-2008 14:16:43

Hello,

Since i installed a new kernel under Fedora 9, rt2570-CVS, downloaded 22 July, does not compile anymore. With previous kernels it compiles fine.
This is the output of make
[code1a3tjduh]make[1]: Entering directory `/usr/src/kernels/2.6.25.10-86.fc9.i686'
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_main.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/mlme.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_bulk.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/connect.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/sync.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_init.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/rtmp_tkip.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/wpa.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/rtmp_wep.o
CC [M] /mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.o
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c: In function ‘rtusb_ioctl_giwscan’:
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:654: warning: passing argument 1 of ‘iwe_stream_add_event’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:654: warning: passing argument 3 of ‘iwe_stream_add_event’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:654: warning: passing argument 4 of ‘iwe_stream_add_event’ makes pointer from integer without a cast
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:654: error: too few arguments to function ‘iwe_stream_add_event’
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:672: warning: passing argument 1 of ‘iwe_stream_add_event’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:672: warning: passing argument 3 of ‘iwe_stream_add_event’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:672: warning: passing argument 4 of ‘iwe_stream_add_event’ makes pointer from integer without a cast
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:672: error: too few arguments to function ‘iwe_stream_add_event’
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:678: warning: passing argument 1 of ‘iwe_stream_add_point’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:678: warning: passing argument 3 of ‘iwe_stream_add_point’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:678: warning: passing argument 4 of ‘iwe_stream_add_point’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:678: error: too few arguments to function ‘iwe_stream_add_point’
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:686: warning: passing argument 1 of ‘iwe_stream_add_point’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:686: warning: passing argument 3 of ‘iwe_stream_add_point’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:686: warning: passing argument 4 of ‘iwe_stream_add_point’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:686: error: too few arguments to function ‘iwe_stream_add_point’
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:699: warning: passing argument 1 of ‘iwe_stream_add_value’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:699: warning: passing argument 4 of ‘iwe_stream_add_value’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:699: warning: passing argument 5 of ‘iwe_stream_add_value’ makes pointer from integer without a cast
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:699: error: too few arguments to function ‘iwe_stream_add_value’
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:710: warning: passing argument 1 of ‘iwe_stream_add_event’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:710: warning: passing argument 3 of ‘iwe_stream_add_event’ from incompatible pointer type
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:710: warning: passing argument 4 of ‘iwe_stream_add_event’ makes pointer from integer without a cast
/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.c:710: error: too few arguments to function ‘iwe_stream_add_event’
make[2]: *** [/mnt/f/src/rt2570-cvs-2008072205/Module/rtusb_info.o] Error 1
make[1]: *** [_module_/mnt/f/src/rt2570-cvs-2008072205/Module] Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.25.10-86.fc9.i686'
rt2570.ko failed to build!
make: *** [module] Error 1[/code1a3tjduh]
Can anyone help?

Thanks in advance.
Hedser

Vern

23-07-2008 17:03:26

Hi hedser,

What is the output of "uname -r" on your system?

Thanks,

IvD

23-07-2008 17:44:03

Vern, I see this is a 2.6.25 _fedora_ kernel, this means it is comparible to a 2.6.26 kernel (much like current wireless-testing.git)

degraaf

23-07-2008 18:31:06

As requested

$ uname -r
2.6.25-14.fc9.x86_64

(This agrees with the error messages that I quoted.)
Actually, it doesn't. My apologies. It is from the older kernel - the one that
still allows the wireless connection to work properly, so I can send this message.

The first line of the make output error was
make[1] Entering directory `/usr/src/kernels/2.6.25.10-86.fc9.x86_64'
corresponding to the new kernel. I have these two sets
$ ll /lib/modules
total 8
drwxr-xr-x 8 root root 4096 2008-07-21 1539 2.6.25-14.fc9.x86_64
drwxr-xr-x 7 root root 4096 2008-07-20 2001 2.6.25.10-86.fc9.x86_64

Apparently hedser and I (degraaf) have the identical problem.

hedser

23-07-2008 20:56:23

Hi Vern,

Kernel is 2.6.25.10-86.fc9.i686
The last kernel i got it working allright is 2.6.25.9-76.fc9.i686

Hedser

Vern

24-07-2008 16:18:44

Thanks Guys,

Also, could you do something like this
[code38c8jk81](touch dummy_file.c; gcc -E -dM dummy_file.c;\rm dummy_file.c)|sort[/code38c8jk81] and attach a gzipped copy of the output to a posting here? The idea is to see if there may be some compiler constant that can be used to conditionally compile for Fedora.

Thanks,

degraaf

24-07-2008 18:39:00

I've run your script for both the older kernel and newer kernel. The outputs were identical.

Vern

24-07-2008 19:56:58

Hi degraaf,

Thanks for the info.

Finally (I hope), what is the output of the "kernelversion" command? (Much too efficient to think of all this on a single post.)

Thanks again,

degraaf

24-07-2008 20:59:04

# kernelversion
-bash kernelversion command not found
# rpm -q kernel

I've never seen such a command on a Fedora system.

Does this help?
# rpm -q kernel
kernel-2.6.25-14.fc9.x86_64
kernel-2.6.25.10-86.fc9.x86_64

I really appreciate your help and support on this issue.

Vern

25-07-2008 15:45:26

Hi degraaf,

OK. Really finally, what do you have in version.h? I'm trying to find out if Fedora has any surprises for the LINUX_VERSION_CODE and KERNEL_VERSION macros.

Thanks again,

deds

25-07-2008 17:34:48

I'm compiling rt2500 cvs but since I get the same error, I'll get into the mix. D

[code2g0xcgws][deds@zeus ~]$ cat /usr/src/kernels/2.6.25.10-86.fc9.x86_64/include/linux/version.h
#define LINUX_VERSION_CODE 132633
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))[/code2g0xcgws]

deds

25-07-2008 17:38:09

Also I want to add to my previous post that it's the same as the version.h in the last working kernel I can compile it in -- 2.6.25.9-76.fc9.x86_64

Vern

25-07-2008 17:57:59

Thanks deds. This problem affects all the legacy drivers. I'll make sure to propagate the fix to all.

degraaf

25-07-2008 19:52:16

Yes, I concur with deds. The content of version.h is the same in both kernels.
The one where rt2570 compiles perfectly

[code2uaxh2x6]$ cat /usr/src/kernels/2.6.25-14.fc9.x86_64/include/linux/version.h
#define LINUX_VERSION_CODE 132633
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[/code2uaxh2x6]
and the one where rt2570 compilation fails

[code2uaxh2x6]$ cat /usr/src/kernels/2.6.25.10-86.fc9.x86_64/include/linux/version.h
#define LINUX_VERSION_CODE 132633
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[/code2uaxh2x6]
Sorry to be redundant. Just want you to know I'm still with you, and give you as much encouragement as possible.

Vern

26-07-2008 01:19:58

OK, really, really finally (maybe), what's the output of "uname -a" on your Fedora systems?

Thanks,

deds

26-07-2008 04:51:38

On the kernel where it won't compile...

[codetsqo2r54][deds@zeus ~]$ uname -a
Linux zeus.homenet 2.6.25.10-86.fc9.x86_64 #1 SMP Mon Jul 7 20:23:46 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux[/codetsqo2r54]

deds

26-07-2008 04:58:05

vern,

I did an interim patch to handle the new definition for the calls to iwe_stream_add_event, iwe_stream_add_value and iwe_stream_add_point in rtmp_info.c and doing this post using that kernel now. I'm not sure if this is the proper way to do it though as I haven't done C in eons. Plus it's most likely to break when compiling on other distros kernel 2.6.25. I'm wondering why Fedora changed the definition in the same point release as it doesn't look like this on 2.6.25-9 (which is also .25).

Anyway here's the patch for rt2500 in case anyone can use it. Or maybe you can help in rewriting it to make it correct if it's possible for inclusion. I doubt that though since it's more likely an isolated FC9 problem due to the difference in the call in the same point release of the kernel.

[code2jff9x21]*** rtmp_info.c.orig 2008-07-26 12:48:01.000000000 +0800
--- rtmp_info.c 2008-07-26 02:37:35.000000000 +0800
***************
*** 461,466 ****
--- 461,467 ----
char *end_buf = extra + IW_SCAN_MAX_DATA;
char *current_val;
struct iw_event iwe;
+ struct iw_request_info iwri;

//check if the interface is down
if (!RTMP_TEST_FLAG(pAdapter, fRTMP_ADAPTER_INTERRUPT_IN_USE)) {
***************
*** 488,497 ****

//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWAP;
iwe.u.ap_addr.sa_family = ARPHRD_ETHER;
memcpy(iwe.u.ap_addr.sa_data, &pAdapter->PortCfg.BssTab.BssEntry[i].Bssid, ETH_ALEN);
! current_ev = iwe_stream_add_event(current_ev,end_buf, &iwe, IW_EV_ADDR_LEN);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWMODE;
--- 489,499 ----

//================================
memset(&iwe, 0, sizeof(iwe));
+ memset(&iwri, 0, sizeof(iwri));
iwe.cmd = SIOCGIWAP;
iwe.u.ap_addr.sa_family = ARPHRD_ETHER;
memcpy(iwe.u.ap_addr.sa_data, &pAdapter->PortCfg.BssTab.BssEntry[i].Bssid, ETH_ALEN);
! current_ev = iwe_stream_add_event(&iwri,current_ev,end_buf, &iwe, IW_EV_ADDR_LEN);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWMODE;
***************
*** 509,521 ****
}

iwe.len = IW_EV_UINT_LEN;
! current_ev = iwe_stream_add_event(current_ev, end_buf, &iwe, IW_EV_UINT_LEN);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWESSID;
iwe.u.data.length = pAdapter->PortCfg.BssTab.BssEntry[i].SsidLen;
iwe.u.data.flags = 1;
! current_ev = iwe_stream_add_point(current_ev,end_buf, &iwe, pAdapter->PortCfg.BssTab.BssEntry[i].Ssid);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWENCODE;
--- 511,523 ----
}

iwe.len = IW_EV_UINT_LEN;
! current_ev = iwe_stream_add_event(&iwri,current_ev, end_buf, &iwe, IW_EV_UINT_LEN);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWESSID;
iwe.u.data.length = pAdapter->PortCfg.BssTab.BssEntry[i].SsidLen;
iwe.u.data.flags = 1;
! current_ev = iwe_stream_add_point(&iwri,current_ev,end_buf, &iwe, pAdapter->PortCfg.BssTab.BssEntry[i].Ssid);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWENCODE;
***************
*** 523,529 ****
iwe.u.data.flags =IW_ENCODE_ENABLED | IW_ENCODE_NOKEY;
else
iwe.u.data.flags = IW_ENCODE_DISABLED;
! current_ev = iwe_stream_add_point(current_ev, end_buf,&iwe, pAdapter->PortCfg.BssTab.BssEntry[i].Ssid);

//================================
memset(&iwe, 0, sizeof(iwe));
--- 525,531 ----
iwe.u.data.flags =IW_ENCODE_ENABLED | IW_ENCODE_NOKEY;
else
iwe.u.data.flags = IW_ENCODE_DISABLED;
! current_ev = iwe_stream_add_point(&iwri,current_ev, end_buf,&iwe, pAdapter->PortCfg.BssTab.BssEntry[i].Ssid);

//================================
memset(&iwe, 0, sizeof(iwe));
***************
*** 534,540 ****
{
iwe.u.bitrate.value = RateIdToMbps[pAdapter->PortCfg.BssTab.BssEntry[i].Rates[i]/2] * 1000000;
iwe.u.bitrate.disabled = 0;
! current_val = iwe_stream_add_value(current_ev,
current_val, end_buf, &iwe,
IW_EV_PARAM_LEN);
}
--- 536,542 ----
{
iwe.u.bitrate.value = RateIdToMbps[pAdapter->PortCfg.BssTab.BssEntry[i].Rates[i]/2] * 1000000;
iwe.u.bitrate.disabled = 0;
! current_val = iwe_stream_add_value(&iwri,current_ev,
current_val, end_buf, &iwe,
IW_EV_PARAM_LEN);
}
***************
*** 547,553 ****
iwe.u.freq.m = pAdapter->PortCfg.BssTab.BssEntry[i].Channel;
iwe.u.freq.e = 0;
iwe.u.freq.i = 0;
! current_ev = iwe_stream_add_event(current_ev,end_buf, &iwe, IW_EV_FREQ_LEN);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVQUAL;
--- 549,555 ----
iwe.u.freq.m = pAdapter->PortCfg.BssTab.BssEntry[i].Channel;
iwe.u.freq.e = 0;
iwe.u.freq.i = 0;
! current_ev = iwe_stream_add_event(&iwri,current_ev,end_buf, &iwe, IW_EV_FREQ_LEN);
//================================
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVQUAL;
***************
*** 559,565 ****
iwe.u.qual.noise = pAdapter->PortCfg.BssTab.BssEntry[i].Noise;
//iwe.u.qual.noise = (pAdapter->PortCfg.LastR17Value > BBP_R17_DYNAMIC_UP_BOUND) ? BBP_R17_DYNAMIC_UP_BOUND : ((ULONG) pAdapter->PortCfg.LastR17Value); // // noise level (dBm)

! current_ev = iwe_stream_add_event(current_ev,end_buf, &iwe, IW_EV_QUAL_LEN);


//================================
--- 561,567 ----
iwe.u.qual.noise = pAdapter->PortCfg.BssTab.BssEntry[i].Noise;
//iwe.u.qual.noise = (pAdapter->PortCfg.LastR17Value > BBP_R17_DYNAMIC_UP_BOUND) ? BBP_R17_DYNAMIC_UP_BOUND : ((ULONG) pAdapter->PortCfg.LastR17Value); // // noise level (dBm)

! current_ev = iwe_stream_add_event(&iwri,current_ev,end_buf, &iwe, IW_EV_QUAL_LEN);


//================================
[/code2jff9x21]

degraaf

26-07-2008 16:01:52

Without carefully reading what deds had done, I tried to apply his patch to the rt2570 code.
Obviously, it failed, because the patch is designed for the rt2500 code.

I tried to read the patch to see if I could apply it manually to the rt2570 code, but wasn't able to understand how to do that. Simply way beyond my C coding comprehension.

Vern

27-07-2008 02:09:03

Hi deds,

Thanks for doing the patch. Unfortunately, I can't figure out how to get patch to apply it. Could you go to the directory that the patched file is in (it should also have the CVS links), and do something like the following[code4kzdrstp]cvs diff -u|gzip >a-suitable-name.gz[/code4kzdrstp]then append a-suitable-name.gz to a posting here?

Thanks,

deds

27-07-2008 05:54:50

Vern,

Here's the attachment for the patch. I haven't adjusted the rt_config.h file. This should probably be a declaration for LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,26) ? But even when that is added, I reckon it's still not going to compile for Fedora kernels 2.6.25.10 and later up to the point where they actually name it 2.6.26.*. Hope this helps.

deds

27-07-2008 06:09:27

degraaf,

I tried patching the code for rt2570. See if this helps you. Go into the Module directory of your CVS source and issue a "patch < location/of/your/patch/file" then try and compile. I'm attaching the patch for 2570 here.

degraaf

28-07-2008 03:33:20

deds & vern
I'm very pleased to report that deds' patch, rt2570.fc9.kernel-2.6.25.10-86.patch, worked. The rt2570 code, rt2570-cvs-2008072016.test/, compiled without complaint and the driver is running now as I write this.
Moreover, a new kernel, kernel-2.6.25.11-97.fc9.x86_64, arrived today and that's what I used to compile the patched rt2570 code. Without this patch, the rt2570 failed to make with the same error messages as before. With the patch, the module seems to work as reliably as ever (based on somewhat brief observation).

Many thanks to all.

hedser

28-07-2008 20:02:27

I've just been away a few days and i see that a patch is made..., great!
I tried it with the 2.6.25.10-86.fc9.i386 kernel and later on with the 2.6.25.11-97.fc9.i386 kernel and it compiles without any problem in both cases

Thanks for the effort everyone!

Hedser

Vern

01-08-2008 20:27:15

Hi deds,

Thanks very much for your patch - and for producing an rt2570 version. It was very informative and turns out to have saved me a lot of legwork. I've adapted it so that the driver will continue to build on kernels earlier than 2.6.26, and *should* work for newer kernels as well as all Fedora versions.

degraaf and/or hedser

I've attached the modified version of deds' patch as rt2570fc1.patch.gz. Could you apply it to a vanilla copy of the latest CVS and see if works for 2.6.25.10-86.fc9.i686 and - if possible - for 2.6.25.9-76.fc9.i686?

If everything's OK, I'll propagate it to the rt2500 driver and see if I can talk deds into checking it over. If that's OK, then I'll do the other legacy drivers. Otherwise, I'll fix it until it is OK.

Also, for my info, what does the Fedora kernel source Makefile have for VERSION, PATCHLEVEL, SUBLEVEL, and EXTRAVERSION?

Thanks,

degraaf

03-08-2008 15:05:30

I am away from home for this week, so cannot test anything until next Sunday, 8/10. However the patched code has been working perfectly for the past week.

Vern

07-08-2008 16:15:14

Since this thing's been up for six days, downloaded seven times, and there's been no complaints, I'm concluding it's good. Patches for this and the other legacy drivers should start showing up in the hourly tarballs soon.

Since you didn't speak up, you must now forever hold your peace (just kidding).

deds

08-08-2008 03:40:04

Vern,

There's a missing condition and a typo in the macro definitions in the code you pushed into CVS so it's not properly expanding the macros. I'm attaching the fix for 2500 here. Thanks for the attribution in the changelog. Name's deds though not debs. wink

deds

08-08-2008 03:56:15

Vern,

Take #2 on the patch. I forgot to include condition for FC kernels < 2.6.25.

Vern

08-08-2008 17:37:39

Hi deds,

Thanks for the fixup (shows what I get for flying blind), and sorry about getting the name wrong.

There is indeed a typo in the mods for rt_config.h[code3drohis2]#define iwri_ref(x) (x,)[/code3drohis2] should be [code3drohis2]#define iwri_ref(x) x,[/code3drohis2] I ran gcc -E with that change in, and things expand as I expected; so it should also make the rtmp_info.c mods OK, too.

As for the compilation conditional, it looks OK to me. As I read it, the left of the OR says "if kernel < 2.6.26" and the right side requires all of "kernel = 2.6.25" AND "fedora is defined" AND "its defined as < 10". If that's true, we use the null expansions. If we're at 2.6.26, or 2.6.25 and Fedora 10 or better, we use the non-null expansions.

Could you try changing just the iwri_ref macro and see if that is indeed sufficient?

Thanks,

Vern

09-08-2008 17:05:03

Well, I mulled over deds' compilation test for the 2.6.26 wireless interface macros some more, and sure enough, I managed to screw it up. Dawned on me just as I went to bed last night.

Anyway, I've put what I hope is really a fix this time for all the legacy drivers into CVS.

If you have compilation problems - especially under 2.6.26 or 2.6.25 Fedora Core 10 and later - please post here.

Thanks,

deds

10-08-2008 12:17:11

Vern,

One last correction in rt_config.h. You forgot the ampersand in the memset operation for iwri_start.

Vern

10-08-2008 15:27:50

Thanks deds. Fix is in CVS and should start showing up in tarballs soon.

danhyanh

12-08-2008 02:10:53

I'm having a problem related to the Fedora compilation problem. The error looks to be similar to the original posted error, except that it says there are "too many arguments" instead of "too few arguments."

Additional information

I am using Arch Linux, with kernel version 2.6.26.2, and the rt2570 driver from CVS was downloaded today, August 11 (rt2570-cvs-2008081119). I had to revert to an earlier CVS version (rt2570-cvs-2008080112) from August 1, which compiles and runs just fine with the 2.6.26.2 kernel as well as the earlier 2.6.25 kernel I was using before.

Here is my make output
[code2w65ot2u]
make[1]: Entering directory `/usr/src/linux-2.6.26-ARCH'
CC [M] /usr/src/rt2570-cvs-2008081119/Module/rtusb_info.o
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c: In function ‘rtusb_ioctl_giwscan’:
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:656: warning: passing argument 1 of ‘iwe_stream_add_event’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:656: warning: passing argument 3 of ‘iwe_stream_add_event’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:656: warning: passing argument 4 of ‘iwe_stream_add_event’ makes integer from pointer without a cast
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:656: error: too many arguments to function ‘iwe_stream_add_event’
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:674: warning: passing argument 1 of ‘iwe_stream_add_event’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:674: warning: passing argument 3 of ‘iwe_stream_add_event’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:674: warning: passing argument 4 of ‘iwe_stream_add_event’ makes integer from pointer without a cast
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:674: error: too many arguments to function ‘iwe_stream_add_event’
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:680: warning: passing argument 1 of ‘iwe_stream_add_point’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:680: warning: passing argument 3 of ‘iwe_stream_add_point’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:680: warning: passing argument 4 of ‘iwe_stream_add_point’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:680: error: too many arguments to function ‘iwe_stream_add_point’
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:688: warning: passing argument 1 of ‘iwe_stream_add_point’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:688: warning: passing argument 3 of ‘iwe_stream_add_point’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:688: warning: passing argument 4 of ‘iwe_stream_add_point’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:688: error: too many arguments to function ‘iwe_stream_add_point’
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:701: warning: passing argument 1 of ‘iwe_stream_add_value’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:701: warning: passing argument 4 of ‘iwe_stream_add_value’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:701: warning: passing argument 5 of ‘iwe_stream_add_value’ makes integer from pointer without a cast
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:701: error: too many arguments to function ‘iwe_stream_add_value’
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:712: warning: passing argument 1 of ‘iwe_stream_add_event’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:712: warning: passing argument 3 of ‘iwe_stream_add_event’ from incompatible pointer type
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:712: warning: passing argument 4 of ‘iwe_stream_add_event’ makes integer from pointer without a cast
/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.c:712: error: too many arguments to function ‘iwe_stream_add_event’
make[2]: *** [/usr/src/rt2570-cvs-2008081119/Module/rtusb_info.o] Error 1
make[1]: *** [_module_/usr/src/rt2570-cvs-2008081119/Module] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.26-ARCH'
rt2570.ko failed to build!
make: *** [module] Error 1
[/code2w65ot2u]
As my knowledge of C is rather limited, I'm not sure what to make of this, but from my searching in the forum it looks like my problem may be related to the earlier problem some users had with Fedora.

Vern

12-08-2008 03:32:01

Hi danhyanh,

The CVS version that works for you preceeds all modifications to accomodate 2.6.26 and Fedora. Two questions

1. What is the output of "uname -a"?
2. Could you provide the content of your "version.h" file - e.g. linux-2.6x/include/linux/version.h?

Thanks,

Vern

12-08-2008 16:39:50

OK, I should have done exactly what deds said in his most recent post. CVS has been updated to suit.

danhyanh, two more questions

3. What are the first five lines of your kernel Makefile?
4. Could you attach a gzipped copy of your kernel source's include/net/iw_handler.h to a posting here?

Thanks,

danhyanh

12-08-2008 21:18:19

1. uname -a output is as follows --
[code1r4sklz7]
2.6.26-ARCH #1 SMP PREEMPT Sun Aug 10 12:29:20 UTC 2008 i686 Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz GenuineIntel GNU/Linux
[/code1r4sklz7]
2. version.h --
[code1r4sklz7]
#define LINUX_VERSION_CODE 132634
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[/code1r4sklz7]
3. First five lines of Makefile --
[code1r4sklz7]
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 26
EXTRAVERSION =
NAME = Rotary Wombat
[/code1r4sklz7]
("Rotary Wombat?" Weird.)

4. File attached.

EDIT Sorry about the first file, I didn't notice it.

Vern

13-08-2008 01:56:31

Hi danhyanh,

Thanks for the info. Unfortunately, the iw_handler.gz you attached is 73 characters of garbage. Could you try it again, maybe like this[code3n9c8ukk]cat /usr/src/linux-2.6.26/include/net/iw_handler.h|gzip >iw_handler.h.gz[/code3n9c8ukk]then attach iw_handler.h.gz to a posting here?

Thanks,

deds

13-08-2008 03:06:54

Vern,

It's possible that the expansion for iwri_ref is blank and the rtmp_info.c has the & inlined resulting in a blank var. My patch before was to move the & to rt_config so that you don't end up with an empty ref. Is that correct?

Vern

13-08-2008 16:32:17

Hi deds,

The blank expansion actually worked OK. The problem was that the non-blank expansion of[code1rm44kre]iwri_start(&iwri)[/code1rm44kre]would give[code1rm44kre]memset(&iwri, 0, sizeof(&iwri)[/code1rm44kre](parameter expansion is everything between the commas). Its legal, and on a 32 bit machine gives the same size as sizeof(iwri), but basically avoids problems thru dumb luck. So moving the & to rt_config avoids that.

Thanks again for your help. This has been a troublesome little beastie.

jdurand

13-08-2008 17:15:59

Compiling debian kernel 2.6.26-2 (to which I add fbcondecor and tuxonice patches - these has nothing to do I believe with the iwe api), I see

[code33lyys6r]make[3]: Entering directory `/usr/src/modules/rt2570'
make[4]: Entering directory `/usr/src/linux-source-2.6.26'
CC [M] /usr/src/modules/rt2570/rtusb_main.o
/usr/src/modules/rt2570/rtusb_main.c: In function 'usb_rtusb_close':
/usr/src/modules/rt2570/rtusb_main.c:1421: warning: ignoring return value of 'down_interruptible', declared with attribute warn_unused_result
CC [M] /usr/src/modules/rt2570/mlme.o
CC [M] /usr/src/modules/rt2570/rtusb_bulk.o
CC [M] /usr/src/modules/rt2570/connect.o
CC [M] /usr/src/modules/rt2570/sync.o
CC [M] /usr/src/modules/rt2570/rtusb_init.o
CC [M] /usr/src/modules/rt2570/rtmp_tkip.o
CC [M] /usr/src/modules/rt2570/wpa.o
CC [M] /usr/src/modules/rt2570/rtmp_wep.o
CC [M] /usr/src/modules/rt2570/rtusb_info.o
/usr/src/modules/rt2570/rtusb_info.c: In function 'rtusb_ioctl_giwscan':
/usr/src/modules/rt2570/rtusb_info.c:656: warning: passing argument 1 of 'iwe_stream_add_event' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:656: warning: passing argument 3 of 'iwe_stream_add_event' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:656: warning: passing argument 4 of 'iwe_stream_add_event' makes integer from pointer without a cast
/usr/src/modules/rt2570/rtusb_info.c:656: error: too many arguments to function 'iwe_stream_add_event'
/usr/src/modules/rt2570/rtusb_info.c:674: warning: passing argument 1 of 'iwe_stream_add_event' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:674: warning: passing argument 3 of 'iwe_stream_add_event' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:674: warning: passing argument 4 of 'iwe_stream_add_event' makes integer from pointer without a cast
/usr/src/modules/rt2570/rtusb_info.c:674: error: too many arguments to function 'iwe_stream_add_event'
/usr/src/modules/rt2570/rtusb_info.c:680: warning: passing argument 1 of 'iwe_stream_add_point' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:680: warning: passing argument 3 of 'iwe_stream_add_point' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:680: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:680: error: too many arguments to function 'iwe_stream_add_point'
/usr/src/modules/rt2570/rtusb_info.c:688: warning: passing argument 1 of 'iwe_stream_add_point' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:688: warning: passing argument 3 of 'iwe_stream_add_point' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:688: warning: passing argument 4 of 'iwe_stream_add_point' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:688: error: too many arguments to function 'iwe_stream_add_point'
/usr/src/modules/rt2570/rtusb_info.c:701: warning: passing argument 1 of 'iwe_stream_add_value' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:701: warning: passing argument 4 of 'iwe_stream_add_value' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:701: warning: passing argument 5 of 'iwe_stream_add_value' makes integer from pointer without a cast
/usr/src/modules/rt2570/rtusb_info.c:701: error: too many arguments to function 'iwe_stream_add_value'
/usr/src/modules/rt2570/rtusb_info.c:712: warning: passing argument 1 of 'iwe_stream_add_event' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:712: warning: passing argument 3 of 'iwe_stream_add_event' from incompatible pointer type
/usr/src/modules/rt2570/rtusb_info.c:712: warning: passing argument 4 of 'iwe_stream_add_event' makes integer from pointer without a cast
/usr/src/modules/rt2570/rtusb_info.c:712: error: too many arguments to function 'iwe_stream_add_event'
make[5]: *** [/usr/src/modules/rt2570/rtusb_info.o] Error 1
make[4]: *** [_module_/usr/src/modules/rt2570] Error 2
make[4]: Leaving directory `/usr/src/linux-source-2.6.26'
rt2570.ko failed to build!
make[3]: *** [module] Error 1
make[3]: Leaving directory `/usr/src/modules/rt2570'
make[2]: *** [binary_modules] Error 2
make[2]: Leaving directory `/usr/src/modules/rt2570'
make[1]: *** [kdist_build] Error 2
make[1]: Leaving directory `/usr/src/modules/rt2570'
Module /usr/src/modules/rt2570 failed.
Hit return to Continue
[/code33lyys6r]

version.h

[code33lyys6r]#define LINUX_VERSION_CODE 132634
#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[/code33lyys6r]

Vern

14-08-2008 16:31:38

Hi danhyanh,

Got your iw_handler.h. Thanks. Looks like what's there are the 2.6.25 iwe_stream_xxx function prototypes. So we have the following situation.

The iwe_stream functions had an extra parameter added to them in 2.6.26 as supplied by kernel.org. We accommodate that.

Then Fedora retrofits those somewhere in the sequence of its versions of 2.6.25 point releases.

Fine. We accommodate that, too.

Now it turns out that Arch Linux (and, I suspect - possibly Mandriva) has forward-fitted the 2.26.25 iwe_stream api into its version of 2.6.26 point releases, as shown by the prototypes in the iw_handler.h file you supplied.

This is becoming combinatorily tough. I guess there are three workaround options[list1hgqr483]1. Use the nextgen driver. It's included in the 2.6.26 kernel and may automagically work.
2. Only use CVS versions earlier than 20080907 for the legacy USB driver. This will get you the suspend/resume fixes, but not the changes made to accommodate the iwe_stream API. You can return to the latest CVS when Arch's iwe_stream API conforms to the standard 2.6.26 version.
3. Roll back to an earlier kernel. This will allow you to always have the latest driver; and you can roll forward when Arch's iwe_stream API conforms to the standard 2.6.26 version.[/listu1hgqr483]

jdurand

Even tho the fbcondecor and tuxonice patches have nothing to do with the iwe api, what happens if you compile without them?

Thanks,

degraaf

14-08-2008 20:52:34

Vern, deds, et al
I've been recovering from last week's vacation, and see there's been lots of activity here.
Since things seem to have stabilized, I downloaded the CVS hourly tarball for rt2570.
'yum update' has also introduced a new kernel-2.6.25.14-108.fc9.x86_64 for Fedora 9.

I am pleased to report that today's rt2570 code compiled without a single error or warning,
and is running perfectly as I type this with a D-Link Corp. [hex] DWL-G122 802.11g rev. B1 [ralink] USB wireless adapter on two separate x86_64 machines.

Way to go, guys!

I hope this good stuff will filter into the actual kernel before too long.

danhyanh

14-08-2008 20:53:55

Wow, the situation with the kernel APIs is unfortunate. Anyway, thanks for your assistance!

jdurand

15-08-2008 05:25:58

jdurand

Even tho the fbcondecor and tuxonice patches have nothing to do with the iwe api, what happens if you compile without them?
[/quoteusnzye1a]

Same error - Thanks, JD.

jdurand

15-08-2008 13:10:19

The iwe_stream functions had an extra parameter added to them in 2.6.26 as supplied by kernel.org. We accommodate that ./.. Then Fedora retrofits those somewhere in the sequence of its versions of 2.6.25 point releases. Fine. We accommodate that, too[/quote1ctgzyxv]

I looked to vanilla 2.6.26.2 - the iwe change in not in there ? But I see it in patch-2.6.27-rc3, indeed.
If I am right then rt2570 should compile with kernels that follow upstream api, fedora kernel being an exception and not the ruler -;

My apologizes if I was wrong about the api version in the vanilla kernel.

Thanks, JD.

jdurand

16-08-2008 06:09:19

FYI, adding a rule for all 2.6.26 kernels but fedora's, it compiles fine for me on debian 2.6.26 and with the following in rt_config.h

[code3jynekyq]#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25) || \
(LINUX_VERSION_CODE == KERNEL_VERSION(2,6,25) && \
(!defined(FEDORA) || (defined(FEDORA) && FEDORA < 10))) || \
(LINUX_VERSION_CODE == KERNEL_VERSION(2,6,26) && !defined(FEDORA))
[/code3jynekyq]

Not yet tested, though.

Thanks, JD.

Vern

18-08-2008 01:05:31

Hi jdurand,

Thanks for the fix. You should start to see it in the CVS tarballs soon.

Your reference to Debian 2.6.26-2 made me suspicious, so I actually patched my own system up to 2.6.26, and - sure enough - got the "too many parameters" errors. Your patch fixes that. It turns out I had too uncritically accepted a statement in another thread (the poster of which shall remain nameless) that the "too few parameters" problem was happening in 2.6.26.

So, the story now is that the change in the numer of IWE parameters is actually for 2.6.27; and your fix handles that.

Thanks again,

bastikr

19-08-2008 07:26:56

Hey guys,
thank you for fixing this!