similar to: KMS/ drm2 i915 spamming sysctl

[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

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

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

[ 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

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

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

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 =

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,

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,

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

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,

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,

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:

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. >

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

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. >

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

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

> 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

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