[Debian] -Longhaul is borken in this configuration


Recommended Posts

Did some searching around and found the site below which explains a bug and the work around for the message Long Haul is broken in this configuration. Don't even have a clue as to what long haul is, but I do see that message when booting up Wheezy on this junk Everex Impact I have here!

http://womble.decadent.org.uk/blog/warning-debian-70-wheezy-on-via-c3-and-cyrix-iii-systems.html

http://planet-search.debian.org/cgi-bin/search.cgi?terms=Ben+Hutchings

if you do not currently use the 'longhaul' module, you should blacklist it by creating e.g. /etc/modprobe.d/blacklist-longhaul.conf containing the line:

blacklist longhaul

OK. I admit I'm totally illiterate at what exactly that means and how do it!

HELP, please!!

Thank you

What in the blue hell is longhaul? Anyways, according to the first link it only applies if you have these chipsets: Via C3 and Cyrix III.

Right -- if I recall, Longhaul is a CPU throttling/powersaving setup designed by VIA for a few of the Cyrix/C3 processors.. not sure on C7 but probably.

I have never seen that message, but I have also never used the hardware mentioned in that post. If you really need to blacklist that module on your machine (which is ONLY on VIA C3 and Cyrix III systems) do the following:


sudo -s
touch /etc/modprobe.d/blacklist-longhaul.conf
echo "blacklist longhaul" >> /etc/modprobe.d/blacklist-longhaul.conf
reboot
[/CODE]

On a side note, you should consider Ben Hutchings an expert on the Debian kernel. He is one of the principal members of the Debian Kernel Team.

Any insight as what long haul is before I do anything? I'm still searching around and not finding very much useful stuff, at least to me!

I definitely didn't like what that one link says about it possibly damaging the hardware! Even if it is junk!!

Everything seems to be working all right though.

Thanks

Edit:

Just found this, http://lists.alioth....May/018970.html and is says disable long haul by default.

Author: benh

Date: Thu May 9 01:25:13 2013

New Revision: 20063

Log:

[i386] cpufreq / Longhaul: Disable driver by default (Closes: #707047)

Added:

dists/wheezy/linux/debian/patches/features/all/cpu-devices/cpufreq-Longhaul-Disable-driver-by-default.patch

Modified:

dists/wheezy/linux/debian/changelog

dists/wheezy/linux/debian/patches/series

Modified: dists/wheezy/linux/debian/changelog

==============================================================================

--- dists/wheezy/linux/debian/changelog Thu May 9 00:41:03 2013 (r20062)

+++ dists/wheezy/linux/debian/changelog Thu May 9 01:25:13 2013 (r20063)

@@ -98,6 +98,7 @@

(Closes: #705655)

* bug script: Remove broken sound functions (Closes: #705619)

* [i386/486] udeb: Add lxfb to fb-modules (Closes: #705780)

+ * [i386] cpufreq / Longhaul: Disable driver by default (Closes: #707047)

-- Ben Hutchings <ben at decadent.org.uk> Wed, 27 Mar 2013 14:10:40 +0000

How do I check if it's disabled?

Any insight as what long haul is before I do anything? I'm still searching around and not finding very much useful stuff, at least to me!

I definitely didn't like what that one link says about it possibly damaging the hardware! Even if it is junk!!

Everything seems to be working all right though.

Thanks

Although I have heard of Longhaul before today, Max Norris says that it provides CPU throttling and power management for VIA processors, and Wikipedia seems to back him up.

Coincidentally,

I just opened synaptics and checked for updates. Although Wheezy has been on this machine for a few days, it just got an update for the Via display driver.

OpenChrome is a project for the development of free and open-source drivers

for the VIA UniChrome video chipsets.

Originally called the 'snapshot' release, since it was a snapshot of an

experimental branch of the unichrome cvs code, this is a continued development

of the open source unichrome driver (from http://unichrome.sf.net) which

also incorporates support for the unichrome-pro chipsets.

Support for hardware acceleration (XvMC) for all chipsets has subsequently

been ripped out of the unichrome.sf.net driver. Therefore your only option if

you wish to make use of the acceleration features of your VIA chip with free

and open-source drivers is to use this version of the driver.

That Wiki says C7 also.

Do I dare use that driver?

Coincidentally,

I just opened synaptics and checked for updates. Although Wheezy has been on this machine for a few days, it just got an update for the Via display driver.

OpenChrome is a project for the development of free and open-source drivers

for the VIA UniChrome video chipsets.

Originally called the 'snapshot' release, since it was a snapshot of an

experimental branch of the unichrome cvs code, this is a continued development

of the open source unichrome driver (from http://unichrome.sf.net) which

also incorporates support for the unichrome-pro chipsets.

Support for hardware acceleration (XvMC) for all chipsets has subsequently

been ripped out of the unichrome.sf.net driver. Therefore your only option if

you wish to make use of the acceleration features of your VIA chip with free

and open-source drivers is to use this version of the driver.

That Wiki says C7 also.

Do I dare use that?

It seems worthwhile to try it. It is exceedingly rare for drivers to permanently damage hardware or firmware (such action is usually the result of a hardware or firmware bug anyway), so the worst that will happen is you will irreparably break your installation and have to reinstall. The driver seems to be in the Debian repository, so proceed at your own risk.

Thanks for that vote of confidence there! :laugh:

Unfortuantely,

I've had my share of video drivers screwing up my Linux installs in the past and why I'm leary of this!

Does that info I posted above in post #6 mean that Long Haul is disabled by default on this setup?

This is what I get when running that command regularly and using sudo:

cork@debian:~/Desktop$ modprobe | grep longhaul

bash: modprobe: command not found

cork@debian:~/Desktop$ sudo modprobe | grep longhaul

[sudo] password for cork:

Error: missing parameters. See -h.

cork@debian:~/Desktop$

cork@debian:~/Desktop$ sudo modprobe | grep longhaul -h

Error: missing parameters. See -h.

Assuming that it's either disabled or simply not installed/running?

Well, here goes that update along with all the others that just came through today!

If I'm not back in a few, you know I'm reinstalling something, maybe!!

Thanks

Edit:

Well, I'm back and didn't have to reinstall anything!! May try that

sudo -s

touch /etc/modprobe.d/blacklist-longhaul.conf

echo "blacklist longhaul" >> /etc/modprobe.d/blacklist-longhaul.conf

reboot

later tonight or tomorrow.

Thanks again!!

This is what I get when running that command regularly and using sudo:

cork@debian:~/Desktop$ modprobe | grep longhaul

bash: modprobe: command not found

cork@debian:~/Desktop$ sudo modprobe | grep longhaul

[sudo] password for cork:

Error: missing parameters. See -h.

cork@debian:~/Desktop$

cork@debian:~/Desktop$ sudo modprobe | grep longhaul -h

Error: missing parameters. See -h.

Assuming that it's either disabled or simply not installed/running?

Oops. That was my fault. I fat fingered the command. The actual command should have been:


lsmod | grep longhaul
[/CODE]

The module definitely won't be loaded now because you blacklisted it, meaning that you will not get any output from the command I just posted.

If youre not sure what it is, you likely don't need it.

That is not true in the least. When it comes to system components, if you don't know EXACTLY what it is you should NOT remove it! Removing system components you don't understand is never a good idea. Your statement holds true only for desktop applications, in most cases.

That is not true in the least. When it comes to system components, if you don't know EXACTLY what it is you should NOT remove it! Removing system components you don't understand is never a good idea. Your statement holds true only for desktop applications, in most cases.

I never said to remove anything.

Oops. That was my fault. I fat fingered the command. The actual command should have been:
 lsmod | grep longhaul [/CODE]

The module definitely won't be loaded now because you blacklisted it, meaning that you will not get any output from the command I just posted.

I haven't blacklisted long haul yet, as I mentioned in a couple posts back. Some what afraid to seeing as how that junk machine is running as good as it is.

You just nailed the EXACT reason I half despise the command line though. Even with my skinny fingers and the fact I DO know how to type, it's simply to easy to screw stuff up using it! Almost nothing worse than an "Oops" when using the command line!

I still have a link to this thread in my e-mail, so maybe will check into this long haul issue after the holiday. About to get out of here and go camping for the weekend! :)

Thanks

  • 3 weeks later...

FWIW,

Yes, I'm still checking into this!

When I run that command

lsmod | grep longhaul

I get absolutley nothing using sudo or not. I don't see where I replied to that last time you replied after you fat fingered the command. ;)

If you get nothing after running that command it means the longhaul module is not loaded. If you have not blacklisted it yet, there is no need to.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Simple answer is yes, you will still get the Windows updates and as long as browser is up to date, you will be good. Only thing secure boot does is protect you against boot level threats and make it harder to install other OS's. I've been looking into this pretty thoroughly lately myself as wifes computer has secure boot disabled plus my other, older computers that run Linux, don't have secure boot enabled. Have seen all kinds of questions about this on the Linux Mint and MX Linux forums. Just don't suddenly enable secure boot now.
    • How many other companies will follow Ford's lead? Or, have they already gotten lazy and become enslaved to AI--and now can't figure out how to get out of that mess.
    • Why would any self-respecting intelligent person follow any recommendation by Donald's GOP administration? With almost two years of fabrications, deceit, and blatantly illegal behavior, why believe them now? They had best be gone after the November 2026 election, so we'll wait and see.
    • AltSendme 0.4.1 by Razvan Serea AltSendme is a minimal, cross-platform application designed for fast, secure, and private peer-to-peer file transfers. It allows users to send files or entire directories directly between devices without relying on cloud servers, accounts, or any personal information. Everything is encrypted end-to-end using modern protocols like QUIC and TLS 1.3, ensuring both strong security and low-latency performance. Transfers are verified with BLAKE3 for data integrity, and interrupted downloads automatically resume, making the experience reliable even on unstable connections. You can transfer anything—images, videos, documents, and more. Integrity checks are performed on both ends, so your files are automatically verified for correctness during both sending and receiving. AltSendme works seamlessly across local networks or long-distance links, capable of saturating multi-gigabit connections for extremely fast delivery. With built-in NAT traversal and encrypted relay fallback, it connects devices almost anywhere. The app integrates with the Sendme CLI and will soon support mobile and web platforms. Fully free and open-source, AltSendme offers a lightweight, privacy-first alternative to traditional cloud-based services, removing size limits, upload costs, and unnecessary data exposure. AltSendme 0.4.1 changelog: Release Highlights Self-hosted relays: Run your own iroh relay so transfers don't rely on public infrastructure. Includes a full deployment template in deploy/relay/ with Docker Compose for a VPS and configuration examples for production use. Fly.io support: One-click deploy template for Fly.io, including a quick-start config (fly.dev.toml) for testing without a custom domain, plus production setup with Let's Encrypt and your own hostname. Relay settings UI: New Settings → Network panel to choose how AltSendme connects: automatic public relays, custom self-hosted URLs (with optional auth token), or disabled. Test connections, verify latency, and see live relay status in the footer. Disable relays: Turn off relay servers entirely when you only need same-network transfers (e.g. LAN). Direct connections only. No relay hop required when devices can reach each other. Android graduates from beta: Android is now part of the regular release cycle alongside desktop. APKs ship with each version (universal, arm64, and armv7). Other improvements Private relay access control via shared auth token Relay fallback notifications when a custom relay is unreachable Broadcast mode toggle in sharing settings Android release build fixes (split-per-ABI APKs, universal APK preservation) UI polish: mobile safe-area insets, dropzone layout, transfer progress animation Bug fixes for minification-related serialization issues and system tray icon loading What's Changed feat(relay): add relay status functionality and settings UI (a120cdf) feat(relay): implement custom relay server configuration and verification (51276c7) feat(relay): add configuration for private relay access and enhance observability features (48fbabf) feat(relay): enhance relay URL validation, display connection status (d4fffa0) feat(relay): add RelayChangeGuard component and enhance relay-related translations (16ba514) feat(broadcast): add toggle setting for broadcast mode in sharing UI (ca6d977) fix(relay): correct QUIC discovery port, pin image, templatize fly.dev (52a2ba5) fix: More broken serialization due to minification (67491a9) fix(android): preserve true universal APK across per-ABI builds (e9f256f) fix(ui): conditional safe-area insets padding on mobile (1182f0e) refactor(transfer): CircularRing component animation fix (944572b) chore(android): drop x86 and x86_64 release APKs, keep universal+arm64+armv7 (34ada0b) Download: AltSendme 0.4.1 | ARM64 | ~9.0 MB (Open Source) Download: AltSendme for MacOS | Android Links: AltSendme Home Page | GitHub | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • You are mostly right about the ephemeral nature of it. As I mention in the article, if you dont add a second device or take a backup of your account before uninstalling it, then yes you will lose access to your account. That said, in terms of actual user experience when you sync multiple devices your message history carries across and there's also a Saved Messages chat like there is on Telegram to send messages and attachments between your installs. But yh, what you point out are correct and its not trying to emulate Messenger or Telegram.
  • Recent Achievements

    • Week One Done
      flexorcist earned a badge
      Week One Done
    • One Month Later
      Woland13 earned a badge
      One Month Later
    • Week One Done
      Woland13 earned a badge
      Week One Done
    • One Year In
      bernmeister earned a badge
      One Year In
    • Week One Done
      Scoobystu earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      495
    2. 2
      +Edouard
      225
    3. 3
      PsYcHoKiLLa
      149
    4. 4
      Steven P.
      75
    5. 5
      FloatingFatMan
      71
  • Tell a friend

    Love Neowin? Tell a friend!