users

users@lists.genode.org

2357 discussions

l4linux block driver bugs
by i.ismagilov 10 Oct '12

10 Oct '12

Thanks for fast fixing of 'SD card doesn't start due to I/O pages caching' bug. But SD card still doesn't normally work on PandaBoard. It seems that there are 2 more problems with it. * * *Bug 1.* File cache subsystem generates an interrupt processing error _at intensive read/write access to SD card_: in Vcpu interrupts are disabled in the place where they should be allowed (/ports-foc/contrib/l4linux/fs/buffer.c:1231/). The same error occurs in qemu in other sub-system (/ports-foc/contrib/l4linux/kernel/softirq.c:159/) *Solution:* Function prototype in /ports-foc/src/lib/l4lx/include/linux.h/: /FASTCALL void l4x_irq_save(unsigned long *flags*); /should be: /FASTCALL void l4x_irq_save(unsigned long **flags*);/ So, value of interrupt state (enabling/disabling) was not properly stored before above correction. *Bug 2.* L4Linux 'hangs' because of problem with its virtual block device _at intensive read/write access to SD card on PandaBoard_. In Genode block driver memory for storing of packages sent via IPC sometimes is over /(ports-foc/src/lib/l4lx/genode_block.cc:281)/. In such case L4Linux virtual block driver is blocked on semaphore /(ports-foc/src/drivers/genode_block.c:98)/. When memory for IPC packages storage in Genode block driver becomes ready for use, driver sends signal to the thread '*blk-signal-thread*' /(ports-foc/src/lib/l4lx/genode_block.cc:126)/. Thread 'blk-signal-thread' catches the signal and generates interrupt by calling function '*l4_irq_trigger*' /(ports-foc/src/lib/l4lx/genode_block.cc:154)/. But, L4Linux doesn't catch the interrupt and hangs. In normal case interrupt is to be catched and interrupt handler '*event_interrupt*' /(ports-foc/src/drivers/genode_block.c:172)/ should be called; increment semaphore counter by 1 (/ports-foc/src/drivers/genode_block.c:146/) and thus un-block L4Linux driver.

2 3

SD service of Genode master branch for Fiasco.OC / PandaBoard doesn’t start
by i.ismagilov 04 Oct '12

04 Oct '12

*_Bug:_* SD service of Genode master branch _for Fiasco.OC / PandaBoard_ doesn’t start with *"SD command error"* (occurs in /os/src/drivers/sd_card/omap4/mmchs.h/:824). *_ _* *_Description:_**__* L4_FPAGE_BUFFERABLE constant (/base-foc/src/base/ipc/pager.cc/:91) is used to configure I/O memory region. In *Fiasco.OC *this constant is prepared as Page::*BUFFERED* (/base-foc/contrib/kernel/fiasco/src/kern/arm/paging-arm.cpp/:65). In *Fiasco.OC revision* *38* this constant is equal to *0x04* (for both ARMv6 and ARMv7). In revision 40 it was changed to *0x40*. This modification causes SD card driver error (and possible other driver errors) for ARMv6 and v7 architectures. *0x04*value seems to correspond to *‘Device’ memory type* (for I/O). Memory pages corresponding to I/O are non-cacheable. *0x40*value is seems for ‘Normal’ memory type. *Pages are cached* in this case but *this is not allowed for I/O* and causes SD card error. *_Solutions:_* 1) Page::*BUFFERED* constant seems to be _used for I/O only_, not for RAM (currently). So, we propose to set Page::BUFFERED constant to 0x40 in rev. 40 as it was in rev. 38 (*see attached patch*). 2) If Page::BUFFERED constant is planned to use _for RAM memory also_, some other constant for I/O memory pages configuring and related workaround in Genode driver to be added.

2 1

[Question] Genode File/IO sync
by 김연우 27 Sep '12

27 Sep '12

2 1

Storage device considerations
by Markus Partheymueller 19 Sep '12

19 Sep '12

Hi Folks, starting to discover the possibilities of using storage devices under genode, a few questions arised: (1) AHCI is declared non-working on Fiasco.OC and NOVA. Is this planned to be resolved in the near future? (2) USB Storage is supporting only one device. Are there plans to extend this? (3) Using the part_blk service, it is possible to redirect children to different partitions of the same storage device. What I'm interested in is somehow the inverse. Is it even possible for a child to get access to multiple block devices? I think it is quite a limiting constraint if a child can only access one single storage device. The background for this question is of course the Vancouver port. I was able to give the guest VM access to exactly one storage device through the Block Session Interface of the USB service. However, as soon as the VM is configured to use a second device, the existing infrastructure does not allow that (or I haven't found the proper service..). So, I would like to open the discussion on this topic to see where the path could lead. Cheers, Markus

3 2

How to make rm-sessions upgradeable?
by Taru Karttunen 18 Sep '12

18 Sep '12

Hello When spawning more threads the rm-session from the env needs to be upgraded in various places. This can occur when spawning new threads and even in thread.start(). Thus one needs a way to make the rm-session in env upgradeable from the outside. A simple way to fix would be to define a class Upgradeable_rm_session : public Rm_session { void upgrade(const char *); }; And make some private inheritance into protected inheritance i.e. Rpc_client into template <typename RPC_INTERFACE> struct Rpc_client : *protected* Capability<RPC_INTERFACE>, RPC_INTERFACE ... Is there a better and more non-invasive way to do this? If not - would a patch implementing this be accepted? An alternative would be to expose the capability in env in addition to the session, but I think that is even more ugly. - Taru Karttunen

2 3

nic_bridge DHCP problem
by Markus Partheymueller 18 Sep '12

18 Sep '12

Hey folks, I'm having some trouble with the nic_bridge provided. When using the nic_drv as single instance, everything works fine. But when I replace it with the nic_bridge, the requests don't seem to make it through. In qemu's TCP dump, I recognized a difference regarding the DHCP broadcast: 13:08:25.494579 IP (tos 0x0, ttl 64, id 5118, offset 0, flags [none], proto UDP (17), length 341) 0.0.0.0.68 > 255.255.255.255.67: [bad udp cksum 0x9134 -> 0xd233!] BOOTP/DHCP, Request from 02:02:02:02:02:02, length 313, xid 0x292e1940, Flags [Broadcast] (0x8000) Client-Ethernet-Address 02:02:02:02:02:02 Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Discover MSZ Option 57, length 2: 1500 Vendor-Class Option 60, length 42: "dhcpcd-5.2.7:Linux-3.5.0:i686:NOVA microHV" Hostname Option 12, length 2: "vm" Parameter-Request Option 55, length 15: Subnet-Mask, Classless-Static-Route, Static-Route, Default-Gateway Domain-Name-Server, Hostname, Domain-Name, MTU BR, NTP, Lease-Time, Server-ID RN, RB, Option 119 The bad checksum irritated me. When I used the nic_drv session, it worked (checksum OK, qemu's DHCP responds correctly with an IP address). Could there be a problem with the bridge itself or is it definitely my problem? Do you have example setups using the bridge that work? Best, Markus

3 4

Qt and lwip-1.4.1
by Ivan Loskutov 17 Sep '12

17 Sep '12

*After upgrade lwip to version 1.4.1 I have an issue in qt-network. In my fork was implemented Ssl support in qt-network for using in web browsers. With new lwip https doesn’t work. Http works, but I think with issues too. I tried to investigate this issue. I think it is related to non-blocking sockets, which implemented in the new version. All simple examples are working properly. Issues occur only in a Qt application. I found that qtapplication calls connect and the connection started in non-blocking mode, connect return EINPROGRESS. After qt made call connect again, in such case connect must return EAGAIN, but it doesn’t happen in lwip. It doesn’t affect for http connection, but ssl connection is dropped. Anyone already faced such issues?* -- Ivan Loskutov

2 1

[Error report] f_stat() failed with error code FR_NO_FILE
by 김은석 12 Sep '12

12 Sep '12

2 1

Threading woes
by Taru Karttunen 07 Sep '12

07 Sep '12

Hello Has anyone tested Genode with a large number of threads on different platforms/kernels? Does it make more sense to just use 1:1 threading or have userlevel soft threads (M:N) with the Genode implementation? It seems that many platforms have currently quite low thread maximums. Threads consume ram in core, but cpu session does not support upgrading the ram amount. This can be fixed quite easily. However a much more harder limitation is found in base-foc/src/core/include/platform_pd.h on Fiasco.OC which defines "THREAD_MAX = (1 << 6)" (64). Now this can be raised to e.g. 256. But not very high since there is 1) an array of threads with static size 2) the memory layout selected With these fixes one can spawn inside one process: Around 43 threads on Nova. Around 100 threads no Fiasco.OC. Has anyone else hacked on this? What is the reasonable way forward? - Taru Karttunen

1 0

[ Error report ] when we setting static IP in lwip_nic_init function .....
by 김은석 07 Sep '12

07 Sep '12

3 2

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

users