21 Aug, 2009
1 commit
-
One of my testboxes triggered this nasty stack overflow crash
during SCSI probing:[ 5.874004] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 5.875004] device: 'sda': device_add
[ 5.878004] BUG: unable to handle kernel NULL pointer dereference at 00000a0c
[ 5.878004] IP: [] print_context_stack+0x81/0x110
[ 5.878004] *pde = 00000000
[ 5.878004] Thread overran stack, or stack corrupted
[ 5.878004] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[ 5.878004] last sysfs file:
[ 5.878004]
[ 5.878004] Pid: 1, comm: swapper Not tainted (2.6.31-rc6-tip-01272-g9919e28-dirty #5685)
[ 5.878004] EIP: 0060:[] EFLAGS: 00010083 CPU: 0
[ 5.878004] EIP is at print_context_stack+0x81/0x110
[ 5.878004] EAX: cf8a3000 EBX: cf8a3fe4 ECX: 00000049 EDX: 00000000
[ 5.878004] ESI: b1cfce84 EDI: 00000000 EBP: cf8a3018 ESP: cf8a2ff4
[ 5.878004] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[ 5.878004] Process swapper (pid: 1, ti=cf8a2000 task=cf8a8000 task.ti=cf8a3000)
[ 5.878004] Stack:
[ 5.878004] b1004867 fffff000 cf8a3ffc
[ 5.878004] Call Trace:
[ 5.878004] [] ? kernel_thread_helper+0x7/0x10
[ 5.878004] BUG: unable to handle kernel NULL pointer dereference at 00000a0c
[ 5.878004] IP: [] print_context_stack+0x81/0x110
[ 5.878004] *pde = 00000000
[ 5.878004] Thread overran stack, or stack corrupted
[ 5.878004] Oops: 0000 [#2] PREEMPT SMP DEBUG_PAGEALLOCThe oops did not reveal any more details about the real stack
that we have and the system got into an infinite loop of
recursive pagefaults.So i booted with CONFIG_STACK_TRACER=y and the 'stacktrace' boot
parameter. The box did not crash (timings/conditions probably
changed a tiny bit to trigger the catastrophic crash), but the
/debug/tracing/stack_trace file was rather revealing:Depth Size Location (72 entries)
----- ---- --------
0) 3704 52 __change_page_attr+0xb8/0x290
1) 3652 24 __change_page_attr_set_clr+0x43/0x90
2) 3628 60 kernel_map_pages+0x108/0x120
3) 3568 40 prep_new_page+0x7d/0x130
4) 3528 84 get_page_from_freelist+0x106/0x420
5) 3444 116 __alloc_pages_nodemask+0xd7/0x550
6) 3328 36 allocate_slab+0xb1/0x100
7) 3292 36 new_slab+0x1c/0x160
8) 3256 36 __slab_alloc+0x133/0x2b0
9) 3220 4 kmem_cache_alloc+0x1bb/0x1d0
10) 3216 108 create_object+0x28/0x250
11) 3108 40 kmemleak_alloc+0x81/0xc0
12) 3068 24 kmem_cache_alloc+0x162/0x1d0
13) 3044 52 scsi_pool_alloc_command+0x29/0x70
14) 2992 20 scsi_host_alloc_command+0x22/0x70
15) 2972 24 __scsi_get_command+0x1b/0x90
16) 2948 28 scsi_get_command+0x35/0x90
17) 2920 24 scsi_setup_blk_pc_cmnd+0xd4/0x100
18) 2896 128 sd_prep_fn+0x332/0xa70
19) 2768 36 blk_peek_request+0xe7/0x1d0
20) 2732 56 scsi_request_fn+0x54/0x520
21) 2676 12 __generic_unplug_device+0x2b/0x40
22) 2664 24 blk_execute_rq_nowait+0x59/0x80
23) 2640 172 blk_execute_rq+0x6b/0xb0
24) 2468 32 scsi_execute+0xe0/0x140
25) 2436 64 scsi_execute_req+0x152/0x160
26) 2372 60 scsi_vpd_inquiry+0x6c/0x90
27) 2312 44 scsi_get_vpd_page+0x112/0x160
28) 2268 52 sd_revalidate_disk+0x1df/0x320
29) 2216 92 rescan_partitions+0x98/0x330
30) 2124 52 __blkdev_get+0x309/0x350
31) 2072 8 blkdev_get+0xf/0x20
32) 2064 44 register_disk+0xff/0x120
33) 2020 36 add_disk+0x6e/0xb0
34) 1984 44 sd_probe_async+0xfb/0x1d0
35) 1940 44 __async_schedule+0xf4/0x1b0
36) 1896 8 async_schedule+0x12/0x20
37) 1888 60 sd_probe+0x305/0x360
38) 1828 44 really_probe+0x63/0x170
39) 1784 36 driver_probe_device+0x5d/0x60
40) 1748 16 __device_attach+0x49/0x50
41) 1732 32 bus_for_each_drv+0x5b/0x80
42) 1700 24 device_attach+0x6b/0x70
43) 1676 16 bus_attach_device+0x47/0x60
44) 1660 76 device_add+0x33d/0x400
45) 1584 52 scsi_sysfs_add_sdev+0x6a/0x2c0
46) 1532 108 scsi_add_lun+0x44b/0x460
47) 1424 116 scsi_probe_and_add_lun+0x182/0x4e0
48) 1308 36 __scsi_add_device+0xd9/0xe0
49) 1272 44 ata_scsi_scan_host+0x10b/0x190
50) 1228 24 async_port_probe+0x96/0xd0
51) 1204 44 __async_schedule+0xf4/0x1b0
52) 1160 8 async_schedule+0x12/0x20
53) 1152 48 ata_host_register+0x171/0x1d0
54) 1104 60 ata_pci_sff_activate_host+0xf3/0x230
55) 1044 44 ata_pci_sff_init_one+0xea/0x100
56) 1000 48 amd_init_one+0xb2/0x190
57) 952 8 local_pci_probe+0x13/0x20
58) 944 32 pci_device_probe+0x68/0x90
59) 912 44 really_probe+0x63/0x170
60) 868 36 driver_probe_device+0x5d/0x60
61) 832 20 __driver_attach+0x89/0xa0
62) 812 32 bus_for_each_dev+0x5b/0x80
63) 780 12 driver_attach+0x1e/0x20
64) 768 72 bus_add_driver+0x14b/0x2d0
65) 696 36 driver_register+0x6e/0x150
66) 660 20 __pci_register_driver+0x53/0xc0
67) 640 8 amd_init+0x14/0x16
68) 632 572 do_one_initcall+0x2b/0x1d0
69) 60 12 do_basic_setup+0x56/0x6a
70) 48 20 kernel_init+0x84/0xce
71) 28 28 kernel_thread_helper+0x7/0x10There's a lot of fat functions on that stack trace, but
the largest of all is do_one_initcall(). This is due to
the boot trace entry variables being on the stack.Fixing this is relatively easy, initcalls are fundamentally
serialized, so we can move the local variables to file scope.Note that this large stack footprint was present for a
couple of months already - what pushed my system over
the edge was the addition of kmemleak to the call-chain:6) 3328 36 allocate_slab+0xb1/0x100
7) 3292 36 new_slab+0x1c/0x160
8) 3256 36 __slab_alloc+0x133/0x2b0
9) 3220 4 kmem_cache_alloc+0x1bb/0x1d0
10) 3216 108 create_object+0x28/0x250
11) 3108 40 kmemleak_alloc+0x81/0xc0
12) 3068 24 kmem_cache_alloc+0x162/0x1d0
13) 3044 52 scsi_pool_alloc_command+0x29/0x70This pushes the total to ~3800 bytes, only a tiny bit
more was needed to corrupt the on-kernel-stack thread_info.The fix reduces the stack footprint from 572 bytes
to 28 bytes.Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Frederic Weisbecker
Cc: Steven Rostedt
Cc: Catalin Marinas
Cc: Jens Axboe
Cc: Linus Torvalds
Cc:
LKML-Reference:
Signed-off-by: Ingo Molnar
19 Aug, 2009
1 commit
-
If one filter item (for set_ftrace_filter and set_ftrace_notrace) is being
setup by more than 1 consecutive writes (FTRACE_ITER_CONT flag), it won't
be handled corretly.I used following program to test/verify:
[snip]
#include
#include
#include
#include
#includeint main(int argc, char **argv)
{
int fd, i;
char *file = argv[1];if (-1 == (fd = open(file, O_WRONLY))) {
perror("open failed");
return -1;
}for(i = 0; i < (argc - 2); i++) {
int len = strlen(argv[2+i]);
int cnt, off = 0;while(len) {
cnt = write(fd, argv[2+i] + off, len);
len -= cnt;
off += cnt;
}
}close(fd);
return 0;
}
[snip]before change:
sh-4.0# echo > ./set_ftrace_filter
sh-4.0# /test ./set_ftrace_filter "sys" "_open "
sh-4.0# cat ./set_ftrace_filter
#### all functions enabled ####
sh-4.0#after change:
sh-4.0# echo > ./set_ftrace_notrace
sh-4.0# test ./set_ftrace_notrace "sys" "_open "
sh-4.0# cat ./set_ftrace_notrace
sys_open
sh-4.0#Signed-off-by: Jiri Olsa
LKML-Reference:
Signed-off-by: Steven Rostedt
18 Aug, 2009
9 commits
-
"echo noglobal-clock > trace_options" can be used to change trace
clock but "echo 0 > options/global-clock" can't. The flag toggling
will be silently accepted without actually changing the clock callback.We can fix it by using set_tracer_flags() in
trace_options_core_write().Changelog:
v1->v2: Simplified switch() after Li Zefan 's
suggestionSigned-off-by: Zhao Lei
Cc: Steven Rostedt
Cc: Li Zefan
Signed-off-by: Frederic Weisbecker -
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
MIPS: Fix HPAGE_SIZE redefinition -
* 'for-linus' of git://oss.sgi.com/xfs/xfs:
xfs: fix locking in xfs_iget_cache_hit -
…s/security-testing-2.6
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
security: define round_hint_to_min in !CONFIG_SECURITY
Security/SELinux: seperate lsm specific mmap_min_addr
SELinux: call cap_file_mmap in selinux_file_mmap
Capabilities: move cap_file_mmap to commoncap.c -
The inotify_add_watch man page specifies that inotify_add_watch() will
return a non-negative integer. However, historically the inotify
watches started at 1, not at 0.Turns out that the inotifywait program provided by the inotify-tools
package doesn't properly handle a 0 watch descriptor. In 7e790dd5 we
changed from starting at 1 to starting at 0. This patch starts at 1,
just like in previous kernels, but also just like in previous kernels
it's possible for it to wrap back to 0. This preserves the kernel
functionality exactly like it was before the patch (neither method broke
the spec)Signed-off-by: Eric Paris
Signed-off-by: Linus Torvalds -
In f44aebcc the tail drop logic of events with no file backing
(q_overflow and in_ignored) was reversed so IN_IGNORED events would
never be tail dropped. This now means that Q_OVERFLOW events are NOT
tail dropped. The fix is to not tail drop IN_IGNORED, but to tail drop
Q_OVERFLOW.Signed-off-by: Eric Paris
Signed-off-by: Linus Torvalds -
inotify decides if private data it passed to get added to an event was
used by checking list_empty(). But it's possible that the event may
have been dequeued and the private event removed so it would look empty.The fix is to use the return code from fsnotify_add_notify_event rather
than looking at the list.Signed-off-by: Eric Paris
Signed-off-by: Linus Torvalds -
* master.kernel.org:/home/rmk/linux-2.6-arm: (37 commits)
ARM: 5673/1: U300 fix initsection compile warning
ARM: Fix broken highmem support
mx31moboard: invert sdhc ro signal sense
ARM: S3C24XX: Fix clkout mpx error
ARM: S3C64XX: serial: Fix a typo in Kconfig
IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes
OMAP3: RX51: Updated rx51_defconfig
OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up
OMAP3: RX51: Define TWL4030 USB transceiver in board file
OMAP3: Overo: Fix smsc911x platform device resource value
OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size
OMAP2/3: DMA errata correction
OMAP: Fix testing of cpu defines for mach-omap1
OMAP3: Overo: add missing pen-down GPIO definition
OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask
OMAP3: PM: Fix wrong sequence in suspend.
OMAP: PM: CPUfreq: obey min/max settings of policy
OMAP2/3/4: UART: allow in-order port traversal
OMAP2/3/4: UART: Allow per-UART disabling wakeup for serial ports
OMAP3: Fixed crash bug with serial + suspend
... -
This patch fixes warnings like this:
CC fs/proc/meminfo.o
In file included from /work/linux/include/linux/mmzone.h:20,
from /work/linux/include/linux/gfp.h:4,
from /work/linux/include/linux/mm.h:8,
from /work/linux/fs/proc/meminfo.c:5:
/work/linux/arch/mips/include/asm/page.h:36:1: warning: "HPAGE_SIZE" redefined
In file included from /work/linux/fs/proc/meminfo.c:2:
/work/linux/include/linux/hugetlb.h:107:1: warning: this is the location of the previous definitionSigned-off-by: Atsushi Nemoto
Acked-by: David Daney
Signed-off-by: Ralf Baechle
17 Aug, 2009
5 commits
-
The locking in xfs_iget_cache_hit currently has numerous problems:
- we clear the reclaim tag without i_flags_lock which protects
modifications to it
- we call inode_init_always which can sleep with pag_ici_lock
held (this is oss.sgi.com BZ #819)
- we acquire and drop i_flags_lock a lot and thus provide no
consistency between the various flags we set/clear under itThis patch fixes all that with a major revamp of the locking in
the function. The new version acquires i_flags_lock early and
only drops it once we need to call into inode_init_always or before
calling xfs_ilock.This patch fixes a bug seen in the wild where we race modifying the
reclaim tag.Signed-off-by: Christoph Hellwig
Reviewed-by: Felix Blyakher
Reviewed-by: Eric Sandeen
Signed-off-by: Felix Blyakher -
Fix the header files to define round_hint_to_min() and to define
mmap_min_addr_handler() in the !CONFIG_SECURITY case.Built and tested with !CONFIG_SECURITY
Signed-off-by: Eric Paris
Signed-off-by: James Morris -
Currently SELinux enforcement of controls on the ability to map low memory
is determined by the mmap_min_addr tunable. This patch causes SELinux to
ignore the tunable and instead use a seperate Kconfig option specific to how
much space the LSM should protect.The tunable will now only control the need for CAP_SYS_RAWIO and SELinux
permissions will always protect the amount of low memory designated by
CONFIG_LSM_MMAP_MIN_ADDR.This allows users who need to disable the mmap_min_addr controls (usual reason
being they run WINE as a non-root user) to do so and still have SELinux
controls preventing confined domains (like a web server) from being able to
map some area of low memory.Signed-off-by: Eric Paris
Signed-off-by: James Morris -
Currently SELinux does not check CAP_SYS_RAWIO in the file_mmap hook. This
means there is no DAC check on the ability to mmap low addresses in the
memory space. This function adds the DAC check for CAP_SYS_RAWIO while
maintaining the selinux check on mmap_zero. This means that processes
which need to mmap low memory will need CAP_SYS_RAWIO and mmap_zero but will
NOT need the SELinux sys_rawio capability.Signed-off-by: Eric Paris
Signed-off-by: James Morris -
Currently we duplicate the mmap_min_addr test in cap_file_mmap and in
security_file_mmap if !CONFIG_SECURITY. This patch moves cap_file_mmap
into commoncap.c and then calls that function directly from
security_file_mmap ifndef CONFIG_SECURITY like all of the other capability
checks are done.Signed-off-by: Eric Paris
Acked-by: Serge Hallyn
Signed-off-by: James Morris
16 Aug, 2009
2 commits
-
drivers/md/dm-log-userspace-transfer.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'size_t'
Previously posted and acked, but apparently lost.
http://lkml.indiana.edu/hypermail/linux/kernel/0906.2/02074.htmlSigned-off-by: Randy Dunlap
Cc: dm-devel@redhat.com
Signed-off-by: Linus Torvalds -
The triggered field of struct poll_wqueues introduced in commit
5f820f648c92a5ecc771a96b3c29aa6e90013bba ("poll: allow f_op->poll to
sleep").It was first set to 1 in pollwake() (now __pollwake() ), tested and
later set to 0 in poll_schedule_timeout(), but not initialized before.As a result when the process needs to sleep, triggered was likely to be
non-zero even if pollwake() is not called before the first
poll_schedule_timeout(), meaning schedule_hrtimeout_range() would not be
called and an extra loop calling all ->poll() would be done.This patch initialize triggered to 0 in poll_initwait() so the ->poll()
are not called twice before the process goes to sleep when it needs to.Signed-off-by: Guillaume Knispel
Acked-by: Thomas Gleixner
Acked-by: Tejun Heo
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds
15 Aug, 2009
5 commits
-
The u300_init_check_chip() function was not properly tagged with
the __init macro and provided a initsection mismatch on
compilation.Signed-off-by: Linus Walleij
Signed-off-by: Russell King -
Currently, highmem is selectable, and you can request an increased
vmalloc area. However, none of this has any effect on the memory
layout since a patch in the highmem series was accidentally dropped.
Moreover, even if you did want highmem, all memory would still be
registered as lowmem, possibly resulting in overflow of the available
virtual mapping space.The highmem boundary is determined by the highest allowed beginning
of the vmalloc area, which depends on its configurable minimum size
(see commit 60296c71f6c5063e3c1f1d2619ca0b60940162e7 for details on
this).We should create mappings and initialize bootmem only for low memory,
while the zone allocator must still be told about highmem.Currently, memory nodes which are completely located in high memory
are not supported. This is not a huge limitation since systems
relying on highmem support are unlikely to have discontiguous memory
with large holes.[ A similar patch was meant to be merged before commit 5f0fbf9ecaf3
and be available in Linux v2.6.30, however some git rebase screw-up
of mine dropped the first commit of the series, and that goofage
escaped testing somehow as well. -- Nico ]Signed-off-by: Russell King
Reviewed-by: Nicolas Pitre -
* git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes:
GFS2: Fix permissions on "recover" file
14 Aug, 2009
17 commits
-
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (38 commits)
V4L/DVB (12441): siano: read buffer overflow
V4L/DVB (12440): Use kzalloc for frontend states to have struct dvb_frontend properly
V4L/DVB (12438): Read buffer overflow
V4L/DVB (12437): dvb: siano uses/depends on INPUT
V4L/DVB (12436): stk-webcam: read buffer overflow
V4L/DVB (12432): em28xx: fix regression in Empire DualTV digital tuning
V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM default handlers
V4L/DVB (12428): hdpvr: add missing initialization of current_norm
V4L/DVB (12424): soc-camera: fix recursive locking in .buf_queue()
V4L/DVB (12422): media/zr364xx: fix build errors
V4L/DVB (12405): em28xx-cards: move register 0x13 setting to the proper place
V4L/DVB (12411): em28xx: Fix artifacts with Silvercrest webcam
V4L/DVB (12410): em28xx: Move the non-board dependent part to be outside em28xx_pre_card_setup()
V4L/DVB (12407): em28xx: Adjust Silvercrest xtal frequency
V4L/DVB (12406): em28xx: fix: don't do image interlacing on webcams
V4L/DVB (12403): em28xx: properly reports some em2710 chips
V4L/DVB (12402): em28xx: fix: some em2710 chips use a different vendor ID
V4L/DVB (12401): m9v011: add vflip/hflip controls to control mirror/upside down
V4L/DVB (12400): em28xx: Allow changing fps on webcams
V4L/DVB (12399): mt9v011: Add support for controlling frame rates
... -
Although this file is only ever written and not read by
userspace, it seems that the utils are opening this
file O_RDWR, so we need to allow that.Also fixes the whitespace which seemed to be broken.
Signed-off-by: Steven Whitehouse
Cc: David Teigland -
Small confusion with our hardware engineer, the WP signal (RO) is
active low on our boards, the signal has to inverted.This is a pretty straightforward patch, it could even go to -rc,
but if not, then push it for 2.6.32.Signed-off-by: Valentin Longchamp
Signed-off-by: Sascha Hauer -
Bug correction: CLK Outputs cannot have XTAL as parent
Signed-off-by: Davide Rizzo
[ben-linux@fluff.org: updated patch subject]
Signed-off-by: Ben Dooks -
The typo causes drivers/serial/s3c6400.c not being built for s3c6400 platform.
Signed-off-by: Ramax Lo
Signed-off-by: Ben Dooks -
With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[].
Subsequently an attempt is made to load the firmware from the resulting
filename.Signed-off-by: Roel Kluin
Signed-off-by: Andrew Morton
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab -
This patch changes most frontend drivers to allocate their state structure via
kzalloc and not kmalloc. This is done to properly initialize the
embedded "struct dvb_frontend frontend" field, that they all have.The visible effect of this struct being uninitalized is, that the member "id"
that is used to set the name of kernel thread is totally random.Some board drivers (for example cx88-dvb) set this "id" via
videobuf_dvb_alloc_frontend but most do not.So I at least get random id values for saa7134, flexcop and ttpci based cards.
It looks like this in dmesg:
DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S)The related kernel thread then also gets a strange name
like "kdvb-ad-1-fe--1".Cc: Michael Krufky
Cc: Steven Toth
Cc: Timothy Lee
Cc: Igor M. Liplianin
Signed-off-by: Matthias Schwarzott
Acked-by: Andreas Oberritter
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab -
parport[n] is checked before n < MAX_CAMS
Signed-off-by: Roel Kluin
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab -
siano uses input_*() functions so it should depend on INPUT
to prevent build errors:ERROR: "input_event" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_register_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_free_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_unregister_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!
ERROR: "input_allocate_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined!Cc: Michael Krufky
Cc: Uri Shkolnik
Signed-off-by: Randy Dunlap
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab -
It tested the value of stk_sizes[i].m before checking whether i was in range.
Cc: Hans Verkuil
Cc: Trent Piepho
Signed-off-by: Roel Kluin
Signed-off-by: Andrew Morton
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab -
Restore support for digital tuning caused by regression during introduction
of disable_i2c_gate parameter to zl10353 driver.Thanks to user "Xwang" for reporting the problem and testing the fix
Cc: Xwang
Signed-off-by: Devin Heitmueller
Signed-off-by: Mauro Carvalho Chehab -
The v4l core supplies default handlers for G_STD and G_PARM. However, both
default handlers are buggy.This patch fixes the following:
1) If no g_std is supplied and current_norm == 0, then this driver does not
support TV video standards (e.g. a radio or webcam driver). Return
-EINVAL. This ensures that there is no bogus VIDIOC_G_STD support for
such drivers.2) The default VIDIOC_G_PARM handler used current_norm instead of first
checking if the driver supported g_std and calling that to get the norm.
It also didn't check if current_norm was 0, since in that case the driver
does not support TV standards (or no standard was set at all) and the
default handler should return -EINVAL.Note that I am very unhappy with these default handlers: I think they
basically behave like some very strange and unexpected side-effect.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
Drivers should either set current_norm or supply a g_std callback.
The hdpvr driver does neither. Since it initializes to a 60 Hz format
I've initialized the current_norm to NTSC | PAL_M | PAL_60 which is the
60 Hz subset of tvnorms.Cc: Janne Grunau
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab -
The .buf_queue() V4L2 driver method is called under
spinlock_irqsave(q->irqlock,...), don't take the lock again inside the
function.Reported-by: Antonio Ospite
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: Mauro Carvalho Chehab -
Fix build errors in zr364xx by adding selects:
zr364xx.c:(.text+0x195ed7): undefined reference to `videobuf_streamon'
zr364xx.c:(.text+0x196030): undefined reference to `videobuf_dqbuf'
zr364xx.c:(.text+0x1960c4): undefined reference to `videobuf_qbuf'
zr364xx.c:(.text+0x196123): undefined reference to `videobuf_querybuf'
zr364xx.c:(.text+0x196182): undefined reference to `videobuf_reqbufs'
zr364xx.c:(.text+0x196224): undefined reference to `videobuf_queue_is_busy'
zr364xx.c:(.text+0x196390): undefined reference to `videobuf_vmalloc_free'
zr364xx.c:(.text+0x196571): undefined reference to `videobuf_iolock'
zr364xx.c:(.text+0x196678): undefined reference to `videobuf_mmap_mapper'
zr364xx.c:(.text+0x196760): undefined reference to `videobuf_poll_stream'
zr364xx.c:(.text+0x19689a): undefined reference to `videobuf_read_one'
zr364xx.c:(.text+0x1969ec): undefined reference to `videobuf_mmap_free'
zr364xx.c:(.text+0x197862): undefined reference to `videobuf_queue_vmalloc_init'
zr364xx.c:(.text+0x197a28): undefined reference to `videobuf_streamoff'
zr364xx.c:(.text+0x198203): undefined reference to `videobuf_to_vmalloc'
zr364xx.c:(.text+0x198603): undefined reference to `videobuf_streamoff'
drivers/built-in.o: In function `free_buffer':
zr364xx.c:(.text+0x19930c): undefined reference to `videobuf_vmalloc_free'
drivers/built-in.o: In function `zr364xx_open':
zr364xx.c:(.text+0x19a7de): undefined reference to `videobuf_queue_vmalloc_init'
drivers/built-in.o: In function `read_pipe_completion':
zr364xx.c:(.text+0x19b17f): undefined reference to `videobuf_to_vmalloc'Signed-off-by: Randy Dunlap
Signed-off-by: Douglas Schilling Landgraf
Signed-off-by: Mauro Carvalho Chehab -
Register 0x13 seems to be a sort of image control, maybe gamma, white
level or black level. Lower values produce better images, while higher
values increases the contrast and shifts colors to green. 0xff produces
a black image. This register is not Silvercrest-specific, so its code
should be moved to a better place.If this register is left alone, a random value can be found at the
register, producing weird results.While here, let's remove register 0x0d, as it had no noticed effect at
the image.Signed-off-by: Mauro Carvalho Chehab
-
Silvercrest mt9v011 sensor produces a 640x480 image. However,
previously, the code were getting only half of the lines and merging two
consecutive frames to "produce" a 640x480 image.With the addition of progressive mode, now em28xx is working with a full
image. However, when the number of lines is bigger than 240, the
beginning of some odd lines are filled with blank.After lots of testing, and physically checking the device for a Xtal, it
was noticed experimentally that mt9v011 is using em28xx XCLK as its
clock. Due to that, changing XCLK value changes the maximum speed of the
stream.At the tests, it were possible to produce up to 32 fps, using a 30 MHz
XCLK. However, at that rate, the artifacts happen even at 320x240. Lower
values of XCLK produces artifacts only at 640x480.At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is
possible to see an invalid sucession of artifacts with this pattern:.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(where the dots represent the blanked pixels)
So, it seems that a waveform in the format of a ramp is interferring at
the image.The cause of this interference is currently unknown. Some possibilities
are:
- electrical interference (maybe this device is broken?);
- some issue at mt9v011 programming;
- some bug at em28xx chip.So, for now, let's be conservative and use a value of XCLK that we know
for sure that it won't cause artifacts.As I'm waiting for more of such devices with different em28xx chipset
revisions, I'll have the opportunity to double check the issue with
other pieces of hardware.Later patches can vary XCLK depending on the vertical resolutions, if a
proper fix is not discovered.Signed-off-by: Mauro Carvalho Chehab
