Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels

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

Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels

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

Re: Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels

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

Logitech G602 wireless mouse kernel error messages in 5.10.11+ kernels

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

4.18.1 "make install" issue

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

4.18.1 "make install" issue

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

AM4 B350 chipset Sata/IDE problem

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

AM4 B350 chipset Sata/IDE problem

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

ata1.00: failed command: WRITE FPDMA QUEUED on new AMD AM4 MSI B350 Motherboard

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

ata1.00: failed command: WRITE FPDMA QUEUED on new AMD AM4 MSI B350 Motherboard

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

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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:04.0:

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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:04.0:

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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

Re: BUG at drivers/iommu/amd_iommu.c:1436!

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

BUG at drivers/iommu/amd_iommu.c:1436!

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

BUG at drivers/iommu/amd_iommu.c:1436!

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

Re: [PATCH 4.7 114/143] Revert "floppy: fix open(O_ACCMODE) for ioctl-only open"

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

Re: [PATCH 4.7 114/143] Revert "floppy: fix open(O_ACCMODE) for ioctl-only open"

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.

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

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

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

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

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

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.

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

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.

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

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

Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

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

Re: Resend: Another 4.4 to 4.5 floppy issue

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 "

Re: Resend: Another 4.4 to 4.5 floppy issue

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 "

Re: Context switch latency in tickless isolated CPU

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

Re: Context switch latency in tickless isolated CPU

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

Re: Context switch latency in tickless isolated CPU

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

Re: Context switch latency in tickless isolated CPU

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

Re: Resend: Another 4.4 to 4.5 floppy issue

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

Re: Resend: Another 4.4 to 4.5 floppy issue

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

Re: Resend: Another 4.4 to 4.5 floppy issue

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' tree already

Re: Resend: Another 4.4 to 4.5 floppy issue

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' tree already

Re: Resend: Another 4.4 to 4.5 floppy issue

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't ignore

Re: Resend: Another 4.4 to 4.5 floppy issue

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't ignore

Re: Resend: Another 4.4 to 4.5 floppy issue

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 "

Re: Resend: Another 4.4 to 4.5 floppy issue

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 "

Re: Resend: Another 4.4 to 4.5 floppy issue

On 07/11/2016 11:36 AM, Jiri Kosina wrote: On Tue, 5 Jul 2016, Mark Hounschell wrote: From: Jiri Kosina <jkos...@suse.cz> 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 bei

Re: Resend: Another 4.4 to 4.5 floppy issue

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

Resend: Another 4.4 to 4.5 floppy issue

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,

Resend: Another 4.4 to 4.5 floppy issue

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.

Another 4.4 to 4.5 floppy issue

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,

Another 4.4 to 4.5 floppy issue

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.

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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 p

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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 produce the problems I was seeing

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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/joro

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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/joro

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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

Re: [PATCH v2] dgnc: Don't save boards in memory that have failed to initialize

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

Re: [PATCH v2] dgnc: Don't save boards in memory that have failed to initialize

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

Re: [PATCH v2] dgnc: Don't save boards in memory that have failed to initialize

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

Re: [PATCH v2] dgnc: Don't save boards in memory that have failed to initialize

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

Re: [PATCH v2] dgnc: Don't save boards in memory that have failed to initialize

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

Re: [PATCH v2] dgnc: Don't save boards in memory that have failed to initialize

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

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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

Re: BUG: SCSI aic7xxx driver and AMD IOMMU

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

Re: IOMMU/DMA API inquiry

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 sup

Re: IOMMU/DMA API inquiry

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

IOMMU/DMA API inquiry

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

IOMMU/DMA API inquiry

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

dma_alloc_coherent - cma - and IOMMU question

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

dma_alloc_coherent - cma - and IOMMU question

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

nouveau: Do you really want these new links in the kernel tree?

/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

nouveau: Do you really want these new links in the kernel tree?

/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

Re: [PATCH v2] Staging: dgnc: Fix long line coding style issues in dgnc_cls.h

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

Re: [PATCH v2] Staging: dgnc: Fix long line coding style issues in dgnc_cls.h

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

Re: [PATCH RESEND] staging: dgap: re-arrange functions for removing forward declarations

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

Re: [PATCH RESEND] staging: dgap: re-arrange functions for removing forward declarations

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 ma...@compro.net Signed-off-by: Daeseok Youn daeseok.y...@gmail.com --- RESEND: This patch is tested all

Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.

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

Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.

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 gre...@linuxfoundation.org: On Mon, Oct 13, 2014

Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.

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

Re: [PATCH] staging: dgap: re-arrange functions for removing forward declarations.

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 gre...@linuxfoundation.org: On Mon, Oct 13, 2014 at 11:34:25AM +0900, Daeseok Youn wrote:

Re: [PATCH V2] staging: dgap: introduce dgap_cleanup_nodes()

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

Re: [PATCH V2] staging: dgap: introduce dgap_cleanup_nodes()

On 07/31/2014 07:14 PM, DaeSeok Youn wrote: Hi, Mark 2014-07-31 21:44 GMT+09:00 Mark Hounschell ma...@compro.net: 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

Re: [PATCH V2] staging: dgap: introduce dgap_cleanup_nodes()

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

Re: [PATCH V2] staging: dgap: introduce dgap_cleanup_nodes()

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

Re: [PATCH] staging: dgap: introduce dgap_cleanup_nodes()

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

Re: [PATCH 6/8 V2] staging: dgap: remove unneeded dgap_err()

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

Re: [PATCH 6/8 V2] staging: dgap: remove unneeded dgap_err()

On 07/16/2014 08:42 PM, DaeSeok Youn wrote: 2014-07-16 23:17 GMT+09:00 Mark Hounschell ma...@compro.net: On 07/16/2014 05:26 AM, DaeSeok Youn wrote: 2014-07-16 8:50 GMT+09:00 Greg KH gre...@linuxfoundation.org: On Wed, Jul 16, 2014 at 08:21:30AM +0900, DaeSeok Youn wrote: Hi, 2014-07-16

Re: [PATCH] staging: dgap: introduce dgap_cleanup_nodes()

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 or

Re: [PATCH 6/8 V2] staging: dgap: remove unneeded dgap_err()

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

Re: [PATCH 7/8 RESEND] staging: dgap: introduce dgap_cleanup_nodes()

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: [PATCH 7/8 RESEND] staging: dgap: introduce dgap_cleanup_nodes()

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: [PATCH 6/8 V2] staging: dgap: remove unneeded dgap_err()

On 07/16/2014 05:26 AM, DaeSeok Youn wrote: 2014-07-16 8:50 GMT+09:00 Greg KH gre...@linuxfoundation.org: On Wed, Jul 16, 2014 at 08:21:30AM +0900, DaeSeok Youn wrote: Hi, 2014-07-16 0:29 GMT+09:00 Greg KH gre...@linuxfoundation.org: On Tue, Jul 15, 2014 at 06:11:44PM +0900, Daeseok Youn

Re: [PATCH V2] staging: dgap: implement proper error handling in dgap_firmware_load()

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

Re: [PATCH V2] staging: dgap: implement proper error handling in dgap_firmware_load()

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

Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()

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

Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()

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

Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()

On 04/25/2014 07:02 AM, DaeSeok Youn wrote: Hi, Dan. 2014-04-25 18:26 GMT+09:00 Dan Carpenter dan.carpen...@oracle.com: 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

Re: [PATCH] staging: dgap: implement error handling in dgap_tty_register()

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 dan.carpen...@oracle.com: Mark, maybe you should add yourself to the MAINTAINERS entry

Re: [PATCH] staging: dgap: remove useless cast on kzalloc()

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.

Re: [PATCH] staging: dgap: remove useless cast on kzalloc()

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.

  1   2   3   >