On 3/10/21 4:48 PM, Hans de Goede wrote:
Hi,
On 3/10/21 9:55 PM, Filipe Laíns wrote:
On Wed, 2021-03-10 at 15:24 -0500, Mark Hounschell wrote:
That is correct, I don't have any buttons bound to keyboard events. With
the original patch the G4(forward) and G5(Backward) buttons work
On 3/10/21 3:24 PM, Mark Hounschell wrote:
On 3/10/21 2:56 PM, Filipe Laíns wrote:
On Wed, 2021-03-10 at 13:55 -0500, Mark Hounschell wrote:
I have been using a Logitech wireless G602 mouse since forever. As of
kernel 5.10.11 I get the following kernel messages;
$dmesg | grep -i logitech
On 3/10/21 2:56 PM, Filipe Laíns wrote:
On Wed, 2021-03-10 at 13:55 -0500, Mark Hounschell wrote:
I have been using a Logitech wireless G602 mouse since forever. As of
kernel 5.10.11 I get the following kernel messages;
$dmesg | grep -i logitech
(snip)
.
.
.
Every mouse event seems to
I have been using a Logitech wireless G602 mouse since forever. As of
kernel 5.10.11 I get the following kernel messages;
$dmesg | grep -i logitech
[7.102140] usb 3-3.4: Manufacturer: Logitech
[ 10.036763] input: Logitech USB Receiver as
/devices/pci:00/:00:08.1/:16:00.3/usb3
Something is amiss. A "make install" of an already compiled 4.18.1
kernel is taking 10 minutes or so. The same thing for a 4.17.14 kernel
takes all of a minute.
And during that 10 minutes
or so we seem hung up on i915.ko
2626 pts/8S+ 0:00 make -f ./scripts/Makefile.build obj=arch/x86/
I'm running a 4.13.13 kernel on an AM4 MSI B350 Tomahawk Arctic MB.
I have a couple of these setups and both do the same. I get this output just
building
a kernel. My drives are older Seagate ST3160815AS, 3.AAD, max UDMA/133
configured
at boot time for UDMA/133 ata1: SATA link up 1.5 Gbps (SStat
With both 4.11 and 4.12 kernels I get the following when doing heavy disk I/O,
like a kernel build with "make -j 15". Even copying the kernel source tree from
one place to another. The hardware is an MSI B350 Tomahawk Arctic MB with 16GB
of memory and a Ryzen 1700 processor. The disk being used
On 11/22/2016 03:45 AM, Joerg Roedel wrote:
On Mon, Nov 21, 2016 at 04:47:59PM -0500, Mark Hounschell wrote:
OK, I did get this message before the reported BUG message.
gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not
allocated [device address=0xffee8000
On 11/21/2016 10:32 AM, Joerg Roedel wrote:
> On Fri, Nov 18, 2016 at 09:04:05AM -0500, Mark Hounschell wrote:
>> OK. It's attached.
>
>> [ 45.033715] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1158
>> check_unmap+0x4ef/0x990
>> [ 45.037651] 3c59x :04:
On 11/17/2016 05:00 PM, Joerg Roedel wrote:
On Thu, Nov 17, 2016 at 04:53:24PM -0500, Mark Hounschell wrote:
On 11/17/2016 04:41 PM, Joerg Roedel wrote:
Hi Mark,
On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote:
Kernel version is 4.8.0. No failure when the IOMMU is disabled
On 11/17/2016 04:41 PM, Joerg Roedel wrote:
Hi Mark,
On Thu, Nov 17, 2016 at 02:13:59PM -0500, Mark Hounschell wrote:
Kernel version is 4.8.0. No failure when the IOMMU is disabled. This
is an out of tree GPL driver using
pci_alloc_consistent/pci_free_consistent. The free causes this.
Can
Kernel version is 4.8.0. No failure when the IOMMU is disabled. This is an out
of tree GPL driver using pci_alloc_consistent/pci_free_consistent. The free
causes this.
The commit is:
2d4c515bf06c9bce87b546279413621f847ef6a3 is the first bad commit
commit 2d4c515bf06c9bce87b546279413621f847ef6a3
On 09/05/2016 12:44 PM, Greg Kroah-Hartman wrote:
4.7-stable review patch. If anyone has any objections, please let me know.
--
From: Jens Axboe
commit 468c298ad3ed3f0d94a65f8ca00f6bfc6c2b4e33 upstream.
This reverts commit ff06db1efb2ad6db06eb5b99b88a0c15a9cc9b0e.
Signed-of
On 08/25/2016 10:41 AM, Jens Axboe wrote:
On 08/25/2016 07:08 AM, Mark Hounschell wrote:
On 08/24/2016 05:11 PM, Jiri Kosina wrote:
On Wed, 24 Aug 2016, Greg Kroah-Hartman wrote:
I have a problem with this patch. It only fixes one of the regressions
caused by the original change to the
On 08/24/2016 05:11 PM, Jiri Kosina wrote:
On Wed, 24 Aug 2016, Greg Kroah-Hartman wrote:
I have a problem with this patch. It only fixes one of the regressions
caused by the original change to the floppy driver. It does not address the
user land breakage of removing the NODELAY flag checks.
On 08/18/2016 09:59 AM, Greg Kroah-Hartman wrote:
4.7-stable review patch. If anyone has any objections, please let me know.
--
From: Jiri Kosina
commit ff06db1efb2ad6db06eb5b99b88a0c15a9cc9b0e upstream.
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-
On 07/12/2016 04:54 AM, Jiri Kosina wrote:
On Mon, 11 Jul 2016, Mark Hounschell wrote:
Well, all that was specified in my original post. I can no longer open the
floppy drive with no floppy media inserted. Worse, I can also no longer open a
floppy with media inserted that is not a "
On 08/22/2016 11:37 AM, Paul E. McKenney wrote:
On Mon, Aug 22, 2016 at 11:12:45AM -0400, Mark Hounschell wrote:
On 08/22/2016 10:48 AM, Paul E. McKenney wrote:
On Mon, Aug 22, 2016 at 05:40:03PM +0800, GeHao Kang wrote:
On Sun, Aug 21, 2016 at 10:53 PM, Paul E. McKenney
wrote:
If latency
On 08/22/2016 10:48 AM, Paul E. McKenney wrote:
On Mon, Aug 22, 2016 at 05:40:03PM +0800, GeHao Kang wrote:
On Sun, Aug 21, 2016 at 10:53 PM, Paul E. McKenney
wrote:
If latency is all you care about, one approach is to map the device
registers into userspace and do the I/O without assistance f
On 08/12/2016 05:37 AM, Jiri Kosina wrote:
On Thu, 11 Aug 2016, Mark Hounschell wrote:
I just tested what is currently in Linus' tree and it does NOT work for
me.
Is there some minimalized reproducer you are seeing the regression with
that you could share?
Thanks,
Your patch is NOT
On 08/11/2016 09:24 AM, Jiri Kosina wrote:
On Wed, 3 Aug 2016, Mark Hounschell wrote:
I'm not sure how to get "for-linus" branch. I don't see it in linux-block.git.
It's there.
A patch for 4.5 would be easy for me though.
Anyway the commit landed in Linus
On 08/02/2016 05:44 AM, Jiri Kosina wrote:
On Wed, 13 Jul 2016, Mark Hounschell wrote:
Alright, so you are basically supplementing O_NDELAY flag in order to
avoid check_disk_change() being called. It's rather a coincidence that
it has worked this way, but I agree with you that we can
On 07/12/2016 04:54 AM, Jiri Kosina wrote:
On Mon, 11 Jul 2016, Mark Hounschell wrote:
Well, all that was specified in my original post. I can no longer open the
floppy drive with no floppy media inserted. Worse, I can also no longer open a
floppy with media inserted that is not a "
On 07/11/2016 11:36 AM, Jiri Kosina wrote:
On Tue, 5 Jul 2016, Mark Hounschell wrote:
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
this is being used setfdprm userspace
Just rejoined the list due to floppy open problems created from 4.4 to
4.5. I found the following email that indicates a fix for one of the
problems.
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It
Just rejoined the list due to floppy open problems created from 4.4 to
4.5. I found the following email that indicates a fix for one of the
problems.
From: Jiri Kosina
Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It
On 03/26/2015 11:52 AM, Joerg Roedel wrote:
Hi Mark,
On Thu, Mar 26, 2015 at 10:58:15AM -0400, Mark Hounschell wrote:
Sorry but CMA was still badly broken. I have a patch below that works.
In which way is it broken? What happens when you try to allocate memory
with dma_alloc_coherent?
I
Hi Joerg,
On 03/26/2015 08:45 AM, Joerg Roedel wrote:
> On Wed, Mar 25, 2015 at 12:36:34PM -0400, Mark Hounschell wrote:
>> BTW, so far the first 2 patches are working well. I was going to
>> wait until the end of the day to report but so far I have been
>> unable to produ
On 03/25/2015 11:13 AM, Joerg Roedel wrote:
Hi again,
On Wed, Mar 25, 2015 at 02:59:37PM +0100, Joerg Roedel wrote:
On Tue, Mar 24, 2015 at 07:57:49AM -0400, Mark Hounschell wrote:
I'll be happy to test it.
Okay, here you go:
git://git.kernel.org/pub/scm/linux/kernel/git
On 03/23/2015 11:03 AM, Joerg Roedel wrote:
Hi Mark,
On Tue, Mar 03, 2015 at 02:36:19PM -0500, Mark Hounschell wrote:
It looks like this problem is NOT a bug with the SCSI aic7xxx driver
after all. I can duplicate this BUG very easily with other hardware.
Simply removing a driver module
On 03/15/2015 08:07 AM, Mark Hounschell wrote:
On 03/14/2015 04:44 AM, Greg KH wrote:
On Fri, Mar 13, 2015 at 04:55:55PM -0400, Mark Hounschell wrote:
On 03/12/2015 12:14 PM, Giedrius Statkevičius wrote:
On 2015.03.12 12:08, Greg KH wrote:
On Mon, Mar 09, 2015 at 06:29:38PM +0200, Giedrius
On 03/14/2015 04:44 AM, Greg KH wrote:
On Fri, Mar 13, 2015 at 04:55:55PM -0400, Mark Hounschell wrote:
On 03/12/2015 12:14 PM, Giedrius Statkevičius wrote:
On 2015.03.12 12:08, Greg KH wrote:
On Mon, Mar 09, 2015 at 06:29:38PM +0200, Giedrius Statkevičius wrote:
Remove BOARD_FAILED and
On 03/12/2015 12:14 PM, Giedrius Statkevičius wrote:
On 2015.03.12 12:08, Greg KH wrote:
On Mon, Mar 09, 2015 at 06:29:38PM +0200, Giedrius Statkevičius wrote:
Remove BOARD_FAILED and don't save dgnc_boards which failed to
initialize.
Assign the result of kzalloc() to brd in dgnc_found_board()
Hi Joerg,
It looks like this problem is NOT a bug with the SCSI aic7xxx driver
after all. I can duplicate this BUG very easily with other hardware.
Simply removing a driver module (whether it its self, has actually used
any of the DMA API or not) that is sitting on the same pci bus as a card
Hi Joerg, Thanks for the response.
On 02/18/2015 01:19 PM, j...@8bytes.org >> Joerg Roedel wrote:
Hi Mark,
On Tue, Feb 17, 2015 at 02:48:03PM -0500, Mark Hounschell wrote:
I understand that AMD IOMMU support is not available for 32-bit
kernels. I believe the INTEL IOMMU is supported
I've searched the Doc tree and web to no avail. I was hoping I might get
some answers to a couple of questions that have arisen as a result of
actually trying to take advantage of the IOMMU in our out of tree GPL
drivers. The AMD IOMMU in particular. I'm currently using the 3.18.x
kernel versi
Sorry for the noise. I've read everything DMA in the kernel Doc dir and
searched the web to no avail. So I thought I might get some useful info
here.
I'm currently using a 3.18.3 (x86_64) kernel on an AMD platform. I am
currently doing 8MB DMAs to and from our device using the in kernel CMA
"
/usr/src/linux-3.18> find drivers/ -type l | xargs ls -al
lrwxrwxrwx 1 markh users 21 Dec 7 17:21
./drivers/gpu/drm/nouveau/core/include/nvif/class.h -> ../../../nvif/class.h
lrwxrwxrwx 1 markh users 21 Dec 7 17:21
./drivers/gpu/drm/nouveau/core/include/nvif/event.h -> ../../../nvif/event.h
lr
On 12/03/2014 06:37 PM, Joe Perches wrote:
On Wed, 2014-12-03 at 21:30 +, Sean Cleator wrote:
A patch to fix the rest of the long line warnings in the dgnc_cls.h file
found by the checkpatch.pl tool
checkpatch is a brainless little tool.
You should prefer to develop a readable style rathe
On 10/29/2014 05:22 AM, Greg KH wrote:
On Sun, Oct 26, 2014 at 11:08:54AM +0900, Daeseok Youn wrote:
Re-arrange the functions for removing forward declarations.
Tested-by: Mark Hounschell
Signed-off-by: Daeseok Youn
---
RESEND: This patch is tested all by Mark.
It is good to merge. Greg
On 10/14/2014 08:01 AM, Mark Hounschell wrote:
On 10/13/2014 10:04 PM, Greg KH wrote:
On Mon, Oct 13, 2014 at 07:56:38AM -0700, Joe Perches wrote:
On Mon, 2014-10-13 at 17:01 +0900, DaeSeok Youn wrote:
Hi,
2014-10-13 12:25 GMT+09:00 Greg KH :
On Mon, Oct 13, 2014 at 11:34:25AM +0900
On 10/13/2014 10:04 PM, Greg KH wrote:
On Mon, Oct 13, 2014 at 07:56:38AM -0700, Joe Perches wrote:
On Mon, 2014-10-13 at 17:01 +0900, DaeSeok Youn wrote:
Hi,
2014-10-13 12:25 GMT+09:00 Greg KH :
On Mon, Oct 13, 2014 at 11:34:25AM +0900, Daeseok Youn wrote:
Re-arrange the functions for remov
On 07/31/2014 07:14 PM, DaeSeok Youn wrote:
Hi, Mark
2014-07-31 21:44 GMT+09:00 Mark Hounschell :
On 07/31/2014 12:02 AM, Daeseok Youn wrote:
When a configration file is parsed with dgap_parsefile(),
makes nodes for saving configrations for board.
Making a node will allocate node memory and
On 07/31/2014 12:02 AM, Daeseok Youn wrote:
When a configration file is parsed with dgap_parsefile(),
makes nodes for saving configrations for board.
Making a node will allocate node memory and strings for saving
configrations with kstrdup().
So these are freed when dgap is unloaded or failed t
On 07/16/2014 09:35 PM, Daeseok Youn wrote:
> When a configration file is parsed with dgap_parsefile(),
> makes nodes for saving configrations for board.
>
> Making a node will allocate node memory and strings for saving
> configrations with kstrdup().
>
> So these are freed when dgap is unloaded
On 07/16/2014 08:42 PM, DaeSeok Youn wrote:
2014-07-16 23:17 GMT+09:00 Mark Hounschell :
On 07/16/2014 05:26 AM, DaeSeok Youn wrote:
2014-07-16 8:50 GMT+09:00 Greg KH :
On Wed, Jul 16, 2014 at 08:21:30AM +0900, DaeSeok Youn wrote:
Hi,
2014-07-16 0:29 GMT+09:00 Greg KH :
On Tue, Jul 15
On 07/16/2014 05:26 AM, DaeSeok Youn wrote:
2014-07-16 8:50 GMT+09:00 Greg KH :
On Wed, Jul 16, 2014 at 08:21:30AM +0900, DaeSeok Youn wrote:
Hi,
2014-07-16 0:29 GMT+09:00 Greg KH :
On Tue, Jul 15, 2014 at 06:11:44PM +0900, Daeseok Youn wrote:
The dgap_err() is printing a message with pr_err
On 07/15/2014 11:30 AM, Greg KH wrote:
On Tue, Jul 15, 2014 at 06:14:25PM +0900, Daeseok Youn wrote:
When a configration file is parsed with dgap_parsefile(),
makes nodes for saving configrations for board.
configuration files should not be parsed in the kernel at all. That
logic should be re
On 05/28/2014 06:11 AM, Dan Carpenter wrote:
> On Wed, May 28, 2014 at 06:29:38PM +0900, DaeSeok Youn wrote:
>>> In your patch it has:
>>> + dgap_tty_uninit(brd, false);
>>>
>>> But it should only be "false" if dgap_tty_init() failed. If
>>> dgap_tty_register_ports() fails then it should be
On 04/25/2014 08:59 AM, Dan Carpenter wrote:
> On Fri, Apr 25, 2014 at 08:29:41AM -0400, Mark Hounschell wrote:
>> On 04/25/2014 07:02 AM, DaeSeok Youn wrote:
>>> Hi, Dan.
>>>
>>> 2014-04-25 18:26 GMT+09:00 Dan Carpenter :
>>>> Mark, maybe you shoul
On 04/25/2014 07:02 AM, DaeSeok Youn wrote:
> Hi, Dan.
>
> 2014-04-25 18:26 GMT+09:00 Dan Carpenter :
>> Mark, maybe you should add yourself to the MAINTAINERS entry for this
>> driver?
>>
I'll look into this. I am clueless on what that would actually mean.
>> On Fri, Apr 25, 2014 at 04:04:59PM
On 03/06/2014 01:17 AM, Daeseok Youn wrote:
coccinelle warning:
drivers/staging/dgap/dgap.c:782:3-7: WARNING:
casting value returned by k[cmz]alloc to (char *) is useless.
drivers/staging/dgap/dgap.c:776:2-16: WARNING:
casting value returned by k[cmz]alloc to (struct board_t *) is useless.
On 12/17/2013 11:00 PM, Mike Galbraith wrote:
On Tue, 2013-12-17 at 16:01 -0500, Mark Hounschell wrote:
I hope it is OK to ask a newbie question here. I'm trying to better
understand the boot process. I can't seem to find where in the kernel
sources the cpu_active_mask (defined in inc
I hope it is OK to ask a newbie question here. I'm trying to better
understand the boot process. I can't seem to find where in the kernel
sources the cpu_active_mask (defined in include/linux/cpumask.h) gets
populated. I can see that it does get populated as it brings cpus online
but it is not
I've been maintaining a couple of Digi International serial port card
(XP and AP) drivers for years now because, well, they just won't do it
anymore. In any case, I'm moving from a 3.4.x kernel, that works just
fine, to a 3.8.8 kernel, that does not. I have code that does something
like this:
I have a wireless-N Linksys router centrally located in my home. I also
have 2 each Linksys E1000 range extenders located at each end of the
house. I have Desktop computers in fixed locations around the house.
Using Network Manager all is well with all of them. I can see all the
Access Points a
On 10/23/2012 02:36 AM, Bruno Prémont wrote:
On Mon, 22 Oct 2012 17:54:26 Mark Hounschell wrote:
Another interesting thing. I changed the boot file to only
"video=HDMI-A-1:e" and the monitor on the DVI port complains about the
resolution being to high. I then put the hdmi cable onto m
Hi Bruno,
On 10/22/2012 01:40 PM, Mark Hounschell wrote:
On 10/22/2012 07:42 AM, Mark Hounschell wrote:
On 10/21/2012 03:18 PM, Bruno Prémont wrote:
Hi Mark,
On Sun, 21 October 2012 Mark Hounschell wrote:
On 10/21/2012 10:58 AM, Bruno Prémont wrote:
On Sun, 21 October 2012 Mark Hounschell
On 10/22/2012 07:42 AM, Mark Hounschell wrote:
On 10/21/2012 03:18 PM, Bruno Prémont wrote:
Hi Mark,
On Sun, 21 October 2012 Mark Hounschell wrote:
On 10/21/2012 10:58 AM, Bruno Prémont wrote:
On Sun, 21 October 2012 Mark Hounschell wrote:
I have a TV that appears to not provide proper
Hi Bruno,
On 10/21/2012 10:58 AM, Bruno Prémont wrote:
Hi mark,
On Sun, 21 October 2012 Mark Hounschell wrote:
I have a TV that appears to not provide proper EDID info to the HDMI or DVI
ports of my Intel DH77DF motherboard. I received some pointers from this
list that pointed me in the
I have a TV that appears to not provide proper EDID info to the HDMI or DVI
ports of my Intel DH77DF motherboard. I received some pointers from this
list that pointed me in the direction of creating my own EDID file and I
now have a binary blob that matches what the service manual says is the
p
On 10/14/2012 04:40 PM, Bruno Prémont wrote:
On Sun, 14 October 2012 Mark Hounschell wrote:
I gave it a try. I don't think it liked my kernel cmdline. dmesg attached.
There is a lot more in there now that nomodeset is gone and the debug is
turned on.
# ls -al /lib/firmware/edid/lg42lb9df
On 10/14/2012 01:22 PM, Bruno Prémont wrote:
Hi Mark,
On Sun, 14 October 2012 Mark Hounschell wrote:
I've taken the EDID data from that service manual. I've looked at the
EDID-Howto for how to specify the connector but all I see is:
"An EDID data set will only be used f
On 10/14/2012 07:03 AM, Bruno Prémont wrote:
On Sun, 14 October 2012 Mark Hounschell wrote:
On 10/14/2012 04:41 AM, Bruno Prémont wrote:
Your best solution is probably to write an EDID blob (or reuse one you find
somewhere) that provides at least one mode matching your TV's native
On 10/14/2012 11:55 AM, Bruno Prémont wrote:
On Sun, 14 October 2012 Daniel Vetter wrote:
On Sun, Oct 14, 2012 at 5:41 PM, Mark Hounschell wrote:
There is something amiss. Here is my i915_pci_probe routine. I Added a
couple more printks. NONE of these show up in dmesg. Not even the "En
On 10/14/2012 07:26 AM, Daniel Vetter wrote:
On Sun, Oct 14, 2012 at 12:20 PM, Mark Hounschell wrote:
Hi Daniel,
cat /proc/cmdline
root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
video=1024x768 noresume splash=silent quiet apm=off nomodeset vga=normal
drm.debug=0xe
On 10/14/2012 07:26 AM, Daniel Vetter wrote:
On Sun, Oct 14, 2012 at 12:20 PM, Mark Hounschell wrote:
Hi Daniel,
cat /proc/cmdline
root=/dev/disk/by-id/ata-INTEL_SSDSC2CW060A3_CVCV205106EB060AGN-part4
video=1024x768 noresume splash=silent quiet apm=off nomodeset vga=normal
drm.debug=0xe
On 10/14/2012 04:41 AM, Bruno Prémont wrote:
Your best solution is probably to write an EDID blob (or reuse one you find
somewhere) that provides at least one mode matching your TV's native mode
(probably full-HD).
Google suggested the following document:
http://www.jordansmanuals.com/ServiceM
On 10/14/2012 04:41 AM, Bruno Prémont wrote:
Hi Mark,
On Sat, 13 October 2012 Mark Hounschell wrote:
On 10/13/2012 02:57 PM, Mark Hounschell wrote:
On 10/12/2012 05:14 PM, Bruno Prémont wrote:
TV - LG 42lb9df
PC - intel DH77DF motherboard
I have another AMD based PC here with an nvidia
On 10/14/2012 04:58 AM, Daniel Vetter wrote:
On Sat, Oct 13, 2012 at 9:17 PM, Mark Hounschell wrote:
One other thing I failed to mention. If i connect the TV HDMI to the Intel
boards DVI port using the adapter, at power up I get all the BIOS messages
and can enter the BIOS and all is fine. But
On 10/13/2012 02:57 PM, Mark Hounschell wrote:
Hi Bruno,
Thanks for the response.
On 10/12/2012 05:14 PM, Bruno Prémont wrote:
Hi Mark,
[CCing intel-gfx]
On Fri, 12 October 2012 Mark Hounschell wrote:
Not sure this is the correct place to ask about a possible drm issue. I
have an intel
On 08/03/2012 09:29 AM, Alan Cox wrote:
assumption that that actually meant they were NOT using GPL symbols.
All symbols in the Linux kernel are to GPL code and all linking dynamic
or otherwise is subject to the GPL licence. That is you need to be able
to show anything non-free linked with it s
On 08/03/2012 01:10 AM, Chris Friesen wrote:
On 08/02/2012 06:19 AM, Mark Hounschell wrote:
This particular driver does in fact build cleanly after changing the GPL
to PROPRIETARY. I haven't actually purchased the product yet so am unable
to load it, but can I assume that if I don
On 08/01/2012 05:43 PM, Alan Cox wrote:
On Wed, 01 Aug 2012 17:24:33 -0400
Mark Hounschell wrote:
What would happen if NVIDIA used this define in their proprietary driver? I
Ask a lawyer but I believe Nvidia has more sense than that both
politically and legally. They walk a very fine line
What would happen if NVIDIA used this define in their proprietary driver? I
ask because I am currently in a situation where I believe I may be about to
use a product that may be doing this very thing. We had to sign a license
agreement to get the kernel driver source for this product. What we
r
Mike Christie wrote:
> Mark Hounschell wrote:
>> Mark Hounschell wrote:
>>> Mike Christie wrote:
>>>> Mike Christie wrote:
>>>>> Mark Hounschell wrote:
>>>>>> I seem to have run into some sort of regression in the SG_IO
>>&
Mark Hounschell wrote:
> Mike Christie wrote:
>> Mike Christie wrote:
>>> Mark Hounschell wrote:
>>>> I seem to have run into some sort of regression in the SG_IO
>>>> interface of 2.6.24.2. I have an application that up until 2.6.24
>>
Mike Christie wrote:
> Mike Christie wrote:
>> Mark Hounschell wrote:
>>> I seem to have run into some sort of regression in the SG_IO
>>> interface of 2.6.24.2. I have an application that up until 2.6.24
>>> worked fine. The 2.6.23.16 kernel works fine.
>
Peter Zijlstra wrote:
> On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:
>
>> As you suggested I'm sending CPU isolation patches for review/inclusion into
>> sched-devel tree. They are against 2.6.25-rc2.
>> You can also pull them from my GIT tree at
>> git://git.kernel.org/pub/scm
Mark Hounschell wrote:
> James Bottomley wrote:
>> On Thu, 2008-02-21 at 10:15 -0500, Mark Hounschell wrote:
>>> I seem to have run into some sort of regression in the SG_IO interface of
>>> 2.6.24.2.
>>> I have an application that up until 2.6.24 worked f
James Bottomley wrote:
> On Thu, 2008-02-21 at 10:15 -0500, Mark Hounschell wrote:
>> I seem to have run into some sort of regression in the SG_IO interface of
>> 2.6.24.2.
>> I have an application that up until 2.6.24 worked fine. The 2.6.23.16 kernel
>> works fin
appreciated
Regards
Mark Hounschell
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Steven Rostedt wrote:
> [CC'd Thomas and Jon]
>
> Thomas, Jon, looks like the someone has the funny interrupt controller.
>
> On Thu, 21 Feb 2008, Mark Hounschell wrote:
>
>> According to /proc/interrupts, every interrupt received by eth1 is also
>> being rece
According to /proc/interrupts, every interrupt received by eth1 is also
being received by the sound card EMU10K1. The problem showed itself
first with this. The sound system was quiet BTW.
It does not happen with 2.6.24 vanilla.
kernel: irq 19: nobody cared (try booting with the "irqpoll" option)
linux-os (Dick Johnson) wrote:
>
> The correct word should be "invalid," in spite of
> the fact that the SCSI committee used invalid syntax.
>
> Alan is right. There is nothing illegal in the kernel
> and if there is, it must be removed as soon as it
> is discovered!
>
il·le·gal (-lgl)
adj.
1
Chris Holvenstot wrote:
> I built 2.6.24-git15 this morning and seem to have picked up a little
> “funny” along the way – occasionally what should be a single key stroke
> ends up spraying multiple characters on to my screen.
>
>
> By this I mean I type “w” and get “w” or whatever.
>
>
Max Krasnyanskiy wrote:
> With CPU isolation
> it's very easy to achieve single digit usec worst case and around 200
> nsec average response times on off-the-shelf
> multi- processor/core systems (vanilla kernel plus these patches) even
> under exteme system load.
Hi Max, could you elaborate on
I'm trying to use an out of kernel GPL driver with the RT-PREEMPT
kernel. Even though this is probably a driver issue I though I'd post it
here in case it might be of interest or if there something I could do to
fix it.
BUG: using smp_processor_id() in preemptible
Feb 2 06:51:08 harley kernel:
[EMAIL PROTECTED] wrote:
> Following patch series extends CPU isolation support. Yes, most people want
> to virtuallize
> CPUs these days and I want to isolate them :).
> The primary idea here is to be able to use some CPU cores as dedicated
> engines for running
> user-space code with minimal k
Mark Hounschell wrote:
> These calls apparently are gone. Can someone tell me why and what are
> the replacements.
>
> Thanks in advance
> Mark
>
I got no response from the glibc people on this and the kernel-newbies
list appears dead so I thought I'd try here sin
Matt Mackall wrote:
> On Thu, Jun 07, 2007 at 06:18:52AM -0400, Mark Hounschell wrote:
>> Matt Mackall wrote:
>>> On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
>>>> On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]>
>>
Matt Mackall wrote:
> On Wed, Jun 06, 2007 at 10:28:28AM -0700, Andrew Morton wrote:
>> On Wed, 06 Jun 2007 09:12:04 -0400 Mark Hounschell <[EMAIL PROTECTED]> wrote:
>>
>>>> As far as a 100% CPU bound task being a valid thing to do, it has been
>>>> do
Mark Hounschell wrote:
> Oleg Nesterov wrote:
>> On 06/02, Mark Hounschell wrote:
>>> Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
>>> c201dbc0 10012 10012
>>> Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
>>> Jun 2 16
Oleg Nesterov wrote:
> On 06/02, Mark Hounschell wrote:
>> Jun 2 16:36:11 harley kernel: ERR!! events/1 flush hang: c201dbc0
>> c201dbc0 10012 10012
>> Jun 2 16:36:11 harley kernel: CURR: 7974 7974 vrsx 93 26
>> Jun 2 16:36:11 harley kernel: wq_barrier_func+0x0/0x
Oleg Nesterov wrote:
> On 06/01, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> On 06/01, Mark Hounschell wrote:
>>>> Ok the prctl never returned. I just replaced the ioctl with it and added
>>>> a printf before and after. I only get the one before.
Oleg Nesterov wrote:
> On 06/01, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> Could you apply the trivial patch below, and change the i/o thread to do
>>>
>>> prctl(1234);// hangs ???
>>> printf(
Oleg Nesterov wrote:
> On 06/01, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> Yes, but see above. flush_scheduled_work() needs a cooperation from events/2
>>> which is bound to CPU 2.
>>>
>> Again I don't understand why flush_scheduled_work() ru
Oleg Nesterov wrote:
> I hope Ingo will correct me if I am wrong,
>
> On 05/31, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> So, the main question is: is it possible that one of RT processes/threads
>>> pins itself
>>> to some CPU and eats 100% cp
Mark Hounschell wrote:
> Oleg Nesterov wrote:
>> On 05/31, Mark Hounschell wrote:
>>> Oleg Nesterov wrote:
>>>> On 05/31, Mark Hounschell wrote:
>>>>> Basically the main RT-process (which is a CPU bound process on
>>>>> processor-2) si
Oleg Nesterov wrote:
> On 05/31, Mark Hounschell wrote:
>> Oleg Nesterov wrote:
>>> On 05/31, Mark Hounschell wrote:
>>>> Basically the main RT-process (which is a CPU bound process on
>>>> processor-2) signals a
>>>> thread to do so
1 - 100 of 120 matches
Mail list logo
