Bug#827604: linux-image-4.6.0-1-amd64: Only mounts XFS drive as read-only
I haven't received any further notifications on this bug. This has remained an issue for me for all Linux versions higher than 4.5. Happy Hacking, David E. McMackins II Associate Member, Free Software Foundation (#12889) www.mcmackins.org www.delwink.com www.gnu.org www.fsf.org On 06/18/2016 11:51 AM, Ben Hutchings wrote: > It looks like systemd is failing to remount David's filesystems as > read/write on Linux 4.6, but not on 4.5. > > Can you suggest how to get a log that would help diagnose this? > > Ben. > > On Sat, 2016-06-18 at 09:44 -0500, David McMackins wrote: >> Package: src:linux >> Version: 4.6.2-1 >> Severity: important >> >> Dear Maintainer, >> >> All of the releases of Linux 4.6 in Debian Sid so far have failed to >> mount my primary disk in read-write mode. I have not tested my other XFS >> disks, because failure to correctly mount all my OS partitions causes >> numerous other daemons to fail to start (for instance, NetworkManager). >> >> I'm not really educated on managing the kernel, so I'm not sure what >> logs I'm supposed to be providing here. It should be noted that I can >> only look at historical logs (if they're even kept), because I can only >> submit this report while falling back to Linux 4.5. >> >> Let me know what information I can provide to accelerate the resolution >> of this big problem for me. > >
Processed: [bts-link] source package src:linux
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package src:linux > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # > user bts-link-upstr...@lists.alioth.debian.org Setting user to bts-link-upstr...@lists.alioth.debian.org (was bts-link-de...@lists.alioth.debian.org). > # remote status report for #817063 (http://bugs.debian.org/817063) > # Bug title: Severe performance regression in Infiniband or IPoIB > # * http://bugzilla.kernel.org/show_bug.cgi?id=111921 > # * remote status changed: ASSIGNED -> RESOLVED > # * remote resolution changed: (?) -> CODE-FIX > # * closed upstream > tags 817063 + fixed-upstream Bug #817063 [src:linux] Severe performance regression in Infiniband or IPoIB Added tag(s) fixed-upstream. > usertags 817063 - status-ASSIGNED Usertags were: status-ASSIGNED. Usertags are now: . > usertags 817063 + status-RESOLVED resolution-CODE-FIX There were no usertags set. Usertags are now: resolution-CODE-FIX status-RESOLVED. > thanks Stopping processing here. Please contact me if you need assistance. -- 817063: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817063 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#844530: [1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
Hello,
On Mon, Oct 24, 2016 at 05:05:26PM +0200, Arnd Bergmann wrote:
> This adds an asm/asm-prototypes.h header for ARM to fix the
> broken symbol versioning for symbols exported from assembler
> files.
>
> In addition to the header, we have to do these other small
> changes:
>
> - move the exports from bitops.h to {change,clear,set,...}bit.S
> - move the exports from csumpartialgeneric.S into the files
> including it
>
> I couldn't find the correct prototypes for the compiler builtins,
> so I went with the fake 'void f(void)' prototypes that we had
> before.
>
> This leaves the mmioset/mmiocpy function for now, as it's not
> obvious how to best handle them.
>
> Signed-off-by: Arnd Bergmann
In my test builds of 4.9-rc5 plus
4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm")
cc6acc11cad1 ("kbuild: be more careful about matching preprocessed asm
___EXPORT_SYMBOL")
(which are in -rc6) I got many warnings à la:
WARNING: "memset" [drivers/media/usb/airspy/airspy.ko] has no CRC!
and booting the resulting kernel failed with messages of the type:
[3.024126] usbcore: no symbol version for __memzero
[3.029107] usbcore: Unknown symbol __memzero (err -22)
so hardly any module could be loaded. modprobe -f works however, but
that's not what my initramfs does.
With this patch and https://patchwork.kernel.org/patch/9392291/ ("ARM:
move mmiocpy/mmioset exports to io.c") I could compile a kernel without
CRC warnings and it boots fine. So it would be great to get these two
patches into 4.9.
Thanks
Uwe
signature.asc
Description: PGP signature
Re: Planning for d-i Stretch Alpha 9
Ben Hutchings (2016-11-20): > On Sun, 2016-11-20 at 04:06 +0100, Cyril Brulebois wrote: > [...] > > [Actual question] > > > > I'd like to know whether you already have some kind of planning for the > > next ABI bump(s?) on the linux side, so that we could align further d-i > > releases accordingly. > [...] > > Yes, there will be an ABI bump in the next upload to unstable (probably > within the next week). Thanks! I'll wait for that to happen & migrate to testing before preparing for the next d-i release. KiBi. signature.asc Description: Digital signature
Bug#844530: [1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
On Mon, Nov 21, 2016 at 07:46:44PM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Oct 24, 2016 at 05:05:26PM +0200, Arnd Bergmann wrote:
> > This adds an asm/asm-prototypes.h header for ARM to fix the
> > broken symbol versioning for symbols exported from assembler
> > files.
> >
> > In addition to the header, we have to do these other small
> > changes:
> >
> > - move the exports from bitops.h to {change,clear,set,...}bit.S
> > - move the exports from csumpartialgeneric.S into the files
> > including it
> >
> > I couldn't find the correct prototypes for the compiler builtins,
> > so I went with the fake 'void f(void)' prototypes that we had
> > before.
> >
> > This leaves the mmioset/mmiocpy function for now, as it's not
> > obvious how to best handle them.
> >
> > Signed-off-by: Arnd Bergmann
>
> In my test builds of 4.9-rc5 plus
>
> 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm")
> cc6acc11cad1 ("kbuild: be more careful about matching preprocessed asm
> ___EXPORT_SYMBOL")
>
> (which are in -rc6) I got many warnings à la:
>
> WARNING: "memset" [drivers/media/usb/airspy/airspy.ko] has no CRC!
>
> and booting the resulting kernel failed with messages of the type:
>
> [3.024126] usbcore: no symbol version for __memzero
> [3.029107] usbcore: Unknown symbol __memzero (err -22)
>
> so hardly any module could be loaded. modprobe -f works however, but
> that's not what my initramfs does.
>
> With this patch and https://patchwork.kernel.org/patch/9392291/ ("ARM:
> move mmiocpy/mmioset exports to io.c") I could compile a kernel without
> CRC warnings and it boots fine. So it would be great to get these two
> patches into 4.9.
Yea, many things would be nice, but I've been unable to track the
issues here - it really didn't help _not_ being copied on the
original set of patches which introduced this mess.
I've merged Nicolas' patch, so now we need to work out what to do
with the remaining bits - which I guess are the asm-prototypes.h
and the mmio* bits. I'm not aware of what's happening with the
patches that they depend on (which is why I recently asked the
question - again, I seem to be completely out of the loop due to
lack of Cc's).
So I'm just throwing my hands up and saying "I don't know what to
do" at this stage.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Bug#844530: [1/2] kbuild: provide include/asm/asm-prototypes.h for ARM
On Mon, 21 Nov 2016 19:13:55 +
Russell King - ARM Linux wrote:
> On Mon, Nov 21, 2016 at 07:46:44PM +0100, Uwe Kleine-König wrote:
> > Hello,
> >
> > On Mon, Oct 24, 2016 at 05:05:26PM +0200, Arnd Bergmann wrote:
> > > This adds an asm/asm-prototypes.h header for ARM to fix the
> > > broken symbol versioning for symbols exported from assembler
> > > files.
> > >
> > > In addition to the header, we have to do these other small
> > > changes:
> > >
> > > - move the exports from bitops.h to {change,clear,set,...}bit.S
> > > - move the exports from csumpartialgeneric.S into the files
> > > including it
> > >
> > > I couldn't find the correct prototypes for the compiler builtins,
> > > so I went with the fake 'void f(void)' prototypes that we had
> > > before.
> > >
> > > This leaves the mmioset/mmiocpy function for now, as it's not
> > > obvious how to best handle them.
> > >
> > > Signed-off-by: Arnd Bergmann
> >
> > In my test builds of 4.9-rc5 plus
> >
> > 4efca4ed05cb ("kbuild: modversions for EXPORT_SYMBOL() for asm")
> > cc6acc11cad1 ("kbuild: be more careful about matching preprocessed asm
> > ___EXPORT_SYMBOL")
> >
> > (which are in -rc6) I got many warnings à la:
> >
> > WARNING: "memset" [drivers/media/usb/airspy/airspy.ko] has no CRC!
> >
> > and booting the resulting kernel failed with messages of the type:
> >
> > [3.024126] usbcore: no symbol version for __memzero
> > [3.029107] usbcore: Unknown symbol __memzero (err -22)
> >
> > so hardly any module could be loaded. modprobe -f works however, but
> > that's not what my initramfs does.
> >
> > With this patch and https://patchwork.kernel.org/patch/9392291/ ("ARM:
> > move mmiocpy/mmioset exports to io.c") I could compile a kernel without
> > CRC warnings and it boots fine. So it would be great to get these two
> > patches into 4.9.
>
> Yea, many things would be nice, but I've been unable to track the
> issues here - it really didn't help _not_ being copied on the
> original set of patches which introduced this mess.
Quick overview:
- asm exports changes allow EXPORT_SYMBOL to be moved into .S files,
but they would not get modversion CRCs generated.
- The core kbuild patches to add modversions support for asm exports
is now merged in Linus's tree from the recent kbuild tree pull.
asm/asm-prototypes.h must contain C style declarations of the symbol
for this to work.
- Architectures can now add their asm/asm-prototypes.h and things
*should* start working.
- Dependency is not a hard one. If you add asm-prototypes.h before
merging the core patches then it should not introduce any problems.
> I've merged Nicolas' patch, so now we need to work out what to do
> with the remaining bits - which I guess are the asm-prototypes.h
> and the mmio* bits. I'm not aware of what's happening with the
> patches that they depend on (which is why I recently asked the
> question - again, I seem to be completely out of the loop due to
> lack of Cc's).
>
> So I'm just throwing my hands up and saying "I don't know what to
> do" at this stage.
>
I don't think you have missed much since last it came up, it's just
taken a bit of time to get the details right and get it merged.
Not sure what your tree looks like, but if you merge this patch 1/2
plus 2a/2 or 2b/2 into upstream, then ARM should be working.
Thanks,
Nick
