Hi Colin,
> I think I understand the logic of this commit, and in general it seems to
> me a better way of handling the scheduling. I used cherry-pick to add it to
> my branch [1], and it seemed to work the same as before. That said, I am
> unable to trigger the signal handler issue with my hardwa
Hi Josef,
We looked at the problem and could you give this commit [1] a try (it is
> still WIP and not finalized). It might be helpful to add a diagnostic
> message to 'alloc' in 'usb/packet_handler.h' to see when the situation
> occurs.
>
> [1] https://github.com/cnuke/genode/commit/8b4896e7
>
I
Hi Colin,
> > D-Link dongle (running via USB passthrough in QEMU and flood pinging it
> > from the out-site). I encountered the I/O signal handling issue once
> > but since its a known problem I mostly ignored that for now.
> >
>
> I had chased that away in "normal" use, but I'm not surprised you
Josef,
Fantastic!
I am happy to confirm that your driver also works with my Ralink-based
> D-Link dongle (running via USB passthrough in QEMU and flood pinging it
> from the out-site). I encountered the I/O signal handling issue once
> but since its a known problem I mostly ignored that for no
Hi Colin,
> > Did you try with a recent branch? I've been having success with
> > rt2x00 and ath9k both lately.
>
> No, I have not found the time yet but there should be some time this
> weekend.
I am happy to confirm that your driver also works with my Ralink-based
D-Link dongle (running via US
Hi Colin,
> Did you try with a recent branch? I've been having success with rt2x00 and
> ath9k both lately.
No, I have not found the time yet but there should be some time this
weekend.
> > That being said, yesterday I rebased [1] your changes to add hot-plugging
> > support to the 'wpa_supplica
Hi Josef,
Thanks also for your help on this, the run scripts are a big time saver
over building a new Sculpt each time.
as you may have noticed, besides briefly looking into your branches
> and pushing simple changes to make it easier to test the driver in Qemu
> I unfortunately did not find th
Hi Colin,
> Thanks for your continous effort, I'll give your branches a try.
as you may have noticed, besides briefly looking into your branches
and pushing simple changes to make it easier to test the driver in Qemu
I unfortunately did not find the time to dig deeper why it apparently
was not wo
Hi Stefan,
Thanks.
it looks like you nailed it. In the current setup, I would change an
> USB client to close the USB session, and later re-open it again if
> rfkill is triggered.
>
This is a change that has some potential challenges. If the driver simply
disconnects the USB when the rfkill o
Hi Colin,
On Mon, May 22, 2023 at 09:53:31PM -0400, Colin Parker wrote:
> As an update, I think I understand why the rt2x00 version cannot recover
> from the rfkill block. In addition to flushing the USBs tx queues, it also
> flushes the rx queue, which calls usb_kill_urb. I have emulated that
> f
As an update, I think I understand why the rt2x00 version cannot recover
from the rfkill block. In addition to flushing the USBs tx queues, it also
flushes the rx queue, which calls usb_kill_urb. I have emulated that
function to simply wait for the packet to complete. For tx queues that's
fine, eit
Hi Colin,
> […]
>
> Josef I am curious if this version will also work for you?
>
> [1]
> https://github.com/cvparker/genode-world/tree/ath9k_driver_support-2023-01-22
> [2] https://github.com/cvparker/genode/tree/ath9k_driver_support-2023-01-22
Thanks for your continous effort, I'll give your b
Update: I was able to get the rt2x00_usb driver to work[1][2]. I ended up
simply forcing a call to unblock_time_handler() before ever running the
linux scheduler. The driver can associate to networks (at least mine) and
serve the test page when run under the test scenario, and it can download
the "
I was able to re-factor the usb emulation to prevent re-entrant scheduling.
However, now I encounter some timer-related issues that I struggle with for
not understanding the lx_emul/lx_kit's handling of linux ticks and timing
(nor am I an expert in how native Linux does this, it seems to be quite
i
> I stumpled across those issues as well ([1], [2]), sorry for not bringing
> […]
[1]
https://github.com/cnuke/genode-world/commits/ath9k_driver_support-2023-03-15
[2] https://github.com/cnuke/genode/commits/ath9k_driver_support-2023-03-15
--
Josef Söntgen
Genode Labs
http://www.genode-labs.co
Hi Colin,
> >> out why. For that I will take a closer look at your USB back-end work
> >> and its integration into the kernel.
> >>
> >
> I have done some investigation into this (see [1]), there is a simple issue
> and a harder issue.
> The simple issue is that for ath9k all control transfers we
I got my hands on a rt2800usb device. Mine differs slightly in which
vendor/product it shows (it's sold by Belkin) and in which firmware it
requests (rt2870.bin), but I suppose the issues will be similar.
Josef wrote:
> So far the RT2800USB driver is non-working and the next step is figuring
>> o
Josef,
> […] Admittedly I was also thinking of some unusual scenarios, such as
> > multiple wifi adapters where it makes sense to have one supplicant and
> > multiple drivers. But that's strange enough maybe it doesn't need to
> > be supported.
>
> At least from my perspective I would rather treat
Hello Colin,
> Good to hear. Was this done with the changes I made to the supplicant
> interface? I'm curious if those break the existing wifi functionality,
> which I can't test other than to say it compiles successfully.
No, in this case I simply enabled the driver in the vanilla
'pc_wifi_drv'
Hi Josef,
I added the ath9k driver [0] to the 'pc_wifi_drv' driver where it worked
> fine in my limited testing (with the one device I have at hand and the
> GSI/MSI quick-fix).
>
Good to hear. Was this done with the changes I made to the supplicant
interface? I'm curious if those break the exist
Hello Colin,
I added the ath9k driver [0] to the 'pc_wifi_drv' driver where it worked
fine in my limited testing (with the one device I have at hand and the
GSI/MSI quick-fix).
[0] https://github.com/cnuke/genode/commits/pc_wifi_drv-ath9k-2023-01-15
I also started to look at your commits in more
Hi Josef:
On Mon, Jan 9, 2023 at 5:48 AM Josef Söntgen
wrote:
> Hello Colin,
>
> I am glad you managed to get your USB wifi dongle working.
>
Thanks! It was a fun project.
> I only briefly skimmed your commit series but I think it would be
> worthwhile to integrate your additions. As we want
Hello Colin,
I am glad you managed to get your USB wifi dongle working.
>If anyone has the hardware (Atheros 9K chipsets are in
>common/inexpensive usb wifi radios) and wants to try it out I would be
>excited to hear if it works for you.
I do not own such a device and since it was easier to acqu
Hi Colin,
your posting made my day!
> Inspired by the recent changes to the Genode driver system, I took
> another crack a porting the Linux ath9k usb wifi driver.
Thank you very much for the nice feedback about Sculpt 22.10 and for
sharing your work about the USB-Wifi driver. It is great to s
24 matches
Mail list logo
