Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix
compile warnings when using plain integer instead of NULL pointer."):
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL
> pointer
> arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL
> pointer
This warning is simply wrong for this code:
> IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> - 0,
> + NULL,
There is (according to the C language specifications) nothing wrong
with writing 0 for a null pointer.
Nor does CODING_STYLE say that it is forbidden to just write 0.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
Ian Jackson writes ("Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile
warnings when using plain integer instead of NULL pointer."):
> Konrad Rzeszutek Wilk writes ("[Xen-devel] [PATCH 09/10] xen/swiotlb: Fix
> compile warnings when using plain integer instead of NULL pointer."):
> > arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL
> > pointer
> > arch/x86/xen/pci-swiotlb-xen.c:96:1: warning: Using plain integer as NULL
> > pointer
>
> This warning is simply wrong for this code:
>
> > IOMMU_INIT_FINISH(pci_xen_swiotlb_detect,
> > - 0,
> > + NULL,
>
> There is (according to the C language specifications) nothing wrong
> with writing 0 for a null pointer.
>
> Nor does CODING_STYLE say that it is forbidden to just write 0.
Oh wait this is Linux kernel code, not in Xen? Still,
Documentation/CodingStyle doesn't say that NULL is required.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile warnings when using plain integer instead of NULL pointer.
Ian Jackson writes ("Re: [Xen-devel] [PATCH 09/10] xen/swiotlb: Fix compile
warnings when using plain integer instead of NULL pointer."):
> Oh wait this is Linux kernel code, not in Xen? Still,
> Documentation/CodingStyle doesn't say that NULL is required.
Someone on irc found me this rant from Linus:
https://lkml.org/lkml/2004/7/8/7
That suggests that perhaps someone should patch CodingStyle to
document this style requirement.
That someone shouldn't be me because I don't agree with the
requirement and a rationale I'd write for it would come out sounding
sarcastic.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.2.19pre10 panic: skput: over: cD158117:3872 put:3872 dev:10
I recently tried out 2.2.19pre10 because of the VM problems with 2.2.18. The system lasted about 10 hours and then paniced. On the console was: chiark login: kernel panic: skput: over: cD158117:3872 put:3872 dev:10 S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S13 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? S10 Transmit timed out, bad line quality? (This was reported to me by my colo's staff, and was probably transcribed with pencil and paper.) I have a no-name NE2K network card. There were no kernel log messages recorded on disk. Some time after the panic, when I noticed that there was something wrong, the machine was still responding to pings and could still answer new TCP connections, but didn't show any evidence of running any userland code. -chiark:linux-2.2.19pre10-chiark> sh scripts/ver_linux -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) Linux chiark 2.2.18 #2 Wed Feb 14 10:56:04 GMT 2001 i586 unknown Kernel modules found Gnu C 2.95.2 Binutils 2.9.5.0.37 Linux C Library2.1.3 Dynamic linker ldd: version 1.9.11 Procps 2.0.6 Mount 2.10f Net-tools 2.05 Kbd0.99 Sh-utils 2.0 cat: /proc/modules: No such file or directory Modules Loaded -chiark:linux-2.2.19pre10-chiark> This kernel was 2.2.18 + Alan's 19pre10 + a few tuning patches of my own, which are attached below. Also attached, all the kernel messages from the run in question, and my .config. I also have gcc272 installed, and it looks like the kernel was compiled with that. -chiark:linux-2.2.19pre10-chiark> gcc272 --version 2.7.2.3 -chiark:linux-2.2.19pre10-chiark> dpkg -l gcc272 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii gcc272 2.7.2.3-15 The GNU C compiler. -chiark:linux-2.2.19pre10-chiark> The process accounting logs show this immediately before the crash: begin date and time command user grouptty devFSDX sigexit 2001-02-14 00:20:23 adnshost mail mail 6 2001-02-14 00:20:23 adnshost mail mail 3 2001-02-14 00:20:23 adnshost mail mail 6 2001-02-14 00:20:23 adnshost mail mail 6 2001-02-14 00:20:22 adnshost mail mail 0 2001-02-14 00:20:22 adnshost mail mail 6 2001-02-14 00:20:22 adnshost mail mail 0 2001-02-14 00:20:22 adnshost mail mail 0 2001-02-14 00:20:22 adnshost mail mail 0 2001-02-14 00:08:06 proftpd root nogroup FS 0 2001-02-14 00:20:17 adnshost mail mail 6 2001-02-14 00:20:14 identd identd identd S 0 2001-02-14 00:20:14 identd identd identd F 0 2001-02-14 00:20:14 identd identd identd F 0 2001-02-14 00:20:14 identd identd identd F 0 2001-02-14 00:20:14 identd identd identd F 0 2001-02-14 00:20:14 identd identd identd F 0 2001-02-14 00:20:14 identd identd identd F 0 2001-02-14 00:20:12 grep markcmarkcpts/310 2001-02-14 00:20:12 mesg markcmarkcpts/310 2001-02-14 00:20:12 mesg markcmarkcpts/310 2001-02-14 00:20:10 exim mail mail S 0 2001-02-14 00:20:10 exim dh219mail FS 0 2001-02-14 00:20:09 sendmail mail mail S 0 2001-02-14 00:20:09 adnshost mail mail 0 adnshost is mainly called by my rece
linux 2.2.18pre17 + VM-global -7 = `Negative d_count' oops
Andrea Arcangeli writes ("Re: linux 2.2.18-pre17: "Kernel panic: LRU list corrupted""):
> I also included the fix in a new VM-global patch against vanilla 2.2.18pre17
> (the VM-global patch is available as a single patch inside 2.2.18pre17aa1/
> directory too but I have to maintain a separate version of it against clean
> 2.2.18pre17 due silly rejects that I can't avoid)
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre17/VM-global-2.2.18pre17-7.bz2
I've been having apparently VM-related `pauses' with 2.2.17 [1], so I
thought I'd try 2.2.18pre17 with that patch. The results weren't
good: I get many instances of
Negative d_count (-805538369) for [binary garbage]/
followed by an oops. Kernel logfile extract below, uuencoded.
I'm sure I'd be able to reproduce this, but I'd rather not because
this is a production system. ver_linux reports:
chiark:linux-2.2.17-chiark> sh scripts/ver_linux
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux chiark 2.2.17 #2 Thu Oct 26 10:57:45 BST 2000 i586 unknown
Kernel modules 2.3.11
Gnu C 2.95.2
Binutils 2.9.5.0.37
Linux C Library2.1.3
Dynamic linker ldd: version 1.9.11
Procps 2.0.6
Mount 2.10f
Net-tools 2.05
Kbd0.99
Sh-utils 2.0
cat: /proc/modules: No such file or directory
Modules Loaded
chiark:linux-2.2.17-chiark>
I don't know why it says `Kernel modules 2.3.11', since I have
disabled kernel modules completely. My CPU is:
processor : 0
vendor_id : AuthenticAMD
cpu family : 5
model : 8
model name : AMD-K6(tm) 3D processor
stepping: 0
cpu MHz : 350.808
cache size : 64 KB
fdiv_bug: no
hlt_bug : no
sep_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 sep mmx 3dnow
bogomips: 699.60
REPORTING-BUGS wanted me to include /proc/scsi/scsi, so here it is:
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DCAS-34330 Rev: S65A
Type: Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 02 Lun: 00
Vendor: IBM Model: DCAS-34330 Rev: S65A
Type: Direct-AccessANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 04 Lun: 00
Vendor: HP Model: T20 Rev: 3.01
Type: Sequential-AccessANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: IBM Model: DNES-318350W Rev: SA30
Type: Direct-AccessANSI SCSI revision: 03
It might be relevant that a large part of the system's job is to be a
shell account server, and users log in with a variety of mechanisms,
most often OpenSSH (Debian 1.2.3-9). I've not had any reports from
users about sessions randomly dropping, which I might have expected;
however, I did have a number of background cron jobs die in very
strange ways suggesting killing of processes at random.
The system as a whole is largely Debian 2.2, and has 256Mb of RAM and
about 400Mb of swap. It usually runs with about 50-100Mb of swap used
and at a load of somewhere around 1ish during busy periods.
[1] VM lockup problem:
I believe that this is a known problem with the 2.2.x VM ? The
symptoms I have are that under reasonably high but not excessive VM
and/or disk load, the system will freeze for around 10-15 minutes.
Most often this seems to have beeen provoked by a moderately large
(20Mb or so) Emacs doing an auto-save during an otherwise-busy time.
During the lockup network packets are processed - pings receive
replies, and TCP connection attempts succeed, but there is no evidence
of any user-mode executing. After the lockup the system apparently
just resumes where it left off. Sometimes afterwards there is a
message like `VM: do_try_to_free_pages failed for emacs...' but more
often there isn't.
Thanks for your attention,
Ian.
begin 664 chiark-oops
M3V-T(#(U(#$U.C`U.C`U(&-H:6%R:R!K97)N96PZ($%D9&EN9R!3=V%P.B`T
M,#DU.3)K('-W87`M5#E$)%Y0=5Y#,<##N./#7#(Q,?9<
M,C$S1"1>1%PR,#/`7E0Y1"1>4'5>1[C[PUPR,C"XX\-<,C$Q]KA=
M7D$O/$Y53$P^"D]C="`R-2`Q-SHS-CHS,R!C:&EA#H@,#`P,#`P-C0@("!E8G@Z(&-F9F,W,#(P("`@
M96-X.B!C86-C8S`P,"`@(&5D>#H@,#`P,#`P,68*3V-T(#(U(#$W.C,V.C,S
M(&-H:6%R:R!K97)N96PZ(&5S:3H@8V9F8S'!R("AP:60Z(#$X-S`V+"!P5]R96%D*S`O
M,C1=(%M?7V9P=70K-C(O-S)=(%MF<'5T*S(S+S5]H86YD;&5R
M*S5#E$)%Y0=5Y#,<##N./#7#(Q,?9<,C$S1"1>
M1%PR,#/`7E0Y1"1>4'5>1[C[PUPR,C"XX\-<,C$Q]KA=7D$O/$Y5
M3$P^"D]C="`R-2`Q.#HP-SHP-R!C:&EA#H@,#`P,#`P-C0@("!E8G@Z(&-F9F,W,#(P("`@96-X.B!C
M-61E93`P,"`@(&5D>#H@,#`P,#`P,38*3V-T(#(U(#$X.C`W.C`W(&-H:6%R
M:R!K97)N96PZ(&5S:3H@8V9F8S'!R("AP
M:60Z(#(S,C8P+"!P5]R96%D*S`O,C1=(%M?
M7V9P=70K-C(O-S)=(%MF<'5T*S(S
Re: linux 2.2.18pre17 + VM-global -7 = `Negative d_count' oops
Andrea Arcangeli writes ("Re: linux 2.2.18pre17 + VM-global -7 = `Negative d_count'
oops"):
> On Thu, Oct 26, 2000 at 06:37:37PM +0100, Ian Jackson wrote:
> > Negative d_count (-805538369) for [binary garbage]/
> >
> > followed by an oops. Kernel logfile extract below, uuencoded.
>
> Thanks for the feedback.
>
> The oops is forced by the kernel after it sees then wrong negative d_count.
>
> I'd say it's memory corruption, but it doesn't look like a memory bitflip.
>
> I'm almost certain that it's not caused by the VM-global patch.
>
> Which device driver and compiler are you using?
chiark:~> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs
gcc version 2.95.2 2220 (Debian GNU/Linux)
chiark:~> dpkg -l gcc
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii gcc2.95.2-13 The GNU C compiler.
chiark:~>
I've enclosed a copy of `.config' from the 2.2.18pre17+VM-global.
I forgot to mention, and it might be relevant (given that the oops is
in `hung_up_tty_read'), that I'm using a VPN system of my own devising
which gets packets in and out of the kernel by using `slattach' on
pty's; it has no nonstandard kernel component, but probably has some
unusual pty handling behaviour. If you really want to look at what it
does, the source is on ftp.chiark.greenend.org.uk in ipif/service.c
inside /users/ian/userv/userv-utils-0.2.0.tar.gz.
Ian.
#
# Automatically generated by make menuconfig: don't edit
#
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set
#
# Loadable module support
#
# CONFIG_MODULES is not set
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
# CONFIG_BINFMT_MISC is not set
# CONFIG_PARPORT is not set
# CONFIG_APM is not set
# CONFIG_TOSHIBA is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
# CONFIG_BLK_DEV_IDE is not set
# CONFIG_BLK_DEV_HD_ONLY is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_MD=y
# CONFIG_MD_LINEAR is not set
CONFIG_MD_STRIPED=y
# CONFIG_MD_MIRRORING is not set
# CONFIG_MD_RAID5 is not set
# CONFIG_MD_BOOT is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_HD is not set
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK_DEV=y
CONFIG_FIREWALL=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_RTNETLINK=y
CONFIG_NETLINK=y
# CONFIG_IP_MULTIPLE_TABLES is not set
# CONFIG_IP_ROUTE_MULTIPATH is not set
# CONFIG_IP_ROUTE_TOS is not set
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_ROUTE_LARGE_TABLES is not set
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=y
CONFIG_IP_FIREWALL_NETLINK=y
CONFIG_NETLINK_DEV=y
# CONFIG_IP_TRANSPARENT_PROXY is not set
# CONFIG_IP_MASQUERADE is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_ALIAS=y
CONFIG_SYN_COOKIES=y
# CONFIG_INET_RARP is not set
CONFIG_SKB_LARGE=y
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set
#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
#
# SCSI low-level drivers
#
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_IP
Re: Revert c5ad33184354260be6d05de57e46a5498692f6d6 "mm/swap.c: flush lru pvecs on compound page arrival" from stable tree? Was:[osstest-ad...@xenproject.org: [Xen-devel] [linux-4.1 bisection] complet
I see that linux-4.1.y is still at 5880876e9469 which has the serious bug introduced by the backport c5ad33184354 "mm/swap.c: flush lru pvecs on compound page arrival". The analogous problem is also still affecting at least linux-3.18.y. Is there some problem with reverting this patch in the stable branches ? Thanks, Ian.
Re: Wiki for automatic reports / fixes
Luis R. Rodriguez writes ("Wiki for automatic reports / fixes"):
[...]
> While discussing expectations and information about
> reports over these with Valentin it occurred to me information about
> all these may be scattered separately and some developers may be
> surprised when they first get reports / fixes from these sorts of
> testing systems and that perhaps it may be useful if we had a single
> wiki entry point where we could refer folks to the different ongoing
> testing infrastructures out there working upstream.
>
> If we could piggy back off of an already existing wiki then great, but
> if not I was thinking something off of wiki.kernel.org might be good.
> How about tests.wiki.kernel.org ? If such projects don't have a wiki
> they could perhaps use pages off of tests.wiki.kernel.org to elaborate
> and set expectations straight. Thoughts?
To clarify what I think you are suggesting, is to create a new wiki or
wiki page which gives information about automatic tests that are
performed on upstream (or going-upstream) Linux branches ?
I think this is a good idea. I'm not sure how much information we
need for each tester, but a page for each would be about right.
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [SCSI] libsas: Kconfig: Enable SATA compatibility by default
Julian Calaby writes ("Re: [PATCH] [SCSI] libsas: Kconfig: Enable SATA
compatibility by default"):
> On Sat, May 2, 2015 at 12:36 AM, Ian Jackson
> wrote:
> > SATA controllers support SATA disks. The kernel should be able to
>
> Do you mean SAS controllers?
Yes, sorry. Do you want me to resubmit with a fixed commit message ?
Ian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [SCSI] libsas: Kconfig: Enable SATA compatibility by default
SATA controllers support SATA disks. The kernel should be able to drive these, by default. It should not silently (apart from a debugging-only printk) ignore them. Signed-off-by: Ian Jackson CC: James Bottomley CC: Donald D Dugger CC: Pawel Baldysiak CC: Lukasz Dorau CC: Artur Paszkiewicz CC: Ian Campbell CC: Konrad Rzeszutek Wilk CC: Boris Ostrovsky CC: David Vrabel --- drivers/scsi/libsas/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/scsi/libsas/Kconfig b/drivers/scsi/libsas/Kconfig index 9dafe64..16258b0 100644 --- a/drivers/scsi/libsas/Kconfig +++ b/drivers/scsi/libsas/Kconfig @@ -34,6 +34,7 @@ config SCSI_SAS_ATA bool "ATA support for libsas (requires libata)" depends on SCSI_SAS_LIBSAS depends on ATA = y || ATA = SCSI_SAS_LIBSAS + default y help Builds in ATA support into libsas. Will necessitate the loading of libata along with libsas. -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] firmware: qcom_scm: Use proper types for dma mappings
Stephen Boyd writes ("[PATCH 1/3] firmware: qcom_scm: Use proper types for dma
mappings"):
> We need to use the proper types and convert between physical addresses
> and dma addresses here to avoid mismatch warnings. This is especially
> important on systems with a different size for dma addresses and
> physical addresses. Otherwise, we get the following warning:
Thanks. Do you expect this to be a backport candidate and if so how
far back do you think it will go ? To be honest, I am not really
convinced that backporting this would be a service to users. The
situation I have, where I changed the compiler but kept the old kernel
code and old configuration, is going to be fairly rare.
I think I should probably therefore disable this driver in the config
on stable branches of Linux, at least.
Thanks,
Ian.
Re: qcom_scm: Incompatible pointer type build failure
Julien Grall writes ("qcom_scm: Incompatible pointer type build failure"):
> Thank you for the report.
...>
> On 30/04/2019 13:44, Ian Jackson wrote:
> > osstest service owner writes ("[linux-4.19 test] 135420: regressions -
> > FAIL"):
> >drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’:
> >drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of
> > ‘dma_alloc_coherent’ from incompatible pointer type
> > [-Werror=incompatible-pointer-types]
...
> > I think this build failure is probably a regression; rather it is due
> > to the stretch update which brings in a new compiler.
>
> The bug has always been present (and still present in master), it is possible
> the compiler became smarter with the upgrade to stretch.
>
> The problem is similar to [1] and happen when the size of phys_addr_t is
> different to dma_addr_t.
>
> I have CCed the maintainers of this file.
That was several weeks ago and osstest is still blocked on this.
Can you please advise what CONFIG_* to disable to work around this ?
Ian.
[OSSTEST PATCH] ts-kernel-build: Disable CONFIG_ARCH_QCOM in Xen Project CI
drivers/firmware/qcom_scm.c:469:47: error: passing argument 3 of `dma_alloc_coherent' from incompatible pointer type [-Werror=incompatible-pointer-types] This is fixed by firmware: qcom_scm: Use proper types for dma mappings but this is not present in all relevant stable branches. We currently have no Qualcomm hardware in the Xen Project test lab so we do not need this enabled. CC: Julien Grall CC: linux-arm-...@vger.kernel.org CC: linux-kernel@vger.kernel.org CC: Stephen Boyd CC: Andy Gross CC: Bjorn Andersson CC: Avaneesh Kumar Dwivedi Signed-off-by: Ian Jackson --- ts-kernel-build | 4 1 file changed, 4 insertions(+) diff --git a/ts-kernel-build b/ts-kernel-build index f7d059b0..5536586f 100755 --- a/ts-kernel-build +++ b/ts-kernel-build @@ -274,6 +274,10 @@ setopt CONFIG_MDIO_THUNDER=m setopt CONFIG_I2C_THUNDERX=m setopt CONFIG_SPI_THUNDERX=m +# Some Linux branches we care about, including 4.19, still lack +# firmware: qcom_scm: Use proper types for dma mappings +CONFIG_ARCH_QCOM=n + END -- 2.11.0
ufs build failure (no __udivdi3) on i386 in linux tip (edf9364d3f92)
osstest service owner writes ("[linux-linus bisection] complete
build-i386-pvops"):
> branch xen-unstable
> xenbranch xen-unstable
> job build-i386-pvops
> testid kernel-build
>
> Tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
>
> *** Found and reproduced problem changeset ***
>
> Bug is in tree: linux
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> Bug introduced: edf9364d3f924aff6f77176b8e52a4b68e5c30d6
> Bug not present: 791a9a666d1afe2603bcb2c6a4852d684e879252
> Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/110566/
This is a merge commit, so the bisection result is not very useful:
git-log --pretty=oneline
791a9a666d1afe2603bcb2c6a4852d684e879252..edf9364d3f924aff6f77176b8e52a4b68e5c30d6
| wc -l
2233
The error message is this:
ERROR: "__udivdi3" [fs/ufs/ufs.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
I searched the commit log and CC'd a couple of people who have fixed
similar bugs elsewhere.
Ian.
