[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: spca5xx freezes system



On Tue, Apr 18, 2006 at 03:24:56PM -0400, D. Hugh Redelmeier wrote:
> | From: Lonni J Friedman <netllama gmail com>
> 
> | I agree that this could still point to a driver bug.  I asked the
> | developer whether he had verified if his driver works with the
> | 'official' gnu gcc-4.1, and he stated that he had not.
> 

I offer this comment as a data point.  I still don't have a problem.

I downloaded spca5xx-20060402 to be current with the others who have
problems hoping I could see a problem. 

I went to the spca5xx-20060402 directory, and as root, did
make clean
make
make install

I try to have a completely up to date system -- 
/etc/cron.daily/yum.cron  runs every night.

rsewill rsewill:~ <3:31> $ rpm -q -a | grep kernel
kernel-2.6.16-1.2080_FC5
kernel-devel-2.6.16-1.2080_FC5

I have the following gcc stuff installed:
rsewill rsewill:~ <3:33> $ rpm -q -a | grep gcc
compat-gcc-32-3.2.3-55.fc5
compat-libgcc-296-2.96-135
compat-gcc-32-c++-3.2.3-55.fc5
libgcc-4.1.0-3
gcc-4.1.0-3
gcc-gfortran-4.1.0-3
gcc-c++-4.1.0-3
compat-gcc-32-g77-3.2.3-55.fc5

The kernel would (should) use whatever gcc compiler, with whatever
options, it is meant to use when building kernel loadable modules
because of the /lib/modules/2.6.16-1.2080_FC5/build symbolic link.

Since more than one person is having problems, I assume there is
nothing from people's environments messing things up, like 
export CC=... or export CFLAGS=...  
[root rsewill spca5xx-20060402]# echo $CC $CFLAGS

[root rsewill spca5xx-20060402]# 

rsewill rsewill:~ <3:28> $ uname -a
Linux rsewill.rsewill.cableone.net 2.6.16-1.2080_FC5 #1 Tue Mar 28
03:38:34 EST 2006 i686 i686 i386 GNU/Linux

> Did you ask this on the spca50x-devs list?  That is probably the best
> place to discuss this.  It should be better than private mail to the
> developer because other users can join in.  It should be better than
> mail to this list since it is more appropriately specialized.  But it
> would great to tell us how this works out.
> 
> A quick look at that list shows a certain amount of bad behaviour on
> the part of this driver.
> 

I have to believe the driver is executing different code given others
have different hardware.  I guess using particular hardware matters.

> Archive:
>   http://sourceforge.net/mailarchive/forum.php?forum=spca50x-devs
> 
> Scary thread:
>   http://sourceforge.net/mailarchive/forum.php?thread_id=9976551&forum_id=32
> 
> One FC5 thread (there are others):
>   http://sourceforge.net/mailarchive/forum.php?thread_id=10186347&forum_id=32
> 
> |  I will be
> | unlikely to have time in the near future (within the next few weeks at
> | least) to rebuild a kernel against gcc-3.2 to verify his claim.  So,
> | if someone else has the time, please let us know how it works out.
> 
> I don't think that it make sense to use GCC-3.2.  Red Hat did their QA
> using 4.x and other parts of the Fedora kernel may break with 3.2.
> 
> It makes more sense to use GCC4.x without -O.  But just for the
> driver.  Surely you can build the driver without building the kernel.
> 
> I must admit that the following message disturbs me.  Building a
> driver should not require write access to the kernel source tree.
>   tom1:/usr/src/spca5xx-20060301# make
>    Building SPCA5XX driver for 2.5/2.6 kernel.
>    Remember: you must have read/write access to your kernel source tree.
> This was extracted from
>   http://sourceforge.net/mailarchive/forum.php?thread_id=10001199&forum_id=32

The idea that spca5xx-xxxxxxxx needs write access to the source would
be disturbing.  I looked at the Makefile, but didn't see any need for
write access to the kernel source.  The Makefile, for 2.6, seems to do
the following: 
        $(MAKE) -C $(KERNELDIR) SUBDIRS=$(PWD) CC=$(CC) modules

I was hoping I could reproduce the problem others have seen.  Sorry.
I'm afraid someone who can reproduce the problem will need to dig into
the code.  I'd focus on bus specific code and/or webcam specific code.

Has anyone successfully figured out the address in SDRAM where the
kernel loadable module was loaded, and compared that address with the
kernel panic address for the case where the kernel panics?

-Rick

> 
> -- 
> fedora-list mailing list
> fedora-list redhat com
> To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]