- 16 Nov, 2006 4 commits
-
-
Zhang, Yanmin authored
I got an oops when booting 2.6.19-rc5-mm1 on my ia64 machine. Below is the log. Oops 11012296146944 [1] Modules linked in: binfmt_misc dm_mirror dm_multipath dm_mod thermal processor f an container button sg eepro100 e100 mii Pid: 0, CPU 0, comm: swapper psr : 0000121008022038 ifs : 800000000000040b ip : [<a0000001000e1411>] Not tainted ip is at __do_IRQ+0x371/0x3e0 unat: 0000000000000000 pfs : 000000000000040b rsc : 0000000000000003 rnat: 656960155aa56aa5 bsps: a00000010058b890 pr : 656960155aa55a65 ldrs: 0000000000000000 ccv : 0000000000000000 fpsr: 0009804c0270033f csd : 0000000000000000 ssd : 0000000000000000 b0 : a0000001000e1390 b6 : a0000001005beac0 b7 : e00000007f01aa00 f6 : 000000000000000000000 f7 : 0ffe69090000000000000 f8 : 1000a9090000000000000 f9 : 0ffff8000000000000000 f10 : 1000a908ffffff6f70000 f11 : 1003e0000000000000909 r1 : a000000100fbbff0 r2 : 0000000000010002 r3 : 0000000000010001 r8 : fffffffffffbffff r9 : a000000100bd8060 r10 : a000000100dd83b8 r11 : fffffffffffeffff r12 : a000000100bcbbb0 r13 : a000000100bc4000 r14 : 0000000000010000 r15 : 0000000000010000 r16 : a000000100c01aa8 r17 : a000000100d2c350 r18 : 0000000000000000 r19 : a000000100d2c300 r20 : a000000100c01a88 r21 : 0000000080010100 r22 : a000000100c01ac0 r23 : a0000001000108e0 r24 : e000000477980004 r25 : 0000000000000000 r26 : 0000000000000000 r27 : e00000000913400c r28 : e0000004799ee51c r29 : e0000004778b87f0 r30 : a000000100d2c300 r31 : a00000010005c7e0 Call Trace: [<a000000100014600>] show_stack+0x40/0xa0 sp=a000000100bcb760 bsp=a000000100bc4f40 [<a000000100014f00>] show_regs+0x840/0x880 sp=a000000100bcb930 bsp=a000000100bc4ee8 [<a000000100037fb0>] die+0x250/0x320 sp=a000000100bcb930 bsp=a000000100bc4ea0 [<a00000010005e5f0>] ia64_do_page_fault+0x8d0/0xa20 sp=a000000100bcb950 bsp=a000000100bc4e50 [<a00000010000caa0>] ia64_leave_kernel+0x0/0x290 sp=a000000100bcb9e0 bsp=a000000100bc4e50 [<a0000001000e1410>] __do_IRQ+0x370/0x3e0 sp=a000000100bcbbb0 bsp=a000000100bc4df0 [<a000000100011f50>] ia64_handle_irq+0x170/0x220 sp=a000000100bcbbb0 bsp=a000000100bc4dc0 [<a00000010000caa0>] ia64_leave_kernel+0x0/0x290 sp=a000000100bcbbb0 bsp=a000000100bc4dc0 [<a000000100012390>] ia64_pal_call_static+0x90/0xc0 sp=a000000100bcbd80 bsp=a000000100bc4d78 [<a000000100015630>] default_idle+0x90/0x160 sp=a000000100bcbd80 bsp=a000000100bc4d58 [<a000000100014290>] cpu_idle+0x1f0/0x440 sp=a000000100bcbe20 bsp=a000000100bc4d18 [<a000000100009980>] rest_init+0xc0/0xe0 sp=a000000100bcbe20 bsp=a000000100bc4d00 [<a0000001009f8ea0>] start_kernel+0x6a0/0x6c0 sp=a000000100bcbe20 bsp=a000000100bc4ca0 [<a0000001000089f0>] __end_ivt_text+0x6d0/0x6f0 sp=a000000100bcbe30 bsp=a000000100bc4c00 <0>Kernel panic - not syncing: Aiee, killing interrupt handler! The root cause is that some irq_chip variables, especially ia64_msi_chip, initiate their memeber end to point to NULL. __do_IRQ doesn't check if irq_chip->end is null and just calls it after processing the interrupt. As irq_chip->end is called at many places, so I fix it by reinitiating irq_chip->end to dummy_irq_chip.end, e.g., a noop function. Signed-off-by:Zhang Yanmin <yanmin.zhang@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Zhang, Yanmin authored
[PATCH] ipmi: use platform_device_add() instead of platform_device_register() to register device allocated dynamically I got below warning when running 2.6.19-rc5-mm1 on my ia64 machine. WARNING at lib/kobject.c:172 kobject_init() Call Trace: [<a0000001000137c0>] show_stack+0x40/0xa0 sp=e0000002ff9f7bc0 bsp=e0000002ff9f0d10 [<a000000100013850>] dump_stack+0x30/0x60 sp=e0000002ff9f7d90 bsp=e0000002ff9f0cf8 [<a000000100407bb0>] kobject_init+0x90/0x160 sp=e0000002ff9f7d90 bsp=e0000002ff9f0cd0 [<a0000001005ae080>] device_initialize+0x40/0x1c0 sp=e0000002ff9f7da0 bsp=e0000002ff9f0cb0 [<a0000001005b88c0>] platform_device_register+0x20/0x60 sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c90 [<a000000100592560>] try_smi_init+0xbc0/0x11e0 sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50 [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0 sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8 [<a000000100009910>] init+0x350/0x780 sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8 [<a000000100011d30>] kernel_thread_helper+0x30/0x60 sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80 [<a0000001000090c0>] start_kernel_thread+0x20/0x40 sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80 WARNING at lib/kobject.c:172 kobject_init() Call Trace: [<a0000001000137c0>] show_stack+0x40/0xa0 sp=e0000002ff9f7b40 bsp=e0000002ff9f0db0 [<a000000100013850>] dump_stack+0x30/0x60 sp=e0000002ff9f7d10 bsp=e0000002ff9f0d98 [<a000000100407bb0>] kobject_init+0x90/0x160 sp=e0000002ff9f7d10 bsp=e0000002ff9f0d70 [<a0000001005ae080>] device_initialize+0x40/0x1c0 sp=e0000002ff9f7d20 bsp=e0000002ff9f0d50 [<a0000001005b88c0>] platform_device_register+0x20/0x60 sp=e0000002ff9f7d50 bsp=e0000002ff9f0d30 [<a00000010058ac00>] ipmi_register_smi+0xcc0/0x18e0 sp=e0000002ff9f7d50 bsp=e0000002ff9f0c90 [<a000000100592600>] try_smi_init+0xc60/0x11e0 sp=e0000002ff9f7dd0 bsp=e0000002ff9f0c50 [<a000000100594900>] init_ipmi_si+0xaa0/0x12e0 sp=e0000002ff9f7de0 bsp=e0000002ff9f0bd8 [<a000000100009910>] init+0x350/0x780 sp=e0000002ff9f7e00 bsp=e0000002ff9f0ba8 [<a000000100011d30>] kernel_thread_helper+0x30/0x60 sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80 [<a0000001000090c0>] start_kernel_thread+0x20/0x40 sp=e0000002ff9f7e30 bsp=e0000002ff9f0b80 The root cause is the device struct is initialized twice. If the device is allocated dynamically by platform_device_alloc, platform_device_alloc will initialize struct device, then, platform_device_add should be used to register the device. The difference between platform_device_register and platform_device_add is platform_device_register will initiate the device while platform_device_add won't. Signed-off-by: -
Linus Torvalds authored
Getting there. Hopefully the MSI and other interrupt problems are all solved now. Signed-off-by: -
Benjamin Herrenschmidt authored
The windfarm code, in it's current incarnation, uses request_module() to load the various submodules it needs for a given platform so that only the main platform control module needs to be modprobed. However, it was missing various bits. This fixes it. In the future, we'll use some hotplug mecanisms to try to get all of this auto-loaded on the platforms where it matters but that isn't ready yet. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
- 15 Nov, 2006 5 commits
-
-
Stephen Rothwell authored
All the infrastructure is already in place for this, so we only need to allocate a syscall number and hook it up. Signed-off-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
Stephen Rothwell authored
This adds the /sys/devices/system/cpu/*/topology/thread_siblings files on powerpc. These files are already available on other architectures. Signed-off-by:
-
Eric W. Biederman authored
Komuro reports that ISA interrupts do not work after a disable_irq(), causing some PCMCIA drivers to not work, with messages like eth0: Asix AX88190: io 0x300, irq 3, hw_addr xx:xx:xx:xx:xx:xx eth0: found link beat eth0: autonegotiation complete: 100baseT-FD selected eth0: interrupt(s) dropped! eth0: interrupt(s) dropped! eth0: interrupt(s) dropped! ... Linus Torvalds <torvalds@osdl.org> said: "Now, edge-triggered interrupts are a _lot_ harder to mask, because the Intel APIC is an unbelievable piece of sh*t, and has the edge-detect logic _before_ the mask logic, so if a edge happens _while_ the device is masked, you'll never ever see the edge ever again (unmasking will not cause a new edge, so you simply lost the interrupt). So when you "mask" an edge-triggered IRQ, you can't really mask it at all, because if you did that, you'd lose it forever if the IRQ comes in while you masked it. Instead, we're supposed to leave it active, and set a flag, and IF the IRQ comes in, we just remember it, and mask it at that point instead, and then on unmasking, we have to replay it by sending a self-IPI." This trivial patch solves the problem. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Cc: Ingo Molnar <mingo@redhat.com> Acked-by:
Komuro <komurojun-mbn@nifty.com> Signed-off-by:
-
Takashi Iwai authored
Disable MSI support on HD-audio driver as default since there are too many broken devices. The module option is changed from disable_msi to enable_msi, too. For turning MSI support on, pass enable_msi=1, instead. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Jiri Slaby authored
port is dereferenced even if it is NULL. Dereference it _after_ the check if (!port)... Thanks Eric <ef87@yahoo.com> for reporting this. This fixes http://bugzilla.kernel.org/show_bug.cgi?id=7527Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
- 14 Nov, 2006 28 commits
-
-
git://one.firstfloor.org/home/andi/git/linux-2.6Linus Torvalds authored
* 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: [PATCH] x86-64: Fix race in exit_idle [PATCH] x86-64: Fix vgetcpu when CONFIG_HOTPLUG_CPU is disabled [PATCH] x86: Add acpi_user_timer_override option for Asus boards [PATCH] x86-64: setup saved_max_pfn correctly (kdump) [PATCH] x86-64: Handle reserve_bootmem_generic beyond end_pfn [PATCH] x86-64: shorten the x86_64 boot setup GDT to what the comment says [PATCH] x86-64: Fix PTRACE_[SG]ET_THREAD_AREA regression with ia32 emulation. [PATCH] x86-64: Fix partial page check to ensure unusable memory is not being marked usable. Revert "[PATCH] MMCONFIG and new Intel motherboards"
-
Linus Torvalds authored
This reverts commit 0130b0b3. Sergey Vlasov points out (and Vadim Lobanov concurs) that the bug it was supposed to fix must be some unrelated memory corruption, and the "fix" actually causes more problems: "However, the new code does not look safe in all cases. If some other task has opened more files while dup_fd() released oldf->file_lock, the new code will update open_files to the new larger value. But newf was allocated with the old smaller value of open_files, therefore subsequent accesses to newf may try to write into unallocated memory." so revert it. Cc: Sharyathi Nagesh <sharyath@in.ibm.com> Cc: Sergey Vlasov <vsu@altlinux.ru> Cc: Vadim Lobanov <vlobanov@speakeasy.net> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Linus Torvalds authored
* 'upstream-linus' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev: libata: fix double-completion on error [PATCH] pata_artop: fix "& (1 >>" typo [PATCH] hpt37x: Check the enablebits
-
Hugh Dickins authored
Commit cb07c9a1 causes the wrong return value. is_hugepage_only_range() is a boolean, so we should return -EINVAL rather than 1. Also - we can use "mm" instead of looking up "current->mm" again. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Jens Axboe authored
cpqarray needs to call disk_stat_add() for iostat to work. Signed-off-by:
Jens Axboe <jens.axboe@oracle.com> Signed-off-by:
-
Jens Axboe authored
cciss needs to call disk_stat_add() for iostat to work. Signed-off-by:
-
Brian King authored
When building a monolithic kernel, the load order of drivers does not work for SAS libata users, resulting in a kernel oops. Convert libata to use subsys_initcall instead of module_init, which ensures that libata gets loaded before any LLDD. This is the same thing that scsi core does to solve the problem. The load order problem was observed on ipr SAS adapters and should exist for other SAS users as well. Signed-off-by:
Brian King <brking@us.ibm.com> Acked-by:
Jeff Garzik <jgarzik@pobox.com> Signed-off-by:
-
David Gibson authored
Unlike mmap(), the codepath for brk() creates a vma without first checking that it doesn't touch a region exclusively reserved for hugepages. On powerpc, this can allow it to create a normal page vma in a hugepage region, causing oopses and other badness. Add a test to prevent this. With this patch, brk() will simply fail if it attempts to move the break into a hugepage reserved region. Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Cc: Adam Litke <agl@us.ibm.com> Cc: Hugh Dickins <hugh@veritas.com> Signed-off-by:
-
Hugh Dickins authored
(David:) If hugetlbfs_file_mmap() returns a failure to do_mmap_pgoff() - for example, because the given file offset is not hugepage aligned - then do_mmap_pgoff will go to the unmap_and_free_vma backout path. But at this stage the vma hasn't been marked as hugepage, and the backout path will call unmap_region() on it. That will eventually call down to the non-hugepage version of unmap_page_range(). On ppc64, at least, that will cause serious problems if there are any existing hugepage pagetable entries in the vicinity - for example if there are any other hugepage mappings under the same PUD. unmap_page_range() will trigger a bad_pud() on the hugepage pud entries. I suspect this will also cause bad problems on ia64, though I don't have a machine to test it on. (Hugh:) prepare_hugepage_range() should check file offset alignment when it checks virtual address and length, to stop MAP_FIXED with a bad huge offset from unmapping before it fails further down. PowerPC should apply the same prepare_hugepage_range alignment checks as ia64 and all the others do. Then none of the alignment checks in hugetlbfs_file_mmap are required (nor is the check for too small a mapping); but even so, move up setting of VM_HUGETLB and add a comment to warn of what David Gibson discovered - if hugetlbfs_file_mmap fails before setting it, do_mmap_pgoff's unmap_region when unwinding from error will go the non-huge way, which may cause bad behaviour on architectures (powerpc and ia64) which segregate their huge mappings into a separate region of the address space. Signed-off-by:
Adam Litke <agl@us.ibm.com> Acked-by:
-
David Brownell authored
Looks like I still take care of the USB gadget/peripheral framework. Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Acked-by:
Greg KH <greg@kroah.com> Signed-off-by:
-
Nathan Lynch authored
Fix binary/logical operator typo which leads to unreachable code. Noticed while looking at other issues; I don't have the relevant hardware to test this. Signed-off-by:
Nathan Lynch <ntl@pobox.com> Cc: "Antonino A. Daplas" <adaplas@pol.net> Acked-by:
James Simmons <jsimmons@infradead.org> Signed-off-by:
-
Ian Kent authored
Resolve the panic on failed mount of an autofs filesystem originally reported by Mao Bibo. It addresses two issues that happen after the mount fail. The first a NULL pointer reference to a field (pipe) in the autofs superblock info structure and second the lack of super block cleanup by the autofs and autofs4 modules. Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
-
Nicolas Kaiser authored
Stray bracket in debug code. Signed-off-by:
Nicolas Kaiser <nikai@nikai.net> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Andrew Morton authored
Fix http://bugzilla.kernel.org/show_bug.cgi?id=7264 We need to target this quirk a little more tightly, using the T20 DMI string. Cc: Pavel Kysilka <goldenfish@bsys.cz> Acked-by:
Kristen Carlson Accardi <kristen.c.accardi@intel.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Daniel Ritz <daniel.ritz@gmx.ch> Signed-off-by:
-
Daniel Ritz authored
Fix interrupt routing for via 586 bridges. pirq can be 5 which needs to be mapped to INTD. But currently the access functions can handle only pirq 1-4. this is similar to the other via chipsets where pirq 4 and 5 are both mapped to INTD. Fixes bugzilla #7490 Cc: Daniel Paschka <monkey20181@gmx.net> Cc: Adrian Bunk <bunk@susta.de> Signed-off-by:
Daniel Ritz <daniel.ritz@gmx.ch> Cc: <stable@kernel.org> Signed-off-by:
-
Andrew Morton authored
When we get a mismatch between handlers on the same IRQ, all we get is "IRQ handler type mismatch for IRQ n". Let's print the name of the presently-registered handler with which we got the mismatch. Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Andi Kleen authored
When another interrupt happens in exit_idle the exit idle notifier could be called an incorrect number of times. Add a test_and_clear_bit_pda and use it handle the bit atomically against interrupts to avoid this. Pointed out by Stephane Eranian Signed-off-by:Andi Kleen <ak@suse.de>
-
Andi Kleen authored
The vgetcpu per CPU initialization previously relied on CPU hotplug events for all CPUs to initialize the per CPU state. That only worked only on kernels with CONFIG_HOTPLUG_CPU enabled. On the others some CPUs didn't get their state initialized properly and vgetcpu wouldn't work. Change the initialization sequence to instead run in a normal initcall (which runs after the normal CPU bootup) and initialize all running CPUs there. Later hotplug CPUs are still handled with an hotplug notifier. This actually simplifies the code somewhat. Signed-off-by: -
Andi Kleen authored
Timer overrides are normally disabled on Nvidia board because they are commonly wrong, except on new ones with HPET support. Unfortunately there are quite some Asus boards around that don't have HPET, but need a timer override. We don't know yet how to handle this transparently, but at least add a command line option to force the timer override and let them boot. Cc: len.brown@intel.com Signed-off-by: -
Magnus Damm authored
x86_64: setup saved_max_pfn correctly 2.6.19-rc4 has broken CONFIG_CRASH_DUMP support on x86_64. It is impossible to read out the kernel contents from /proc/vmcore because saved_max_pfn is set to zero instead of the max_pfn value before the user map is setup. This happens because saved_max_pfn is initialized at parse_early_param() time, and at this time no active regions have been registered. save_max_pfn is setup from e820_end_of_ram(), more exact find_max_pfn_with_active_regions() which returns 0 because no regions exist. This patch fixes this by registering before and removing after the call to e820_end_of_ram(). Signed-off-by:
Magnus Damm <magnus@valinux.co.jp> Signed-off-by:
-
Andi Kleen authored
This can happen on kexec kernels with some configurations, in particularly on Unisys ES7000 systems. Analysis by Amul Shah Cc: Amul Shah <amul.shah@unisys.com> Signed-off-by: -
Steven Rostedt authored
Stephen Tweedie, Herbert Xu, and myself have been struggling with a very nasty bug in Xen. But it also pointed out a small bug in the x86_64 kernel boot setup. The GDT limit being setup by the initial bzImage code when entering into protected mode is way too big. The comment by the code states that the size of the GDT is 2048, but the actual size being set up is much bigger (32768). This happens simply because of one extra '0'. Instead of setting up a 0x800 size, 0x8000 is set up. On bare metal this is fine because the CPU wont load any segments unless they are explicitly used. But unfortunately, this breaks Xen on vmx FV, since it (for now) blindly loads all the segments into the VMCS if they are less than the gdt limit. Since the real mode segments are around 0x3000, we are getting junk into the VMCS and that later causes an exception. Stephen Tweedie has written up a patch to fix the Xen side and will be submitting that to those folks. But that doesn't excuse the GDT limit being a magnitude too big. AK: changed to compute true gdt size in assembler, fixed comment Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Andi Kleen authored
ptrace(PTRACE_[SG]ET_THREAD_AREA) calls from ia32 code should be passed onto the x86_64 implementation. The default case in sys32_ptrace used to call to sys_ptrace(), but is now EINVAL. This patch fixes a regression caused by that changed. Signed-off-by:
Mike McCormack <mike@codeweavers.com> Signed-off-by:
-
Aaron Durbin authored
Fix partial page check in e820_register_active_regions to ensure partial pages are not being marked as active in the memory pool. Signed-off-by:
Aaron Durbin <adurbin@google.com> Signed-off-by:
-
Andi Kleen authored
This reverts 4c6e052a commit. Following Linus' i386 change: revert resource reservation for mmcfg config now. Will be revisited in .20 hopefully.
-
Darrick J. Wong authored
A curious thing happens, however, when ata_qc_new_init fails to get an ata_queued_cmd: First, ata_qc_new_init handles the failure like this: cmd->result = (DID_OK << 16) | (QUEUE_FULL << 1); done(cmd); Then, we return to ata_scsi_translate and do this: err_mem: cmd->result = (DID_ERROR << 16); done(cmd); It appears to me that first we set a status code indicating that we're ok but the device queue is full and finish the command, but then we blow away that status code and replace it with an error flag and finish the command a second time! That does not seem to be desirable behavior since we merely want the I/O to wait until a command slot frees up, not send errors up the block layer. In the err_mem case, we should simply exit out of ata_scsi_translate instead. Signed-off-by:Darrick J. Wong <djwong@us.ibm.com> Signed-off-by:
Jeff Garzik <jeff@garzik.org>
-
Alexey Dobriyan authored
Signed-off-by:
Alexey Dobriyan <adobriyan@openvz.org> Signed-off-by:
-
Alan Cox authored
Helps for PATA but SATA bridged devices lie and always set all the bits so will need the error handling fixes from Tejun. Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
- 13 Nov, 2006 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmcLinus Torvalds authored
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc: MMC: Do not set unsupported bits in OCR response MMC: Poll card status after rescanning cards
-
Linus Torvalds authored
* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband: IB/mad: Fix race between cancel and receive completion RDMA/amso1100: Fix && typo RDMA/amso1100: Fix unitialized pseudo_netdev accessed in c2_register_device IB/ehca: Activate scaling code by default IB/ehca: Use named constant for max mtu IB/ehca: Assure 4K alignment for firmware control blocks
-
Linus Torvalds authored
Commit 450efcfd broke Avermedia 777 support. Added obvious missing "break" statement. Cc: Jos Surez <j.suarez.agapito@gmail.com> Cc: Michael Krufky <mkrufky@linuxtv.org> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Signed-off-by:
-
