Hi,
Bug 1042892 in nvidia-legacy-390xx-kernel-dkms was fixed on 2 August,
and the packages for amd64 and i386 were built 8 days ago, but they
are still in the "Uploaded" state (contrary to armhf):
https://buildd.debian.org/status/package.php?p=nvidia-graphics-drivers-legacy-390xx
Wh
On Wed, Apr 26, 2023 at 07:11:00PM +0530, karans wrote:
> Dear Debian Team
>
> We have Debian 10 buster based linux OS but we are facing issue after install
> linux
Please contact the support channels for your OS, not for Debian.
> This e-mail is for the sole use of the intended recipient(s) and
compatible drivers for the amdgpu
Thanks & Regards,
Karan Sharma / श्री कर्ण शर्मा
Project Engineer /श्री कर्ण शर्मा
Centre for Development of Advanced Computing(C-DAC) / प्रगत संगणन विकास
केन्द्र(सी-डैक)
Tidel Park”, 8th Floor, “D” Block, (North &South) / “टाइडल पार्क”,8वीं मंजिल,
“ड
Processing control commands:
> reassign -1 installation-reports
Bug #1030280 [general] general: General non-recognized errors (im novice) after
the installation: drivers, battery, booting errors...
Bug reassigned from package 'general' to 'installation-reports'.
Ignoring
hese questions, where appropriate ***
>
>* What led up to the situation?
> After the installation, I proceed to use the hardware and no correct firmware
> had been installed. Couldn't use neither the touchpad, the wifi card (AX200
> Intel) nor several screen caracteristics
installed. Couldn't use neither the touchpad, the wifi card (AX200
Intel) nor several screen caracteristics.
I've tried to install its drivers but they dont work. I think something went
wrong during the installation. Besides, battery is running out quite fast and
fans are most of the time act
Am 28.06.22 um 22:15 schrieb julien.pu...@gmail.com:
Le mardi 28 juin 2022 à 22:08 +0200, Bastian Venthur a écrit :
Wild guess: were your new uploads _*source-only*_ ?
Good point! I totally forgot about that :)
Thanks,
Bastian
--
Dr. Bastian Venthur https://v
On Tue, 2022-06-28 at 22:23 +0200, Paul Gevers wrote:
> There are patches to support throw away binaries, but as far as I'm
> aware they haven't been merged and I don't know the status of the
> patches. That won't remove the need for binary uploads, but it would
> remove the need for a re-uploa
Hi
On 28-06-2022 22:17, Scott Talbert wrote:
All uploads need to be source-only (since
bullseye?).
To be more correct, all package that are intended to migrate to testing
need to be source-only. However, in the review process of NEW binaries,
the upload still needs to contain all (and one ar
Le mardi 28 juin 2022 à 16:17 -0400, Scott Talbert a écrit :
> On Tue, 28 Jun 2022, julien.pu...@gmail.com wrote:
> >
> > Wild guess: were your new uploads _*source-only*_ ?
>
> I looked at a couple of them and they were (source all) so that does
> appear to be the problem. All uploads need to
On Tue, 28 Jun 2022, julien.pu...@gmail.com wrote:
Hi,
sorry I didn't follow the conversation but it seems that all my
Python
packages are still not migrating to testing and I don't really
understand how to fix it. The error I see consistently in my Python
packages is:
> Issues preventing mig
Le mardi 28 juin 2022 à 22:08 +0200, Bastian Venthur a écrit :
> Hi,
>
> sorry I didn't follow the conversation but it seems that all my
> Python
> packages are still not migrating to testing and I don't really
> understand how to fix it. The error I see consistently in my Python
> packages is:
stian
Am 24.05.22 um 20:07 schrieb M. Zhou:
I wonder why an irrelevant package suddenly triggered autoremoval
of a very large portion of packages from testing.
https://udd.debian.org/cgi-bin/autoremovals.cgi
Searched for keyword nvidia-graphics-drivers-tesla-470, and I got
68866 entries. There
On Sun, May 29, 2022 at 01:03:11PM +0530, Pirate Praveen wrote:
> 2022, മേയ് 28 8:42:22 PM IST, Thomas Goirand ൽ എഴുതി
> >On 5/27/22 09:48, Paul Gevers wrote:
> >> Patches welcome. Code is here:
> >> https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl
> >>
2022, മേയ് 28 8:42:22 PM IST, Thomas Goirand ൽ എഴുതി
>On 5/27/22 09:26, Andreas Tille wrote:
>> Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
>>> Would it be possible to manually remove this item from the list that
>>> generates
>>> autoremovals?
>>
>> ... or generate a blackl
On 5/27/22 09:26, Andreas Tille wrote:
Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
Would it be possible to manually remove this item from the list that generates
autoremovals?
... or generate a blacklist of packages that should not trigger those removals.
The autoremoval wa
Hi all,
On 27-05-2022 09:42, Julien Puydt wrote:
... or generate a blacklist of packages that should not trigger
those removals.
That exists: key packages.
Or the removal watcher could have a cap on the number of warnings it
sends per sensible period of time. If it exceeds this numbe
Hi
Le ven. 27 mai 2022 à 09:27, Andreas Tille a écrit :
> Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
> > Would it be possible to manually remove this item from the list that
> generates
> > autoremovals?
>
> ... or generate a blacklist of packages that should not trigger thos
Am Thu, May 26, 2022 at 08:47:20AM +0200 schrieb Nilesh Patra:
> Would it be possible to manually remove this item from the list that generates
> autoremovals?
... or generate a blacklist of packages that should not trigger those removals.
The autoremoval warnings are pretty helpful in general bu
No, see https://bugs.debian.org/1011268 (already linked in the bug report
you replied to).
--
WBR, wRAR
signature.asc
Description: PGP signature
Would it be possible to manually remove this item from the list that generates autoremovals?This is creating an insane amount of noise and emails too.--Best,NileshOn 26/05/22, 12:11 pm Timo Lindfors wrote:
On 5/24/22 21:34, Paul Gevers wrote:
> https://bugs.debian.org/1011268 (but app
Le jeudi 26 mai 2022 à 09:32 +0300, Timo Lindfors a écrit :
>
> On 5/24/22 21:34, Paul Gevers wrote:
> > https://bugs.debian.org/1011268 (but apparently my first assumption
> > was wrong and it's another bug, most likely Simon was right.
>
> Thanks for the link. I was quite puzzled this morning w
On 5/24/22 21:34, Paul Gevers wrote:
https://bugs.debian.org/1011268 (but apparently my first assumption
was wrong and it's another bug, most likely Simon was right.
Thanks for the link. I was quite puzzled this morning when I saw several
removals messages. I guess I should just wait and hop
Hi,
On 24-05-2022 20:07, M. Zhou wrote:
I wonder why an irrelevant package suddenly triggered autoremoval
of a very large portion of packages from testing.
https://udd.debian.org/cgi-bin/autoremovals.cgi
Searched for keyword nvidia-graphics-drivers-tesla-470, and I got
68866 entries. There
I wonder why an irrelevant package suddenly triggered autoremoval
of a very large portion of packages from testing.
https://udd.debian.org/cgi-bin/autoremovals.cgi
Searched for keyword nvidia-graphics-drivers-tesla-470, and I got
68866 entries. There must be something wrong.
https
Description : ODPI-C: Oracle Database Programming Interface for Drivers
and Applications
Oracle Database Programming Interface for C (ODPI-C) is an open source
library of C code that simplifies access to Oracle Database for applications
written in C or C++. It is a wrapper over Oracle Call
Control: reassign -1 debian-installer
Hello,
The installer including firmware is probably easier to use if firmware
is needed during the install.
On Vi, 15 ian 21, 20:04:44, Dave Dyer wrote:
> package: installer
>
> Installing on an old x86 cpu which requires "non free
; * URL : https://github.com/DIGImend/digimend-kernel-drivers
> * License : GPL-2.0+
> Description : Collection of graphics tablet drivers
>
> DIGImend kernel drivers are collection of graphics tablet drivers
> for the Linux kernel.
> .
> The following
accessing Linux kernel cryptographic
drivers
Cryptodev-linux is a device that allows access to Linux kernel
cryptographic drivers; thus allowing of userspace applications to take
advantage of hardware accelerators. Cryptodev-linux is implemented as a
standalone module that requires no
: library to support Octavia provider drivers
This python module provides a python library for Octavia provider driver
developers. Drivers are enabled by entries in the Octavia configuration file.
.
See the provider driver development guide for more information:
.
https
Programming Lang: Python
Description : generate a matrix of pluggable drivers and their support to
an API
This package contains a Sphinx directive that allows creating matrices of
drivers a project contains and which features they support. The directive
takes an INI file with specific syntax
On Mon, Feb 26, 2018 at 10:35:48AM +0100, Christopher Schramm wrote:
> * Package name: irda-dkms
> Version : 0.1
> * URL : https://github.com/cschramm/irda
> * License : GPL
> Programming Lang: C
> Description : IrDA subsystem and devic
Package: wnpp
Severity: wishlist
Owner: Christopher Schramm
* Package name: irda-dkms
Version : 0.1
* URL : https://github.com/cschramm/irda
* License : GPL
Programming Lang: C
Description : IrDA subsystem and device drivers
The IrDA subsystem and
drivers for Lime Microsystems LMS7002M RFIC
The Lime Suite is a collection of tools of software supporting several
hardware platforms including the LimeSDR, drivers for the LMS7002M
transceiver RFIC, and other tools for developing with LMS7-based
hardware. It contains a SoapySDR driver module and
support for SoapySDR
The SoapyOsmo project provides SoapySDR modules to access the OsmoSDR,
Mirics SDR, and RFSpace SDR hardware through the drivers in gr-osmosdr.
This will be maintained in the hamradio team.
Package: wnpp
Owner: Balint Reczey
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name: libopenhmd
Version : 0.2.0
* URL : http://openhmd.net/
* License : BSL-1.0
Programming Lang: FIXME
Description : API and drivers for
Package: wnpp
Severity: wishlist
Owner: Wookey
Package name: mali-driver
Version : 0.1
Upstream Author : ARM Limited
URL :
http://malideveloper.arm.com/develop-for-mali/features/mali-t6xx-gpu-use
r-space-drivers/
License : ARM Proprietary
Programming
licensed under GPL version 2 or newer.
While the downloads on teh Brother website carry hints on the drivers being
proprietary, the seperate files in the packages tell a different story and are
clearly tagged with a DFSG-compatible license.
Getting all those drivers into Debian would now be a
Description: Ceph FS and RBD Linux kernel drivers (DKMS version)
DKMS drivers for Ceph file system and RBD devices.
.
This package provides DKMS kernel modules for Linux Kernel 3.14+.
.
Ceph is a scalable distributed storage system; RBD is a block device
striped across multiple distributed objects in
On 29.09.2013 07:34, Bob Tracy wrote:
> On Sun, Sep 29, 2013 at 04:32:05AM +0100, Ben Hutchings wrote:
>> On Sat, 2013-09-28 at 10:16 -0500, Bob Tracy wrote:
>>> On Sat, Sep 28, 2013 at 02:29:05PM +0100, Jurij Smakov wrote:
On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau
wrote:
> (.
On Sun, Sep 29, 2013 at 04:32:05AM +0100, Ben Hutchings wrote:
> On Sat, 2013-09-28 at 10:16 -0500, Bob Tracy wrote:
> > On Sat, Sep 28, 2013 at 02:29:05PM +0100, Jurij Smakov wrote:
> > > On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau
> > > wrote:
> > > > (...)
> > > > xserver-xorg-video-sis
>
On Sat, 2013-09-28 at 10:16 -0500, Bob Tracy wrote:
> On Sat, Sep 28, 2013 at 02:29:05PM +0100, Jurij Smakov wrote:
> > On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau wrote:
> > > (...)
> > > xserver-xorg-video-sis
> > > (...)
>
> The SiS chipset was, unfortunately, really popular with manufactu
Hey,
Op 28-09-13 17:16, Bob Tracy schreef:
> On Sat, Sep 28, 2013 at 02:29:05PM +0100, Jurij Smakov wrote:
>> On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau wrote:
>>> (...)
>>> xserver-xorg-video-sis
>>> (...)
> The SiS chipset was, unfortunately, really popular with manufacturers of
> relative
be easy to get them to stop FTBFS
>> right now, it doesn't seem worth it to keep all of those drivers around
>> with the maintenance overhead that comes with that if nobody's going to
>> notice anyway. So please speak up if you want to see one of these in
>>
On Sat, Sep 28, 2013 at 02:29:05PM +0100, Jurij Smakov wrote:
> On Thu, Sep 26, 2013 at 10:26 PM, Julien Cristau wrote:
> > (...)
> > xserver-xorg-video-sis
> > (...)
The SiS chipset was, unfortunately, really popular with manufacturers of
relatively expensive micro PeeCees (EzGo, Jadetec, etc.),
them to stop FTBFS
> right now, it doesn't seem worth it to keep all of those drivers around
> with the maintenance overhead that comes with that if nobody's going to
> notice anyway. So please speak up if you want to see one of these in
> jessie.
>
> xserver-xorg-video-a
Hello,
On Thu, 26 Sep 2013 23:26:22 +0200
Julien Cristau wrote:
> xserver-xorg-video-s3
I'd vote for this one, but I can't maintain it, unfortunately.
--
WBR, Andrew
signature.asc
Description: PGP signature
ross-check against the MAINTAINERS file. But at least
some that are listed as maintained there were removed in X11R7.7:
http://www.x.org/releases/X11R7.7/doc/xorg-docs/ReleaseNotes.html#Removed_in_this_Release
> > While it would probably be easy to get them to stop FTBFS
> > right now
feel like it.
> While it would probably be easy to get them to stop FTBFS
> right now, it doesn't seem worth it to keep all of those drivers around
> with the maintenance overhead that comes with that if nobody's going to
> notice anyway.
Sure, although several of them h
e, if you're very lucky they get a release with all the build fixes
once in a while, and it's likely most of them don't have any users
anymore. While it would probably be easy to get them to stop FTBFS
right now, it doesn't seem worth it to keep all of those drivers around
with the
On Fri, Mar 1, 2013 at 4:12 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
> Is it just me or this thread about propietary stuff should not be happening
> here?
http://www.debian.org/social_contract
> It may be just me, yes.
It definitely isn't just you.
--
bye,
pabs
http://wiki.debian.org/P
On Thu 28 Feb 2013 14:46:28 Carlos Alberto Lopez Perez escribió:
> On 28/02/13 15:54, Mikko Rasa wrote:
> > We considered the possibility of updating the DDK to version 1.9, but in
> > the end decided to stay with 1.7. An update of the DDK would involve an
> > unknown amount of work in making the
ou know where I can find a driver built with the DDK
1.9? I'm eager to try it and see if it performs better than the ones
based on DDK 1.7 available.
Is there any distribution or website out there distributing such drivers?
>
> The Ubuntu version does indeed perform poorly, and impr
On 25.02.2013 17:06, Carlos Alberto Lopez Perez wrote:
On 25/02/13 15:09, Mikko Rasa wrote:
On 21.02.2013 19:42, Carlos Alberto Lopez Perez wrote:
On 21/12/12 14:23, Mikko Rasa wrote:
Hi Debian developers,
I'm working as a consultant on a project to develop drivers for the
PowerVR gra
On 25/02/13 15:09, Mikko Rasa wrote:
> On 21.02.2013 19:42, Carlos Alberto Lopez Perez wrote:
>> On 21/12/12 14:23, Mikko Rasa wrote:
>>> Hi Debian developers,
>>>
>>> I'm working as a consultant on a project to develop drivers for the
>>> Pow
On 21.02.2013 19:42, Carlos Alberto Lopez Perez wrote:
On 21/12/12 14:23, Mikko Rasa wrote:
Hi Debian developers,
I'm working as a consultant on a project to develop drivers for the
PowerVR graphics processor in the Cedarview family of Intel Atom
microprocessors in a Debian environment.
On 21/12/12 14:23, Mikko Rasa wrote:
> Hi Debian developers,
>
> I'm working as a consultant on a project to develop drivers for the
> PowerVR graphics processor in the Cedarview family of Intel Atom
> microprocessors in a Debian environment. The current target is Wheezy,
&
On 21.12.2012 21:00, Thomas Goirand wrote:
On 12/21/2012 09:23 PM, Mikko Rasa wrote:
Hi Debian developers,
I'm working as a consultant on a project to develop drivers for the
PowerVR graphics processor in the Cedarview family of Intel Atom
microprocessors in a Debian environment. The cu
On Sat, 2012-12-22 at 03:00 +0800, Thomas Goirand wrote:
> On 12/21/2012 09:23 PM, Mikko Rasa wrote:
> > Hi Debian developers,
> >
> > I'm working as a consultant on a project to develop drivers for the
> > PowerVR graphics processor in the Cedarview family of Int
On 12/21/2012 09:23 PM, Mikko Rasa wrote:
> Hi Debian developers,
>
> I'm working as a consultant on a project to develop drivers for the
> PowerVR graphics processor in the Cedarview family of Intel Atom
> microprocessors in a Debian environment. The current target is
> W
On Fri, 2012-12-21 at 15:03 +0100, Cyril Brulebois wrote:
> Hello Mikko,
>
> Mikko Rasa (21/12/2012):
> > It should be noted that due to licensing issues, the driver will be
> > closed source.
>
> I should note: lol.
>
> > There's also one kernel patch that needs to be applied to Wheezy's
> > k
Note: this is my personal POV, this is not endorsed by anyone except me ;-)
On Fri 21 Dec 2012 10:23:09 Mikko Rasa escribió:
> Hi Debian developers,
[snip]
> On to questions:
>
> 1. Is there any possibility of getting the drivers in the initial Wheezy
> release? If so, what nee
l maintainers
at .
> 1. Is there any possibility of getting the drivers in the initial
> Wheezy release? If so, what needs to happen on our end?
No.
> 2. What about a subsequent update to Wheezy? I wasn't able to find
> information on what kinds of changes are permitted.
Hi Debian developers,
I'm working as a consultant on a project to develop drivers for the
PowerVR graphics processor in the Cedarview family of Intel Atom
microprocessors in a Debian environment. The current target is Wheezy,
and Intel wishes to get the drivers into the official distrib
kernel's Copyright practice. Some files have their own copyright and in
those cases the license is mentioned in the file. All additional work made to
building this package is licensed under the GPLv2.
Programming Lang: C
Description : backported linux wireless drivers
These packages co
drivers glued by the DDE layer
This package would ship recent (2.6.29.6 for now) Linux network drivers
for the Hurd port. These are run in userland processes thanks to the
DDE layer and a port of ddekit provided by the hurd package. It should
permit to completely drop the in-gnumach network drivers
Hi,
Am Montag, den 26.12.2011, 07:12 +0100 schrieb Cyril Brulebois:
> Joachim Breitner (05/08/2011):
> > sounds very interesting. But I wonder if the name could be a bit more
> > specific, like opengl-trace or graphics-api-trace, as it does not seem
> > to trace arbitrary APIs.
>
> Currently I s
Joachim Breitner (05/08/2011):
> sounds very interesting. But I wonder if the name could be a bit more
> specific, like opengl-trace or graphics-api-trace, as it does not seem
> to trace arbitrary APIs.
Currently I see:
| Source: apitrace
| Package: apitrace-gl-tracer
| Package: apitrace-gl-retra
rogramming Lang: C++, Python
> Description : tools for debugging OpenGL applications and drivers
>
> apitrace is a suite of tools for debugging OpenGL applications and drivers.
> It includes a tool to generate a trace of all the OpenGL calls an applicaton
> makes and a tool for repl
: tools for debugging OpenGL applications and drivers
apitrace is a suite of tools for debugging OpenGL applications and drivers.
It includes a tool to generate a trace of all the OpenGL calls an applicaton
makes and a tool for replaying these traces and inspecting the rendering and
OpenGL state
: Binary-only X11 and EGL drivers for NVIDIA Tegra chipset
Description: NVIDIA Tegra binary Xorg driver
This package provides the driver for the graphical unit of
NVIDIA's Tegra chipset.
--
Julian Andres Klode - Debian Developer, Ubuntu Member
See http://wiki.debian.org/JulianAndresKlode and
On Tue, 2011-05-31 at 10:41 +0200, Michalxo wrote:
> Package: general
> Severity: important
>
> Hello,
> I am experiencing some problem with wifi drivers rtl8192ce supported by
> kernel
> 6.38-2-amd64. Waking up from suspend last probably 2-3minutes with all black
> scr
Package: general
Severity: important
Hello,
I am experiencing some problem with wifi drivers rtl8192ce supported by kernel
6.38-2-amd64. Waking up from suspend last probably 2-3minutes with all black
screen. When system finally manages to wake up I see messages about "kernel
bugs report
On Feb 05, Marco d'Itri wrote:
> I cannot even find anymore this i810_tco/i8xx_tco module, so in the next
> udev upload I will remove all watchdog drivers from the blacklist and
> maybe add back the ones reported as broken.
Done, with the exception of iTCO_wdt which is still
Package: wnpp
Severity: wishlist
Owner: "C.J. Adams-Collier"
Owner: "C.J. Adams-Collier"
* Package name : xen-unmodified-drivers
Version : 3.4.3
Upstream Author : Xen developers
* URL : http://www.xen.org/
* License : GPL
Programming L
> Any chances of uploading the new version (after it has stabilized and made
> it to testing) to backports.org?
Sure, I'm currently just waiting for it to migrate.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes
On Fri, 19 Feb 2010, Michael Meskes wrote:
> > For the record, the watchdog daemon seems not to be able to deal with 1Hz
> > cleanly (must have something to do with these zombies it likes to keep
> > around for 1s) in my test boxes. It can do 0.5Hz just fine though.
>
> The latest upload 5.7-4 or
> For the record, the watchdog daemon seems not to be able to deal with 1Hz
> cleanly (must have something to do with these zombies it likes to keep
> around for 1s) in my test boxes. It can do 0.5Hz just fine though.
The latest upload 5.7-4 or an older version? The older versions use sleep()
wh
On Mon, 08 Feb 2010, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Feb 2010, Darren Salt wrote:
> > I demand that Guillem Jover may or may not have written...
> > > On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
> > >> Please keep in mind the OOM killer will only influence watchdog i
: GPL
Programming Lang: C++
Description : implements a KDE configuration GUI for the Wacom drivers
KDE 4 KCModule
This module implements a GUI for the Wacom Linux Drivers and extends it
with profile support to handle different button / pen layouts per profile.
For hardware support have a lo
> If you want to test forking ability just enable test-binary test without
> giving
> it a test-binary or use an empty one. This will make watchdog fork() and react
> if not possible.
Thinking about this some more, the test for an emtpy test-binary is done
*after* the fork, so it should find the
On Tue, 09 Feb 2010, Michael Meskes wrote:
> > drivers have different defaults, and as far as I recall, some of them
> > default to whatever the BIOS or BMC programmed in the watchdog.
> >
> > A period of 1s would be a much safer default on the userland side.
>
&
On Tue, Feb 09, 2010 at 12:57:29PM -0200, Henrique de Moraes Holschuh wrote:
> The kernel drivers don't always expect pats at 0.016Hz by default. Some
That's what it was years ago.
> drivers have different defaults, and as far as I recall, some of them
> default to whate
On Mon, Feb 08, 2010 at 08:54:23PM +0100, Guillem Jover wrote:
> The OOM killer can be disabled for precious processes by writting the
> string "-17" to “/proc//oom_adj”.
Added in git. Thanks for the hint.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|
;t
> > have
> > any report about a spurious reboot, but if you do have some I'd like to
> > learn
> > more about it to see where this problem stems from.
> The kernel drivers don't always expect pats at 0.016Hz by default. Some
> drivers have different
see where this problem stems from.
The kernel drivers don't always expect pats at 0.016Hz by default. Some
drivers have different defaults, and as far as I recall, some of them
default to whatever the BIOS or BMC programmed in the watchdog.
A period of 1s would be a much safer default on the us
TOn Mon, Feb 08, 2010 at 11:44:55PM -0200, Henrique de Moraes Holschuh wrote:
> And while at it, change wd_keepalive and watchdog to default to pat at 1Hz
> instead of 0.1Hz. That will reduce a _lot_ the changes of spurious
> reboots.
This looks like a workaround for some other problem to me. Pat
On Tue, Feb 09, 2010 at 01:20:31AM +, Darren Salt wrote:
> > The OOM killer can be disabled for precious processes by writting the
> > string "-17" to “/proc//oom_adj”.
>
> That sounds to me like a good thing to do by default.
Absolutely agreed. As soon as I find the time.
Michael
--
Michae
On Tue, 09 Feb 2010, Darren Salt wrote:
> I demand that Guillem Jover may or may not have written...
> > On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
> >> Please keep in mind the OOM killer will only influence watchdog if it
> >> happens to kill it. If you happen to run out of memory
I demand that Guillem Jover may or may not have written...
> On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
>> Please keep in mind the OOM killer will only influence watchdog if it
>> happens to kill it. If you happen to run out of memory though, you can
>> tell watchdog to test if e
Package: wnpp
Severity: normal
X-Debbugs-CC: debian-devel@lists.debian.org
Greetings,
I am placing this Request for Help as I can no longer do the majority of
the work on the NVIDIA packages. Although some people have offered time
and work over recent years, there really needs to be another Devel
Hi!
On Mon, 2010-02-08 at 20:15:30 +0100, Michael Meskes wrote:
> Please keep in mind the OOM killer will only influence watchdog if it happens
> to kill it. If you happen to run out of memory though, you can tell watchdog
> to
> test if enough free mem is available.
The OOM killer can be disabl
On Mon, Feb 08, 2010 at 04:12:10PM +, Mark Brown wrote:
> The core problem with watchdog WRT stuff like that that is that it's a
> fairly small program and doesn't monitor the state of the rest of
Plus it locks itself into main memory and will not suffer from swappiness
itself.
> userspace so
On Mon, Feb 08, 2010 at 04:02:17PM +0100, Marco d'Itri wrote:
> I am not aware of any other users of /dev/watchdog.
There used to be other programs accessing it, but maybe they all vanished.
> I use the default configuration. The system is broken enough that new
The default configuration in Debi
On Mon, Feb 08, 2010 at 03:51:24PM +0100, Michael Meskes wrote:
> On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote:
> > (BTW, is there any other watchdog daemon? The watchdog package reliably
> > fails to detect when the system is half-killed by OOM.)
> How about explaing your problem
On Feb 08, Michael Meskes wrote:
> On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote:
> > If the defaults for some drivers are wrong then I can't see why they
> > should not be fixed, but if default configuration parameters are needed
> > then they sho
On Mon, Feb 08, 2010 at 04:45:53AM +0100, Marco d'Itri wrote:
> If the defaults for some drivers are wrong then I can't see why they
> should not be fixed, but if default configuration parameters are needed
> then they should be provided by the watchdog package.
If the watc
On Feb 07, Henrique de Moraes Holschuh wrote:
> I'd rather we had a watchdog mini policy that boils down to:
As the udev and module-init-tools maintainer my goal is to support
automatically loading all the drivers which their maintainers intended
to be automatically loaded and blackli
is one.
I'd rather we had a watchdog mini policy that boils down to:
Watchdog drivers have to default to *at least* N seconds timeout (N can't be
too large, some watchdogs have hardware/firmware limits).
All watchdog-enabled packages have to default to *at most* N/2 seconds
timeout
1 - 100 of 180 matches
Mail list logo
