Displaying 20 results from an estimated 1000 matches similar to: "KMS/ drm2 i915 spamming sysctl"
2010 Dec 15
1
IPSEC allegations
[redirected from -hackers to -security]
Jakub Lach <jakub_lach@mailplus.pl> writes:
> http://marc.info/?l=openbsd-tech&m=129236621626462&w=2
http://maycontaintracesofbolts.blogspot.com/2010/12/openbsd-ipsec-backdoor-allegations.html
DES
--
Dag-Erling Sm?rgrav - des@des.no
2009 Feb 06
1
DRM fills logs
I have a system with 3 video cards; 2 dual-DVI and one single DVI. I'd
like to get nouveau running on this system.
selene:/var/log# lspci | grep VGA
01:07.0 VGA compatible controller: nVidia Corporation NV34GL [Quadro NVS
280 PCI] (rev a1)
02:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro NVS
285] (rev a1)
07:00.0 VGA compatible controller: nVidia Corporation NV44 [Quadro
2012 Dec 10
3
WiFi / Hot-Spot Open Source World
Dear Experts
i am sure many of you would be the part of the real game, where lot of
technology is implemented (Internet Service Providers) those serve
thousands of clients everyday . i am requesting opinion & advice from
those experts. Surfing web does not help much unless someone who is
practically touch and making the use of the technology everyday. And i
could not find the best place than
2009 Apr 27
0
7.2RC2 panic in drm_open_helper on amd64
[ Normally I'd have replied to the original email but I couldn't
figure out a way to subscribe to a list, and then reply to an email
already posted to the list.]
I have this very problem (with a different card):
http://lists.freebsd.org/pipermail/freebsd-stable/2009-April/049618.html
It looks like drm_open_helper() gets a NULL dev parameter and a panic
occurs when it attempts to set
2012 Oct 05
16
FreeBSD 10-CURRENT and 9-STABLE snapshots
Hi,
A number of FreeBSD users have displayed interest in the availability
and testing of -STABLE and -CURRENT snapshot releases.
I have been working on generating snapshots regularly, and now would
like to announce their availability for those interested in testing.
Please note, as always with the -STABLE and -CURRENT branches, these
snapshots are not intended for production systems.
The
2012 Apr 16
1
kldload uhci lockup
I observed that following could cause
machine lockup since at least 8-CURRENT.
Now I'm on 9-STABLE
No usb in kernel, attached mouse pointer.
# kldload usb ums ehci
# kldload uhci
or
# kldload uhci usb ums ehci
uhci is required for working mouse.
Can anyone confirm? Please
test few different iterations, as
it's probably not easily reproducible.
Most times nothing happens, if
2017 Sep 12
0
[PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming
Hi Colin,
On 12 September 2017 at 10:45, Colin King <colin.king at canonical.com> wrote:
> From: Colin Ian King <colin.king at canonical.com>
>
> Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
> log with qxl_mmap information messages. The following example code
> illustrates this:
>
> int main(void)
> {
> int fd =
2017 Sep 12
0
[PATCH][V2] drm: qxl: remove pr_info message, stops log spamming
From: Colin Ian King <colin.king at canonical.com>
Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:
int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");
for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED,
2017 Sep 12
0
[PATCH][V2] drm: qxl: remove pr_info message, stops log spamming
From: Colin Ian King <colin.king at canonical.com>
Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:
int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");
for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED,
2018 Dec 01
0
Mailing list address harvested for spamming
Quoting dovecot-e51 at deemzed.uk:
> Not to stir the pot, but I notice my email address has recently been
> harvested from this list for spamming purposes. This email address is
> unique and not used for anything else.
>
> I'd distinguish this from spam sent to the mailing list itself, which is
> obviously different.
>
> Is there anything further that could be done
2017 Sep 12
2
[PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming
From: Colin Ian King <colin.king at canonical.com>
Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:
int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");
for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED,
2017 Sep 12
2
[PATCH] drm: qxl: ratelimit pr_info message, reduce log spamming
From: Colin Ian King <colin.king at canonical.com>
Simply mmap'ing /dev/dri/card0 repeatedly will spam the kernel
log with qxl_mmap information messages. The following example code
illustrates this:
int main(void)
{
int fd = open("/dev/dri/card0", O_RDONLY);
if (fd == -1)
err(1, "open failed");
for (;;) {
void *m = mmap(NULL, 4096, PROT_READ,
MAP_SHARED,
2016 May 14
1
[Bug 95403] New: [GK110] misaligned_gpr spamming dmesg when playing victor vran
https://bugs.freedesktop.org/show_bug.cgi?id=95403
Bug ID: 95403
Summary: [GK110] misaligned_gpr spamming dmesg when playing
victor vran
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: minor
Priority: medium
Component:
2018 Dec 02
0
Mailing list address harvested for spamming
On Sun, Dec 02, 2018 at 10:09:02AM +1000, Noel Butler wrote:
> On 02/12/2018 05:31, M. Balridge wrote:
>
> > Quoting dovecot-e51 at deemzed.uk:
> >
> >> Not to stir the pot, but I notice my email address has recently been
> >> harvested from this list for spamming purposes. This email address is
> >> unique and not used for anything else.
>
2018 Dec 01
3
Mailing list address harvested for spamming
Not to stir the pot, but I notice my email address has recently been
harvested from this list for spamming purposes. This email address is
unique and not used for anything else.
I'd distinguish this from spam sent to the mailing list itself, which is
obviously different.
Is there anything further that could be done to prevent this?
--
Dave
2023 Aug 08
2
[Bridge] [PATCH v2 00/14] sysctl: Add a size argument to register functions in sysctl
On Mon, Aug 07, 2023 at 07:50:44PM -0700, Chris Maness wrote:
> I tried running the current mainline kernel (current Arch Linux) with
> simple single MUX socket (ax0) using LinFBB. I was a happy camper as
> it seemed to work fine at first, then the system just slowed to a
> crawl. I am wondering if any of these patches are addressing this
> behavior.
If its a regressio no.
>
2023 Aug 08
1
[Bridge] [PATCH v2 00/14] sysctl: Add a size argument to register functions in sysctl
On Mon, 7 Aug 2023 14:44:11 -0700 Luis Chamberlain wrote:
> > This is looking great thanks, I've taken the first 7 patches above
> > to sysctl-next to get more exposure / testing and since we're already
> > on rc4.
>
> Ok I havent't heard much more feedback from networking folks
What did you expect to hear from us?
My only comment is to merge the internal
2023 Aug 07
3
[Bridge] [PATCH v2 00/14] sysctl: Add a size argument to register functions in sysctl
On Mon, Jul 31, 2023 at 02:36:50PM -0700, Luis Chamberlain wrote:
> > Joel Granados (14):
> > sysctl: Prefer ctl_table_header in proc_sysctl
> > sysctl: Use ctl_table_header in list_for_each_table_entry
> > sysctl: Add ctl_table_size to ctl_table_header
> > sysctl: Add size argument to init_header
> > sysctl: Add a size arg to __register_sysctl_table
2023 Jul 31
2
[Bridge] [PATCH v2 00/14] sysctl: Add a size argument to register functions in sysctl
> Joel Granados (14):
> sysctl: Prefer ctl_table_header in proc_sysctl
> sysctl: Use ctl_table_header in list_for_each_table_entry
> sysctl: Add ctl_table_size to ctl_table_header
> sysctl: Add size argument to init_header
> sysctl: Add a size arg to __register_sysctl_table
> sysctl: Add size to register_sysctl
> sysctl: Add size arg to __register_sysctl_init
2023 Aug 07
3
[Bridge] [PATCH v2 00/14] sysctl: Add a size argument to register functions in sysctl
On Mon, Aug 07, 2023 at 04:00:49PM -0700, Chris Maness wrote:
> When are these likely to hit the mainline release code?
linux-next tomorrow. The first 7 patches are scheduled for mainline
as they were merged + tested without any hiccups. These last few patches
I'll wait and see. If nothing blows up on linux-next perhaps I'll
include them to Linux for mainline during the next merge