Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

V4L2: Increase the MMAL timeout to 3sec - not present in recent kernels #592

Closed
zboobzor opened this issue May 13, 2014 · 4 comments
Closed

Comments

@zboobzor
Copy link

Commit e083ef7 (V4L2: Increase the MMAL timeout to 3sec) does not appear to be applied to linux 3.12 and 3.14.
Please apply this change to the aformentioned kernels.

Thanks.

@popcornmix
Copy link
Collaborator

Okay. Added to source trees. Will be in next rpi-update.

@zboobzor
Copy link
Author

Wow, that was fast, thanks :)

@brabl2
Copy link

brabl2 commented May 15, 2014

Same issue for commit d89bb12 (i2c-bcm2708: fixed baudrate)
Could it be also added.
Thanks.

popcornmix pushed a commit to raspberrypi/firmware that referenced this issue May 16, 2014
See: raspberrypi/linux#588

kernel: Perform I2C combined transactions when possible
See: raspberrypi/linux#318

kernel: V4L2: Increase the MMAL timeout to 3sec
See: raspberrypi/linux#592

kernel: i2c-bcm2708: fixed baudrate
See: raspberrypi/linux#592

firmware: Avoid calling hdcp_shutdown() when hotplug deasserted
See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=101848#pid101848

firmware: hello_fft: Update readme to mention use with GL
See: http://www.raspberrypi.org/forums/viewtopic.php?f=68&t=76189

firmware: Clear unused pixels in the subsample image in H264 codec
See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=76845&p=551515#p551515
popcornmix pushed a commit to Hexxeh/rpi-firmware that referenced this issue May 16, 2014
See: raspberrypi/linux#588

kernel: Perform I2C combined transactions when possible
See: raspberrypi/linux#318

kernel: V4L2: Increase the MMAL timeout to 3sec
See: raspberrypi/linux#592

kernel: i2c-bcm2708: fixed baudrate
See: raspberrypi/linux#592

firmware: Avoid calling hdcp_shutdown() when hotplug deasserted
See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=101848#pid101848

firmware: hello_fft: Update readme to mention use with GL
See: http://www.raspberrypi.org/forums/viewtopic.php?f=68&t=76189

firmware: Clear unused pixels in the subsample image in H264 codec
See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=76845&p=551515#p551515
@popcornmix
Copy link
Collaborator

There two changes should be present in latest rpi-update firmware. Please test and close if happy.

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
See: raspberrypi/linux#588

kernel: Perform I2C combined transactions when possible
See: raspberrypi/linux#318

kernel: V4L2: Increase the MMAL timeout to 3sec
See: raspberrypi/linux#592

kernel: i2c-bcm2708: fixed baudrate
See: raspberrypi/linux#592

firmware: Avoid calling hdcp_shutdown() when hotplug deasserted
See: http://forum.stmlabs.com/showthread.php?tid=11003&pid=101848#pid101848

firmware: hello_fft: Update readme to mention use with GL
See: http://www.raspberrypi.org/forums/viewtopic.php?f=68&t=76189

firmware: Clear unused pixels in the subsample image in H264 codec
See: http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=76845&p=551515#p551515
popcornmix pushed a commit that referenced this issue Oct 16, 2017
Tetsuo Handa and Fengguang Wu reported a panic in the unwinder:

  BUG: unable to handle kernel NULL pointer dereference at 000001f2
  IP: update_stack_state+0xd4/0x340
  *pde = 00000000

  Oops: 0000 [#1] PREEMPT SMP
  CPU: 0 PID: 18728 Comm: 01-cpu-hotplug Not tainted 4.13.0-rc4-00170-gb09be67 #592
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
  task: bb0b53c0 task.stack: bb3ac000
  EIP: update_stack_state+0xd4/0x340
  EFLAGS: 00010002 CPU: 0
  EAX: 0000a570 EBX: bb3adccb ECX: 0000f401 EDX: 0000a570
  ESI: 00000001 EDI: 000001ba EBP: bb3adc6b ESP: bb3adc3f
   DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
  CR0: 80050033 CR2: 000001f2 CR3: 0b3a7000 CR4: 00140690
  DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
  DR6: fffe0ff0 DR7: 00000400
  Call Trace:
   ? unwind_next_frame+0xea/0x400
   ? __unwind_start+0xf5/0x180
   ? __save_stack_trace+0x81/0x160
   ? save_stack_trace+0x20/0x30
   ? __lock_acquire+0xfa5/0x12f0
   ? lock_acquire+0x1c2/0x230
   ? tick_periodic+0x3a/0xf0
   ? _raw_spin_lock+0x42/0x50
   ? tick_periodic+0x3a/0xf0
   ? tick_periodic+0x3a/0xf0
   ? debug_smp_processor_id+0x12/0x20
   ? tick_handle_periodic+0x23/0xc0
   ? local_apic_timer_interrupt+0x63/0x70
   ? smp_trace_apic_timer_interrupt+0x235/0x6a0
   ? trace_apic_timer_interrupt+0x37/0x3c
   ? strrchr+0x23/0x50
  Code: 0f 95 c1 89 c7 89 45 e4 0f b6 c1 89 c6 89 45 dc 8b 04 85 98 cb 74 bc 88 4d e3 89 45 f0 83 c0 01 84 c9 89 04 b5 98 cb 74 bc 74 3b <8b> 47 38 8b 57 34 c6 43 1d 01 25 00 00 02 00 83 e2 03 09 d0 83
  EIP: update_stack_state+0xd4/0x340 SS:ESP: 0068:bb3adc3f
  CR2: 00000000000001f2
  ---[ end trace 0d147fd4aba8ff50 ]---
  Kernel panic - not syncing: Fatal exception in interrupt

On x86-32, after decoding a frame pointer to get a regs address,
regs_size() dereferences the regs pointer when it checks regs->cs to see
if the regs are user mode.  This is dangerous because it's possible that
what looks like a decoded frame pointer is actually a corrupt value, and
we don't want the unwinder to make things worse.

Instead of calling regs_size() on an unsafe pointer, just assume they're
kernel regs to start with.  Later, once it's safe to access the regs, we
can do the user mode check and corresponding safety check for the
remaining two regs.

Reported-and-tested-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: LKP <lkp@01.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 5ed8d8b ("x86/unwind: Move common code into update_stack_state()")
Link: http://lkml.kernel.org/r/7f95b9a6993dec7674b3f3ab3dcd3294f7b9644d.1507597785.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Terminus-IMRC pushed a commit to Idein/linux that referenced this issue Jan 4, 2018
commit add295a upstream.

Accessing the OTP memory on AR9950 causes a data bus
like this:

  Data bus error, epc == 801f7774, ra == 801f7774
  Oops[#1]:
  CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-rc3 raspberrypi#592
  task: 87c28000 ti: 87c22000 task.ti: 87c22000
  $ 0   : 00000000 00000061 deadc0de 00000000
  $ 4   : b8115f18 00015f18 00000007 00000004
  $ 8   : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
  $12   : 7c7c3c7c 80320a68 00000000 7c7c7c3c
  $16   : 87cd8010 00015f18 00000007 00000000
  $20   : 00000064 00000004 87c23c7c 8035210c
  $24   : 00000000 801f3674
  $28   : 87c22000 87c23b48 00000001 801f7774
  Hi    : 00000000
  Lo    : 00000064
  epc   : 801f7774 ath9k_hw_wait+0x58/0xb0
      Not tainted
  ra    : 801f7774 ath9k_hw_wait+0x58/0xb0
  Status: 1000cc03 KERNEL EXL IE
  Cause : 4080801c
  PrId  : 00019750 (MIPS 74Kc)
  Modules linked in:
  Process swapper (pid: 1, threadinfo=87c22000, task=87c28000, ts=00000000)
  Stack : 0000000f 00000061 00002710 8006240c 00000001 87cd8010 87c23bb0 87cd8010
          00000000 00000004 00000003 80210c7c 000000b3 67fa8000 0000032a 000006fe
          000003e8 00000002 00000028 87c23bf0 000003ff 80210d24 803e5630 80210e28
          00000000 00000007 87cd8010 00007044 00000004 00000061 000003ff 000001ff
          87c26000 87cd8010 00000220 87cd8bb8 80210000 8020fcf4 87c22000 87c23c08
          ...
  Call Trace:
  [<801f7774>] ath9k_hw_wait+0x58/0xb0
  [<80210c7c>] ar9300_otp_read_word+0x80/0xd4
  [<80210d24>] ar9300_read_otp+0x54/0xb0
  [<8020fcf4>] ar9300_check_eeprom_header+0x1c/0x40
  [<80210fe4>] ath9k_hw_ar9300_fill_eeprom+0x118/0x39c
  [<80206650>] ath9k_hw_eeprom_init+0x74/0xb4
  [<801f96d0>] ath9k_hw_init+0x7ec/0x96c
  [<801e65ec>] ath9k_init_device+0x340/0x758
  [<801f35d0>] ath_ahb_probe+0x21c/0x2c0
  [<801c041c>] driver_probe_device+0xc0/0x1e4
  [<801c05ac>] __driver_attach+0x6c/0xa4
  [<801bea08>] bus_for_each_dev+0x64/0xa8
  [<801bfa40>] bus_add_driver+0xcc/0x24c
  [<801c0954>] driver_register+0xbc/0x17c
  [<803f8fc0>] ath9k_init+0x5c/0x88
  [<800608fc>] do_one_initcall+0xec/0x1a0
  [<803e6a68>] kernel_init_freeable+0x13c/0x200
  [<80309cdc>] kernel_init+0x1c/0xe4
  [<80062450>] ret_from_kernel_thread+0x10/0x18

On the AR9550, the OTP registers are located at
the same address as on the AR9340. Use the correct
values to avoid the error.

Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pfpacket pushed a commit to pfpacket/linux-rpi-rust that referenced this issue Apr 7, 2023
rust: add Hardware Random Number Generator subsystem
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants