Fedora41: Libreoffice crash on PDF export

Hi, Running Fedora41 with all RPM updates to date, and with KDE on X11. A recent update to libreoffice has done two things: 1. On exporting a "*.odt" file using the toolbar "Export to PDF" button, libreoffice will often crash. Not first time after you load the documen

Re: /var/spool/abrt/ccpp-* crash informations not created after debuginfo package installed

via users < > users@lists.fedoraproject.org> wrote: > > > On my Fedora 40 x86_64 system named (ISC BIND daemon) crashes at start. > > There is active abrtd, and it after systemd-coredump action create > > some information about crash in /var/spool/abrt/ccpp--mm-dd-*

Re: /var/spool/abrt/ccpp-* crash informations not created after debuginfo package installed

On Sat, 10 Aug 2024 22:01:41 +0200 Franta Hanzlík via users wrote: > On my Fedora 40 x86_64 system named (ISC BIND daemon) crashes at start. > There is active abrtd, and it after systemd-coredump action create > some information about crash in /var/spool/abrt/ccpp--mm-dd-* >

Re: /var/spool/abrt/ccpp-* crash informations not created after debuginfo package installed

4 system named (ISC BIND daemon) crashes at start. > There is active abrtd, and it after systemd-coredump action create > some information about crash in /var/spool/abrt/ccpp--mm-dd-* > directory. I wanted to see some details about the crash, so I installed > the debug package (# dnf in

/var/spool/abrt/ccpp-* crash informations not created after debuginfo package installed

On my Fedora 40 x86_64 system named (ISC BIND daemon) crashes at start. There is active abrtd, and it after systemd-coredump action create some information about crash in /var/spool/abrt/ccpp--mm-dd-* directory. I wanted to see some details about the crash, so I installed the debug package

Re: gthumb crash on startup and bugzilla reporting

On Tuesday, February 28, 2023 4:24:03 PM EDT Jerry James wrote: > On Tue, Feb 28, 2023 at 7:46 AM Max Pyziur wrote: > > --- Running analyze_BodhiUpdates --- > > Looking for similar problems in bugzilla > > fatal: RPC failed at server. The API key you specified is invalid. Please > > check that yo

Re: gthumb crash on startup and bugzilla reporting

On Tue, Feb 28, 2023 at 7:46 AM Max Pyziur wrote: > I occasionally forget to shutdown gthumb before shutting down my pc. > > On startup of the PC, I see a message indicating that gthumb crashed and > asking whether or not I want to report the bug. > > (This is more of a nuisance; I can always star

gthumb crash on startup and bugzilla reporting

Greetings, I occasionally forget to shutdown gthumb before shutting down my pc. On startup of the PC, I see a message indicating that gthumb crashed and asking whether or not I want to report the bug. (This is more of a nuisance; I can always start gthumb, and it works very well.) I click

Re: 6.0.16-200.fc36.x86_64 crash

On 1/6/23 18:13, Ulf Volmer wrote: On 06.01.23 23:03, stan via users wrote: On Fri, 6 Jan 2023 14:57:53 -0500 Roger Wells wrote: I boot from the latest kernel (subject) then mount a shared directory on a RHEL 7.9 host. As soon as I access any file or directory on the shared directory the my

Re: Launching Nautilus makes F37 'hard crash'

On 09/01/2023 14:46, Ron Yorston wrote: Frederic Muller wrote: This is happening with the latest 2 kernel versions (just updated and the same is happening). I thought I wouldn't be the only one and the bug would magically disappear... well it seems not. It's probably this: https://bugzilla

Re: Launching Nautilus makes F37 'hard crash'

Frederic Muller wrote: >This is happening with the latest 2 kernel versions (just updated and >the same is happening). I thought I wouldn't be the only one and the bug >would magically disappear... well it seems not. It's probably this: https://bugzilla.kernel.org/show_bug.cgi?id=216895 The

Launching Nautilus makes F37 'hard crash'

Hi! This is happening with the latest 2 kernel versions (just updated and the same is happening). I thought I wouldn't be the only one and the bug would magically disappear... well it seems not. Has anyone experience this? On my side it's happening 100% of the time, starting with previous k

Re: 6.0.16-200.fc36.x86_64 crash

On 06.01.23 23:03, stan via users wrote: On Fri, 6 Jan 2023 14:57:53 -0500 Roger Wells wrote: I boot from the latest kernel (subject) then mount a shared directory on a RHEL 7.9 host. As soon as I access any file or directory on the shared directory the my machine instantly & completely freeze

Re: 6.0.16-200.fc36.x86_64 crash

On Fri, 6 Jan 2023 14:57:53 -0500 Roger Wells wrote: > I boot from the latest kernel (subject) then mount a shared directory > on a RHEL 7.9 host. > As soon as I access any file or directory on the shared directory the > my machine instantly & completely freezes. > Even the clock on the top bar s

6.0.16-200.fc36.x86_64 crash

I boot from the latest kernel (subject) then mount a shared directory on a RHEL 7.9 host. As soon as I access any file or directory on the shared directory the my machine instantly & completely freezes. Even the clock on the top bar stops, cursor stops blinking, and other pc's cannot ping this o

Kernel crash due to bad disk?

the disk that is related to this particular host's data that is triggering this. When it happens, there is a segfault message on the console, but nothing related to it in the logs. There are bits from the kernel about being unable to write prior to the crash, however: Aug 1 12:24:32 m

Re: Kernel crash every day at 6:30am

#x27;s still a legit kernel crash. aops:ext4_da_aops ino:bca118c dentry name:"rsyslog.log" flags: 0x17c0060010(lru|mappedtodisk|reclaim|node=0|zone=2|lastcpupid=0x1f) raw: 0017c0060010 e613d17e0208 e613d17e00c8 8e452d1070d0 raw: 02fd3d40 000

Re: Kernel crash every day at 6:30am

d. I've since removed the huge log file and disabled the log entry in rsyslog.conf, so I'll now continue to watch it, but it's still a legit kernel crash. aops:ext4_da_aops ino:bca118c dentry name:"rsyslog.log" flags: 0x17c0060010(lru|mappedtodisk|reclaim|node=0|z

Re: Kernel crash every day at 6:30am

Hi, > >> Here's a bit of the kernel message from dmesg > >> [ cut here ] > >> WARNING: CPU: 4 PID: 633983 at kernel/exit.c:739 do_exit+0x37/0xa90 > >> general protection fault, probably for non-canonical address > >> 0xcc2a8cfcb62a56a1: [#1] SMP PTI > >> CPU: 4 PID: 63

Re: Kernel crash every day at 6:30am

Gordon Messmer writes: On 2/12/22 14:59, Alex wrote: Here's a bit of the kernel message from dmesg [ cut here ] WARNING: CPU: 4 PID: 633983 at kernel/exit.c:739 do_exit+0x37/0xa90 general protection fault, probably for non-canonical address 0xcc2a8cfcb62a56a1: [#1]

Re: Kernel crash every day at 6:30am

On Sun, 13 Feb 2022 10:41:36 -0800 Gordon Messmer wrote: > bio_crypt_clone suggests something wrong in an encrypted block device.  > Maybe corrupt data that rsync traverses during the backup? Perhaps run the same rsync command with a -v option in a terminal and see if the crash happens

Re: Kernel crash every day at 6:30am

On 2/12/22 14:59, Alex wrote: Here's a bit of the kernel message from dmesg [ cut here ] WARNING: CPU: 4 PID: 633983 at kernel/exit.c:739 do_exit+0x37/0xa90 general protection fault, probably for non-canonical address 0xcc2a8cfcb62a56a1: [#1] SMP PTI CPU: 4 PID: 63398

Re: Kernel crash every day at 6:30am

cess causing it. Yes, there is an automated backup using rsync around that time, but there should be no userland process that could ever cause a kernel crash. CPU: 4 PID: 633983 Comm: rsync Not tainted 5.14.18-200.fc34.x86_64 #1 Thanks, Alex

Re: Kernel crash every day at 6:30am

On 2/12/22 15:59, Alex wrote: Anyone else experiencing similar problems with the latest kernels? The fact that it happens at the same time every day makes me wonder if there's some job that's in process causing it. ___ users mailing list -- users@l

Kernel crash every day at 6:30am

Hi, I have a fedora34 system that I'm using as a mail server, and for the past few weeks, it's had a kernel crash at 6:30am every morning. Sometimes it results in the server going catatonic and unresponsive, and other times it just seems to report the kernel crash and continue running.

Re: Messages following a crash: [Hardware Error]: event severity: fatal

out the slots and then blew out the slots with air, and made sure to tightly seat and screw in the cards, and that fixed my crash that had been going on for many months (before I happened to be looking at dmesg for something else and found the MCE error that decoded to the PCI bus, mine is an AMD

Re: Messages following a crash: [Hardware Error]: event severity: fatal

[Hardware Error]: 0c00: I understand that this is related to the preceding crash. If so, what does it tell me? Doing a search suggests that if this happens rarely then it can be ignored- true?.\ I now see that I had it also last O

Re: Messages following a crash: [Hardware Error]: event severity: fatal

: [Hardware Error]:   :   ... continue until Jan 11 19:28:54 e7 kernel: [Hardware Error]:   0c00:   I understand that this is related to the preceding crash. If so, what does it tell

Re: Messages following a crash: [Hardware Error]: event severity: fatal

0 >> ... continue until >> Jan 11 19:28:54 e7 kernel: [Hardware Error]: 0c00: >> >> >> I understand that this is related to the preceding crash. If so, what does >> it tell me?

Re: Messages following a crash: [Hardware Error]: event severity: fatal

> ... continue until > Jan 11 19:28:54 e7 kernel: [Hardware Error]: 0c00: > .... > > I understand that this is related to the preceding crash. If so, what does > it tell me? > > Doing a search suggests

Re: Messages following a crash: [Hardware Error]: event severity: fatal

Error]: : > > ... continue until > Jan 11 19:28:54 e7 kernel: [Hardware Error]: 0c00: > .... > > I understand that this is related to the preceding crash. If so, what does it &g

Messages following a crash: [Hardware Error]: event severity: fatal

I understand that this is related to the preceding crash. If so, what does it tell me? Doing a search suggests that if this happens rarely then it can be ignored- true?.\ I now see that I had it also last Oct but not earlier. This hard lock-up happens at times (more than

Re: messages from F33 crash

On Thu, 6 Jan 2022, Roger Heflin wrote: well, if you plug in a usb device and that happens that indicates the hardware completely reset. To me, the weird thing was that there was no device, just the cable. If it was just a kernel crash then the machine would have stayed hung until you reset

Re: messages from F33 crash

well, if you plug in a usb device and that happens that indicates the hardware completely reset. If it was just a kernel crash then the machine would have stayed hung until you reset/power cycled it. It would have to be it crashed because of the usb device being plugged in, and it would have to

Re: messages from F33 crash

On Thu, 6 Jan 2022, stan via users wrote: On Thu, 6 Jan 2022 16:17:07 -0600 (CST) Michael Hennebry wrote: Where does F33 keep the messages from the last system crash? If they were captured, I think one of the places they would be is the journal. journalctl -r will read the journal from the

Re: messages from F33 crash

On 1/6/22 14:25, stan via users wrote: On Thu, 6 Jan 2022 16:17:07 -0600 (CST) Michael Hennebry wrote: Where does F33 keep the messages from the last system crash? If they were captured, I think one of the places they would be is the journal. journalctl -r will read the journal from the end

Re: messages from F33 crash

On Thu, 6 Jan 2022 16:17:07 -0600 (CST) Michael Hennebry wrote: > Where does F33 keep the messages from the last system crash? > If they were captured, I think one of the places they would be is the journal. journalctl -r will read the journal from the end towards the beginning. You wil

messages from F33 crash

Where does F33 keep the messages from the last system crash? -- Michael henne...@web.cs.ndsu.nodak.edu "Sorry but your password must contain an uppercase letter, a number, a haiku, a gang sign, a heiroglyph, and the blood of a v

Re: F35 - yet another kernel crash

number if you have rebooted since the incident. I piped that to a file which is 9.4MB.  Is that what I should attach to the bug report? No, the point was for you to take a look and see if there was an obvious reason for the crash. It should either be the last thing in the log or near the end de

Re: F35 - yet another kernel crash

On 12/31/21 15:32, Samuel Sieb wrote: On 12/31/21 08:57, Robert Moskowitz wrote: I was downloading some mp4 lectures in Firefox and getting ready to respond to the save to dialog when the system hung hard requiring a power cycle.  Couple not even switch to a non-graphic session to login as r

Re: F35 - yet another kernel crash

On 12/31/21 08:57, Robert Moskowitz wrote: I was downloading some mp4 lectures in Firefox and getting ready to respond to the save to dialog when the system hung hard requiring a power cycle.  Couple not even switch to a non-graphic session to login as root. I had just done a dnf update that

Re: F35 - yet another kernel crash

On Fri, 31 Dec 2021 12:31:44 -0500 Robert Moskowitz wrote: > So it seems not to be my problem? I guess not. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduc

Re: F35 - yet another kernel crash

On 12/31/21 12:23, Tom Horsley wrote: On Fri, 31 Dec 2021 12:14:23 -0500 Robert Moskowitz wrote: How do I know if I am using nouveau and then how to switch to nvidia? Run: lspci | fgrep VGA 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8330]

Re: F35 - yet another kernel crash

On Fri, 31 Dec 2021 12:14:23 -0500 Robert Moskowitz wrote: > How do I know if I am using nouveau and then how to switch to nvidia? Run: lspci | fgrep VGA if that mentions an NVIDIA video card, then fedora will have used the nouveau drivers by default. You could also run lsmod and see if it ment

Re: F35 - yet another kernel crash

On 12/31/21 12:10, Tom Horsley wrote: If you are using the nouveau video drivers, try switching to the rpmfusion nvidia drivers. Every new release I try to use the nouveau drivers, and within a couple of weeks, I always get crashes like this, almost always when using a browser. So I switch to n

Re: F35 - yet another kernel crash

If you are using the nouveau video drivers, try switching to the rpmfusion nvidia drivers. Every new release I try to use the nouveau drivers, and within a couple of weeks, I always get crashes like this, almost always when using a browser. So I switch to nvidia, and the crashes stop. _

F35 - yet another kernel crash

I was downloading some mp4 lectures in Firefox and getting ready to respond to the save to dialog when the system hung hard requiring a power cycle.  Couple not even switch to a non-graphic session to login as root. I had just done a dnf update that installed the new 5.15.11 kernel (was runni

Re: Problem reporting/Mate Screensaver crash/Packagekit crash. No answer ?

On 9/26/21 6:10 AM, Ger van Dijck wrote: Quite right this is a type error !  In the application when I choose Applications /System Tools /Problem Reporting the URL is spelled correctly .  What now ? Has it something to do with Bugzilla ?  I think it is very important to report problems so t

Re: Problem reporting/Mate Screensaver crash/Packagekit crash. No answer ?

On 9/21/21 11:59 AM, Ger van Dijck wrote: When I want to do a Problem Reporting ( Bugzilla ? ) I get the message : https://retrace.fedoraproject .org does not excist ( server error 404 ). Well of course it doesn't. There's a space before the final .org that makes it into an invalid url. Hay

Re: Problem reporting/Mate Screensaver crash/Packagekit crash. No answer ?

On 9/21/21 11:59 AM, Ger van Dijck wrote: When I want to do a Problem Reporting ( Bugzilla ? ) I get the message : https://retrace.fedoraproject .org does not excist ( server error 404 ). Well of course it doesn't. There's a space before the final .org that makes it into an invalid url.

Problem reporting/Mate Screensaver crash/Packagekit crash. No answer ?

To all , When I activate the screensaver I get the message " Mate-Screensaver quit unexpectedly". Application crsh Package-Kit : The same message. When this happens ( after a delay of ca. 5 minutes ) I get a blue screen and have to turn off the cumputer by force ; So tturn hardware OFF. W

Problem reporting / Mate-Screensaver crash / Packagekit crach.

To all, When I activate the screesaver I get the message : Mate-Screensaver quit unexpectedly : Application crash, Packagekit idem : Application crash . When this happens ( after a delay of 5 minutes ) I get a blue screen and have to turn off the system by force , so hardware OFF. When

Re: Desktop crash during a `dnf upgrade`, will this be a problem now?

On 3/31/21 11:30 PM, Qiyu Yan wrote: Just now during a routine update using `dnf update` my desktop process gnome-shell crashed. Afterwards, I checked dnf history and /var/log/dnf.log to see if any inconsistency is present. dnf.log didn't report the last transaction as completed, but `dnf histor

Desktop crash during a `dnf upgrade`, will this be a problem now?

Hi! folks, Just now during a routine update using `dnf update` my desktop process gnome-shell crashed. Afterwards, I checked dnf history and /var/log/dnf.log to see if any inconsistency is present. dnf.log didn't report the last transaction as completed, but `dnf history info last` report the act

Re: nvme crash

nt 1 is a more solid lead than comment 2, because comment 2 is > > a > > value that is based on what? A guess? Reading the rest of the > > thread, > > it's still uncertain. > > > > > > > For the second time this disk stopped working (first was abo

Re: nvme crash

could not be reset, the machine was powered off/on. I think (not sure) that last time I just hit the reset button but it did not boot. The machine was booted (after dnf update) around 8pm, and crashed at 4am. Following the earlier crash a serial console was set up which is how I can see the fai

Re: nvme crash

but it did not boot. The machine was booted (after dnf update) around 8pm, and crashed at 4am. Following the earlier crash a serial console was set up which is how I can see the failure messages. == nvme related messages [    7.488638] nvme nvme0: pci function :06:00.0 [    7.536593

Re: nvme crash

tton but it did not > boot. > > The machine was booted (after dnf update) around 8pm, and crashed at 4am. > > Following the earlier crash a serial console was set up which is how I can > see the failure messages. > > == nvme related messages > [7.488638] nvme nvme0: pci fun

nvme crash

was booted (after dnf update) around 8pm, and crashed at 4am. Following the earlier crash a serial console was set up which is how I can see the failure messages. == nvme related messages [7.488638] nvme nvme0: pci function :06:00.0 [7.536593] nvme nvme0: allocated 32 MiB host memory

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

a Fedora problem. Btw, I tried oracle's > > jdk-14.0.2_linux-x64_bin.rpm and had the same result. > > > > > > I filed a bug report: > > https://bugzilla.redhat.com/show_bug.cgi?id=1877524 > > > > Why does everyone seem to think this is a Java bug? &g

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

> https://bugzilla.redhat.com/show_bug.cgi?id=1877524 > > Why does everyone seem to think this is a Java bug? My system generated crash report (including a core dump) that identified a segfault in the Java runtime. A Java process is started by JGR(). JavaGD() seems to start another

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

> I filed a bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1877524 > > Why does everyone seem to think this is a Java bug? The system log > showed that a crash occurred in Rf_eval (libR.so + 0x157ab3); i.e., in > the R library. The stack trace shows a lot of calls to these > functions: >

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

eem to think this is a Java bug? The system log showed that a crash occurred in Rf_eval (libR.so + 0x157ab3); i.e., in the R library. The stack trace shows a lot of calls to these functions: bcEval forcePromise getvar R_execClosure Rf_appyClosure Rf_eval It's possible that R is being h

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

On Wed, 9 Sep 2020 15:52:26 -0300 "George N. White III" wrote: > On Wed, 9 Sep 2020 at 13:33, Ranjan Maitra wrote: > > > Thanks, I will file the bug report: should it be upstream or on Fedora? I > > know about Fedora's BZ, but what is upstream? > > > > Ranjan > > > > I tried to reproduce the pr

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

On Wed, 9 Sep 2020 at 13:33, Ranjan Maitra wrote: > Thanks, I will file the bug report: should it be upstream or on Fedora? I > know about Fedora's BZ, but what is upstream? > > Ranjan > I tried to reproduce the problem on Ubuntu 20.04. Using wayland the fonts in the JGR window are so tiny I ca

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

.0-openjdk-devel > > > > > > > > > > then: > > > > > > > > > > sudo R > > > > > install.packages(c('JGR','Deducer')) > > > > > q() > > > > > > > > > > Not

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

he first one is from rstudio.com. Also, the installation > > function > > > > may ask for more libraries to be installed. > > > > > > > > Once installed, go to R and inside R, type: > > > > > > > > library(JGR) > > > >

Re: (With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

graphical interface with a jaguar > logo > > > (pretty cool). All is well. In the bottom window type: > > > data(cars) > > > > > > Then go to the graphical interface above, and under "Plots" -> "Quick" > -> > > > "simpl

(With updated info) Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

ce above, and under "Plots" -> "Quick" -> > > "simple boxplot" > > This opens a window, and put speed as x variable and run. > > A window begins to open and the entire window system running JGR comes > > crashing down. > > > > Bt

Re: Figuring out reason behind java crash on F32 (not on Muck/Windoze)

On Tue, 8 Sep 2020 at 18:34, Ranjan Maitra wrote: > Dear friends, > > I have a strange situation that shows up only on F32 (only linux > distributions tried) but does not show up on Windoze or Muck. The way to > illustrate this is rather complicated, so I will first summarize. > > For my introduc

Figuring out reason behind java crash on F32 (not on Muck/Windoze)

Dear friends, I have a strange situation that shows up only on F32 (only linux distributions tried) but does not show up on Windoze or Muck. The way to illustrate this is rather complicated, so I will first summarize. For my introductory students, I use a java-based front-end to R called Deduce

Re: repeatable usb crash [CLOSED]

On 2020-06-29 11:19, fed...@eyal.emu.id.au wrote: On 2020-06-27 15:45, Samuel Sieb wrote: On 6/26/20 9:59 PM, fed...@eyal.emu.id.au wrote: The problem happens reliably on 5.6.13. Boot single user. unmount filesystems other than root. Manage from a serial console. New computer (Gigabyte Z390 UD

Re: repeatable usb crash [CLOSED, UNRESOLVED]

On 2020-06-27 15:45, Samuel Sieb wrote: On 6/26/20 9:59 PM, fed...@eyal.emu.id.au wrote: The problem happens reliably on 5.6.13. Boot single user. unmount filesystems other than root. Manage from a serial console. New computer (Gigabyte Z390 UD, Intel Core i7-9700)  f30    5.6.13-100.fc30  

Re: repeatable usb crash [CLOSED, UNRESOLVED]

On 6/26/20 9:59 PM, fed...@eyal.emu.id.au wrote: The problem happens reliably on 5.6.13. Boot single user. unmount filesystems other than root. Manage from a serial console. New computer (Gigabyte Z390 UD, Intel Core i7-9700) f30    5.6.13-100.fc30    problem reproduces f30    5.6.11-

Re: repeatable usb crash [CLOSED, UNRESOLVED]

did it again, to check that the crash is related to the SD card, with same result. - The card reader is regularly used and never had any problem. - The same card reader and SD card then worked just fine on another machine. The SD card is the only new item here, acquired recently and maybe used for

Re: repeatable usb crash

On 2020-06-27 04:25, Samuel Sieb wrote: On 6/26/20 10:01 AM, Roger Heflin wrote: What kind of usb card is it?  You may want to google the specific card on linux and/or test other cards of different types. It was an SD card.  I have seen various bug reports about the newer categories, which, f

Re: repeatable usb crash

On 2020-06-27 03:01, Roger Heflin wrote: What kind of usb card is it? You may want to google the specific card on linux and/or test other cards of different types. The card reader is probably this https://www.ebay.com.au/itm/-/122393457372 and the SD card is probably this http

Re: repeatable usb crash

All of that depends on where the usb device locks up/crashes at. If the usb card reader locks up/crashes when it is attempting to use the usb bus then no one else can use it since it may stop functioning while applying a signal to the bus. This happens every so often on SAS, fiber channel, and scs

Re: repeatable usb crash

On 6/26/20 10:01 AM, Roger Heflin wrote: What kind of usb card is it? You may want to google the specific card on linux and/or test other cards of different types. It was an SD card. I have seen various bug reports about the newer categories, which, from the given logs, appears to be the cas

Re: repeatable usb crash

What kind of usb card is it? You may want to google the specific card on linux and/or test other cards of different types. And do lsusb and see if you can find the reader model, the bugs are specific to the readers and MB makers may pick whatever they have used before or whatever is cheapest, so

Re: repeatable usb crash

On Fri, 26 Jun 2020 at 08:21, wrote: > On 2020-06-26 20:40, George N. White III wrote: > > On Fri, 26 Jun 2020 at 04:56, fed...@eyal.emu.id.au>> wrote: > > > > On 2020-06-26 16:22, Samuel Sieb wrote: > > > On 6/24/20 11:36 PM, fed...@eyal.emu.id.au fed...@eyal.emu.id.au> wrote: > >

Re: repeatable usb crash

On 2020-06-26 20:40, George N. White III wrote: On Fri, 26 Jun 2020 at 04:56, mailto:fed...@eyal.emu.id.au>> wrote: On 2020-06-26 16:22, Samuel Sieb wrote: > On 6/24/20 11:36 PM, fed...@eyal.emu.id.au wrote: >> Jun 23 18:06:17 e7 kernel: usb 2-7: Dis

Re: repeatable usb crash

On Fri, 26 Jun 2020 at 04:56, wrote: > On 2020-06-26 16:22, Samuel Sieb wrote: > > On 6/24/20 11:36 PM, fed...@eyal.emu.id.au wrote: > >> Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U1 > failed. > >> Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U2 > failed.

Re: repeatable usb crash

On 6/26/20 12:56 AM, fed...@eyal.emu.id.au wrote: On 2020-06-26 16:22, Samuel Sieb wrote: I suggest upgrading the system because there is likely a kernel fix for the initial trigger that caused the whole problem.  And possibly a dvb fix as well to avoid the oops.  I second the suggestion of tes

Re: repeatable usb crash

On 2020-06-26 16:22, Samuel Sieb wrote: On 6/24/20 11:36 PM, fed...@eyal.emu.id.au wrote: Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U1 failed. Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U2 failed. There is some issue with handling the SD card modes.

Re: repeatable usb crash

the system up properly. (*1) I did it again, to check that the crash is related to the SD card, with same result. - The card reader is regularly used and never had any problem. - The same card reader and SD card then worked just fine on another machine. The SD card is the only new item here

Re: repeatable usb crash

On 6/24/20 11:36 PM, fed...@eyal.emu.id.au wrote: Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U1 failed. Jun 23 18:06:17 e7 kernel: usb 2-7: Disable of device-initiated U2 failed. There is some issue with handling the SD card modes. Jun 23 18:06:23 e7 kernel: xhci_hcd :

Re: repeatable usb crash

There are a number of different SD card readers, each of their drivers have unique issues. With one specific card I had my laptop reader failed to read the card at all, but when put on a different linux machine it worked fine. That was an issue because the specific SD card lied about voltages it

Re: repeatable usb crash

On 2020-06-25 17:39, Ed Greshko wrote: On 2020-06-25 15:32, Qiyu Yan wrote: That is mysterious, since a normal reset won't fix, I guess this have something to do with both your BIOS/UEFI and kernel. That is to say, BIOS/UEFI gives wrong information to kernel and crashed a kernel driver. And t

Re: repeatable usb crash

On 2020-06-25 17:36, Qiyu Yan wrote: And the problem may be with the USB device itself, maybe a malformed response to your computer, and can you try to do a reset but unplug the card reader? First I unplugged the SD card, then I unplugged the card reader, finally I reset the machine. If sys

Re: repeatable usb crash

On 2020-06-25 15:32, Qiyu Yan wrote: > That is mysterious, since a normal reset won't fix, I guess this have > something to do with both your BIOS/UEFI and kernel. > > That is to say, BIOS/UEFI gives wrong information to kernel and crashed a > kernel driver. And the kernel thinks the oops is fat

Re: repeatable usb crash

And the problem may be with the USB device itself, maybe a malformed response to your computer, and can you try to do a reset but unplug the card reader? If system boots, the problem can have nothing to do with BIOS/UEFI but can be your specific card reader and motherboard related. __

Re: repeatable usb crash

That is mysterious, since a normal reset won't fix, I guess this have something to do with both your BIOS/UEFI and kernel. That is to say, BIOS/UEFI gives wrong information to kernel and crashed a kernel driver. And the kernel thinks the oops is fatal and panicked. I don't know the reason, but

repeatable usb crash

console 4 - I attempt to shut down mythtv at this point the machine totally crashes. No magic sysrq response. Pressing the reset button caused a boot into grub, looping with errors. A full power off/on brought the system up properly. (*1) I did it again, to check that the crash is related to the

Re: Looking for doc on kernel crash dump handling.

How one configured crash dumps had not significantly changed in a long time (from what I know). If the hardware gets a significant hardware error and does not deliver an NMI to the os, but does force a hw reset, then you won't get a crashdump. On Thu, Feb 27, 2020 at 7:54 PM George R Goff

Re: Looking for doc on kernel crash dump handling.

On Fri, 2020-02-28 at 01:53 +, George R Goffe via users wrote: > Hi, > > I'm trying to help shoot a possible kernel bug which may create a dump. I'm > trying to find doc on how to enable the crashdump "features" of my FC33 > (Rawhide) system. > > tldp.org seems to be out of date > docs.fedo

Looking for doc on kernel crash dump handling.

Hi, I'm trying to help shoot a possible kernel bug which may create a dump. I'm trying to find doc on how to enable the crashdump "features" of my FC33 (Rawhide) system. tldp.org seems to be out of date docs.fedoraproject.org doesn't seem to have a search facility... Can anyone give me a hint

Re: last sometimes posts crash on reboot

On Wed, 4 Dec 2019 13:44:42 +0530 Vikram Goyal wrote: > Hi, > > I am facing a peculiar issue where a system reboot sometimes & not > always posts a crash in last output. > > root pts/0Wed Dec 4 11:47 still logged in > reboot system boot Wed Dec

last sometimes posts crash on reboot

Hi, I am facing a peculiar issue where a system reboot sometimes & not always posts a crash in last output. root pts/0Wed Dec 4 11:47 still logged in reboot system boot Wed Dec 4 11:30 - 11:57 (00:26) root pts/0Tue Dec 3 18:14 - crash (17:16) reboot sy

Re: Fedora 28 "crash"

On Sun, Sep 16, 2018 at 11:41 AM Bob Goodwin wrote: > On 09/16/18 09:28, Richard Shaw wrote: > > > I agree, smartctl should be on the live image. I know the idea is to keep > the ISO size down but it makes the live media useless as a diagnostic > utility so I usually end up keeping System Rescue

  1   2   3   4   5   >