On 09/03/2021 18:27, Holger Hoffstätte wrote:
On 2021-03-07 17:18, Eric Valette wrote:
I have the following systematic crash at boot since 5.10.20 (.19 was ok)
This laptop has two graphic cards:
03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI]
Navi 14 [Radeon RX 5500/5500M
I have the following systematic crash at boot since 5.10.20 (.19 was ok)
This laptop has two graphic cards:
03:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi
14 [Radeon RX 5500/5500M / Pro 5500M] (rev c1)
07:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AM
On 3/25/18 11:39 PM, Eric Valette wrote:
On 3/25/18 11:07 PM, Eric Valette wrote:
Since a few kernels I get this error when streaming video to TV via
minidlna:
Checked it started with at least 4.14.25. My older kern.log.2.gz file
says before first march I did not get this error. But I
On 3/25/18 11:07 PM, Eric Valette wrote:
Since a few kernels I get this error when streaming video to TV via
minidlna:
Checked it started with at least 4.14.25. My older kern.log.2.gz file
says before first march I did not get this error. But I removed older
kernels from my /boot directory
40 78 72 13 89 de 45 85 db b8 02 00 00 00 5b 0f 45 d0 e9
[ 9308.859846] RIP: tcp_push+0x70/0xeb RSP: c900016b3bc0
[ 9308.859848] CR2: 0078
[ 9308.859851] ---[ end trace 4fc2992bf2697a64 ]---
root@nas2:~#
--
__
/ ` Eric Valette
/-- __
On 12/10/2017 19:57, Shuah Khan wrote:
On Thu, Oct 12, 2017 at 11:52 AM, Eric Valette wrote:
Hi,
Just compiled a fresh 4.9.55, with same .config, same user space than 4.9.54
and discovered I had no network because ifup fails because dhcp cleint
fails. As everything is identical, 4.9.54 still
Hi,
Just compiled a fresh 4.9.55, with same .config, same user space than
4.9.54 and discovered I had no network because ifup fails because dhcp
cleint fails. As everything is identical, 4.9.54 still works, I guess
one patch in net/core/... did break something.
ifup eth0
Internet Systems Con
I have a NAS system that does supend itslef when rx/tx counts drops
below a level meaning no activity...
The last working kernel was 3.14.58, any thing longterm after that
refuse to freeze after a while with:
[ 9692.905439] ehci-pci :00:1d.0: remove, state 1
[ 9692.905448] usb usb4: USB
Hi,
I have a nas build around a dedicated NAS enclosure and a classical
mini-atx zotac Intel board. Was using happily 3.14.x (x=36) and sleepd
to automatically suspend to ram when Eth traffic was down for 15 mins
and wakeonLan mechanism for resume.
As 3.18 has been declared longterm, I switched t
On 01/07/2013 20:40, Eric Valette wrote:
Hi,
After hunting an unreproducible bug, I decided to run memtest86+ and
found that only 8 byte of memory refuse to write the last two digit on
the last 4GB memory stick.
Memory is at 0x31db357558
So I decided to add a memmap=4K@0x00031db35000
Hi,
After hunting an unreproducible bug, I decided to run memtest86+ and
found that only 8 byte of memory refuse to write the last two digit on
the last 4GB memory stick.
Memory is at 0x31db357558
So I decided to add a memmap=4K@0x00031db35000 boot options in
GRUB_CMDLINE_LINUX. But ch
On 04/04/2013 09:03 PM, Eric Valette wrote:
I fixed this already.
https://git.kernel.org/cgit/linux/kernel/git/jgarzik/libata-dev.git/commit/?h=upstream-fixes&id=8e725c7f8a60feaa88edacd4dee2c754d5ae7706
Thanks for the support. I will apply the patch manually and wait for 3.8.6
Jus
On 04/04/2013 22:45, David Woodhouse wrote:
> On Thu, 2013-04-04 at 21:44 +0200, Borislav Petkov wrote:
>>> ahci :00:1f.2: DMA-API: device driver maps memory fromstack
>>> [addr=88040df2da50]
> I fixed this already.
>
> https://git.kernel.org/cgit/linux/kernel/git/jgarzik/libata-dev.git/co
Hi,
When booting a brand new machine freshly installed I notice in the dmesg
output always the same worrying trace:
PS copy me I'm not subscribed.
ata2.00: ATA-9: Samsung SSD 840 Series, DXT07B0Q, max UDMA/133
ata2.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[
Rob Hussey wrote:
> On 9/15/07, ポール・ロラン Paul Rolland <[EMAIL PROTECTED]> wrote:
>
>> Hi Eric,
>>
>> On Sat, 15 Sep 2007 20:30:14 +0200
>> Eric Valette <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Rob Hussey wrote:
>
Johannes Berg wrote:
> On Sa, 2007-09-15 at 21:00 +0200, Eric Valette wrote:
>
>
>> I came to this conclusion too. But I would have preferred to have
>> #define subsys_exit(fn) modules_exit(fn)
>>
>> in the case of a modu
Paul Rolland (ポール・ロラン) wrote:
> Hi Eric,
>> Now I have two side questions:
>> - the code is no more symetric "subsys_initcall" -> "module_exit".
>> Do not know if it is "normal" but I love symmetry in code :-). Did not test
>> it still works as a module...
> Symmetry is not broken, as we have
Rob Hussey wrote:
> On 9/15/07, Eric Valette <[EMAIL PROTECTED]> wrote:
>> Eric Valette wrote:
>>
>>> I can probably take a picture of the backtrace if you want.
>> Just saw that just above my message in the LKML web interface, someone
>> posted a backtra
Eric Valette wrote:
> I can probably take a picture of the backtrace if you want.
Just saw that just above my message in the LKML web interface, someone
posted a backtrace. Mine is different but at least, we are at least two
to have the crash.
-- eric
-
To unsubscribe from this list: send
First let me start by a thanks: it was the last piece of my P5W de luxe
machine based that has not its driver from stock kernel.
It works like a charm when used as a module:
lsusb
Bus 005 Device 001: ID :
Bus 003 Device 001: ID :
Bus 004 Device 001: ID :
Bus 002 Device 001
20 matches
Mail list logo
