[1.] One line summary of the problem:
dmesg tracedumps on rtsx_usb module loading during boot
[2.] Full description of the problem/report:
SD card driver does not work.
I tried to pinpoint commit that caused it in staging tree using git
bisect. But 13 commits between "good" and "bad" would not compile due to
errors.
[3.] Keywords (i.e., modules, networking, kernel):
rtsx_usb dma-mapping usb_hcd_map_urb_for_dma
[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Linux version 5.17.0-12897-g9ae2a143081f (aleksa@artix) (gcc (GCC)
12.1.0, GNU ld (GNU Binutils) 2.38) #2 SMP PREEMPT_DYNAMIC Fri Jul 8
14:25:23 CEST 2022
[4.2.] Kernel .config file:
<attached .config>
[5.] Most recent kernel version which did not have the bug:
5.17.0-12883-g37fcacb50be7
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
37fcacb50be7071d146144a6c5c5bf0194b9a1cf
[6.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/admin-guide/bug-hunting.rst)
<attached decode_stacktrace.log>
[7.] A small shell script or example program which triggers the
problem (if possible)
[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)
<attached ver_linux.log>
[8.2.] Processor information (from /proc/cpuinfo):
<attached cpuinfo.log>
[8.3.] Module information (from /proc/modules):
<attached modules.log>
[8.4.] Loaded driver and hardware information (/proc/ioports,
/proc/iomem)
[8.5.] PCI information ('lspci -vvv' as root)
$ lsusb
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129
Card Reader Controller
[8.6.] SCSI information (from /proc/scsi/scsi)
[8.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
I tried to find that introduced this bug using git bisect but following
13 commits (before 9ae2a143081fa8fba5042431007b33d9a855b7a2) are
unbuildable:
possible first bad commit: [9ae2a143081fa8fba5042431007b33d9a855b7a2]
Merge tag 'dma-mapping-5.18' of
git://git.infradead.org/users/hch/dma-mapping
possible first bad commit: [8ddde07a3d285a0f3cec14924446608320fdc013]
dma-mapping: benchmark: extract a common header file for map_benchmark
definition
possible first bad commit: [80e4390981618e290616dbd06ea190d4576f219d]
dma-debug: fix return value of __setup handlers
possible first bad commit: [f5ff79fddf0efecca538046b5cc20fb3ded2ec4f]
dma-mapping: remove CONFIG_DMA_REMAP
possible first bad commit: [fba09099c6e506608e05e08ac717bf34501f821b]
media: v4l2-pci-skeleton: Remove usage of the deprecated
"pci-dma-compat.h" API
possible first bad commit: [8c155674d9757be855547dc4eb6bcb82d52482e7]
rapidio/tsi721: Remove usage of the deprecated "pci-dma-compat.h" API
possible first bad commit: [0fb3436b4b36cf69f4544385aa2bb8c5a4913509]
sparc: Remove usage of the deprecated "pci-dma-compat.h" API
possible first bad commit: [ffecba83be9c7ced229b9f1d75643d5a49f820c4]
agp/intel: Remove usage of the deprecated "pci-dma-compat.h" API
possible first bad commit: [06cc5cf16591c3b1d63af2bbc9d33a66419ced98]
alpha: Remove usage of the deprecated "pci-dma-compat.h" API
possible first bad commit: [e62c17f0455a74b182ce6373e2777817256afaa1]
MAINTAINERS: update maintainer list of DMA MAPPING BENCHMARK
possible first bad commit: [404f9373c4e5c943ed8a5e71c8dcfef9eddd54ab]
swiotlb: simplify array allocation
possible first bad commit: [c0a4191c27a12d3175283fa33f16db20e91008fd]
swiotlb: tidy up includes
possible first bad commit: [35265899acef135225e946b883fb07acba1d31a2]
swiotlb: simplify debugfs setup
possible first bad commit: [dfcf2e017f5bb928094952d5d56d3566d3d07ba7]
swiotlb: do not zero buffer in set_memory_decrypted()
Errors that occur I had when trying to compile them:
subcmd-util.h:58:31: error: pointer may be used after ‘realloc’
[-Werror=use-after-free]
58 | ret = realloc(ptr, 1);
check.c:2867:58: error: ‘%d’ directive output may be truncated writing
between 1 and 10 bytes into a region of size 9
[-Werror=format-truncation=]
2867 | snprintf(pvname, sizeof(pvname), "pv_ops[%d]",
idx);
Full logs:
<attached full_dmesg_bad.log>
<attached full_dmesg_good.log>
<attached git_bisect.log>
I am willing to help with testing/compiling.
Could you please just point me in the right direction (for example
should i disable -Werror or somthing) for the unbuildable commits to
exacly pinpoint bad commit.
Thanks in advance,
Aleksa Vuckovic
On Fri, Jul 08, 2022 at 03:49:42PM +0200, Aleksa Vučković wrote:
> [1.] One line summary of the problem:
> dmesg tracedumps on rtsx_usb module loading during boot
This should be fixed in linux-next now, right?
Shuah (on cc:) send in some commits to resolve this, look at this
thread:
https://lore.kernel.org/all/[email protected]/
If you could test those 2 patches, that would be great.
thanks,
greg k-h
On 7/8/22 7:53 AM, Greg Kroah-Hartman wrote:
> On Fri, Jul 08, 2022 at 03:49:42PM +0200, Aleksa Vučković wrote:
>> [1.] One line summary of the problem:
>> dmesg tracedumps on rtsx_usb module loading during boot
>
> This should be fixed in linux-next now, right?
>
> Shuah (on cc:) send in some commits to resolve this, look at this
> thread:
> https://lore.kernel.org/all/[email protected]/
>
> If you could test those 2 patches, that would be great.
>
> thanks,
>
> greg k-h
>
Yes. Please test these patches and send me the trace you are seeing
as well. It will help us confirm if it is the same problem or a new
one.
thanks,
-- Shuah
On 22/07/08 01:09PM, Shuah Khan wrote:
> On 7/8/22 7:53 AM, Greg Kroah-Hartman wrote:
> > On Fri, Jul 08, 2022 at 03:49:42PM +0200, Aleksa Vučković wrote:
> > > [1.] One line summary of the problem:
> > > dmesg tracedumps on rtsx_usb module loading during boot
> >
> > This should be fixed in linux-next now, right?
> >
> > Shuah (on cc:) send in some commits to resolve this, look at this
> > thread:
> > https://lore.kernel.org/all/[email protected]/
> >
> > If you could test those 2 patches, that would be great.
I just applied these two patches into staging tree and it seems to fix
dma mapping error. There is no trace dump in dmesg now.
>
> Yes. Please test these patches and send me the trace you are seeing
> as well. It will help us confirm if it is the same problem or a new
> one.
>
> thanks,
> -- Shuah
However, I mistakenly assumed that dmesg trace was also only indicator
that SD card reader does not work. It seems like these two issues are
not connected, both 37fcacb50be7071d146144a6c5c5bf0194b9a1cf (last
commit that does not have trace dump) and this version after patch do
not register SD card.
I will do another bisect to find out which commit actually causes SD
card reader to not register SD cards. I will contact you after I do more
testing.
Sincerely,
Aleksa Vuckovic