Re: Asterisk 20 doesn't include chan_sip.so

[hw]

On Sun, 2022-11-20 at 13:07 -0600, Mark Kamichoff wrote:
> Hi - 
> 
> I'm not sure if this is a bug or intentional so I figured I'd ask here
> first before submitting a bug report.
> 
> The Asterisk package in testing (1:20.0.0~dfsg+~cs6.12.40431414-2)
> doesn't appear to have chan_sip.so included anymore.  The file is no
> longer there so no amount of noload'ing pjsip and load'ing chan_sip
> works.  The package for version 18 (1:18.14.0~dfsg+~cs6.12.40431414-1)
> has it included.  From my understanding even though chan_sip has been
> deprecated in favor of pjsip for a few releases, it is still included
> until version 21 (Oct 2023?) where it will be removed completely in
> favor of res_pjsip.
> 
> I didn't find anything about its removal in changelog or NEWS files.
> 
> Can any Asterisk users out there comment if this may have been
> intentional or whether this was a miss on the Asterisk 20 package build?

You'd probably have to ask the package manager about it --- or make a bug
report.  The xmpp module was also removed from asterisk, and that really sucks
:(

Re: tbird AND javamail both broken

[gene heskett]

On 11/21/22 00:16, Gareth Evans wrote:

On Sun 20 Nov 2022, at 07:08, Tom Dial  wrote:

On 11/19/22 10:09, gene heskett wrote:

On 11/19/22 11:45, gene heskett wrote:

On 11/19/22 06:45, Gareth Evans wrote:



On 19 Nov 2022, at 10:17, Gareth Evans  wrote:



On 19 Nov 2022, at 04:08, gene heskett  wrote:

On 11/18/22 19:05, Gareth Evans wrote:

[...]

iirc, headers (that is, the lot of them) are supposed to be terminated by a 
blank line (double line break) before message content/multipart 
boundaries/blocks begin


[...]


You're right of coarse, and yes, that was a straight copy paste from a geany 
session on the saved message [...]


If you view the message source in Thunderbird, are the individual headers still 
separated by blank lines?  Saving the message and examining the output  
introduces the possibility of CRLF line endings, which Geany may not convert.


I think David Wright is correct that Tb is showing the (empty) plain text 
section.  I didn't notice this at first as I was struck by the blank lines and 
didn't look any further.

If there were blank lines between headers in the raw message, I think Tb would 
be displaying the contents of the raw message after the first blank line, in 
plaintext, because the chain of headers had been broken at that point, and 
multipart boundaries etc not interpreted.

So I think the blank lines in headers are probably a red herring, however they 
got there.

The base64-encoded string in the text/html part (which begins "PEhUT...") 
converts to HTML:

https://devpal.co/base64-decode/?data=PEhUTUw%2BPEJPRFk%2BPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwMDA7Ij48c3BhbiBzdHlsZT0iZm9u%0A%0AdC1mYW1pbHk6QXJpYWwsSG


=_Part_164_535344686.1668739861264
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64
PEhUT...


What happens if you try (in Tb)

View > Message Body As > Original HTML

?


And I'll repeat one more time, then I'm done, there is NO html content in the 
messages, not even a mimetype boundary for it.

Here is a verbatum copy/paste of the most recent msg of several I have received 
from this online seller:
==
Return-Path: 
Received: from 216.163.176.191 unverified ([216.163.176.191]) by 
mwweb09oc.mail2world.com with Mail2World SMTP Server;
  Sat, 19 Nov 2022 07:08:13 -0800
Received: from [47.90.198.27] (port=48703 helo=out198-27.us.a.mail.aliyun.com)
  by prd-mail2world-inbound-ash1-008.ash1.cynet with esmtps  (TLS1.2) tls 
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  (Exim 4.94.2)
  (envelope-from )
  id 1owPSF-0002kY-Pd
  for ghesk...@shentel.net; Sat, 19 Nov 2022 15:08:28 +
X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e2;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047206;MF=c...@omc-stepperonline.com;NM=1;PH=DS;RN=1;RT=1;SR=0;TI=SMTPD_---.QBl8rV7_1668870493;
Received: from iZuf677iw3xihpZ(mailfrom:c...@omc-stepperonline.com 
fp:SMTPD_---.QBl8rV7_1668870493)
    by smtp.aliyun-inc.com;
    Sat, 19 Nov 2022 23:08:13 +0800
Date: Sat, 19 Nov 2022 23:08:13 +0800 (CST)
From: c...@omc-stepperonline.com
To: gene heskett 
Message-ID: <457669489.89.1668870493425@iZuf677iw3xihpZ>
Subject: Re:We found the problem as to why I cannot "see" your emails.
MIME-Version: 1.0
Content-Type: multipart/alternative;
  boundary="=_Part_88_360748977.1668870493425"
X-mailer: javamail@rebee
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
x-ctasd: uncategorized
x-ctasd-vod: uncategorized
X-CTCH-Flags: 0
X-CTCH-RefID: 
str=0001.0A742F15.6378F16C.000F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
X-CTASD-IP: 47.90.198.27
X-CTASD-Sender: c...@omc-stepperonline.com
X-OpenTrafficX: clean
X-OpenTrafficX-type: clean
X-OpenTrafficX-ID: 155810::1668870508-ABFD6BA6-19F98021/0/0

--=_Part_88_360748977.1668870493425
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: base64


--=_Part_88_360748977.1668870493425
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64

PEhUTUw+PEJPRFk+PHNwYW4gaWQ9ImNrLW1haWwtY29udGVudCIgc3R5bGU9ImZvbnQtZmFtaWx5
OkFyaWFsO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMDAwMDA7Ij5EZWFyIEdlbmUsPGJyIC8+Cjxi
ciAvPgpUaGFuayB5b3UgZm9yIGxldHRpbmcgbWUga25vdy4gQ2FuIHlvdSBzZWUgbXkgZW1haWwg
bm93PyZuYnNwOzwvc3Bhbj4KPGRpdj4mbmJzcDs8L2Rpdj4KCjxkaXYgbmFtZT0icmItc2lnbmF0
dXJlLWRpdiI+CjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg
Y29sb3I6ICMwMDAwMDA7IHBhZGRpbmctbGVmdDogMDsgbWFyZ2luLWxlZnQ6IDA7Ij5CZXN0IFJl
Z2FyZHM8YnIgLz4KWW9sYW5kYTxiciAvPgombmJzcDs8YnIgLz4KPHN0cm9uZyBzdHlsZT0iZm9u
dC1zaXplOiAyMnB4OyBmb250LWZhbWlseTogQXJpYWw7Ij48c3BhbiBzdHlsZT0iY29sb3I6ICMw
MDdjYzM7Ij5TVEVQUDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6ICMwMDA7Ij5FPC9zcGFuPjxz
cGFuIHN0eWxlPSJjb2xvcjogIzAwN2NjMzsiPlJPTkxJTjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6ICMwMDA7Ij5FPC9zcGFuPjwvc3Ryb25nPjxiciAvPgpUZWw6ICs4Ni0yNS04NzE1NjU3OCB4
MDU5PGJyIC8+CjxhIGhyZWY9Im1haWx0bzpjczA2QG9tYy1zdGVwcGVyb25saW5lLmNvbSIgc3R5

Re: FIREFOX is killing the whole PC PART II

[Gareth Evans]

On Mon 21 Nov 2022, at 06:56, Gareth Evans  wrote:
> On Sun 20 Nov 2022, at 10:53, Schwibinger Michael  wrote:
>> Hello
>> and thank You.
>> 
>> 
>> 
>> 
>> Thank you, this did help.
>
>> Two Questions more.
>
>> How can I find by terminal all dirt which is produced by browsers (Chrome, 
>> Firefox, Midori ...)?
>> I did try something like cache, but there were no new files.
>
> I think it would be easier to clear the cache and other data (possibly 
> including history if you wish) automatically when the browsers close.  
> There are usually settings available to do that.
>
> See below.
>
>> How can I tell the browser (Firefox, Chrome and so on): Do not save any 
>> information.
>> Example:
>> I do open www.hotmail.de, sending Emails, and close hotmail.
>> No there should be no information left on the pc abour hotmail. Only the 
>> bookmark www.hotmail.de.
>
> If you mean an actual bookmark, clearing the history will not remove this.
>

> For Firefox:
>
> Settings > Privacy and Security
>
> - Delete cookies and site data when Firefox is closed
>
> - History 

Make sure "Firefox will: Use custom settings for history" is selected, to see 
further options

Re: FIREFOX is killing the whole PC PART II

[Gareth Evans]

On Sun 20 Nov 2022, at 10:53, Schwibinger Michael  wrote:
> Hello
> and thank You.
> 
> 
> 
> 
> Thank you, this did help.

> Two Questions more.

> How can I find by terminal all dirt which is produced by browsers (Chrome, 
> Firefox, Midori ...)?
> I did try something like cache, but there were no new files.

I think it would be easier to clear the cache and other data (possibly 
including history if you wish) automatically when the browsers close.  There 
are usually settings available to do that.

See below.

> How can I tell the browser (Firefox, Chrome and so on): Do not save any 
> information.
> Example:
> I do open www.hotmail.de, sending Emails, and close hotmail.
> No there should be no information left on the pc abour hotmail. Only the 
> bookmark www.hotmail.de.

If you mean an actual bookmark, clearing the history will not remove this.

For Firefox:

Settings > Privacy and Security

- Delete cookies and site data when Firefox is closed

- History 
-- Clear history when Firefox closes [Settings...]

There are options for what to clear if you click the "settings" button, such as 

- browsing history
- cookies
- cache

So there seem to be two ways to clear cookies and site data when closing 
Firefox, but I'm not sure if the options under History > Settings include all 
the "site data" removed by the other setting.

Best wishes,
Gareth



> 
> 
> Thank you.
> 
> 
> Reards,
> Sophie
> 
> 
> 
> *Von:* Gareth Evans 
> *Gesendet:* Samstag, 19. November 2022 14:12
> *An:* debian-user@lists.debian.org 
> *Betreff:* Re: FIREFOX is killing the whole PC 
>  
> On Sat 19 Nov 2022, at 13:14, DdB  
> wrote:
> > Am 19.11.2022 um 10:34 schrieb Schwibinger Michael:
> >> Hello
> >> 
> >> Any idea?
> >> 
> >> What did happen?
> >> FF did open a page with bad PC,
> >> so it needs 5 minutes to open it.
> >> We killed the tab.
> >> When we now try to open FF
> >> whole PC is blocked.
> >> How can we clean FF
> >> because bad page is in it.
> >> 
> >> Regards
> >> Sophie
> >> 
> 
> > Did you try to start it from the commandline with the option safe-mode?
> >
> > firefox --safe-mode
> 
> If the idea is to prevent previous tabs from opening on startup, that only 
> works for me if firefox is already running when I run 
> 
> firefox --safe-mode
> 
> ...which may not be possible for Sophie.
> 
> Removing the line:
> 
> user_pref("browser.startup.page", 3);
> 
> from
> 
> /home/username/.mozilla/firefox/XXX.default-esr/prefs.js
> 
> has the desired effect (where "XXX" is the appropriate string of letters and 
> numbers).
> 
> There may be more than one such profile directory, in which case, if other 
> users don't rely on tabs being restored, then remove that line from all the 
> 
> XXX.whatever/prefs.js 
> 
> files you can find.
> 
> It may also be necessary to add the line
> 
> user_pref("browser.sessionstore.resume_from_crash", false);
> 
> I don't know if the order of lines matters.  In my prefs.js, this appears in 
> the sequence
> 
> user_pref("browser.search.region", "GB");
> user_pref("browser.search.widget.inNavBar", true);
> user_pref("browser.sessionstore.resume_from_crash", false);
> 
> when added from about:config, but the 2nd line is non-default as well as the 
> 3rd, and these are only present if added manually or set in settings or 
> about:config, as appropriate.
> 
> Hope that helps
> Gareth
> 
> 
> 

Re: CUDA error cudaStreamSynchronize(stream) and CUDA error in ComputeBondedCUDA

[Peter von Kaehne]

I do not know if this would work with this kind of computation but I would suggest you try and run the programme under gdb.Nvidia suggests CUDA-gdb for this purposeCUDA-GDB :: CUDA Toolkit Documentationdocs.nvidia.comSo, I think this is the way to go. You should be able to figure out even without great knowledge of this kind of thing where the error lies - in your main programme or in a library. The whole thing is, I guess, so niche that you need to do some work to narrow things down more for others likely to show some interest.As a guess I would say that a library was updated and your programme does not check on that but struggles (and fails) now. Peter

Re: tbird AND javamail both broken

[Gareth Evans]

On Sun 20 Nov 2022, at 07:08, Tom Dial  wrote:
> On 11/19/22 10:09, gene heskett wrote:
>> On 11/19/22 11:45, gene heskett wrote:
>>> On 11/19/22 06:45, Gareth Evans wrote:

> On 19 Nov 2022, at 10:17, Gareth Evans  wrote:
> 
>
>> On 19 Nov 2022, at 04:08, gene heskett  wrote:
>>
>> On 11/18/22 19:05, Gareth Evans wrote:
> [...]
>>> iirc, headers (that is, the lot of them) are supposed to be terminated 
>>> by a blank line (double line break) before message content/multipart 
>>> boundaries/blocks begin
>
> [...]
>
>> You're right of coarse, and yes, that was a straight copy paste from a 
>> geany session on the saved message [...]
>
> If you view the message source in Thunderbird, are the individual headers 
> still separated by blank lines?  Saving the message and examining the 
> output  introduces the possibility of CRLF line endings, which Geany may 
> not convert.

 I think David Wright is correct that Tb is showing the (empty) plain text 
 section.  I didn't notice this at first as I was struck by the blank lines 
 and didn't look any further.

 If there were blank lines between headers in the raw message, I think Tb 
 would be displaying the contents of the raw message after the first blank 
 line, in plaintext, because the chain of headers had been broken at that 
 point, and multipart boundaries etc not interpreted.

 So I think the blank lines in headers are probably a red herring, however 
 they got there.

 The base64-encoded string in the text/html part (which begins "PEhUT...") 
 converts to HTML:

 https://devpal.co/base64-decode/?data=PEhUTUw%2BPEJPRFk%2BPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwMDA7Ij48c3BhbiBzdHlsZT0iZm9u%0A%0AdC1mYW1pbHk6QXJpYWwsSG

>> =_Part_164_535344686.1668739861264
>> Content-Type: text/html;charset=UTF-8
>> Content-Transfer-Encoding: base64
>> PEhUT...

 What happens if you try (in Tb)

 View > Message Body As > Original HTML

 ?
>>>
>>> And I'll repeat one more time, then I'm done, there is NO html content in 
>>> the messages, not even a mimetype boundary for it.
>>>
>>> Here is a verbatum copy/paste of the most recent msg of several I have 
>>> received from this online seller:
>>> ==
>>> Return-Path: 
>>> Received: from 216.163.176.191 unverified ([216.163.176.191]) by 
>>> mwweb09oc.mail2world.com with Mail2World SMTP Server;
>>>  Sat, 19 Nov 2022 07:08:13 -0800
>>> Received: from [47.90.198.27] (port=48703 
>>> helo=out198-27.us.a.mail.aliyun.com)
>>>  by prd-mail2world-inbound-ash1-008.ash1.cynet with esmtps  (TLS1.2) 
>>> tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>>>  (Exim 4.94.2)
>>>  (envelope-from )
>>>  id 1owPSF-0002kY-Pd
>>>  for ghesk...@shentel.net; Sat, 19 Nov 2022 15:08:28 +
>>> X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e2;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047206;MF=c...@omc-stepperonline.com;NM=1;PH=DS;RN=1;RT=1;SR=0;TI=SMTPD_---.QBl8rV7_1668870493;
>>> Received: from iZuf677iw3xihpZ(mailfrom:c...@omc-stepperonline.com 
>>> fp:SMTPD_---.QBl8rV7_1668870493)
>>>    by smtp.aliyun-inc.com;
>>>    Sat, 19 Nov 2022 23:08:13 +0800
>>> Date: Sat, 19 Nov 2022 23:08:13 +0800 (CST)
>>> From: c...@omc-stepperonline.com
>>> To: gene heskett 
>>> Message-ID: <457669489.89.1668870493425@iZuf677iw3xihpZ>
>>> Subject: Re:We found the problem as to why I cannot "see" your emails.
>>> MIME-Version: 1.0
>>> Content-Type: multipart/alternative;
>>>  boundary="=_Part_88_360748977.1668870493425"
>>> X-mailer: javamail@rebee
>>> X-CTCH-Spam: Unknown
>>> X-CTCH-VOD: Unknown
>>> x-ctasd: uncategorized
>>> x-ctasd-vod: uncategorized
>>> X-CTCH-Flags: 0
>>> X-CTCH-RefID: 
>>> str=0001.0A742F15.6378F16C.000F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
>>> X-CTASD-IP: 47.90.198.27
>>> X-CTASD-Sender: c...@omc-stepperonline.com
>>> X-OpenTrafficX: clean
>>> X-OpenTrafficX-type: clean
>>> X-OpenTrafficX-ID: 155810::1668870508-ABFD6BA6-19F98021/0/0
>>>
>>> --=_Part_88_360748977.1668870493425
>>> Content-Type: text/plain;charset=UTF-8
>>> Content-Transfer-Encoding: base64
>>>
>>>
>>> --=_Part_88_360748977.1668870493425
>>> Content-Type: text/html;charset=UTF-8
>>> Content-Transfer-Encoding: base64
>>>
>>> PEhUTUw+PEJPRFk+PHNwYW4gaWQ9ImNrLW1haWwtY29udGVudCIgc3R5bGU9ImZvbnQtZmFtaWx5
>>> OkFyaWFsO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMDAwMDA7Ij5EZWFyIEdlbmUsPGJyIC8+Cjxi
>>> ciAvPgpUaGFuayB5b3UgZm9yIGxldHRpbmcgbWUga25vdy4gQ2FuIHlvdSBzZWUgbXkgZW1haWwg
>>> bm93PyZuYnNwOzwvc3Bhbj4KPGRpdj4mbmJzcDs8L2Rpdj4KCjxkaXYgbmFtZT0icmItc2lnbmF0
>>> dXJlLWRpdiI+CjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg
>>> Y29sb3I6ICMwMDAwMDA7IHBhZGRpbmctbGVmdDogMDsgbWFyZ2luLWxlZnQ6IDA7Ij5CZXN0IFJl
>>> 

Re: Starting Debian

[David Wright]

On Sat 19 Nov 2022 at 07:26:24 (+0100), to...@tuxteam.de wrote:
> On Sat, Nov 19, 2022 at 02:10:03AM +, debian-u...@howorth.org.uk wrote:
> > > I  have heard good things said about XXX (XXX),
> > > from several YouTubers.
> > 
> > This seems like a paid advertisement, or am I misunderstanding
> > something?
> 
> Dunno whether it's paid, but (1) it has nothing to do with the
> original post (which would be rude, to say the least)

The OP said "if I could find … good security through a VPN",
which could be interpreted as soliciting recommendations for
a good, secure VPN, as opposed to a cheap/free one that harvests
the names of all the domains you connect to (assuming that's what
you're afraid of).

(AIUI, Debian provides software for using VPNs, not a VPN service.)

Myself, I'd recommend ███ at ███.com/honest :)

> and (2)
> the touted "product" is one of a commercial entity.

There are occasional queries here about obtaining a permanent
email address, and replies usually involve purchase of (a) an
email hosting service and (b) a domain hosted by some registrar.
I don't think the people who post recommendations are being
paid by the companies named, and I don't think mentioning
commercial products is banned like, say, on the BBC.

> So yes, at least a strange post.

Inasmuch as the attribution of the recommendation is vague, I'd agree,
but I don't know any youtubers. And the OP was a little odd, too.

Cheers,
David.

Re: recover old files after key deprecations in openssl3

[Bhasker C V]

Thanks Dan, i did that anyway. I compiled 1.1 and decrypted and
re-encrypted them. My data is back.
I didnt know that there is such backward compatibility issues with 3.x


On Fri, Oct 28, 2022 at 12:16 PM Dan Ritter  wrote:

> Bhasker C V wrote:
> > Hi,
> >
> >
> >  Could someone help me please on how do I go about migrating data of mine
> > from old SSL encryption
> >
> >  For instance
> >
> >
> > OPENSSL 1.1 (on a old system)
> >
> > $ echo hai | openssl bf-cbc -md md5 > hello.txt
> >
> > and then in
> >
> > OPENSSL 3
> >
> > $ cat hello.txt  | openssl bf-cbc  -md md5 -d -provider legacy
> > enter BF-CBC decryption password:
> > *** WARNING : deprecated key derivation used.
> > Using -iter or -pbkdf2 would be better.
> > EVP_BytesToKey failed
> > 40D7C740377F:error:0308010C:digital envelope
> routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:373:Global
> > default library context, Algorithm (MD5 : 100), Properties ()
> > 40D7C740377F:error:0386:digital envelope
> > routines:evp_md_init_internal:initialization
> > error:../crypto/evp/digest.c:252:
> >
> >
> > Is there anything else missing other than -provider legacy for decrypting
> > such files ? I am guessing the MD5 is not compatible with legacy
> provider.
> >
> > I have tried fips, base, legacy
>
> I recommend two things:
>
> First, use openssl 1.1 to decrypt your files. Once you have the
> plaintext, you can re-encrypt them as you see fit.
>
> Second, don't use openssl 3 yet. It's still the season of
> frequent CVEs.
>
> -dsr-
>

PSA: anacron might be disabled if 2.3-33 was ever installed

[Paul Wise]

Hi folks,

If you run Debian testing/unstable and ever installed anacron 2.3-33 on
a systemd based system, then anacron will no longer be enabled and the
daily/weekly/monthly cron jobs will not be run until it is.

Since not all cron jobs have migrated to systemd timers, Debian
testing/unstable systems with systemd and anacron may be missing
some essential cron jobs, such as making backups of aptitude state.

To see if a system is affected you can use these commands:

   zgrep -i anacron.*2.3-33 /var/log/apt/history.log*
   systemctl status anacron.service anacron.timer

To re-enable anacron you can use these commands:

   sudo systemctl enable anacron.service anacron.timer
   sudo systemctl start anacron.service anacron.timer

More details of this problem are available in these bugs:

   https://bugs.debian.org/1019554
   https://bugs.debian.org/1020966
   https://bugs.debian.org/1021496

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: Falta de firmware

[Simeón Ignacio Martirén]

Muchísimas gracias, muy solidaria la lista. solucionado. Ahora, no sé cómo
se le agrega al Asunto: Falta de firmware el SOLUCONADO.

El mar, 15 nov 2022 a las 11:12, Camaleón () escribió:

> El 2022-11-15 a las 09:23 -0300, Simeón Ignacio Martirén escribió:
>
> > root@Bulls:/home/ign# dmesg | grep -i i915
> > [1.409150] i915 :00:02.0: vgaarb: deactivate vga console
> > [1.411397] i915 :00:02.0: vgaarb: changed VGA decodes:
> olddecodes=io+mem,decodes=io+mem:owns=io+mem
> > [1.427825] [drm] Initialized i915 1.6.0 20200917 for :00:02.0 on
> minor 0
> > [1.454822] fbcon: i915drmfb (fb0) is primary device
> > [1.559817] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer
> device
> > [   15.572406] snd_hda_intel :00:1b.0: bound :00:02.0 (ops
> > i915_audio_component_bind_ops [i915])
>
> Vale, no te pide ningún firmware de Intel.
>
> Puedes ignorar los mensajes de alerta que te sugieren que instales el
> paquete o si no quieres recibir esos mensajes, instalar los paquetes que
> te piden.
>
> Empieza con «»firmware-misc-nonfree», vuelve a generar la imagen del
> kernel y mira a ver si ya no te aparece ningún mensaje de alerta.
>
> Saludos,
>
> --
> Camaleón
>
>

-- 
*  Ignacio*

Re: Intel X540-AT2 and Debian: intermittent connection

[hw]

On Sun, 2022-11-20 at 10:25 -0800, David Christensen wrote:
> On 11/20/22 08:25, hw wrote:
> > On Sun, 2022-11-20 at 12:45 +0100, hw wrote:
> > > [...]
> 
> I am unable to determine if Intel has fixed any device driver bugs for 
> the X540-AT2 adapter since FreeBSD-12.3-RELEASE-amd64-memstick.img was 
> released.

IIRC, the card is EOL since 2 years or so.  Intel probably won't touch it unless
the driver supports other cards that are still being sold.

The network interfaces I got in FreeBSD were ix0 and ix1.

Re: tbird broken

[David Wright]

On Fri 18 Nov 2022 at 23:07:37 (-0500), gene heskett wrote:
> On 11/18/22 19:05, Gareth Evans wrote:
> > > On 18 Nov 2022, at 23:29, gene heskett wrote:
> > > On 11/18/22 15:48, Curt wrote:
> > > > > On 2022-11-18, gene heskett wrote:
> > > > > On 11/18/22 08:05, Jeffrey Walton wrote:
> > > > > > On Thu, Nov 17, 2022 at 11:53 PM gene heskett wrote:
> > > > > > > 
> > > > > > > I've just discovered that either tbird  is busted, or its missing
> > > > > > > whatever it takes to display a properly mimetyped base64 encoded 
> > > > > > > content.
> > > > > > > 
> > > > > > > What do I install to make this work, I'm looking at an empty 
> > > > > > > screen when
> > > > > > > the raw msg has bout 10k of base64'd content.
> > > > > > > 
> > > > > > > bullseye, intel i5, uptodate yesterday.
> > > > > > 
> > > > > > Maybe https://bugzilla.mozilla.org/show_bug.cgi?id=1777439 ?
> > > > > > 
> > > > > > .
> > > > > This seems to be NNTP related. But this is imap email, and no errors 
> > > > > are
> > > > > reported, it simply does not decode and display base64'd content that
> > > > > appears to be properly MIMETYPED, boundary lines present and matched.
> > > > Maybe show the headers of the problem email, because I've read
> > > > Thunderbird is strict in that regard.
> > > 
> > > here is the msg up to the first line of the base64:
> > > Return-Path: 
> > > 
> > > Received: from 216.163.176.191 unverified ([216.163.176.191]) by 
> > > mwde08oc.mail2world.com with Mail2World SMTP Server;
> > > 
> > > Thu, 17 Nov 2022 18:50:54 -0800
> > > 
> > > Received: from [115.124.28.121] (port=37128 
> > > helo=out28-121.mail.aliyun.com)
> > > 
> > > by prd-mail2world-inbound-ash1-018.ash1.cynet with esmtps  (TLS1.2) 
> > > tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> > > 
> > > (Exim 4.94.2)
> > > 
> > > (envelope-from )
> > > 
> > > id 1ovrT7-000c7v-2g
> > > 
> > > for ghesk...@shentel.net; Fri, 18 Nov 2022 02:51:05 +
> > > 
> > > X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R211e2;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047194;MF=c...@omc-stepperonline.com;NM=1;PH=DS;RN=1;RT=1;SR=0;TI=SMTPD_---.QADTSrI_1668739861;
> > > 
> > > Received: from iZuf677iw3xihpZ(mailfrom:c...@omc-stepperonline.com 
> > > fp:SMTPD_---.QADTSrI_1668739861)
> > > 
> > >   by smtp.aliyun-inc.com;
> > > 
> > >   Fri, 18 Nov 2022 10:51:01 +0800
> > > 
> > > Date: Fri, 18 Nov 2022 10:51:01 +0800 (CST)
> > > 
> > > From: c...@omc-stepperonline.com
> > > 
> > > To: gene heskett 
> > > 
> > > Message-ID: <288312227.165.1668739861266@iZuf677iw3xihpZ>
> > > 
> > > Subject: Re:Re: STEPPERONLINE - Enquiry from ghesk...@shentel.net
> > > 
> > > MIME-Version: 1.0
> > > 
> > > Content-Type: multipart/alternative;
> > > 
> > > boundary="=_Part_164_535344686.1668739861264"
> > > 
> > > X-mailer: javamail@rebee
> > > 
> > > X-CTCH-Spam: Unknown
> > > 
> > > X-CTCH-VOD: Unknown
> > > 
> > > x-ctasd: uncategorized
> > > 
> > > x-ctasd-vod: uncategorized
> > > 
> > > X-CTCH-Flags: 0
> > > 
> > > X-CTCH-RefID: 
> > > str=0001.0A742F21.6376F319.001D:SCFSTAT68748618,ss=1,re=-4.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
> > > 
> > > X-CTASD-IP: 115.124.28.121
> > > 
> > > X-CTASD-Sender: c...@omc-stepperonline.com
> > > 
> > > X-OpenTrafficX: clean
> > > 
> > > X-OpenTrafficX-type: clean
> > > 
> > > X-OpenTrafficX-ID: 155810::1668739865-C1AB8BFC-07DF5517/0/0
> > > 
> > > 
> > > 
> > > --=_Part_164_535344686.1668739861264
> > > 
> > > Content-Type: text/plain;charset=UTF-8
> > > 
> > > Content-Transfer-Encoding: base64
> > > 
> > > 
> > > 
> > > 
> > > 
> > > --=_Part_164_535344686.1668739861264
> > > 
> > > Content-Type: text/html;charset=UTF-8
> > > 
> > > Content-Transfer-Encoding: base64
> > > 
> > > 
> > > 
> > > PEhUTUw+PEJPRFk+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwMDA7Ij48c3BhbiBzdHlsZT0iZm9u
> > > 
> > > dC1mYW1pbHk6QXJpYWwsSG
> > > > .
> > > 
> > 
> > Are the blank lines between the headers verbatim from the source?
> > 
> > iirc, headers (that is, the lot of them) are supposed to be terminated by a 
> > blank line (double line break) before message content/multipart 
> > boundaries/blocks begin, so that may be part of the problem.  Do the 
> > headers of other base64 messages look like this?
> > 
> You're right of coarse, and yes, that was a straight copy paste from a
> geany session on the saved message, so all that double line spacing
> was part of the incoming message. So their copy of javamail, whatever
> the heck that is, is sending bogus emails. That double spaced
> mime-boundary is sick bird. I had forgotten that. Thank you for
> reminding me.

This thread obviously moved on while I was on the road, so this
is just a curtesy reply.

It's not uncommon for people to post HTML without any text version
to accompany it, eg, some (but not all) alerts from Bank of America,
and other times the text version can have different information from
the HTML version, but it's rarer to get a 

Re: AW: FIREFOX is killing the whole PC Part III

[Curt]

On 2022-11-20, Schwibinger Michael  wrote:
>
> To avoid problems by surfing
> I tried
> nice.
> No good enough.
>
> I did try
>
> nice -n 19 chromium-browser
>  cpulimit -e chrome -l 30
>
> But this also did not work,
> cause URLS do open other URLs.
>
> I found this.
>
> 2 Questions:
>
> What does it do?
>
> Why does it not work.
>
>
> # Find and limit all child processes of all browsers.
> for name in firefox firefox-esr chromium chrome
> do
> for ppid in $(pgrep "$name")
> do
> cpulimit --pid="$ppid" --limit"$LIMIT" &
> for pid in "$ppid" $(pgrep --parent "$ppid")
> do
> cpulimit --pid="$pid" --limit"$LIMIT" &
> done
> done
> done
>
> Regards Sophie

I suppose it does what it says in the comment at the front, and fails to
work because you need to define $LIMIT beforehand.

  -l, --limit=N
 percentage  of  CPU allowed from 1 up. Usually 1 - 100,
 but can be higher on multi-core CPUs. (mandatory)


  # cpulimit -l 20 firefox
 Launch Firefox web browser and limit its CPU usage to
 20%

Asterisk 20 doesn't include chan_sip.so

[Mark Kamichoff]

Hi - 

I'm not sure if this is a bug or intentional so I figured I'd ask here
first before submitting a bug report.

The Asterisk package in testing (1:20.0.0~dfsg+~cs6.12.40431414-2)
doesn't appear to have chan_sip.so included anymore.  The file is no
longer there so no amount of noload'ing pjsip and load'ing chan_sip
works.  The package for version 18 (1:18.14.0~dfsg+~cs6.12.40431414-1)
has it included.  From my understanding even though chan_sip has been
deprecated in favor of pjsip for a few releases, it is still included
until version 21 (Oct 2023?) where it will be removed completely in
favor of res_pjsip.

I didn't find anything about its removal in changelog or NEWS files.

Can any Asterisk users out there comment if this may have been
intentional or whether this was a miss on the Asterisk 20 package build?

Thanks!

- Mark

-- 
Mark Kamichoff
p...@prolixium.com
https://www.prolixium.com/


signature.asc
Description: PGP signature

Re: CUDA error cudaStreamSynchronize(stream) and CUDA error in ComputeBondedCUDA

[Peter von Kaehne]

I do not know if this would work with this kind of computation but I would 
suggest you try and run the programme under gdb.

This should  tell you where things go wrong. You might have recompile the 
programme and enable debugging symbols 

Peter 

Sent from my phone. Please forgive misspellings and weird “corrections”

> On 20 Nov 2022, at 18:08, Francesco Pietra  wrote:
> 
> 
> Hello
> Main board GA-X79-UD3 with two 680 GPUs
> Debian10 Linux,
> kernel 5.10.0-19-amd64
> OpenGL 4.6.0 
> nvidia driver 470.141.03
> Months ago, following updating/upgrading of amd64, the GPUs, while rendering 
> correctly, became unable to run classical molecular dynamics simulations. 
> Launching a minimization with software NAMD with both GPUs or with one of 
> them (by software or even by removing one GPU)
> 
> namd2 +idlepoll +p12 +devices 0,1 min.conf
> namd2 +idlepoll +p12 +devices 0 min.conf
> namd2 +idlepoll +p12 +devices 1 min.conf
> 
> NAMD organizes the simulation correctly but at the stage of starting the 
> computation, accessing memory, a crash occurs with error
> 
>> TCL: Minimizing for 3000 steps
>> FATAL ERROR: CUDA error cudaStreamSynchronize(stream) in file 
>> src/CudaTileListKernel.cu, function buildTileLists, line 1136
>> on Pe 4 (gig64 device 0 pci 0:2:0): an illegal memory access was encountered
>> FATAL ERROR: CUDA error in ComputeBondedCUDA::forceDoneCheck after polling 
>> 48 times over 0.005047 s on Pe 8 (gig64 device 1 pci 0:3:0): an illegal 
>> memory access was encountered
>> FATAL ERROR: CUDA error cudaStreamSynchronize(stream) in file 
>> src/CudaTileListKernel.cu, function buildTileLists, line 1136
>> on Pe 4 (gig64 device 0 pci 0:2:0): an illegal memory access was encountered
>> FATAL ERROR: CUDA error in ComputeBondedCUDA::forceDoneCheck after polling 
>> 48 times over 0.005047 s on Pe 8 (gig64 device 1 pci 0:3:0): an illegal 
>> memory access was encountered
>> [Partition 0][Node 0] End of program 
> 
> "illegal memory access" is a software error (as also proven by using 
> alternatively one of the two GPUs) that escapes all my attempts at unraveling 
> its origin. I had no clues from NAMD forum. Hope here.
> 
> Thanks for your kind attention
> 
> francesco pietra
> 
> 
> 

AW: FIREFOX is killing the whole PC Part III

[Schwibinger Michael]

To avoid problems by surfing
I tried
nice.
No good enough.

I did try

nice -n 19 chromium-browser
 cpulimit -e chrome -l 30

But this also did not work,
cause URLS do open other URLs.

I found this.

2 Questions:

What does it do?

Why does it not work.


# Find and limit all child processes of all browsers.
for name in firefox firefox-esr chromium chrome
do
for ppid in $(pgrep "$name")
do
cpulimit --pid="$ppid" --limit="$LIMIT" &
for pid in "$ppid" $(pgrep --parent "$ppid")
do
cpulimit --pid="$pid" --limit="$LIMIT" &
done
done
done

Regards Sophie



Von: DdB 
Gesendet: Samstag, 19. November 2022 16:32
An: Schwibinger Michael 
Cc: debian-user 
Betreff: Re: FIREFOX is killing the whole PC

Am 19.11.2022 um 15:04 schrieb Schwibinger Michael:
> Hello
> Thank You.
> I tried
> also with CPU Limit
> bute it did catch the whole CPU:
>
> Where can I delete by terminal the whole cache?
>
> Regards
> Sophie

Hello Sophie!

I suggest you to relax a bit, otherwise your aggressive attempts to
remedy a sim0le problem might cause further havor that can be difficult
to fix later.

You situation is not dramatic, and erasing the cache is possible, but
not meaningful.

Myself, i am using Firefox differently from you, it never reopens
anything due to my settings. But i just tried it and saw, that safe-mode
was in fact not helping. (Sorry for that!)

And i found a proper description of how to fix the problem here


I hope your english will be good enough to understand the approach, and
your computer skill will suffice to execute this remedy.

Otherwise ask again on the list and people will be able to explain it
differently.

best regards, DdB

Re: Intel X540-AT2 and Debian: intermittent connection

[David Christensen]

On 11/20/22 08:25, hw wrote:

On Sun, 2022-11-20 at 12:45 +0100, hw wrote:

[...]
I don't know, I'll try the Debian rescue and FreeBSD when the currently
running
backups are finished.


I booted the Debian rescue and the LEDs on the network cards don't light up and
the link remains down even when I replug the cable.

I rebooted into the installed Debian and the LEDs are back on and the link is up
and I can ping.  After 53 pings, the address is unreachable again.

So I booted FreeBSD and went into the shell.  Dmesg said link up and down from
my plugging and ifconfig kept saying 'no carrier'.  After giving the interface
an IPv6 address with ifconfig it still said no carrier and after replugging the
cable, I could ping 127 times.  Then ping stopped for a few seconds before it
pinged one more time, and now it's stuck.  After a while, it pinged again, and
after another while, ping stopped again.

There are no further messages in dmesg and ifconfig keeps saying the interface
is active even when it doesn't ping.

FreeBSD ping times are about almost 100ms less the ones with Linux.

This is probably not a software issue.  I'll switch cards around in a couple
days or so.  That's gona suck but now I want to know.  Stay tuned ...




Regarding the FreeBSD installer rescue shell/ live CD, I am wondering if 
the device driver is loaded (?).



This is the FreeBSD installer I use:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.3/

FreeBSD-12.3-RELEASE-amd64-memstick.img


Booting and choosing "Welcome" -> "Shell":

# freebsd-version ; uname -a
12.3-RELEASE
FreeBSD  12.3-RELEASE FreeBSD 12.3-RELEASE r371126 GENERIC  amd64

# ls -l /boot/kernel/*ixgbe*
ls: /boot/kernel/*ixgbe*: No such file or directory


Searching, I found:

# ls -l /boot/kernel/if_ix.ko
-r-xr-xr-x  1 root  wheel  351112 Dec  2  2021 /boot/kernel/if_ix.ko

# md5sum /boot/kernel/if_ix.ko
dd37c6a5077ca77289be338566ab3ade  /boot/kernel/if_ix.ko


If I try to load it:

# kldload if_ix
module_register: cannot register pci/ix from if_ix.ko; already loaded 
from kernel

kldload: can't load if_ix: module already loaded or in kernel


Using a recently updated VM:

2022-11-20 09:36:10 toor@f3 ~
# freebsd-version ; uname -a
12.3-RELEASE-p7
FreeBSD f3.tracy.holgerdanske.com 12.3-RELEASE-p6 FreeBSD 
12.3-RELEASE-p6 GENERIC  amd64


2022-11-20 09:36:24 toor@f3 ~
# ll /boot/kernel/if_ix.ko
-r-xr-xr-x  2 root  wheel  351112 2022/01/30 20:50:57 /boot/kernel/if_ix.ko

2022-11-20 09:44:00 toor@f3 ~
# md5sum /boot/kernel/if_ix.ko
dd37c6a5077ca77289be338566ab3ade  /boot/kernel/if_ix.ko

2022-11-20 09:36:29 toor@f3 ~
# kldload if_ix
kldload: can't load if_ix: module already loaded or in kernel


So, it looks like the driver is loaded in 
FreeBSD-12.3-RELEASE-amd64-memstick.img, and the driver has not been 
updated on the 12.3-R branch.



Looking at the FreeBSD download page, the date on the installer is 
2021-Dec-02 06:37.



Looking at the Intel driver page for FreeBSD:

https://www.intel.com/content/www/us/en/download/14303/intel-network-adapters-driver-for-pcie-10-gigabit-network-connections-under-freebsd.html


The tarball is:

ix-3.3.31.tar.gz


I assume the version number is 3.3.31.


STFW for FreeBSD-12.3-RELEASE source code, I see:

https://github.com/freebsd/freebsd-src/tree/releng/12.3/sys/dev/ixgbe


Looking at a few *.h and *.c files, I am unable to find a version number.


Looking at "Intel ® Ethernet Controller Products 27.7 Release Notes" -> 
"2.0 Fixed Issues" -> "2.3 Intel ® Ethernet 500 Series Network 
Adapters", I see:


None for this release.


I am unable to determine if Intel has fixed any device driver bugs for 
the X540-AT2 adapter since FreeBSD-12.3-RELEASE-amd64-memstick.img was 
released.



David

CUDA error cudaStreamSynchronize(stream) and CUDA error in ComputeBondedCUDA

[Francesco Pietra]

Hello
Main board GA-X79-UD3 with two 680 GPUs
Debian10 Linux,
kernel 5.10.0-19-amd64
OpenGL 4.6.0
nvidia driver 470.141.03
--
Months ago, following updating/upgrading of amd64, the GPUs, while
rendering correctly, became unable to run classical molecular dynamics
simulations. Launching a minimization with software NAMD with both GPUs or
with one of them (by software or even by removing one GPU)

namd2 +idlepoll +p12 +devices 0,1 min.conf
namd2 +idlepoll +p12 +devices 0 min.conf
namd2 +idlepoll +p12 +devices 1 min.conf

NAMD organizes the simulation correctly but at the stage of starting the
computation, accessing memory, a crash occurs with error

TCL: Minimizing for 3000 steps
> FATAL ERROR: CUDA error cudaStreamSynchronize(stream) in file
> src/CudaTileListKernel.cu, function buildTileLists, line 1136
> on Pe 4 (gig64 device 0 pci 0:2:0): an illegal memory access was
> encountered
> FATAL ERROR: CUDA error in ComputeBondedCUDA::forceDoneCheck after polling
> 48 times over 0.005047 s on Pe 8 (gig64 device 1 pci 0:3:0): an illegal
> memory access was encountered
> FATAL ERROR: CUDA error cudaStreamSynchronize(stream) in file
> src/CudaTileListKernel.cu, function buildTileLists, line 1136
> on Pe 4 (gig64 device 0 pci 0:2:0): an illegal memory access was
> encountered
> FATAL ERROR: CUDA error in ComputeBondedCUDA::forceDoneCheck after polling
> 48 times over 0.005047 s on Pe 8 (gig64 device 1 pci 0:3:0): an illegal
> memory access was encountered
> [Partition 0][Node 0] End of program
>

"illegal memory access" is a software error (as also proven by using
alternatively one of the two GPUs) that escapes all my attempts at
unraveling its origin. I had no clues from NAMD forum. Hope here.

Thanks for your kind attention

francesco pietra

Re: Intel X540-AT2 and Debian: intermittent connection

[hw]

On Sat, 2022-11-19 at 17:35 -0800, David Christensen wrote:
> On 11/19/22 15:51, hw wrote:
> > On Sat, 2022-11-19 at 13:35 -0800, David Christensen wrote:
> > > On 11/19/22 06:50, hw wrote:
> > > > On Fri, 2022-11-18 at 17:02 -0800, David Christensen wrote:
> > > 
> > > > > ... I suggest trying a Category 6A factory patch cable at least 2
> > > > > meters
> > > > > long.
> > > > 
> > > > I tried it with a 10m cat6 cable and the connection was intermittent. 
> > > > It's
> > > > the
> > > > same (as in "identical to") cable that works between the other server
> > > > and a
> > > > client.
> > > 
> > > 
> > > Okay.  I suggest putting a unique mark/ serial number on each cable for
> > > tracking purposes until you resolve the intermittent connection issue.
> > 
> > What for?  All the cables I used except for the new ones are known good.
> 
> 
> Sanity check/ OCD.  I went through a period with SATA III drive problems 
> and marked all of my SATA cables to help with troubleshooting.

Hm I can see that for when you have so many of them that they're hard to tell
apart.

> [...]
> > > Perhaps that is a good reason to do some devops development -- e.g.
> > > write a data-driven script that reads a configuration file to
> > > interconnect the VM virtual network interfaces and host physical network
> > > interfaces.
> > 
> > Why would I do that?  How would a script figure out which interface is which
> > and
> > how would it guarantee that they will be exactly the same as seen by
> > OPNsense
> > running in that VM when I switch them around?  I'm not saying it's
> > impossible,
> > but I'd rather resolve this problem in a timely manner and not in a couple
> > years
> > when I might have finished the script and tested it in a bunch of servers
> > which
> > aren't even relevant.
> 
> 
> I agree that creating software for devops can be difficult and time 
> consuming, but it is nice to have when done.  I have built up a 
> collection of shell and Perl scripts over the years that are very useful.

I do that when it makes sense, not when it doesn't.  You should try to set up a
VM with OPNsense and a couple network cards you have to pass through so you see
how much fun that is.  It took me a day or two to get it to work stable, and it
was a one-time endevour.  You'd have to have some robot arm to pull the server
from the rack, take off the cover (requires two arms maybe) and have them move
the cards in the PCI slots, controlled by an AI that's acutally smart enough to
understand what it's doing and able to do the testing as well.  Good luck with
programming that :)

> > > > I suspect it's a mainboard issue.
> 
> 
> The clues support that hypothesis.

Or the card is broken.  At least Intel makes cards that appear to behave
somewhat consistently even when they don't work ;)
> > 

> [...]
> > > Did you try the d-i rescue shell
> > 
> > You mean the rescue system that comes with the Debian installer?  No, I
> > haven't.
> > How would that make a difference?
> 
> 
> It would provide data point for troubleshooting.

The LEDs on the cards don't come when the rescue system is running and it
doesn't work at all.

> > > or any live sticks?
> > 
> > only the Fedora one
> 
> 
> That indicates a bad NIC and/or a bad PCIe slot.

Right, FreeBSD also makes an intermittent connection.

> 
> > > > I plugged the Intel card back in and the on-card
> > > > worked again.  I'd try disabling the on-board card but there is no
> > > > option to
> > > > do
> > > > that in the BIOS.
> > > 
> > > Okay.  That indicates the issue is software.
> > 
> > How would it be a software issue affecting a network card from a totally
> > different manufacturer in a PCI slot that the BIOS doesn't have an option to
> > disable the on-board network card?
> 
> 
> Without extensive engineering information and the right test equipment, 
> who knows?

Something that isn't there can't have an effect ...

> > 
> [...]
> It sounds like you could use more spare parts and/or computers.

I already have too many.

> Let us know what happens with the Broadcom card and with whatever BSD 
> you pick (the FreeBSD installer includes a rescue shell and a live system).

ok

Re: Intel X540-AT2 and Debian: intermittent connection

[hw]

On Sun, 2022-11-20 at 12:45 +0100, hw wrote:
> [...]
> I don't know, I'll try the Debian rescue and FreeBSD when the currently
> running
> backups are finished.

I booted the Debian rescue and the LEDs on the network cards don't light up and
the link remains down even when I replug the cable.

I rebooted into the installed Debian and the LEDs are back on and the link is up
and I can ping.  After 53 pings, the address is unreachable again.

So I booted FreeBSD and went into the shell.  Dmesg said link up and down from
my plugging and ifconfig kept saying 'no carrier'.  After giving the interface
an IPv6 address with ifconfig it still said no carrier and after replugging the
cable, I could ping 127 times.  Then ping stopped for a few seconds before it
pinged one more time, and now it's stuck.  After a while, it pinged again, and
after another while, ping stopped again.

There are no further messages in dmesg and ifconfig keeps saying the interface
is active even when it doesn't ping.

FreeBSD ping times are about almost 100ms less the ones with Linux.

This is probably not a software issue.  I'll switch cards around in a couple
days or so.  That's gona suck but now I want to know.  Stay tuned ...

Re: Problem with card reader on Debian 11

[Curt]

On 2022-11-20, Claudia Neumann  wrote:
>
> I read the answer in stackoverflow, but I don't know how I should implement 
> it with /dev/
> ttyACM0.
>

There appears to be a Debian package that contains a utility to read the
German Gesundheitkarte (/usr/bin/egk-tool); maybe du solltest take a gander
at the code (oder something).

https://packages.debian.org/bullseye/opensc

Perhaps you're already aware of all this.

Re: FIREFOX is killing the whole PC Part III

[DdB]

Am 20.11.2022 um 12:06 schrieb Schwibinger Michael:
> 
> 2 Questions:
> 
> What does it do?

The script, that you included, seems to search for a couple of browser
processes to limit their usage of CPU resources.

I do not think, this would be such a great idea.

In order to avoid, that a browser changes your system in any way, you
could do, what i do:

I did locate the places, the browser uses (not just as cache, but also
for storing defaults, history, and such). Then i use a tmpfs to create
an overlay filesystem and allow the browser to change those filesystems
only temporarily.
works as intended, but created problems, if you WANT to change something
(like f.i. download a file).

But this method is a bit difficult to implement for someone, who is
incomfortable with commandline and scripts.

Re: Intel X540-AT2 and Debian: intermittent connection

[hw]

On Sun, 2022-11-20 at 10:46 +0100, hede wrote:
> On Sun, 20 Nov 2022 00:51:20 +0100 hw  wrote:
> 
> > Unfortunately it doesn't work anymore with Fedora either ...  I tried it
> > with a
> > live system if it would work and it didn't.
> 
> The source of connection resets can be diverse.

Is it a connection reset?  I can ping for a short time, then the address is
unreachable, then the pings get through again.

> Sometimes dmesg will show useful info, sometimes not. It can be anything, from
> the link layer (ethernet re-negitiation) to some upper layers (arp, ip, etc.).
> What kind of logs and status apps did you examined already? (dmesg,
> ethtool/mii-tool, syslog, systemd journal, journal for which kind of services,
> etc.)

I checked dmesg and messages and that only shows when the link is up when I
unplug/plug the cable.  Ethtool doesn't show anything special, either.  There
are no services running using the card; it's sole purpose is to make backups
faster via rsync (I don't have a 10GB switch).

> Does the live system use the same kernel as the installed one? That's
> typically not the case as those get updated very frequently. As such the
> driver can still be different. (can, maybe, not a must)

I don't know, I'll try the Debian rescue and FreeBSD when the currently running
backups are finished.

> Does the X540-AT2 uses external or builtin firmware? With external firmware
> even that can differ between systems and firmware is also a potential source
> of connection problems. 

I don't know.  While I was trying to fix the problem, I installed the Linux
firmware package, and there doesn't seem to be a particular card for the card. 
I haven't seen any notices about firmware being loaded and having the firmware
package installed didn't make a difference.


dmesg | grep -i firm
[0.156099] Spectre V2 : Enabling Restricted Speculation for firmware calls
[0.895840] GHES: APEI firmware first mode is enabled by WHEA _OSC.
[3.489013] 3w-sas: scsi0: Firmware FH9X 5.12.00.007, BIOS BE9X 5.11.00.006,
Phys: 8.
[4.689010] 3w-sas: scsi7: Firmware FH9X 5.12.00.007, BIOS BE9X 5.11.00.006,
Phys: 8.


Hm, is it normal for both controllers to say 'Phys: 8'?  They are working fine,
but perhaps they're conflicting with the network card.

> For the cable: my own experience is that with shorter connections the cable is
> more irrelevant. On shorter connections even cat 5 works on 10 GBit. I had to
> use those for some room-to-room connection (wall-moulded cables for fire
> protection between two adjacent rooms, not simply exchangeable). They are
> perfectly working in full speed. So if you tried several cat 6 cables 10 m and
> less, which are working between other systems, I don't think(!) the cable is
> of interest here... 

I don't think so, either.  When you use a short patch cable like 50 or 25cm
there could be issues because those can be of really poor quality; or when you
have 50--100 meters of a quality that works fine up to 30 meters, you might see
transmission errors and delays in the connection.  The shorter cables are
usually fine unless you have that doesn't work at all, but that's easy to figure
out.  Ethernet is remarkably robust, at least with 1GB.

I think that the network card works fine and that the mainboard is having some
issue that somehow sometimes prevents everything from being transmitted through
that card.  I'll find out if the cards works once some parts I'm waiting on have
arrived.  (I could pull the SAS controllers but without them the server is
rather useless because the disks won't be connected ...)

AW: FIREFOX is killing the whole PC PART II

[Schwibinger Michael]

Hello
and thank You.




Thank you, this did help.

Two Questions more.
1
How can I find by terminal all dirt which is produced by browsers (Chrome, 
Firefox, Midori ...)?
I did try something like cache, but there were no new files.

Second Question
How can I tell the browser (Firefox, Chrome and so on): Do not save any 
information.
Example:
I do open www.hotmail.de, sending Emails, and close hotmail.
No there should be no information left on the pc abour hotmail. Only the 
bookmark www.hotmail.de.


Thank you.


Reards,
Sophie



Von: Gareth Evans 
Gesendet: Samstag, 19. November 2022 14:12
An: debian-user@lists.debian.org 
Betreff: Re: FIREFOX is killing the whole PC

On Sat 19 Nov 2022, at 13:14, DdB  
wrote:
> Am 19.11.2022 um 10:34 schrieb Schwibinger Michael:
>> Hello
>>
>> Any idea?
>>
>> What did happen?
>> FF did open a page with bad PC,
>> so it needs 5 minutes to open it.
>> We killed the tab.
>> When we now try to open FF
>> whole PC is blocked.
>> How can we clean FF
>> because bad page is in it.
>>
>> Regards
>> Sophie
>>

> Did you try to start it from the commandline with the option safe-mode?
>
> firefox --safe-mode

If the idea is to prevent previous tabs from opening on startup, that only 
works for me if firefox is already running when I run

firefox --safe-mode

...which may not be possible for Sophie.

Removing the line:

user_pref("browser.startup.page", 3);

from

/home/username/.mozilla/firefox/XXX.default-esr/prefs.js

has the desired effect (where "XXX" is the appropriate string of letters and 
numbers).

There may be more than one such profile directory, in which case, if other 
users don't rely on tabs being restored, then remove that line from all the

XXX.whatever/prefs.js

files you can find.

It may also be necessary to add the line

user_pref("browser.sessionstore.resume_from_crash", false);

I don't know if the order of lines matters.  In my prefs.js, this appears in 
the sequence

user_pref("browser.search.region", "GB");
user_pref("browser.search.widget.inNavBar", true);
user_pref("browser.sessionstore.resume_from_crash", false);

when added from about:config, but the 2nd line is non-default as well as the 
3rd, and these are only present if added manually or set in settings or 
about:config, as appropriate.

Hope that helps
Gareth

Re: net.ipv4.ip_forward=1

[Pierre-Elliott Bécue]

Hello,

Olivier Back my spare  wrote on 20/11/2022 at 
11:26:43+0100:

> Bonjour
>
> J'ai une question. Cela fait des années que je me pose la question sur
> la pertinence de cette commande.
> Énormément de howto sur le net disent qu'il faut décommenter la ligne
> suivante :
> net.ipv4.ip_forward=1
>
> Ce que je ne comprends pas. Si la ligne est commenté par défaut sur
> debian installation basique, pourquoi faut-il le faire.
> Ma question peut paraître idiote. Mais la partie réseau (en général),
> ce n'est pas mon café du matin. Désolé.
>
> Merci par avance.

Cela autorise ta machine à router du trafic qui ne lui est pas destiné.

Tu n'en as besoin que si tu héberges des VMs/conteneurs ou que tu
utilises ta machine comme routeur/pare-feu.

Bien à toi,
-- 
PEB


signature.asc
Description: PGP signature

net.ipv4.ip_forward=1

[Olivier Back my spare]

Bonjour

J'ai une question. Cela fait des années que je me pose la question sur 
la pertinence de cette commande.
Énormément de howto sur le net disent qu'il faut décommenter la ligne 
suivante :

net.ipv4.ip_forward=1

Ce que je ne comprends pas. Si la ligne est commenté par défaut sur 
debian installation basique, pourquoi faut-il le faire.
Ma question peut paraître idiote. Mais la partie réseau (en général), ce 
n'est pas mon café du matin. Désolé.


Merci par avance.

Cdt.

--
Gestionnaire d'infrastructure/ Gestionnaire de parc informatique
"It is possible to commit no errors and still lose. That is not a 
weakness. That is life."

– Captain Jean-Luc Picard to Data

Re: Intel X540-AT2 and Debian: intermittent connection

[hede]

On Sun, 20 Nov 2022 00:51:20 +0100 hw  wrote:

> Unfortunately it doesn't work anymore with Fedora either ...  I tried it with 
> a
> live system if it would work and it didn't.

The source of connection resets can be diverse. Sometimes dmesg will show 
useful info, sometimes not. It can be anything, from the link layer (ethernet 
re-negitiation) to some upper layers (arp, ip, etc.). What kind of logs and 
status apps did you examined already? (dmesg, ethtool/mii-tool, syslog, systemd 
journal, journal for which kind of services, etc.)

Does the live system use the same kernel as the installed one? That's typically 
not the case as those get updated very frequently. As such the driver can still 
be different. (can, maybe, not a must)

Does the X540-AT2 uses external or builtin firmware? With external firmware 
even that can differ between systems and firmware is also a potential source of 
connection problems. 

For the cable: my own experience is that with shorter connections the cable is 
more irrelevant. On shorter connections even cat 5 works on 10 GBit. I had to 
use those for some room-to-room connection (wall-moulded cables for fire 
protection between two adjacent rooms, not simply exchangeable). They are 
perfectly working in full speed. So if you tried several cat 6 cables 10 m and 
less, which are working between other systems, I don't think(!) the cable is of 
interest here... 

hede

Re: Problem with card reader on Debian 11

[Claudia Neumann]

Hi again,

I read the answer in stackoverflow, but I don't know how I should implement it 
with /dev/
ttyACM0.

I don't initiate oder configure /dev/ttyACM0. Ich send my request to the device 
and the
device answers. How would I configure it to answer with 256 Bytes?

Best regards

Claudia

Am Montag, 14. November 2022, 19:19:03 CET schrieb to...@tuxteam.de:
> [CC'ing Claudia per her own wish]
>
> On Sun, Nov 13, 2022 at 04:34:30PM -, Curt wrote:
> > On 2022-11-12, to...@tuxteam.de  wrote:
> > > If that is successful, the next step would be to tell udev to stop
> > > loading that module. But first steps first :)
> >
> > There is an oddly analogous thread (but maybe 64 bytes from ttyacm0 is a
> > thing) below from way back when that incriminates the code, which
> > probably won't be helpful (but we have so many electrons there's really
> > no use being frugal about them):
> >
> > https://stackoverflow.com/questions/18288839/ttyacm0-only-reads-64-bytes
>
> Looks similar, yes. I didn't have the time to dive more into it, may
> be later.
>
> Thanks for the pointer
>
> cheers
> --
> t