Am Montag, dem 07.04.2025 um 21:10 +0200 schrieb André Apitzsch:
> Am Montag, dem 10.03.2025 um 23:35 +0100 schrieb André Apitzsch:
> > Hi Sakari,
> >
> > Am Montag, dem 10.03.2025 um 11:11 + schrieb Sakari Ailus:
> > > Hi André,
> > >
> > > On Sat, Mar 08, 2025 at 10:47:54PM +0100, André Api
Am Montag, dem 10.03.2025 um 23:35 +0100 schrieb André Apitzsch:
> Hi Sakari,
>
> Am Montag, dem 10.03.2025 um 11:11 + schrieb Sakari Ailus:
> > Hi André,
> >
> > On Sat, Mar 08, 2025 at 10:47:54PM +0100, André Apitzsch via B4
> > Relay
> > wrote:
> > > The imx214 driver currently supports on
On Wed, Dec 16, 2020 at 03:03:55AM +0100, Andrew Lunn wrote:
> > > From what you are saying, it sounds like from software you cannot
> > > independently control the GPIO controller reset?
> >
> > No. The hardware implements the default MAC reset behavior. So the
> > GPIO controller gets reset sync
> > From what you are saying, it sounds like from software you cannot
> > independently control the GPIO controller reset?
>
> No. The hardware implements the default MAC reset behavior. So the
> GPIO controller gets reset synchronously with the MAC reset and that
> can't be changed.
Is there pin
On Tue, Dec 15, 2020 at 02:58:37PM +0100, Andrew Lunn wrote:
> > > > Anyway the hardware setup depicted above doesn't seem
> > > > problematic at the first glance, but in fact it is. See, the DW *MAC
> > > > driver
> > > > (STMMAC ethernet driver) is doing the MAC reset each time it performs
> >
> > > Anyway the hardware setup depicted above doesn't seem
> > > problematic at the first glance, but in fact it is. See, the DW *MAC
> > > driver
> > > (STMMAC ethernet driver) is doing the MAC reset each time it performs the
> > > device open or resume by means of the call-chain:
> > >
> > >
Hello Andrew,
On Mon, Dec 14, 2020 at 04:31:43PM +0100, Andrew Lunn wrote:
> On Mon, Dec 14, 2020 at 12:25:16PM +0300, Serge Semin wrote:
> > Hello folks,
> >
> > I've got a problem, which has been blowing by head up for more than three
> > weeks now, and I'm desperately need your help in that ma
Hello Alexandre,
Thanks for the response. My comments are below.
On Mon, Dec 14, 2020 at 11:52:14AM +0100, Alexandre Torgue wrote:
> Hi Serge,
>
> Sorry I never used GPIO provided by DWMAC IP. Obviously, I think is to late
> for you to use GPIOs provided by your SoC directly. Unfortunately, it
On Mon, Dec 14, 2020 at 12:25:16PM +0300, Serge Semin wrote:
> Hello folks,
>
> I've got a problem, which has been blowing by head up for more than three
> weeks now, and I'm desperately need your help in that matter. See our
> Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
>
Hi Serge,
Sorry I never used GPIO provided by DWMAC IP. Obviously, I think is to
late for you to use GPIOs provided by your SoC directly. Unfortunately,
it seems to be a "perfect" chicken and eggs problem :(.
Do you have possibilty to "play" with gpio setting. I mean change
configuration of
Hello folks,
I've got a problem, which has been blowing by head up for more than three
weeks now, and I'm desperately need your help in that matter. See our
Baikal-T1 SoC is created with two DW GMAC v3.73a IP-cores. Each core
has been synthesized with two GPIOs: one as GPI and another as GPO. Ther
+ nouv...@lists.freedesktop.org
On Wed, Dec 02, 2020 at 10:32:57AM +, Capek Pavel wrote:
> Dear kernel maintainers,
>
> After upgrading Fedora from 31 to 32 I try to deal with frequent and
> substantial slowing down of the OS. The computer does not react at random
> when I move a mouse or I
From: Marc Kleine-Budde
[ Upstream commit 4ba1cb39fce4464151517a37ce0ac0a1a3f580d6 ]
The firmware on the original USB2CAN by Geschwister Schneider Technologie
Entwicklungs- und Vertriebs UG exchanges all data between the host and the
device in host byte order. This is done with the struct
gs_hos
From: Marc Kleine-Budde
[ Upstream commit 4ba1cb39fce4464151517a37ce0ac0a1a3f580d6 ]
The firmware on the original USB2CAN by Geschwister Schneider Technologie
Entwicklungs- und Vertriebs UG exchanges all data between the host and the
device in host byte order. This is done with the struct
gs_hos
From: Marc Kleine-Budde
[ Upstream commit 4ba1cb39fce4464151517a37ce0ac0a1a3f580d6 ]
The firmware on the original USB2CAN by Geschwister Schneider Technologie
Entwicklungs- und Vertriebs UG exchanges all data between the host and the
device in host byte order. This is done with the struct
gs_hos
From: Marc Kleine-Budde
[ Upstream commit 4ba1cb39fce4464151517a37ce0ac0a1a3f580d6 ]
The firmware on the original USB2CAN by Geschwister Schneider Technologie
Entwicklungs- und Vertriebs UG exchanges all data between the host and the
device in host byte order. This is done with the struct
gs_hos
From: Marc Kleine-Budde
[ Upstream commit 4ba1cb39fce4464151517a37ce0ac0a1a3f580d6 ]
The firmware on the original USB2CAN by Geschwister Schneider Technologie
Entwicklungs- und Vertriebs UG exchanges all data between the host and the
device in host byte order. This is done with the struct
gs_hos
On Thu, 2020-10-22 at 15:59 +0200, Christophe Leroy wrote:
> Hi,
>
> Runnning ./scripts/checkpatch.pl -g HEAD, I get the following error:
>
> Global symbol "$gitroot" requires explicit package name at
> ./scripts/checkpatch.pl line 980.
> Execution of ./scripts/checkpatch.pl aborted due to compi
Hi,
Runnning ./scripts/checkpatch.pl -g HEAD, I get the following error:
Global symbol "$gitroot" requires explicit package name at
./scripts/checkpatch.pl line 980.
Execution of ./scripts/checkpatch.pl aborted due to compilation errors.
Reverting commit f5f613259f3f ("checkpatch: allow not us
> On 26. Jun 2020, at 18:13, David Laight wrote:
>
> From: Xin Long
>> Sent: 23 June 2020 11:14
It looks like a bug to me. Testing with this test app here, I can see
the INIT_ACK being sent with a bunch of ipv4 addresses in it and
that's unexpected for a v6only socket. As is, it's
From: Xin Long
> Sent: 23 June 2020 11:14
> > > It looks like a bug to me. Testing with this test app here, I can see
> > > the INIT_ACK being sent with a bunch of ipv4 addresses in it and
> > > that's unexpected for a v6only socket. As is, it's the server saying
> > > "I'm available at these other
inyard wrote:
>>>>>>>>>>
>>>>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
>>>>>>>>>>> wrote:
22 June 2020 19:33
> >>>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> >>>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >>>>>>>>
> >>>>>>>> On Mon, Jun 22, 202
at 08:01:24PM +0200, Michael Tuexen wrote:
> > > > > >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > > > > >>>
> > > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > > > >>&g
t;>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>>>>>>>>
>>>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
>>&
> >>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >>>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> I've stu
9:33
>>>> On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
>>>>>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>>>>>>
>>>>>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>>>> On
; > > > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > > > >
> > > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> > > > >> wrote:
&
t;> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>>>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>>>>
>>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>>>>>> sctp
; > > > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> > > >>>
> > > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create
> > >
wrote:
> > > > >>>
> > > > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> > > > >>>> wrote:
> > > > >>&
g wrote:
> > > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard
> > > >>>> wrote:
> > > >>>>>
> > > >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I
> > > >>&g
ichael Tuexen wrote:
> > >>> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> > >>>
> > >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> > >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> > >>
t;> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> > >>>
> > >>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> > >>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> > >
t;>>
> >>> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>>>
> >>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> &
>>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>>>
>>>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>>>>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
>>>&g
On Mon, Jun 22, 2020 at 08:01:24PM +0200, Michael Tuexen wrote:
> > On 22. Jun 2020, at 18:57, Corey Minyard wrote:
> >
> > On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> >> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >>>
> >
> On 22. Jun 2020, at 18:57, Corey Minyard wrote:
>
> On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
>> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>>
>>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>&
On Mon, Jun 22, 2020 at 08:01:23PM +0800, Xin Long wrote:
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
> >
> > I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> > sctp listening socket on :: and set the IPV6_V6ONLY socket optio
> On 22. Jun 2020, at 14:01, Xin Long wrote:
>
> On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>>
>> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
>> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
&
On Sun, Jun 21, 2020 at 11:56 PM Corey Minyard wrote:
>
> I've stumbled upon a strange problem with SCTP and IPv6. If I create an
> sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
> then I make a connection to it using ::1, the connection will drop af
I've stumbled upon a strange problem with SCTP and IPv6. If I create an
sctp listening socket on :: and set the IPV6_V6ONLY socket option on it,
then I make a connection to it using ::1, the connection will drop after
2.5 seconds with an ECONNRESET error.
It only happens on SCTP, it doesn&#
From: Larry Finger
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did
From: Larry Finger
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did
From: Larry Finger
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did
From: Larry Finger
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43lega
From: Larry Finger
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did
From: Larry Finger
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43lega
From: Larry Finger
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43lega
From: Larry Finger
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did
From: Larry Finger
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43lega
From: Larry Finger
commit 75d057bda1fbca6ade21378aa45db712e5f7d962 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43 did
From: Larry Finger
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43lega
From: Larry Finger
commit 6a29d134c04a8acebb7a95251acea7ad7abba106 upstream.
Since the driver was first introduced into the kernel, it has only
handled the ciphers associated with WEP, WPA, and WPA2. It fails with
WPA3 even though mac80211 can handle those additional ciphers in software,
b43lega
From: Kevin Barnett
[ Upstream commit 5b083b305b49f65269b85455b8c0cf1a52e4 ]
Obtain the unique IDs from the RLL and RPL instead of VPD page 83h.
Link:
https://lore.kernel.org/r/157048751833.11757.11996314786914610803.stgit@brunhilda
Reviewed-by: Scott Benesh
Reviewed-by: Scott Teel
Signe
On Thu, Oct 03, 2019 at 01:25:09PM -0700, Stephen Boyd wrote:
> Quoting Hans de Goede (2019-10-03 13:20:24)
> >
> > The best solution I can come up with is adding a new
> > platform_get_irq_byname_optional mirroring platform_get_irq_optional
> > and using that in drivers such as the dwc3 driver.
>
Quoting Hans de Goede (2019-10-03 13:20:24)
>
> The best solution I can come up with is adding a new
> platform_get_irq_byname_optional mirroring platform_get_irq_optional
> and using that in drivers such as the dwc3 driver.
>
> Does anyone have a better suggestion?
>
A byname_optional API soun
Hi all,
I've been debugging a new error printed with 5.4-rc1:
[ 25.570893] dwc3 dwc3.0.auto: IRQ peripheral not found
This is caused by the "driver core: platform: Add an error message to
platform_get_irq*()"
commit.
The dwc3 driver first tries to get the IRQ by 2 different names before fal
This patch series fixes problem with recovering Vybrid's NXP DSPI
controller state after master transmission distortion.
It was tested with a setup where /dev/spidevX.Y devices were used in
a loopback mode (provided by proper HW connections). During this test
the distortion was introduced an
This patch series fixes problem with recovering Vybrid's NXP DSPI
controller state after master transmission distortion.
It was tested with a setup where /dev/spidevX.Y devices were used in
a loopback mode (provided by proper HW connections). During this test
the distortion was introduced an
Hi,
I'm plagued with Ubuntu (currently eoan but was the same previously)
with regard to vfat filesystem timezone.
uname -a gives
Linux lola 5.2.0-8-lowlatency #9-Ubuntu SMP PREEMPT Mon Jul 8 13:49:06 UTC 2019
x86_64 x86_64 x86_64 GNU/Linux
The documentation states that mount option tz=UTC is
On Tue, May 21, 2019 at 09:51:33AM -0700, Alexander Duyck wrote:
> I think we need to narrow this down a bit more. Let's try forcing the
> lookup table all to one value and see if traffic is still going to
> queue 0.
>
> Specifically what we need to is run the following command to try and
> force
On Tue, May 21, 2019 at 8:15 AM Lennart Sorensen
wrote:
>
> On Fri, May 17, 2019 at 03:20:02PM -0700, Alexander Duyck wrote:
> > I was hoping it would work too. It seemed like it should have been the
> > answer since it definitely didn't seem right. Now it has me wondering
> > about some of the ot
On Fri, May 17, 2019 at 03:20:02PM -0700, Alexander Duyck wrote:
> I was hoping it would work too. It seemed like it should have been the
> answer since it definitely didn't seem right. Now it has me wondering
> about some of the other code in the driver.
>
> By any chance have you run anything li
On Mon, May 13, 2019 at 9:55 AM Lennart Sorensen
wrote:
>
> On Fri, May 03, 2019 at 04:59:35PM -0400, Lennart Sorensen wrote:
> > On Fri, May 03, 2019 at 10:19:47AM -0700, Alexander Duyck wrote:
> > > The TCP flow could be bypassing RSS and may be using ATR to decide
> > > where the Rx packets are
On Fri, May 3, 2019 at 8:14 AM Lennart Sorensen
wrote:
>
> On Thu, May 02, 2019 at 01:59:46PM -0700, Alexander Duyck wrote:
> > If I recall correctly RSS is only using something like the lower 9
> > bits (indirection table size of 512) of the resultant hash on the
> > X722, even fewer if you have
On Sun, Dec 16, 2018 at 12:02:49PM +0100, Rafał Miłecki wrote:
> OK, if you say so, I'll try not to panic seeing those errors repeating
> over and over.
Yes, patience is the key :-)
> I know such issues may take months or years to get fixed, so I was
> trying to do some hacking on my own. I'll tr
On Sun, 16 Dec 2018 at 11:44, Borislav Petkov wrote:
> On Sun, Dec 16, 2018 at 11:26:29AM +0100, Rafał Miłecki wrote:
> > Debugging CPU errors.
>
> I told you that this issue is being worked on and there will be a fix
> of sorts at some point. Don't try any funky business of downgrading the
> micr
On Sun, Dec 16, 2018 at 11:26:29AM +0100, Rafał Miłecki wrote:
> Debugging CPU errors.
I told you that this issue is being worked on and there will be a fix
of sorts at some point. Don't try any funky business of downgrading the
microcode and maybe break your boxes in the process. Just ignore the
On Sun, 16 Dec 2018 at 11:06, Borislav Petkov wrote:
> > For my hack tests I'd like to replace my 0x0810100b with a 0x08101007.
>
> Why would you even want to downgrade the microcode?!
Debugging CPU errors. I have two notebooks:
1) HP EliteBook 745 G5 with Ryzen 5 PRO 2500U
It runs 1.03.01 BIOS
On Sun, Dec 16, 2018 at 09:08:00AM +0100, Rafał Miłecki wrote:
> Thanks! I had no idea microcode_amd_fam17h.bin is a container with few
> microcodes. I thought there is a single microcode for a whole family
> (e.g. 17h).
It is a container for all F17h - you're simply making the wrong
assumption th
On 16.12.2018 01:05, Borislav Petkov wrote:
On Sun, Dec 16, 2018 at 12:46:05AM +0100, Rafał Miłecki wrote:
[19.736770] microcode: [find_equiv_id] sig:8458000
That's your CPU's family/model/stepping: 0x0810f10
[19.736772] microcode: [find_equiv_id] equiv_table->installed_cpu:8392466
[19.73677
On Sun, Dec 16, 2018 at 12:46:05AM +0100, Rafał Miłecki wrote:
> I'm trying to reload AMD Ryzen Mobile (fam17h) microcode doing:
> echo 1 > /sys/devices/system/cpu/microcode/reload
Also, I'd advise against using the late loading method but put the
microcode in the initrd (which your distro should
On Sun, Dec 16, 2018 at 12:46:05AM +0100, Rafał Miłecki wrote:
> [19.736770] microcode: [find_equiv_id] sig:8458000
That's your CPU's family/model/stepping: 0x0810f10
> [19.736772] microcode: [find_equiv_id] equiv_table->installed_cpu:8392466
> [19.736775] microcode: [find_equiv_id] equiv_table->
Hi,
I'm trying to reload AMD Ryzen Mobile (fam17h) microcode doing:
echo 1 > /sys/devices/system/cpu/microcode/reload
The problem is I don't get any feedback. No error for the "echo"
command, no a single new line in the "dmesg". I have no idea if
microcode has been reloaded or not.
I did a quick
4.9-stable review patch. If anyone has any objections, please let me know.
--
[ Upstream commit 0e490657c7214cce33fbca3d88227298c5c968ae ]
The vif->idx value is always 0 for two interfaces.
wl->vif_num = 0;
loop {
...
vif->idx = wl->vif_num;
...
wl->vif_nu
From: Aditya Shankar
[ Upstream commit 0e490657c7214cce33fbca3d88227298c5c968ae ]
The vif->idx value is always 0 for two interfaces.
wl->vif_num = 0;
loop {
...
vif->idx = wl->vif_num;
...
wl->vif_num = i;
i++;
...
}
At present, vif->idx is assigned t
I have a XFX Radeon 580 4GB installed on X58 chipset.
I have only been able to get it to work on Linux 4.18.x and 4.19.x by
using the amdgpu.dc=0 kernel boot parameter.
It works up to the 4.17.19 kernel but the console font comes out shitty,
pixelated and unreadable and it will not display w
On Mon, Jul 23, 2018 at 02:28:16PM +0200, Fabio Coatti wrote:
> Hi, any hope to see this backported to 4.17.X as well? Just to avoid to
> revert that commit at every new release :)
You can send the patch to stable@.
Hi, any hope to see this backported to 4.17.X as well? Just to avoid to
revert that commit at every new release :)
Many thanks!
Il giorno gio 5 lug 2018 alle ore 21:31 Christoph Hellwig ha
scritto:
> On Mon, Jul 02, 2018 at 08:23:00PM +0200, Fabio Coatti wrote:
> > Yep, it does. I issued a
> >
On Mon, Jul 02, 2018 at 08:23:00PM +0200, Fabio Coatti wrote:
> Yep, it does. I issued a
> git revert d657c5c73ca987214a6f9436e435b34fc60f332a
> on mainline (4.18-rc3) and recompiled, the card works just fine.
Thanks for confirming. I'll end the revert to Linus this week.
On Monday 2 July 2018 15:19:51 CEST Christoph Hellwig wrote:
> > By reverting this commit the card works again, tested in 4.17.3 . I've
> > noticed that the corresponding amd commit (
> > b468620f2a1dfdcfddfd6fa54367b8bcc1b51248) has been reverted in linus tree
> > (e16c4790de39dc861b749674c2a93195
> By reverting this commit the card works again, tested in 4.17.3 . I've
> noticed
> that the corresponding amd commit ( b468620f2a1dfdcfddfd6fa54367b8bcc1b51248)
> has been reverted in linus tree (e16c4790de39dc861b749674c2a9319507f6f64f),
> and 4.16.X stable tree iirc, but the intel one has n
Hi all,
since kernel 4.17 my laptop fails to enable wireless card (04:00.0 Network
controller: Intel Corporation Wireless 8260 (rev 3a) )
with this error:
Jul 01 09:34:36 hobbes kernel: iwlwifi: probe of :04:00.0 failed with error
-12
I bisected the issue to this result:
d657c5c73ca987214a
On Tue, May 08, 2018 at 07:15:06AM -0700, Dave Hansen wrote:
> Thanks for the excellent bug report!
>
> On 05/08/2018 02:37 AM, Thadeu Lima de Souza Cascardo wrote:
> > 2) The bad address is next to do_syscall_64 on the host.
>
> So a host address leaked into a guest oops?
>
> We should bring th
Thanks for the excellent bug report!
On 05/08/2018 02:37 AM, Thadeu Lima de Souza Cascardo wrote:
> 2) The bad address is next to do_syscall_64 on the host.
So a host address leaked into a guest oops?
We should bring the KVM folks into this and probably also need to widen
the cc list quite a bit
When running a 4.15 kernel on top of 4.17-rc3, I noticed a problem on the guest:
[4.836637] BUG: unable to handle kernel NULL pointer dereference at
[4.839290] IP: 0x8a00147e
[4.840300] PGD 0 P4D 0
[4.840510] Oops: [#1] SMP PTI
[4.840510] Modules
t;
>> This time the result of 'trace-cmd report' is so large I do not include
>> it here, but I attach the trace.dat file. Not sure why but the timing of
>> sending the NMI to the backtrace print is different (but content the
>> same AFIK) so in the odd change it can
Hi Vincent,
On 2018-04-26 17:27:24 +0200, Vincent Guittot wrote:
> Hi Niklas,
>
> >> Thanks for the trace, I have been able to catch a problem with it.
> >> Could you test the patch below to confirm that the problem is solved ?
> >> The patch apply on-top
Hi Niklas,
>> Thanks for the trace, I have been able to catch a problem with it.
>> Could you test the patch below to confirm that the problem is solved ?
>> The patch apply on-top of
>> c18bb396d3d261eb ("Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git
b396d3d261eb ("Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net").
> >
> > This time the result of 'trace-cmd report' is so large I do not include
> > it here, but I attach the trace.dat file. Not sure why but the timing of
> > sen
On Thu, Apr 26, 2018 at 12:31:33PM +0200, Vincent Guittot wrote:
> From: Vincent Guittot
> Date: Thu, 26 Apr 2018 12:19:32 +0200
> Subject: [PATCH] sched/fair: fix the update of blocked load when newly idle
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding:
trace.dat file. Not sure why but the timing of
> sending the NMI to the backtrace print is different (but content the
> same AFIK) so in the odd change it can help figure this out:
>
Thanks for the trace, I have been able to catch a problem with it.
Could you test the patch below to c
Hi Niklas,
Le Monday 23 Apr 2018 à 00:18:27 (+0200), Niklas Söderlund a écrit :
> Hi Vincent,
>
> On 2018-04-20 18:00:13 +0200, Vincent Guittot wrote:
>
> [snip]
>
> > >
> > > You results are similar to Heiner's ones. The problem is still there
> > > even if we only kick ilb which mainly send
On Fri, Apr 20, 2018 at 9:00 AM, Vincent Guittot
wrote:
[..]
>
> Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
>> Hi Niklas,
>>
>> On 13 April 2018 at 00:39, Niklas Söderlund
>> wrote:
>> > Hi Vincent,
>> >
>> > Thanks for helping trying to figure this out.
>> >
>> > On 20
Hi Heiner and Niklas,
Le Saturday 14 Apr 2018 à 13:24:20 (+0200), Vincent Guittot a écrit :
> Hi Niklas,
>
> On 13 April 2018 at 00:39, Niklas Söderlund
> wrote:
> > Hi Vincent,
> >
> > Thanks for helping trying to figure this out.
> >
> > On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote:
> >
't do it in any
>> > > other way, I'm happy to try other methods if you got some ideas. The
>> > > symptom of the issue is a complete hang of the system for more then 30
>> > > seconds and then this information is printed in the console:
>> >
>> &g
Hi Niklas,
On 13 April 2018 at 00:39, Niklas Söderlund
wrote:
> Hi Vincent,
>
> Thanks for helping trying to figure this out.
>
> On 2018-04-12 15:30:31 +0200, Vincent Guittot wrote:
>
> [snip]
>
>>
>> I'd like to narrow the problem a bit more with the 2 patchies aboves. Can
>> you try
>> them s
th patches, with both of them the issue still occurs. However,
> on top of linux-next from yesterday I have the impression that it happens
> less frequent with the second patch.
> On top of the commit mentioned by you I don't see a change in system behavior
> with either patch.
Th
e issue is a complete hang of the system for more then 30
> > > seconds and then this information is printed in the console:
> >
> > Heiner (edded cc) also reported similar problem with his platform: a
> > dual core celeron
> >
> > Do you confirm that your p
1 - 100 of 1779 matches
Mail list logo
