Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upUSB Hard Float issue - drivers/usb/host/built-in - kernel Compile ERROR #276
Comments
|
There's no floating point in the kernel, so there's no benefit to building it with hard float abi. |
|
Okay got you. I used just the recomened Flags from http://elinux.org/RPi_Software#GPU_bootloaders for Compile . Been they still Correct written down ? |
|
here are the Documented reason for the issue : http://wiki.debian.org/ArmHardFloatPort The combination of -mfpu=vfp and -mfloat-abi=hard/ is not available in FSF GCC 4.4; see TODO section below for options. "" gcc --version So , Compile with option " -mfloat-abi=hard" using the standard delivered gcc may not supported. With the comment from popcornmix , there is NO hardware based hardFP either on the bmc2708. The only working combination may then : "-mfpu=vfp and -mfloat-abi=vfp" . CLOSE issue. |
This patch fixes the following RCU warning: [ 51.680236] =============================== [ 51.681914] [ INFO: suspicious RCU usage. ] [ 51.683610] 3.8.0-rc6-next-20130206-sasha-00028-g83214f7-dirty #276 Tainted: G W [ 51.686703] ------------------------------- [ 51.688281] net/ipv6/ip6_flowlabel.c:671 suspicious rcu_dereference_check() usage! we should use rcu_dereference_bh() when we hold rcu_read_lock_bh(). Reported-by: Sasha Levin <sasha.levin@oracle.com> Cc: David S. Miller <davem@davemloft.net> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: Cong Wang <amwang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Similar to the file I/O path, re-direct all I/O to the DAX path for I/O
to a block-device special file. Both regular files and device special
files can use the common filp->f_mapping->host lookup to determing is
DAX is enabled.
Otherwise, we confuse the DAX code that does not expect to find live
data in the page cache:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
__delete_from_page_cache+0x9f6/0xb60()
Modules linked in:
CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
00000000ffffffff ffff88006d3f7738 ffffffff82999e2d 0000000000000000
ffff8800620a0000 ffffffff86473d20 ffff88006d3f7778 ffffffff81352089
ffffffff81658d36 ffffffff86473d20 00000000000000d9 ffffea0000009d60
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
[<ffffffff81352089>] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
[<ffffffff813522b9>] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
[<ffffffff81658d36>] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
[<ffffffff81658fb2>] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
[<ffffffff818af369>] __dax_fault+0x859/0x1800 fs/dax.c:487
[<ffffffff8186f4f6>] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
[< inline >] wp_pfn_shared mm/memory.c:2208
[<ffffffff816e9145>] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
[< inline >] handle_pte_fault mm/memory.c:3323
[< inline >] __handle_mm_fault mm/memory.c:3417
[<ffffffff816ecec3>] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
[<ffffffff8127eff6>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
[<ffffffff8127f738>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
[<ffffffff812705c4>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
[<ffffffff86338f78>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986
[<ffffffff86336c36>] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---[ end trace dae21e0f85f1f98c ]---
Fixes: 5a023cd ("block: enable dax for raw block devices")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reported-by: Kirill A. Shutemov <kirill@shutemov.name>
Suggested-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Matthew Wilcox <willy@linux.intel.com>
Tested-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Following commit cceb0a5 ("rtlwifi: Add work queue for c2h cmd."), the following BUG is reported when rtl8723be is used: BUG: sleeping function called from invalid context at mm/slab.h:432 in_atomic(): 1, irqs_disabled(): 1, pid: 0, name: swapper/0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 4.11.0-rc3-wl+ #276 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014 Call Trace: <IRQ> dump_stack+0x63/0x89 ___might_sleep+0xe9/0x130 __might_sleep+0x4a/0x90 kmem_cache_alloc_trace+0x19f/0x200 ? rtl_c2hcmd_enqueue+0x3e/0x110 [rtlwifi] rtl_c2hcmd_enqueue+0x3e/0x110 [rtlwifi] rtl8723be_c2h_packet_handler+0xac/0xc0 [rtl8723be] rtl8723be_rx_command_packet+0x37/0x5c [rtl8723be] _rtl_pci_rx_interrupt+0x200/0x6b0 [rtl_pci] _rtl_pci_interrupt+0x20c/0x5d0 [rtl_pci] __handle_irq_event_percpu+0x3f/0x1d0 handle_irq_event_percpu+0x23/0x60 handle_irq_event+0x3c/0x60 handle_fasteoi_irq+0xa2/0x170 handle_irq+0x20/0x30 do_IRQ+0x48/0xd0 common_interrupt+0x89/0x89 ... Although commit cceb0a5 converted most c2h commands to use a work queue, the Bluetooth coexistence routines can be in atomic mode when they execute such a call. Fixes: cceb0a5 ("rtlwifi: Add work queue for c2h cmd.") Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
kernel 3.8.7(kernel 3.8.y+incrmental patch ) + force hard float compile
..
LD drivers/usb/storage/built-in.o
CC drivers/usb/usb-common.o
LD drivers/usb/built-in.o
ld: error: drivers/usb/host/built-in.o uses VFP register arguments, drivers/usb/built-in.o does not
ld: failed to merge target specific data of file drivers/usb/host/built-in.o
make[2]: *** [drivers/usb/built-in.o] Fehler 1
make[1]: *** [drivers/usb] Fehler 2
make: *** [drivers] Fehler 2
^C[1]+ Exit 2 nohup make CPPFLAGS="-Ofast -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s" CFLAGS="-Ofast -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s" dep zImage Modules
root@lb1:/usr/src# echo "int main(void) { return 0; }" > test.c
root@lb1:/usr/src# CPPFLAGS="-Ofast -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s";CFLAGS="-Ofast -mfpu=vfp -mfloat-abi=hard -march=armv6zk -mtune=arm1176jzf-s"
root@lb1:/usr/src# gcc -mfloat-abi=hard test.c -o test
root@lb1:/usr/src# ./test
glibc debian RPI been hartfload right ?
since the simple test not failed.
Anyone assitance / helpfully Hints ?