Re: [OpenWrt-Devel] block info and DISK_MEDIA_CHANGE events

2016-02-20 Thread Karl Palsson 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

John Crispin  wrote:
> 
> 
> On 19/02/2016 18:00, Karl Palsson wrote:
> > Hi,
> > 
> > I'm trying to get "block mount" to behave well when a microSD
> > card is removed/inserted from a fixed USB card reader. I've
> > compiled the uevent-hotplug debugger example from
> > https://www.kernel.org/doc/pending/hotplug.txt and running that
> > on my device, I can see that "block info" is somehow triggering
> > the uevent change notifications I hope. (I can't see anywhere in
> > the fstools how the uevent is triggered, but it only happens if I
> > run "block info" manually, "blkid" doesn't trigger any events, so
> > it's something in block info
> > 
> > Example event (unfortuntely it's identical for card inserted ->
> > removed and for removed -> inserted)
> > ```
> > change@/devices/platform/ehci-platform/usb1/1-1/1-1.1/1-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda
> > ACTION=change
> > DEVPATH=/devices/platform/ehci-platform/usb1/1-1/1-1.1/1-1.1:1.0/host0/target0:0:0/0:0:0:0/block/sda
> > SUBSYSTEM=block DISK_MEDIA_CHANGE=1 MAJOR=8 MINOR=0 DEVNAME=sda
> > DEVTYPE=disk SEQNUM=637
> > ```
> > 
> 
> 
> fstools/libblkid-tiny/libblkid-tiny.c: probe_block()
> 
> does an open() on the device node which will eventually end up
> inside
> 
> drivers/scsi/sd.c: sd_open()
> 
> which will call check_disk_change(bdev);
> 
> and that triggers the uevent.

Ahh, thanks.

> 
> i am not sure how you can get it to automatically send the
> event without polling it.

I can live with that, my real concern is that I want it to be
unmounted/mounted. Should "block hotplug" be handling this to
add/remove? I can work on adding this to handle the change
events, but is that the right way, and would that be accepted, or
should something else be converting them into add/remove events
elsewhere? On desktop linux, I see the change event with
DISK_MEDIA_CHANGE=1, then a subsequent add/remove event.

As for automatically getting the event, I can enable the kernel
event polling, by setting /sys/block/sda/events_poll_msecs to
~500ms or so, and I can then see the SCSI LUN check commands with
usbmon, and I can see the responses change as soon as the card is
inserted/removed, but no events come out. I kinda feel that's
something I should take up upstream, but I'm perfectly ok with
having to poll "block info" at the moment.

Sincerely,
Karl P

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJWyMezAAoJEBmotQ/U1cr2xQsP/2nC9BiSIcMwR/2QZg4QvvyR
65+uZ7cRoGutmPd2V7QQu/ZAtwET9lft8CgYh5uY1htNEvVTjEagz1+1yAjrqAau
Uc4uEOmwteXupIIAQeB/nTheAugfvt8+PhzXAAxyHxtV4udyYdM0wp8sDFvw201/
R2n9fgDyz8Oyw+qtf3vNPZcHXHGb7ewM8GTxkjnkeKMTCt307hDjh3uAVBNQvdem
3sQpx13nMgfbT6jVlXya8QMvOozW5P/1w9cOJUPDlAgdeZd3H6WbZ9YI1mivJgUa
F/LTfmheHqwXPj6HTVZ7nuHe10SqXRjrDike88FxjOtyp/gg7tleuWNSzZ8Rq8gj
40JHU9HdUJ5CWKMGjnI10gbj/zW9s+9OiLRWHUHW242WLIe3lTckosyPLoKi2VtB
svqqv3aNnHM0Esf1EKDVFiu0KqP0cZWaE+UOGRm+kp/+4pp35l5mOtzonZtbLWF5
FOR4y/fJmJmpwi9MrNo6e1fPxpr+IxSv6bmNvH2mEvbX9DspH3a8tJX6AsQsVweJ
s6D1N+QQnHNEnIF2gXvGwLAGvItlifJM3p+4v9dUBb5XQtHxzraVkW7ygx5XfOhn
MWc9MxDwlEYJd0DIPWAQ8ORrEfkJ+49oklnGWjxAe48K/A5jx2zs/Ve7YMpATMp7
nDRP9DPTizzcQcHH3gA8
=Hdwm
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] openwrt.org down ?

2016-02-20 Thread smilebef 
I need access to the server...
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] uci_lookup_ptr() seg fault

2016-02-20 Thread bkil 
You can investigate a core dump file using gdb or an IDE to review the
call stack and variables (extra useful if compiled with -g and -O0).
You may need to enable core dumping like so:

http://www.idimmu.net/2013/06/21/enable-linux-core-dump/
http://www.akadia.com/services/ora_enable_core.html

By the way, if you get a segfault on the uci_lookup_ptr() line, you
probably have pkg==NULL, as returned by uci_load().

On Tue, Feb 16, 2016 at 7:12 PM, Farid Farid  wrote:
> Hi All,
>
> I am getting seg fault sometimes on the uci_lookup_ptr() call. here is the
> way I call this function:
> It happens I would say once every couple of hundred calls.
> I appreciate if someone can help and guide me how to debug this issue.
> I have tried it with uci package from 2016-02-02
>
> char *
> get_uci_option_api (char* file_name , char* section_name , char*
> section_value , char* option_name)
> {
> struct uci_element *e;
> struct uci_section *s = NULL;
> struct uci_package *pkg;
> struct uci_context *m_uci;
> struct uci_ptr  ptr;
>
> m_uci = uci_alloc_context();
> if (!m_uci)
> return NULL;
>
> uci_load ( m_uci , file_name , );
> memset(,0,sizeof(struct uci_ptr));
>
> ptr.option = NULL;
> ptr.section = section_value;
> ptr.package =  file_name;
> ptr.value = section_name;
> if (!uci_lookup_ptr(pkg->ctx,  , NULL , true))
> {
> s = ptr.s;
> }
> else
> s = NULL;
>
> if (!s)
> return NULL;
>
> uci_foreach_element (>options, e)
> {
> if (!strcmp (e->name, option_name))
> {
> struct uci_option *o = uci_to_option (e);
> if (o->type == UCI_TYPE_STRING)
> return o->v.string;
> }
>   return NULL;
> }
>
> Thanks,
> Farid
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/5] lantiq/xrx200-net: fix PCE_MAPx handling

2016-02-20 Thread Felix Fietkau 
On 2016-02-18 14:13, Martin Schiller wrote:
> Remove unnecessary MPMAP (PCE_MAP1) initialization and make DMCPMAP (PCE_MAP2)
> and UUCMAP (PCE_MAP3) configurable from user space.
> 
> Signed-off-by: Martin Schiller 
This looks a lot like a low level implementation detail that should not
be exposed to the configuration. Please provide an explanation of how
exactly these port map registers works, so we can figure out a way to
set it dynamically from within the driver.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 2/2] Add support for 'metric' to QMI, NCM, MBIM and DirectIP

2016-02-20 Thread Felix Fietkau 
On 2016-02-18 17:53, Bruno Randolf wrote:
> On 02/18/2016 04:43 PM, John Crispin wrote:
>> ideally this gets handled generically, which wont be easy as these are
>> all virtual interfaces. maybe if we just add the code in a generic place
>> rather than duplicate it lots of times.
> 
> Ideally - yes... but where?
The helpers should go into netifd.git - scripts/netifd-proto.sh

They could look something like this:

PROTO_DEFAULT_OPTIONS="defaultroute peerdns metric"

proto_config_add_defaults() {
# add default config options
}
proto_add_dynamic_defaults() {
# json_add_* calls for dynamic interfaces
}

Any proto handler can add $PROTO_DEFAULT_OPTIONS to its json_get_vars
call and optionally filter/override them if necessary, before they get
used by proto_add_dynamic_defaults

> Also I don't understand why these have to be virtual interfaces.
> Wouldn't it be possible to attach the dhcp client to the normal
> interface, just as it is done for ethernet or wifi interfaces?
Well, some proto handlers create multiple dynamic interfaces (for v4 and
v6), and right now we don't have support for dealing with multiple proto
tasks yet.

> That would simplify other things as I have been trying to mention in my
> mail titled: "QMI/NCM/MBIM interfaces netifd ifup event too early"
> https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg37608.html
I think we may need to change netifd to add support for embedding
dynamic interfaces in the proto notification and marking the main
interface as up only if one of its dynamic interfaces was activated.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel