gcc -D__KERNEL__ -I/.share/usr/src/linux-2.5.7-pre2/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
-march=i386 -DMODULE -DMODVERSIONS -include
/.share/usr/src/linux-2.5.7-pre2/include/linux/modversions.h
-DKBUILD_BASENAME=ataraid -DEXPORT_SYMTAB -c ataraid.c
ataraid.c: In function `ataraid_make_request':
ataraid.c:105: structure has no member named `b_rdev'
ataraid.c:103: warning: `minor' might be used uninitialized in this function
ataraid.c: In function `ataraid_split_request':
ataraid.c:182: structure has no member named `b_rsector'
ataraid.c:193: warning: passing arg 1 of `generic_make_request_Rsmp_dd2e0d32'
makes pointer from integer without a cast
ataraid.c:193: too many arguments to function
`generic_make_request_Rsmp_dd2e0d32'
ataraid.c:194: warning: passing arg 1 of `generic_make_request_Rsmp_dd2e0d32'
makes pointer from integer without a cast
ataraid.c:194: too many arguments to function
`generic_make_request_Rsmp_dd2e0d32'
ataraid.c: In function `ataraid_init':
ataraid.c:249: `hardsect_size' undeclared (first use in this function)
ataraid.c:249: (Each undeclared identifier is reported only once
ataraid.c:249: for each function it appears in.)
ataraid.c:280: warning: passing arg 2 of
`blk_queue_make_request_Rsmp_e6d39e8a' from incompatible pointer
typeataraid.c: In function `ataraid_exit':
ataraid.c:289: `hardsect_size' undeclared (first use in this function)
make[2]: *** [ataraid.o] Error 1
make[2]: Leaving directory `/.share/usr/src/linux-2.5.7-pre2/drivers/ide'
make[1]: *** [_modsubdir_ide] Error 2
make[1]: Leaving directory `/.share/usr/src/linux-2.5.7-pre2/drivers'
make: *** [_mod_drivers] Error 2
On Mon, Mar 18, 2002 at 11:37:33AM -0200, Denis Vlasenko wrote:
> gcc -D__KERNEL__ -I/.share/usr/src/linux-2.5.7-pre2/include -Wall
> -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> -march=i386 -DMODULE -DMODVERSIONS -include
> /.share/usr/src/linux-2.5.7-pre2/include/linux/modversions.h
> -DKBUILD_BASENAME=ataraid -DEXPORT_SYMTAB -c ataraid.c
Yup, this, the Raid5 report, and a few other non-compiling bits
are logged at http://www.codemonkey.org.uk/Linux-2.5.html
If there's no change in those files between pre's, re-reporting
the same non-compile errors probably isn't going to get them fixed
any quicker 8-)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On 18 March 2002 11:22, Dave Jones wrote:
> On Mon, Mar 18, 2002 at 11:37:33AM -0200, Denis Vlasenko wrote:
> > gcc -D__KERNEL__ -I/.share/usr/src/linux-2.5.7-pre2/include -Wall
> > -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> > -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2
> > -march=i386 -DMODULE -DMODVERSIONS -include
> > /.share/usr/src/linux-2.5.7-pre2/include/linux/modversions.h
> > -DKBUILD_BASENAME=ataraid -DEXPORT_SYMTAB -c ataraid.c
>
> Yup, this, the Raid5 report, and a few other non-compiling bits
> are logged at http://www.codemonkey.org.uk/Linux-2.5.html
>
> If there's no change in those files between pre's, re-reporting
> the same non-compile errors probably isn't going to get them fixed
> any quicker 8-)
I didn't mean "hey it's broken, _fix _them _for _me_".
I don't use any of these things, I'll disable them in .config
and that's all.
Should I restrain from posting compile errors for 2.5?
--
vda
> I didn't mean "hey it's broken, _fix _them _for _me_".
> I don't use any of these things, I'll disable them in .config
> and that's all.
Yup, I know 8-)
> Should I restrain from posting compile errors for 2.5?
Only if they're regressions from previous kernels.
I try to keep the page at the URL in the previous mail up to date,
though in the last week, I've fallen behind a little.. I'll try
and catch up soon.
Thanks,
Dave.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, Mar 18, 2002 at 02:53:13PM +0100, Dave Jones wrote:
> I try to keep the page at the URL in the previous mail up to date,
> though in the last week, I've fallen behind a little.. I'll try
> and catch up soon.
Dave, can you put kernel versions next to the problem reports?
That way it'll be easier to see just how old the report is and see if it
should be tested again (for testers) or fixed (for developers).
Mike
On Mon, Mar 18, 2002 at 08:42:15AM -0800, Mike Fedyk wrote:
> Dave, can you put kernel versions next to the problem reports?
> That way it'll be easier to see just how old the report is and see if it
> should be tested again (for testers) or fixed (for developers).
At the top. "Up to date as of 2.5.6pre1."
(Yes, I'm a the report is a whole 4 patches behind..
I'll fix it up maybe later tonight)
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
On Mon, Mar 18, 2002 at 05:45:27PM +0100, Dave Jones wrote:
> On Mon, Mar 18, 2002 at 08:42:15AM -0800, Mike Fedyk wrote:
> > Dave, can you put kernel versions next to the problem reports?
> > That way it'll be easier to see just how old the report is and see if it
> > should be tested again (for testers) or fixed (for developers).
>
> At the top. "Up to date as of 2.5.6pre1."
> (Yes, I'm a the report is a whole 4 patches behind..
> I'll fix it up maybe later tonight)
>
2. Capable Of Corrupting Your FS/data.
* Some reports of unknown cause of ext2 corruption since 2.5.3 (not
related to the missing i_fsize clearing from .3pre3-5)
It would be good to report the last version that this problem was reported
against, and this type of problem can't really be tested on each pre patch.
That's basically what I was asking for before...
==============
# IDE floppy oops on some (zip100) setups. (Triggers BUG_ON() in
elevator.c:237)
If the version is reported for this then you can see what function was being
reported at the time. Otherwise some other patch could shift the contents
to make line 237 point to another function (rewrites and such...)
Mike
> * Some reports of unknown cause of ext2 corruption since 2.5.3 (not
> related to the missing i_fsize clearing from .3pre3-5)
>
> It would be good to report the last version that this problem was reported
> against, and this type of problem can't really be tested on each pre patch.
> That's basically what I was asking for before...
Gotcha. Point taken.
> # IDE floppy oops on some (zip100) setups. (Triggers BUG_ON() in
> elevator.c:237)
>
> If the version is reported for this then you can see what function was being
> reported at the time. Otherwise some other patch could shift the contents
> to make line 237 point to another function (rewrites and such...)
I'll make those BUG() descriptions include the function name & BUG condition
in future descriptions.
Thanks for the feedback
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs