is there any Android APK that generate the SIGBUG error because of ARM NEON instructions?
Hi All: anybody who met such error of Android application? the logcat will be something like below: signal 7 (SIGBUS), code 128 (?), fault addr #00 pc 00015cec /data/data/com.pccw.mobile.sip/lib/libavcodec.so --this lib use ARM NEON instructions i found that Linux Kernel(even in latest 3.2 version) does not support un-alignment NEON instruction in data abort handler, if anybody who are interested in this topic, please contact me, i can provide the patch to workaroud it. Best Regards ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. Can you please point to some code in Linux Kernel that does the job? In kernel/exit.c, look at do_exit(). It cleans up a process after it's terminated (for whatever reason). It does a lot of cleanup, but through exit_files() - put_files_struct() - close_files() it ends up iterating over all open file descriptors and closing them. What's done for each close depends on what the process had open. Normal files will just be closed, or a TCP socket might be closed, or if a device node was opened the corresponding drivers close() function will be called. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: About interrupt handler
I'm begin to learn the Kernel and i'm reading Linux kernel development.It says This is an important point, always keep in mind that all interrupt handler has interrupted other code(possibly even another interrupt handler on a different line).What i am not able to understand is how a interrupt handler be interrupted ? DID NOT it uninterrupted? It depends on the architecture and the interrupt controller being used, and the driver code itself. Normally, when an interrupt fires, that particular interrupt will be masked and your own handler won't interrupt itself, but you may very well be interrupted by other interrupts. Can you please point out some code for explanation? --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On Fri, Feb 24, 2012 at 11:04 AM, Kristof Provost kris...@sigsegv.be wrote: On 2012-02-24 09:07:40 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: Imagine a driver which only one app can use at a time (perhaps a serial port). The kernel will take a lock when the user space app open()s the device node and release it when it close()s. If the app segfaults in between the open() and close() the lock will still get released. The kernel always cleans up open files for stopped processes, regardless of how they stop. During this cleanup the kernel will close() the device node, and as a result the driver will release the lock. Can you please point to some code in Linux Kernel that does the job? In kernel/exit.c, look at do_exit(). It cleans up a process after it's terminated (for whatever reason). It does a lot of cleanup, but through exit_files() - put_files_struct() - close_files() it ends up iterating over all open file descriptors and closing them. What's done for each close depends on what the process had open. Normal files will just be closed, or a TCP socket might be closed, or if a device node was opened the corresponding drivers close() function will be called. I meant that I don't see any semaphore related stuff in do_exit(). It seems that semaphore just remains there in the system after a user land task is killed... --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: pagetables used in interrupt context
I am not familiar with other architecture, but for ARM, Linux Kernel 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in chip.c, both of them will call handle_IRQ_event() which is in handle.c. and the function handle_IRQ_event() will call the interrupt handler written by user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt handler in handle_IRQ_event() function. this is only for top-half interrupt handling. for bottom-half, it is no doubt that the interrupt will be opened. The same applies to 3.3.0 as I see from the code of handle_irq_event_percpu() and its friends... --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
Can you please point to some code in Linux Kernel that does the job? In kernel/exit.c, look at do_exit(). It cleans up a process after it's terminated (for whatever reason). It does a lot of cleanup, but through exit_files() - put_files_struct() - close_files() it ends up iterating over all open file descriptors and closing them. What's done for each close depends on what the process had open. Normal files will just be closed, or a TCP socket might be closed, or if a device node was opened the corresponding drivers close() function will be called. I meant that I don't see any semaphore related stuff in do_exit(). It seems that semaphore just remains there in the system after a user land task is killed... In this (fictional, I've not looked at the serial driver code) example I'm assuming a semaphore owned by a driver. The user space application is using the driver through a device node. The semaphore is managed by the driver, and released when the close is called. The driver does not know how (or even if) the application stopped, only that it closed the file descriptor. What specific type of semaphore are you interested in? Who acquires it, what does it protect? I think of user land program opening a socket and crashing on segmentation fault. In code 'socket' syscall does: sock_map_fd -- sock_alloc_file -- alloc_file -- ... get lost ... Where exactly in this case lock is held - I mean the lock that gets released when user land process dies? Thanks, --- KostaZ ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Semaphore
On 2012-02-24 12:15:03 (+0200), Kosta Zertsekel zertse...@gmail.com wrote: I think of user land program opening a socket and crashing on segmentation fault. In code 'socket' syscall does: sock_map_fd -- sock_alloc_file -- alloc_file -- ... get lost ... Where exactly in this case lock is held - I mean the lock that gets released when user land process dies? In this case there doesn't appear to be any lock. The sock_map_fd function is most probably called from the socket syscall. This call isn't locked. Multiple processes can be in the socket syscall at the same time. There certainly won't be a (kernel) lock which is held between two system calls. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Kernel panic - not syncing: junk in compressed archive
Hello all, I'm building a linux system for a new architecture, and I want to use initramfs support to build a filesystem. I have seen that there are several ways to do that with initramfs. Either the kernel will build the cpio archive for me, or I can provide an external one with the CONFIG_INITRAMFS_SOURCE option. An other way is to provide a configuration file to this option. I have tried all these methods but each time, the boot stops with the following message: Kernel panic - not syncing: junk in compressed archive I have googled on that but have not found relevant solution. Does anyone know what could generally be the cause of this problem? Thanks in advance for your help. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
SPARC T2000: Can't get nfsroot working. Kernel 2.6.39 don't mount nfsroot
hi,
I had build kernel 2.6.39 from the Debian Squeeze backports, with buildin
initrd for booting sparcs over OpenBoot. The kernel works with a Sunfire a
v245. Now I try the same with the T2000 (Enterprise), but the kernel doesn't do
anything with NFS, after the last DHCP resquest.
Successful boot from the v245
[...]
[ 81.551492] Sending DHCP and RARP requests .
[ 82.133403] tg3 :0c:04.1: eth3: Link is up at 100 Mbps, full duplex
[ 82.222831] tg3 :0c:04.1: eth3: Flow control is on for TX and on for RX
[ 83.107506] , OK
[ 83.133234] IP-Config: Got DHCP answer from 192.168.1.1, my address is
192.168.1.5
[ 83.391853] IP-Config: Complete:
[ 83.434289] device=eth3, addr=192.168.1.5, mask=255.255.255.0,
gw=192.168.1.1,
[ 83.531766] host=fire, domain=rbg.domain.foo, nis-domain=(none),
[ 83.637249] bootserver=192.168.1.1, rootserver=192.168.1.1,
rootpath=/srv/fai-sparc/nfsroot
-- See a successful mount request on the NFS server side
-
[ 83.756486] Warning: unable to open an initial console.
[ 83.871691] udev[73]: starting version 164
[ 84.282325] Fusion MPT base driver 3.04.18
[ 84.336261] Copyright (c) 1999-2008 LSI Corporation
[ 84.472595] Fusion MPT SPI Host driver 3.04.18
[ 84.546341] Fusion MPT SAS Host driver 3.04.18
[ 84.605341] mptbase: ioc0: Initiating bringup
[ 84.663233] mptbase: ioc1: Initiating bringup
[...]
===
in the end, I get a login ..
but, T2000
[ 94.161607] Sending DHCP requests .
[ 94.482496] e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control:
Rx/Tx
[ 94.482750] e1000e :04:00.0: eth0: 10/100 speed: disabling TSO
[ 96.481510] ., OK
[ 96.489592] IP-Config: Got DHCP answer from 192.168.1.1, my address is
192.168.1.6
[ 96.489940] IP-Config: Complete:
[ 96.489981] device=eth0, addr=192.168.1.6, mask=255.255.255.0,
gw=192.168.1.1,
[ 96.490079] host=e01, domain=rbgdomain.foo, nis-domain=(none),
[ 96.490163] bootserver=192.168.1.1, rootserver=192.168.1.1,
rootpath=/srv/fai-sparc/nfsroot
-- See nothing on the NFS server and with (nfs/rpc ...)
tcpdump -
[ 96.490334] Warning: unable to open an initial console.
[ 96.495441] Kernel panic - not syncing: Attempted to kill init!
[ 96.495518] Call Trace:
[ 96.495570] [0045b8f8] do_exit+0xa8/0x6bc
[ 96.495619] [0045bf7c] do_group_exit+0x70/0xa8
[ 96.495680] [0045bfcc] SyS_exit_group+0x18/0x28
[ 96.495747] [00405fd4] linux_sparc_syscall32+0x34/0x40
[ 96.495859] Press Stop-A (L1-A) to return to the boot prom
==
everything is identical, except the ip:
boot net3:dhcp root=/dev/nfs boot=live FAI_ACTION=sysinfo
nfsroot:192.168.1.1:/srv/fai-sparc/nfsroot ip=eth3: debug
I discovered that there was a big delay, with the network card. I did a ping
from the nfs-server side to the client and after the DHCP request, the ping
disappears. But after ~20-30 seconds, the ping appears again (still in kernel
panic) ! So far I thought, must be the reason, that nfsroot doesn't work. So I
found a patch:
http://kernel.opensuse.org/cgit/kernel/commit/?id=3fb72f1e6e6165c5f495e8dc11c5bbd14c73385c
I patched my 2.6.39 kernel and now, the ping appears after a second again, but
still no success with NFSroot :-/
My kernel config: https://www.pug.org/mediawiki/images/4/4e/Config-fai.txt
So I have no idea anymore ...
any suggestions?
=== complete boot ==
{0} ok boot net3:dhcp root=/dev/nfs boot=live FAI_ACTION=install
FAI_FLAGS=sshd verbose reboot ip=eth3: debug
Boot device: /pci@7c0/pci@0/pci@2/network@0,1:dhcp File and args:
root=/dev/nfs boot=live FAI_ACTION=install FAI_FLAGS=sshd verbose reboot
ip=eth3: debug
100 Mbps full duplex Link up
/
[0.00] PROMLIB: Sun IEEE Boot Prom 'OBP 4.30.4.b 2010/07/09 13:48'
[0.00] PROMLIB: Root node compatible: sun4v
[0.00] Linux version 2.6.39 (2.6.39) (root@fire04) (gcc version 4.4.5
(Debian 4.4.5-8) ) #5 Wed Feb 22 10:24:35 CET 2012
[0.00] bootconsole [earlyprom0] enabled
[0.00] ARCH: SUN4V
[0.00] Ethernet address: 00:14:4f:cb:d1:f8
[0.00] Kernel: Using 3 locked TLB entries for main kernel image.
[0.00] Remapping the kernel... done.
[0.00] OF stdout device is: /virtual-devices@100/console@1
[0.00] PROM: Built device tree with 89203 bytes of memory.
[0.00] MDESC: Size is 30528 bytes.
[0.00] PLATFORM: banner-name [SPARC Enterprise T2000]
[0.00] PLATFORM: name [SUNW,SPARC-Enterprise-T2000]
[0.00] PLATFORM: hostid [84cbd1f8]
[0.00] PLATFORM: serial# [00ab4130]
[0.00] PLATFORM: stick-frequency [3b9aca00]
[0.00] PLATFORM: mac-address [144fcbd1f8]
[0.00] PLATFORM: watchdog-resolution [1000 ms]
[0.00] PLATFORM: watchdog-max-timeout
Re: pagetables used in interrupt context
Hi 卜弋天, 2.6.35, i checked the function handle_level_irq()and handle_edge_irq() in chip.c, both of them will call handle_IRQ_event() which is in handle.c. and the function handle_IRQ_event() will call the interrupt handler written by user. Kernel does not open interrupt(ARM CPSR I bit)when calling interrupt handler in handle_IRQ_event() function. Thank you for the valuable pointers. I have looked at the handle_IRQ_event function, it seems at the end of the do while loop its unconditionally disable the local interrupt (ARM CPSR I bit). If the handler is running with interrupts disabled, why do we need to disable the interrupts again. Could you please explain about this logic. Thanks in advance for your help and sorry to take up your time on this. -- With Regards Subin Gangadharan I am not afraid and I am also not afraid of being afraid. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
want to verify equivalence of Kconfig variants
i'm fairly sure i know the answer to this, but i figured i'd run it by others just to make sure i'm not missing anything subtle. in drivers/video/omap2/Makefile, we see: ... snip ... obj-$(CONFIG_OMAP2_DSS) += dss/ obj-$(CONFIG_FB_OMAP2) += omapfb/ obj-y += displays/ ... snip ... and when i see obj-y, i like to assume that's a component that will be compiled unconditionally. but if you look at the Kconfig file in the displays/ directory, you see: menu OMAP2/3 Display Device Drivers depends on OMAP2_DSS ... entire file contents ... endmenu but that suggests that that entire subdirectory depends on OMAP2_DSS, so one could remove the dependency from that Kconfig file and just move it up to the Makefile above: obj-$(CONFIG_OMAP2_DSS) += displays/ correct? i prefer that approach since the dependency is obvious from the Makefile, without having to descend into the directory itself to learn of it. thoughts? is there anything i'm not noticing about this? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
locking in net_device_ops callbacks
Hi,
I was hoping somebody could enlighten me on how serialization of access
to data in struct net_device and associated netdev_priv() data works in
the callback functions registered in net_device_ops. For example, I am
looking at drivers/net/e1000/e1000_main.c in my 2.6.32 based kernel
tree. My understanding is this is a reference driver of sorts, so it
should be doing the right thing.
This driver registers a callback for the ndo_set_mac_address callback
like this (much of what I think is not significant to the question code
replaced with ... below for brevity):
static const struct net_device_ops e1000_netdev_ops = {
...
.ndo_set_mac_address= e1000_set_mac,
...
};
static int __devinit e1000_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct net_device *netdev;
netdev = alloc_etherdev(sizeof(struct e1000_adapter));
netdev-netdev_ops = e1000_netdev_ops;
...
err = register_netdev(netdev);
...
}
Most network drivers seem to follow more or less the same initialization
sequence.
When I look at the implementation of e1000_set_mac(), I see this:
static int e1000_set_mac(struct net_device *netdev, void *p)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = adapter-hw;
struct sockaddr *addr = p;
...
memcpy(netdev-dev_addr, addr-sa_data, netdev-addr_len);
memcpy(hw-mac_addr, addr-sa_data, netdev-addr_len);
...
return 0;
}
I can't help but notice there is no locking going on around the
memcpy()s of the passed in MAC address to the net_device dev_addr and
private data mac_addr fields.
I assume that e1000_set_mac() is typically called in process context in
response to some user space application like ifconfig or ip changing the
interface MAC address. I am also assuming that these dev_addr and
mac_addr fields are also referenced in other contexts. An Ethernet MAC
address is 6 bytes, so the memcpy()'s can't be atomic operations at
least on a 32 bit machine.
Shouldn't there have been some sort of lock taken before the memcpy()s
are executed so that other execution contexts won't see a partially
copied MAC address?
Is there some sort of lock taken higher up the call stack by the code
that calls these callback functions so that the callbacks themselves
don't have to do it explicitly?
I am writing a network device driver (modifying an existing one
actually) and am therefore trying to understand what kinds of explicit
locking my net_device_ops callbacks need to take in order to ensure
proper operation on an SMP system.
Thanks,
Jeff Haran
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: About interrupt handler
Hi Kosta, On Fri, Feb 24, 2012 at 1:19 AM, Kosta Zertsekel zertse...@gmail.com wrote: I'm begin to learn the Kernel and i'm reading Linux kernel development.It says This is an important point, always keep in mind that all interrupt handler has interrupted other code(possibly even another interrupt handler on a different line).What i am not able to understand is how a interrupt handler be interrupted ? DID NOT it uninterrupted? It depends on the architecture and the interrupt controller being used, and the driver code itself. Normally, when an interrupt fires, that particular interrupt will be masked and your own handler won't interrupt itself, but you may very well be interrupted by other interrupts. Can you please point out some code for explanation? Could you be a bit more specific about what example you're looking for? -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: About interrupt handler
HI Kosta, On Fri, Feb 24, 2012 at 1:08 PM, Dave Hylands dhyla...@gmail.com wrote: Hi Kosta, On Fri, Feb 24, 2012 at 1:19 AM, Kosta Zertsekel zertse...@gmail.com wrote: I'm begin to learn the Kernel and i'm reading Linux kernel development.It says This is an important point, always keep in mind that all interrupt handler has interrupted other code(possibly even another interrupt handler on a different line).What i am not able to understand is how a interrupt handler be interrupted ? DID NOT it uninterrupted? It depends on the architecture and the interrupt controller being used, and the driver code itself. Normally, when an interrupt fires, that particular interrupt will be masked and your own handler won't interrupt itself, but you may very well be interrupted by other interrupts. Can you please point out some code for explanation? Could you be a bit more specific about what example you're looking for? I also believe that things have changed (since I looked at this in any detail). It seems that interrupts are now run with other interrupts disabled. See: http://lwn.net/Articles/364583/ and look at the IRQF_DISABLED discussion. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to debug system freeze?
Hm, sounds like a bug during suspend. Perhaps you can do strace pm-suspend. And/or enable CONFIG_DETECT_SOFTLOCKUP. And hopefully you can pinpoint the related syscall or kernel instruction that leads to the bug It's not that easy. The problem occurs only when I'm going to suspend with closing laptop's lid and it does not happen every time (but mostly yes). I'll try to enable CONFIG_DETECT_SOFTLOCKUP but if it's hard freeze, will I see the output? Regards, Lukasz Sowa ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
