@non_space OK, so remove that option save/reboot and check it’s back to [deep]…
1 Like
This morning brought a new kernel option, 6.13.7 . . . rebooted into it and it provided revival service one time, but not a second time.
Seems like (from memory) the 6.13.5 provided 4 display revivals but not the 5th, so far that is likely the best function of the 6.13x series.
Reposting from the bug report . . . languishing in bugzilla oblivion:
Again posting that my other linux installs are “catching up” to the kernel iterations in TW . . . and working to revive the old machine from suspending, whereas in TW the last reliable kernel remains 6.12.6 . . . .
Today Sid is running 6.12.16-amd64 and has revived numerous times in this brief morning.
Is this totally a “kernel” problem?? Perhaps, perhaps not . . . zypper is not able to discern what works to keep this system functioning at a basic level.
Next stop . . . the Factory list-serve??? Searching for light while stumbling in darkness . . . friends, countrymen, lend me thine ears.
The Factory mailing list is not a bug tracker, bug reporting tool, or support avenue.
1 Like
i don’t think many are following this monologue-styled never-ending topic, but zypper is a package manager - not its job to handle regressions or hardware quirks.
3 Likes
Thanks for letting me know, that could have been embarrassing, but this must be a new thing. In the “old” days, if a thread wasn’t getting any insights or solutions from the support forum, or from the bug report . . . then folks seemed to post the issue on the Factory list-serve and would often get expert insight and advice on the problem . . . . Guess those days are over?
This is kind of an interesting comment from a mod . . . the thread is droning on, because there has been no insight or especially solution to the problem from the support forum OR the bug report filed on it.
The machine was running TW just fine, until the 2082 package upgrade was run through, then immediately after that, no revival of the display. Comments on the thread were “the hardware is too old,” but before the major package upgrade, the problem, having happened numerous times when the machine was “younger” . . . the solution was found in moving up the kernel to the bleeding edge kernel, via Backports.
This time Takashi says, “It’s not the kernel, the problem is complicated.” And that was it. So, then the comments were, “You should be embarrassed to be trying to run TW on such an old machine.” But, the point is, it was running, just fine, and then after a zypper dup and a fair number since . . . it was not.
Now, my 6 other linux installs on the same machine are catching up in the kernel department, and . . . the old machine runs fine. So, is this earth-shattering in importance, obviously not; but the problem keeps happening, particularly in my openSUSE installs . . . for ever-changing reasons, each time taking time to simply regain basic function . . . .
And, “not many are following the monologue” . . . except it has had apparently “1.6K views” . . . . It would be very simple, if, after the dup the system completely broke, black screen, blinking cursor . . . then we might say, “machine is too old, TW is done.” But, TW boots and runs fine . . . until suspended . . . so there is intermittent function.
Why is it intermittent and not totally dysfunctional if it is a hardware problem, rather than the more likely software problem??
It’s going to be more actively moderated, yes. The Factory mailing list is for development discussion, and the more off-topic stuff that happens there, the more the developers and maintainers just tune it out, because the Signal:Noise ratio is too high.
I’m one of them. The only reason I do actually pay attention to the Factory ML is because I’m a moderator, and I kind of have to.
(From this point forward “you” is the generic “you”, not referring to the OP.)
That being said, the openSUSE Project is not providing any sort of SLA, or even promising support of anything, and developers and maintainers are under no “obligation” to provide end user support, much less to provide it in a fashion the End User judges as “timely and appropriate”. But that’s true of pretty close to every non-commercial Linux Distribution that I’m aware of.
Yep, it sucks when you’ve got a problem, and you’re not getting answers in the places that are specifically set up to provide those answers. It’s damned frustrating, and I’ve been there myself. But that also doesn’t make it OK to do excessive cross-posting, or to go into communication channels (Factory-ML, #factory on Matrix, etc) to try and get those answers, when that’s not what those communication channels are there for.
It’s a bit rude, frankly.
If it were just a case of the odd End User question on the Factory-ML, that would be one thing, but the list has become a catch all for everything. End User Support, random ranting, axe grinding and bike shedding, and is pretty much killing it’s utility, based on it’s stated purpose.
1 Like
Tumbleweed upgrades perfectly on older Hardware: 60°C Idle Temperature on freshly installed Leap-15.4 KDE on a Lenovo Thinkpad W530 Notebook.
root: ~
# inxi -zFmy222
System: Kernel: 6.13.7-1-default arch: x86_64 bits: 64
Console: pty pts/1 Distro: openSUSE Tumbleweed 20250324
Machine: Type: Laptop System: LENOVO product: 2447K70 v: ThinkPad W530 serial: <filter>
Mobo: LENOVO model: 2447K70 serial: <filter> UEFI: LENOVO v: G5ET96WW (2.56 ) date: 11/27/2013
Battery: ID-1: BAT0 charge: 67.1 Wh (98.4%) condition: 68.2/93.6 Wh (72.9%)
Memory: System RAM: total: 32 GiB available: 31.17 GiB used: 1.27 GiB (4.1%) igpu: 64 MiB
Array-1: capacity: 32 GiB slots: 4 modules: 4 EC: None
Device-1: ChannelA-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
Device-2: ChannelA-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
Device-3: ChannelB-DIMM0 type: DDR3 size: 8 GiB speed: 1600 MT/s
Device-4: ChannelB-DIMM1 type: DDR3 size: 8 GiB speed: 1600 MT/s
CPU: Info: quad core model: Intel Core i7-3740QM bits: 64 type: MT MCP cache: L2: 1024 KiB
Speed (MHz): avg: 1200 min/max: 1200/3700 cores: 1: 1200 2: 1200 3: 1200 4: 1200 5: 1200 6: 1200 7: 1200 8: 1200
Graphics: Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: kernel
Device-2: Bison ThinkPad Integrated Camera driver: uvcvideo type: USB
Display: unspecified server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.6 driver: X: loaded: modesetting unloaded: vesa dri: crocus gpu: i915 tty: 236x54 resolution: 1600x900
API: EGL v: 1.5 drivers: crocus,swrast platforms: gbm,surfaceless,device
API: OpenGL v: 4.5 compat-v: 4.2 vendor: mesa v: 25.0.2 note: console (EGL sourced) renderer: Mesa Intel HD Graphics 4000 (IVB GT2), llvmpipe (LLVM 19.1.7 256 bits)
API: Vulkan v: 1.4.309 drivers: N/A surfaces: N/A
Info: Tools: api: eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdpyinfo, xprop, xrandr
Audio: Device-1: Intel 7 Series/C216 Family High Definition Audio driver: snd_hda_intel
API: ALSA v: k6.13.7-1-default status: kernel-api
Network: Device-1: Intel 82579LM Gigabit Network driver: e1000e
IF: enp0s25 state: down mac: <filter>
Device-2: Intel Centrino Advanced-N 6205 [Taylor Peak] driver: iwlwifi
IF: wlp3s0 state: up mac: <filter>
IF-ID-1: wwp0s20u4i6 state: down mac: <filter>
Drives: Local Storage: total: 465.76 GiB used: 74.83 GiB (16.1%)
ID-1: /dev/sda vendor: Samsung model: SSD 850 EVO 500GB size: 465.76 GiB
Partition: ID-1: / size: 231.56 GiB used: 74.8 GiB (32.3%) fs: btrfs dev: /dev/sda4
ID-2: /boot/efi size: 545 MiB used: 27.5 MiB (5.1%) fs: vfat dev: /dev/sda1
ID-3: /home size: 231.56 GiB used: 74.8 GiB (32.3%) fs: btrfs dev: /dev/sda4
ID-4: /opt size: 231.56 GiB used: 74.8 GiB (32.3%) fs: btrfs dev: /dev/sda4
ID-5: /var size: 231.56 GiB used: 74.8 GiB (32.3%) fs: btrfs dev: /dev/sda4
Swap: Alert: No swap data was found.
Sensors: System Temperatures: cpu: 48.0 C mobo: N/A
Fan Speeds (rpm): fan-1: 0
Info: Processes: 234 Uptime: 1d 13h 58m Init: systemd Shell: Bash inxi: 3.3.37
root: ~
#
You need to cope with changes. Some subtleties need to be observed.
When I look across my browser tabs in my various linux installs I see a comparatively large number of support posts and bug reports for openSUSE. That could be viewed two ways, the first, which I have been ignoring for some years is, it breaks, a lot. The second, which I have been using is that the support forums and bug reports actually get response and support with solutions to the problems, so there has historically been a benefit to the large effort involved in simply maintaining an OS. But there is a “signal to noise” ratio which at some point becomes more clear about which is which.
Thanks for your post, glad to hear that TW “runs fine on older hardware,” if you were to read back into the thread, you could see the posts that provided that insight on the problem.
I looked through your linked page. As I mentioned right above, TW runs fine, zypper dup runs through fine, except for the revival from suspend . . . which I suspect is related to the Nvidia 780 card . . . but that is the card that I am running.
I appreciate the comment about “subtleties” . . . the problem with subtleties is that they are often subtle, sometimes very subtle.
Some time back I did follow your guidance to set up the dup script, but the problem in my mind is that, when I want to shut down, I don’t know where in the script we are. So I run zypper in the GUI. For the 2082 packages I ran it in a TTY using screen . . . it ran through fine.
Someday perhaps my prince or princess will arrive??
@non_space Until the frog turns up with the same openSUSE Distribution and hardware I think you will be waiting… and waiting… and waiting… 
1 Like
Indeed, as you have said . . . but Karl says, “It’s not the Old, it’s all in knowing the subtleties . . . .” : - )
TW runs quite fine on 6.12.6, but then the question is, “What is the point of running TW with an ancient kernel?” : - 0
@non_space bisect the working kernel with the first one that doesn’t work…
2 Likes
OK, that sounds interesting . . . have to say that in kicking around the edges of linux since '07 I have never once seen any mention of “bisecting the kernel.”
Back in the PPC days where there were often problems even getting a distro to boot and run in the motorola based cpu system, there was talk of “compiling a kernel” which was seen as a way to get the kernel to match specifically with the hardware . . . . But, at that time even thinking about doing that was above my pay grade. Once Apple went to Intel, there were no problems to get an OS to boot/run. Now it boots runs fine until suspended.
I’m assuming that “bisecting” would be like some type of “merging” . . . but I would have no way of knowing how to run that in the console . . . . No background in doing that going back into my early days using ubuntu based flavors . . . no bisecting mentioned.
The last consistent kernel in TW is 6.12.6 . . . each of the kernels that failed to revive after that have been removed, so first question is, would 6.12.7 still be in the TW repos, or even the Slow Roll???
And then the question would be, does it have to be the “next” kernel after 6.12.6 . . . or could it be any of the 6.13.xxx series that for the most part have failed to bring the display back? The idea of bisecting being that somehow the working parts of 6.12.6 would be preserved, and the non-working parts of subsequent kernels would be eliminated??
Some introductory reading about the concept:
https://docs.kernel.org/admin-guide/bug-bisect.html
2 Likes
Interesting to see that 6.13.7 is running on your “old” hardware . . . seeing that it probably isn’t the age per se of the machine but the hardware; in my case I think the Nvidia card is involved in my sticky wicket.
I have a Manjaro install in my '12 Mac Pro, and on Manjaro I get consistent revival from their 6.13.-rt5-3 kernel, which is further up the chain than TWs 6.12.6; but I can’t get their 6.13.7-1 to revive consistently on the Mac Pro.
However, on another '12 Mac Mini i7 with onboard graphics I am running Manjaro 6.13.7 reviving consistently.
The other interesting item of note, in the Mac Pro Manjaro pacman update the other day I saw their mhwd-nvidia-570.133.07-2 was installed along with the 6.13.7 kernel upgrade, which Malcolm I think mentioned back at the beginning of the thread, but I either locked G05 in or locked G06 out, because G06 caused problems for my 780 card?
Anyway, difficult to follow all of the details, but suffice it to say that seemingly in the same machine, the kernels are tapping out, but at different points, in the machine with the Nvidia card, but in the machine running intel graphics it seems to be moving on up . . . in an old Mac machine. Have to check into the Manjaro viewpoint of the situation at some point, to see if there is a “why?” to it all.
@non_space Your card (Legacy GPU) is only supported with the 470 series…
1 Like
The ThinkPads indeed run with the Integrated Graphics and have Nvidia switched off:
root: ~
# inxi -Gy222
Graphics: Device-1: Intel 3rd Gen Core processor Graphics driver: i915 v: kernel
Device-2: Bison ThinkPad Integrated Camera driver: uvcvideo type: USB
Display: unspecified server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.6 driver: X: loaded: modesetting unloaded: vesa dri: crocus gpu: i915 tty: 236x54 resolution: 1600x900
API: EGL v: 1.5 drivers: crocus,swrast platforms: gbm,surfaceless,device
API: OpenGL v: 4.5 compat-v: 4.2 vendor: mesa v: 25.0.2 note: console (EGL sourced) renderer: Mesa Intel HD Graphics 4000 (IVB GT2), llvmpipe (LLVM 19.1.7 256 bits)
API: Vulkan v: 1.4.309 drivers: N/A surfaces: N/A
Info: Tools: api: eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdpyinfo, xprop, xrandr
root: ~
#
The benefit isn’t worth the hassle with the legacy hardware.
BTW: Infamous Host Erlangen uses both rolling software and rolling hardware:
CPU upgrade path: i4130 (z87) > 6700k (z170) > 3400g (b450)> 5600x (b450)> 5700g (b450,b550)
NVME SSD path: 950 Pro 512 GB > 970 EVO Plus 2TB > 990 EVO 2TB
RAM: 2x 16 GiB DDR4.
All of the previous components are still in use, except for the 5600x which I sold when replacing it with the 5700g.
1 Like
So when you say “Nvidia is switched off” what does that mean exactly? Not using proprietary drivers?? I haven’t used proprietary in some years, but is there some other way of “switching off” Nvidia, while using the card?
In my instance the display cables are plugged into the card, so the card is in some sense in use . . . via nouveau. I don’t know if my Mac Pro 5,1 has onboard graphics or not. I have a newer '20 Sys76 laptop that I can “switch graphics” in that has an Nvidia card . . . Pop_OS has historically laced “Nvidia” into their OS, so I can’t “get rid of it.”
I like the Nvidia hardware, the rendering of the display is crispy . . . but, seemingly the 780 is growing “old” and might be replaced. Would the system “recognize” the newer card, of whatever ilk that might be, as I had an '00 PowerMac that I upgraded the card in and the Ubuntu PPC 16??? system did not recognize it, I think I could get to a TTY?? Not sure, changing the card was not accepted by the system. So, would that mean needing to re-install all of my OSs to get a new card up and running??
PS: I went to the “Infamous Host” page and scanned thru it, I like KISS, however the “Rolling Hardware” at the bottom of the page just had that, no link to the rolling hardware data??? It just has the two words ???
~> sudo inxi -Gy222
[sudo] password for root:
Graphics: Device-1: NVIDIA GK110 [GeForce GTX 780] driver: nouveau v: kernel
Display: x11 server: X.org v: 1.21.1.15 with: Xwayland v: 24.1.6 driver: X: loaded: modesetting unloaded: vesa dri: nouveau gpu: nouveau tty: 80x24 resolution: 1280x1024
API: OpenGL Message: GL data unavailable in console for root.
API: EGL Message: EGL data unavailable in console, eglinfo missing.
Info: Tools: api: glxinfo de: kscreen-doctor x11: xprop,xrandr
The ThinkPads have a switch in UEFI.
That’s definitely carp. Infamous Host Erlangen has:
erlangen:~ # inxi -zaM
Machine:
Type: Desktop System: Micro-Star product: MS-7C56 v: 2.0 serial: N/A
Mobo: Micro-Star model: B550-A PRO (MS-7C56) v: 2.0 serial: <filter>
Its rear panel has Headers #2 and #7 for integrated graphics output: https://storage-asset.msi.com/datasheet/mb/de/B550-A-PRO.pdf
Provide the equivalent information of your system.
You can always use ssh. Need the information from inxi -M for further comments.
It’s a living document, but currently dormant.
1 Like
“Carp”??? What is “carp”?? “Fishy”???
sudo inxi -zaM
[sudo] password for root:
Machine:
Type: Desktop System: Apple product: MacPro5,1 v: 0.0 serial: <filter>
Chassis: type: 7 v: Mac-F221BEC8 serial: <filter>
Mobo: Apple model: Mac-F221BEC8 serial: <filter>
uuid: 24cc20b6-40e2-bd56-xxxxxx-xxxxx-xxxxxx UEFI: Apple v: 138.0.0.0.0
date: 07/30/2018
buto@no-pc:~> sudo inxi -M
Machine:
Type: Desktop System: Apple product: MacPro5,1 v: 0.0 serial: C07KH09BF4MC
Mobo: Apple model: Mac-F221BEC8 serial: J531300DQCZJC UEFI: Apple
v: 138.0.0.0.0 date: 07/30/2018
I don’t know what the “2018” is about, this is a 2012 machine, perhaps a firmware update was run at that time??
So I get that a “box” is a box containing parts, and the parts can be changed, in “rolling” fashion . . . . The nice thing about the Mac Pro is that it is easy to get to RAM and Graphic card slots, and then apparently the CPU is on a tray . . . not sure how easy it is to get to the mobo, like if that is what you were suggesting with the link to the MSI mobo page . . . .
Nothing like a fresh mobo to change the way the game is played . . . would TW be able to sense the changes in hardware and just play on with it?? Or, stop the presses, we don’t have a clue what happened to the mobo???