drivers/usb/ov511.c does not compile
Apologies if this has been posted before. I imagine it has.
In kernel 2.4.5 stock, ov511.c fails to compile. A little intelligent searching through 2.4.4 source reveals that the following line in 2.4.4:
static const char version[] = "1.28";
is missing in 2.4.5, and this is why it does not compile. While I could fix this myself manually (and plan to do so), it would be nice to get the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock.
Quoted 11 lines · Kelledin Tane
Apologies if this has been posted before. I imagine it has.
In kernel 2.4.5 stock,
ov511.cfails to compile. A little intelligent searching through 2.4.4 source reveals that the following line in 2.4.4:static const char version[] = "1.28";
is missing in 2.4.5, and this is why it does not compile. While I could fix this myself manually (and plan to do so), it would be nice to get the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock.
This has already been fixed in the 2.4.5 pre patches.
JE
Quoted 4 lines
Quoted 2 lines
the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock.
This has already been fixed in the 2.4.5 pre patches.
.6 I assume.
ov511 still has some bad bugs in it - it doesnt work with some uhci drivers and it also does precisely the wrong thing when you set the capture size and breaks stuff like ffserver. The comments are right but the code picks the size which is bigger than the capture, not the nearest smaller size..
Quoted 6 lines · Alan Cox
Quoted 4 lines
Quoted 2 lines
the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock.
This has already been fixed in the 2.4.5 pre patches.
.6 I assume.
Yes, you're absolutely correct. Typo on my part.
Quoted 4 lines
ov511 still has some bad bugs in it - it doesnt work with some uhci drivers and it also does precisely the wrong thing when you set the capture size and breaks stuff like ffserver. The comments are right but the code picks the size which is bigger than the capture, not the nearest smaller size..
Hmm, I'll see if I can produce a patch to fix that.
JE
Kernel 2.0.35 limits
Just this morning, our firewall get a kernel panic after 500 days of uptime.
As you can see from the log files, the date starts at June 15th, where we get two div by zeros, then jumps May 11th, then a kernel panic. A reboot brings it back to June 15th. Since cron could not open /dev/rtc. My first thought was an internal kernel limit on the time, but 500 days seems a bit short.
Any ideas ?
Last message via e-mail was:
Date: Fri, 15 Jun 2001 08:01:05 -0400
To: [email protected]
From: Cron Daemon <[email protected]>
Subject: Cron <root@tap> run-parts /etc/cron.hourly
Unable to open /dev/rtc, open() errno = Device or resource busy (16)
The log file has:
...
Jun 15 08:01:13 tap PAM_pwdb[3491]: (su) session opened for user nobody by (uid=99) Jun 15 08:01:16 tap kernel: divide error: 0000 Jun 15 08:01:16 tap kernel: CPU: 0 Jun 15 08:01:16 tap kernel: EIP: 0010:[do_fast_gettimeoffset+71/120] Jun 15 08:01:16 tap kernel: EFLAGS: 00013002 Jun 15 08:01:16 tap kernel: eax: 0ccabc7c ebx: 01ea65e1 ecx: 00000017 edx: 00146440 Jun 15 08:01:16 tap kernel: esi: eb72aa0f edi: 00000000 ebp: bffffbd4 esp: 00718f88 Jun 15 08:01:16 tap kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Jun 15 08:01:16 tap kernel: Process hwclock (pid: 3495, process nr: 63, stackpage=00718000) Jun 15 08:01:16 tap kernel: Stack: 00718fb0 00003246 00000001 001109d6 bffffb3c 00000000 00117e08 00718fb0 Jun 15 08:01:16 tap kernel: 00a84414 bffffea8 3b29f90c 00007530 0010a989 bffffb3c 00000000 00000000 Jun 15 08:01:16 tap kernel: bffffea8 00000001 bffffbd4 ffffffda 0000002b 0000002b 0000002b 0000002b Jun 15 08:01:16 tap kernel: Call Trace: [do_gettimeofday+34/68] [sys_gettimeofday+44/112] [system_call+85/124] Jun 15 08:01:16 tap kernel: Code: f7 f1 ba 10 27 00 00 89 c1 31 c0 f7 f1 a3 e4 03 1d 00 89 c3 Jun 15 08:01:16 tap kernel: divide error: 0000 Jun 15 08:01:16 tap kernel: CPU: 0 Jun 15 08:01:16 tap kernel: EIP: 0010:[do_fast_gettimeoffset+71/120] Jun 15 08:01:16 tap kernel: EFLAGS: 00010002 Jun 15 08:01:16 tap kernel: eax: 0cf383d2 ebx: 01ea65e1 ecx: 00000019 edx: 00146440 Jun 15 08:01:16 tap kernel: esi: eb9b7165 edi: 00000000 ebp: bffffbd4 esp: 00ba1f88 Jun 15 08:01:16 tap kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Jun 15 08:01:16 tap kernel: Process hwclock (pid: 3509, process nr: 26, stackpage=00ba1000) Jun 15 08:01:16 tap kernel: Stack: 00ba1fb0 00000246 3b29f90b 001109d6 bffffb2c 00000000 00117e08 00ba1fb0 Jun 15 08:01:16 tap kernel: 00842c0c 3b29f90c 3b29f90c 0000c350 0010a989 bffffb2c 00000000 00000001 Jun 15 08:01:16 tap kernel: 3b29f90c 3b29f90b bffffbd4 ffffffda 0000002b 0000002b 0000002b 0000002b ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 7829 now 7829. May 11 07:52:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. May 11 07:53:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. May 11 07:54:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. Jun 15 10:33:39 tap kernel: klogd 1.3-3, log source = /proc/kmsg started. Jun 15 10:33:40 tap kernel: Loaded 4215 symbols from /boot/System.map. Jun 15 10:33:40 tap kernel: Symbols match kernel version 2.0.35.
...
Thank You.
Signature · 4 lines
Paul N. Faure 613.266.3286 Chief Technical Officer, CertainKey Inc. [email protected] Carleton University Systems Eng. 3rd Year [email protected] Engineering Society Administrator [email protected]
Re: Kernel 2.0.35 limits
Quoted 2 lines
Just this morning, our firewall get a kernel panic after 500 days of uptime.
Interesting very interesting in fact. There is a 497 day wrap on the kernel but it should do nothing more than send the uptime back to zero. Im not sure how the crash fits in to this but it could be significant that its about the wrap time
Re: Kernel 2.0.35 limits
The exact uptime is unknown, so it may have actually been 497 days.
No matter, since we will now upgrade the system. We held back on the upgrade before since it had such a nice uptime. Better than any other system on campus and its run by student volunteers.
Thanks for the info.
Quoted 8 lines · Alan Cox
Quoted 2 lines
Just this morning, our firewall get a kernel panic after 500 days of uptime.
Interesting very interesting in fact. There is a 497 day wrap on the kernel but it should do nothing more than send the uptime back to zero. I'm not sure how the crash fits in to this but it could be significant that its about the wrap time
Signature · 4 lines
Paul N. Faure 613.266.3286 Chief Technical Officer, CertainKey Inc. [email protected] Carleton University Systems Eng. 3rd Year [email protected] Engineering Society Administrator [email protected]
Re: Kernel 2.0.35 limits
In reply to Paul FaureQuoted 10 lines · Paul Faure
Just this morning, our firewall get a kernel panic after 500 days of uptime.
As you can see from the log files, the date starts at June 15th, where we get two div by zeros, then jumps May 11th, then a kernel panic. A reboot brings it back to June 15th. Since cron could not open
/dev/rtc. My first thought was an internal kernel limit on the time, but 500 days seems a bit short.Any ideas ?
(1<<32) / (24 * 60 * 60 * 100) == 497
IOW, 2^32 timer interrupts since the boot.
Re: Kernel 2.0.35 limits
In reply to Paul FaureQuoted 7 lines · Alan Cox
Quoted 2 lines
Just this morning, our firewall get a kernel panic after 500 days of uptime.
Interesting very interesting in fact. There is a 497 day wrap on the kernel but it should do nothing more than send the uptime back to zero. Im not sure how the crash fits in to this but it could be significant that its about the wrap time
there is a division by zero possibilty in the 2.0.35 do_fast_gettimeoffset (there is a division by jiffies, which is 0 for one tick). Our department server got struck by this at the jiffies rollover some time ago.
Thomas.
Signature · 2 lines
Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ Alexander Viro on linux-kernel ]
Quoted 4 lines
While I could
fix this myself manually (and plan to do so), it would be nice to get the developer's blessing on this, and also nice to know exactly what version number to give this driver in 2.4.5 stock.
F**k me, forget I asked about the version. I just read a little further down in the source. I think I'll crawl up in a corner and just generally feel stupid now. ;)
Kelledin