drivers/usb/ov511.c does not compile

drivers/usb/ov511.c does not compile

[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.

Re: drivers/usb/ov511.c does not compile

[Johannes Erdfelt]

On Fri, Jun 15, 2001, Kelledin Tane <runesong@earthlink.net> wrote:
> 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

Re: drivers/usb/ov511.c does not compile

[Kelledin Tane]

> 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

Re: drivers/usb/ov511.c does not compile

[Alan Cox]

> > 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..

Re: drivers/usb/ov511.c does not compile

[Johannes Erdfelt]

On Fri, Jun 15, 2001, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > > 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.

> 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

[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 ?

Last message via e-mail was:
  Date: Fri, 15 Jun 2001 08:01:05 -0400
  To: root@inside.engsoc.carleton.ca
  From: Cron Daemon <root@inside.engsoc.carleton.ca>
  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.

-- 
Paul N. Faure					613.266.3286
Chief Technical Officer, CertainKey Inc.	paul@certainkey.com
Carleton University Systems Eng. 3rd Year	paul@faure.ca
Engineering Society Administrator		paul@engsoc.org

Re: Kernel 2.0.35 limits

[Alan Cox]

> 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

[Alexander Viro]

On Fri, 15 Jun 2001, Paul Faure wrote:

> 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

[Paul Faure]

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.

On Fri, 15 Jun 2001, Alan Cox wrote:

> > 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
>

-- 
Paul N. Faure					613.266.3286
Chief Technical Officer, CertainKey Inc.	paul@certainkey.com
Carleton University Systems Eng. 3rd Year	paul@faure.ca
Engineering Society Administrator		paul@engsoc.org

Re: Kernel 2.0.35 limits

[Thomas Bogendoerfer]

On Fri, Jun 15, 2001 at 10:27:35PM +0100, Alan Cox wrote:
> > 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.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]