Skip to contentSkip to conversation

drivers/usb/ov511.c does not compile

DISCUSSION Kelledin Tane 6 participants 10 messages Jun 15, 2001 – Jun 16, 2001

lore
Share & tools
lore
#0 lore raw

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.

#1 lore raw
Quoted 11 lines · Kelledin Tane

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.

This has already been fixed in the 2.4.5 pre patches.

JE

#2 lore raw
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..

#3 lore raw
In reply to Johannes Erdfelt
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

#4 lore raw

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]
#5 lore raw

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

#6 lore raw

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]
#7 lore raw

Re: Kernel 2.0.35 limits

In reply to Paul Faure
Quoted 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.

#8 lore raw

Re: Kernel 2.0.35 limits

In reply to Paul Faure
Quoted 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 ]
#9 lore raw
In reply to Kelledin Tane
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