Well devices being added to the driver won't add overhead by itself.
Adding new Realtek devices usually looks like:
[RTL_GIGA_MAC_VER_31] = {"RTL8168dp/8111dp"},
[RTL_GIGA_MAC_VER_51] = {"RTL8168ep/8111ep"},
static void rtl8168dp_driver_start(struct rtl8169_private *tp)
{
On 11/9/22 21:27, Rod Webster wrote:
Alec, the RT8169 hardware may be ok but the same driver is used for a host
of other hardware and it does not work as well. The RT8168-dkms driver
covers some of them and can be used to replace the RT8169.
https://packages.debian.org/buster/r8168-dkms. Read the
Alec, the RT8169 hardware may be ok but the same driver is used for a host
of other hardware and it does not work as well. The RT8168-dkms driver
covers some of them and can be used to replace the RT8169.
https://packages.debian.org/buster/r8168-dkms. Read the notes on the repo
page
I had the RT816
Andy, I seem to remember an earlier post where Seb said he had technical
issues or bad hardware or lost keys preventing a Bullseye buildbot. I can't
find it, sorry.
Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au
On Thu, 10 Nov 2022 at 11:13, andy
Rod,
RTAI Debian packages exist for Bullseye, I packaged them myself. RTAI will
never and has never been deployed in upstream Debian. I have an r8169 NIC and
don't have any issues with network latency. 5.4 kernel debs would also work for
Bookworm but it takes 5+ minutes to reach my desktop scre
On Thu, 10 Nov 2022 at 00:14, Rod Webster wrote:
> It's not useful to have RTAI in Bullseye as we don't have any debs for that
> platform.
Well, this comes back to a question I asked some time ago (which did not
get a single reply (30th Oct 18:15 GMT timestamp)). What _should_ we be
releasing 2
It's not useful to have RTAI in Bullseye as we don't have any debs for that
platform. It needs to target Bookworm so it is deployed to the Debian repos.
Also, on the topic of kernels, there is a significant issue with the 5.x
and 6.x kernels in Debian which have excessive network latency
mostly/po
On Wed, 9 Nov 2022 at 21:38, Alec Ari via Emc-developers <
emc-developers@lists.sourceforge.net> wrote:
> Since there's been great progress with RTAI developments, can RTAI Debian
> package support for Bullseye be a milestone before 2.9.0 makes it's initial
> stable release?
I would like to see
Since there's been great progress with RTAI developments, can RTAI Debian
package support for Bullseye be a milestone before 2.9.0 makes it's initial
stable release? I was hoping to have PREEMPT_RT and RTAI work together with the
5.4 kernel so one LinuxCNC package will work on all, but I don't t
Master is wide open now, things commited to master create conflicts in 2.9.
So as soon as master or 2.9 moves then the problem comes to the surface.
Sent from my Galaxy
Original message
From: Hans Unzner
Date: 2022-11-09 12:12 a.m. (GMT-08:00)
To: EMC developers
Subject: R
As the dev that must approve the request, you can send a comment:
This looks like it needs to go in master too, "can you make another pull that
cherrypicks or commits this to master"
Or if you are so inclined you could take this on for your self.
So rather then you as the dev, having to figur
Package: linuxcnc-uspace
Severity: wishlist
I have just uploaded the following non-maintainer upload to fix the
build errors on arm and hppa blocking migration to testing.
--- linuxcnc-2.9.0~pre0+git20221105.ffb6bda926/debian/changelog 2022-11-06
03:48:00.0 +0100
+++ linuxcnc-2.9.0~pre
I updated the NMU to handle an extra HPPA CPU string found on a build
daemon. This is the updated patch.
--- linuxcnc-2.9.0~pre0+git20221105.ffb6bda926/debian/changelog 2022-11-06
03:48:00.0 +0100
+++ linuxcnc-2.9.0~pre0+git20221105.ffb6bda926-nmu/debian/changelog
2022-11-08 22:39
On Tue, 8 Nov 2022 at 10:06, andy pugh wrote:
>
> One result of this is that at the moment the builbot is probably _not_
> building 2.9 debs any more. I don't think that I can fix this.
>
This was a false alarm. The buildbot does attempt to build 2.9 debs, but
it fails.
http://buildbot.linuxcn
On Wed, 9 Nov 2022 at 01:49, Chris Morley
wrote:
> But it really doesn't make sense.
> That is my point.
>
So, we get a pull-request for a bug fix in 2.8.
Who now decides whether it needs to be cherry-picked into 2.9 and 2.10? And
who does that?
--
atp
"A motorcycle is a bicycle with a pandem
I would say the "degree of making sense" depends on how much the branches
are diverged. Currently I think it makes much sense, because 2.9 and master
are (almost) identical and the bug fixes for 2.9 are 100% applicable for
master.
Am Mi., 9. Nov. 2022 um 02:49 Uhr schrieb Chris Morley <
chrisinnan
16 matches
Mail list logo
