Bug#764263: linux-image-3.16-2-amd64: WARNING at drivers/base/firmware_class.c:1109 _request_firmware+0x521/0xaf0() [btusb?]
Ben Hutchings writes:
> On Mon, 2014-10-06 at 20:15 +0200, Julien Cristau wrote:
>> Package: src:linux
>> Version: 3.16.3-2
>> Severity: normal
>>
>> Hi,
>>
>> I get the following trace in my kernel log, which I don't think I've
>> seen in pre-3.16 versions:
>>
>> Sep 29 19:12:49 betterave kernel: [ 7696.920600] PM: resume of devices
>> complete after 508.149 msecs
>> Sep 29 19:12:49 betterave kernel: [ 7696.921181] [ cut here
>> ]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921188] WARNING: CPU: 2 PID: 3533
>> at /build/linux-P15SNz/linux-3.16.3/drivers/base/firmware_class.c:1109
>> _request_firmware+0x521/0xaf0()
> [...]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921405] [] ?
>> request_firmware+0x2c/0x40
>> Sep 29 19:12:49 betterave kernel: [ 7696.921412] [] ?
>> btusb_setup_bcm_patchram+0x85/0x430 [btusb]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921419] [] ?
>> rpm_check_suspend_allowed+0x6a/0xc0
> [...]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921528] bluetooth hci0: firmware:
>> brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded
> [...]
>
> This means: btusb tries to load firmware during its resume operation,
> when userland is not yet available. This doesn't work if firmware
> loading depends on the userland firmware agent.
>
> The warning won't appear if the firmware is installed in the usual
> place, as direct loading will work. And the firmware agent is npw
> deprecated and not even enabled in Debian kernels. We could remove this
> warning, but it would be papering over a driver bug.
Are you sure about this? FWIW I've occasionally seen similar warnings
from another btusb device with firmware (using kernels I've built
myself, so not reported here of course). And I haven't really bothered to
look at the root cause before, so I haven't reported it upstream either.
But looking at _request_firmware() now it seems to me that this warning
is triggered _before_ we attempt any direct loading:
_request_firmware(const struct firmware **firmware_p, const char *name,
struct device *device, unsigned int opt_flags)
{
..
if (opt_flags & FW_OPT_NOWAIT) {
timeout = usermodehelper_read_lock_wait(timeout);
if (!timeout) {
dev_dbg(device, "firmware: %s loading timed out\n",
name);
ret = -EBUSY;
goto out;
}
} else {
ret = usermodehelper_read_trylock();
if (WARN_ON(ret)) {
dev_err(device, "firmware: %s will not be loaded\n",
name);
goto out;
}
}
ret = fw_get_filesystem_firmware(device, fw->priv);
That's the WARN_ON() we are hitting, as can be seen by the error message
following the warning. So we fail to get the usermodehelper read lock
(why do we need that?) and bail out before even attempting the direct
loading.
I will not claim I understand any of this. But the warning is
definitely triggered on some resumes, with firmware in the usual place
and without the firmware agent being enabled.
Bjørn
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8738b02vr1@nemi.mork.no
Bug#764162: linux-image-3.16-2-kirkwood: [regression 3.14->3.16] file data corruption, via network
On Mon, 2014-10-06 at 01:21 +0200, Svenska wrote:
> Package: src:linux
> Version: 3.16.3-2
> Severity: serious
> Justification: may cause silent data corruption
>
> Hello,
>
> after upgrading the kernel of my NAS to 3.16-2-kirkwood, I noticed
> corrupt data on my files. The NAS works as a DHCP client on its single
> LAN port, the two hard drives run in a RAID1 configuration. Both
> drives are fine according to mdadm and smartctl. Kernel logs in both
> cases have not been eye-catching. Samba is configured with "unix
> charset = ISO-8859-1".
>
> When copying data from the NAS to some other device using CIFS or
> Samba (the other devices run jessie/amd64 or wheezy/i686), the files
> are partly corrupt. The reported md5 checksums of files change every
> time the files are read. (And they differ from the checksums as stored
> on disk as well.) The files are not completely destroyed: ZIP archives
> show CRC errors only for some files in them, and video files remain
> generally playable, with lots of audio/video errors and crashing
> players.
>
> Shell access using SSH generally works. Trying to copy files with scp
> or sftp breaks the connection ("invalid MAC packets" or similar). File
> listing and mounting with sshfs work. Trying to copy files via sshfs
> results in a "Socket not connected" error, and the mount point is
> gone.
>
> As far as I can see, the on-disk data seems to be fine, as do files
> copied to the NAS while running the corrupt kernel. I am unable to
> check all new files, though - there might have been silent data
> corruption on new files.
It's sounding like the issue might be corruption on the networking path
rather than the disk path then?
> Data corruption on NAS devices is a serious issue for me.
> Reverting back to 3.14-2-kirkwood fixed the problems.
Which exact version did you revert to? Looking at debian/changelog since
the first 3.14 version I don't see much specific to kirkwood. At some
point there were some changes with the network PHY but they predate 3.14
IIRC.
The only thing which jumps out is "[armel/kirkwood] mm: Enable HIGHMEM
(Closes: #760786)" in 3.16.2-1. If you were able to try 3.16-1~exp1[0]
from snapshot.debian.org that might help rule that out.
If 3.16-1~exp1 still has the issue then I think we are looking at an
upstream regression. It might be worth bisecting a bit over the old
kernels from experimental which can be found on snapshot.d.o e.g. to
narrow down if the issue appeared in 3.15 or 3.16.
After that please could you to take this up with the upstream
developers[1], who are normally very responsive to kirkwood issues.
Thanks,
Ian.
[0] Should be at http://snapshot.debian.org/package/linux/3.16-1~exp1/
[1]
ARM/Marvell Dove/Kirkwood/MV78xx0/Orion SOC support
M: Jason Cooper
M: Andrew Lunn
M: Sebastian Hesselbarth
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
>
> Best Regards
>
> -- Package-specific info:
> ** Kernel log: boot messages should be attached
>
> ** Model information
> Hardware : QNAP TS-119/TS-219
> Revision :
>
> ** PCI devices:
> 00:00.0 Host bridge [0600]: Marvell Technology Group Ltd. Device
> [11ab:6282] (rev 01)
> Subsystem: Marvell Technology Group Ltd. Device [11ab:11ab]
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 9
> Region 0: Memory at (64-bit, prefetchable)
> Capabilities:
>
> 00:01.0 SATA controller [0106]: JMicron Technology Corp. JMB363 SATA/IDE
> Controller [197b:2363] (rev 03) (prog-if 01 [AHCI 1.0])
> Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller
> [197b:2363]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Latency: 0, Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 9
> Region 5: Memory at e001 (32-bit, non-prefetchable) [size=8K]
> [virtual] Expansion ROM at e000 [disabled] [size=64K]
> Capabilities:
> Kernel driver in use: ahci
>
> 00:01.1 IDE interface [0101]: JMicron Technology Corp. JMB363 SATA/IDE
> Controller [197b:2363] (rev 03) (prog-if 85 [Master SecO PriO])
> Subsystem: JMicron Technology Corp. JMB363 SATA/IDE Controller
> [197b:2363]
> Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-Interrupt: pin B routed to IRQ 9
> Region 0: I/O ports at 1010 [disabled] [size=8]
> Region 1: I/O ports at 1020 [disabled] [size=4]
> Region 2: I/O ports at 1018 [disabled] [size=8]
> Region 3: I/O p
Bug#762984: initramfs-tools: Alert! /dev/vg0/usr does not exist
On 10/07/2014 11:59 AM, IOhannes m zmoelnig wrote: > i am hit by the same problem. > as a temporary fix, i added the 'vgchange -ay' to > /usr/share/initramfs-tools/scripts/local-top/lvm2 > as adding it to > /etc/initramfs-tools/scripts/local-top/vgscan > somehow did not work (most likely due wrong order of execution, but i did not > investigate further) i turned out that i had forgotten to set +x permissions for /etc/initramfs-tools/scripts/local-top/vgscan gfmrdsa IOhannes signature.asc Description: OpenPGP digital signature
Bug#762984: initramfs-tools: Alert! /dev/vg0/usr does not exist
Package: initramfs-tools Version: 0.118 Followup-For: Bug #762984 i am hit by the same problem. as a temporary fix, i added the 'vgchange -ay' to /usr/share/initramfs-tools/scripts/local-top/lvm2 as adding it to /etc/initramfs-tools/scripts/local-top/vgscan somehow did not work (most likely due wrong order of execution, but i did not investigate further) -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 17M Oct 7 11:49 /boot/initrd.img-3.16-2-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.16-2-amd64 root=/dev/mapper/--vg-root ro quiet acpi_backlight=vendor pcie_aspm=force -- resume RESUME=/dev/mapper/--vg-swap_1 -- /proc/filesystems btrfs ext3 ext2 ext4 fuseblk -- lsmod Module Size Used by ctr12927 1 ccm17577 1 bnep 17431 2 binfmt_misc16949 1 pci_stub 12429 1 vboxpci23077 0 vboxnetadp 25443 0 vboxnetflt 23324 0 vboxdrv 340020 3 vboxnetadp,vboxnetflt,vboxpci nfsd 263053 2 auth_rpcgss51240 1 nfsd oid_registry 12419 1 auth_rpcgss nfs_acl12511 1 nfsd nfs 187961 0 lockd 83417 2 nfs,nfsd fscache45542 1 nfs sunrpc237445 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl ecb12737 1 btusb 29721 0 uvcvideo 79005 0 bluetooth 374429 21 bnep,btusb videobuf2_vmalloc 12816 1 uvcvideo videobuf2_memops 12519 1 videobuf2_vmalloc videobuf2_core 47787 1 uvcvideo 6lowpan_iphc 16588 1 bluetooth v4l2_common12995 1 videobuf2_core videodev 126451 3 uvcvideo,v4l2_common,videobuf2_core media 18305 2 uvcvideo,videodev acpi_call 12552 0 x86_pkg_temp_thermal12951 0 intel_powerclamp 17159 0 joydev 17063 0 intel_rapl 17356 0 iTCO_wdt 12831 0 coretemp 12820 0 iTCO_vendor_support12649 1 iTCO_wdt kvm_intel 139077 0 kvm 388597 1 kvm_intel crc32_pclmul 12915 0 ghash_clmulni_intel12978 0 aesni_intel 151423 3 arc4 12536 2 aes_x86_64 16719 1 aesni_intel iwldvm135156 0 lrw12757 1 aesni_intel mac80211 474202 1 iwldvm gf128mul 12970 1 lrw glue_helper12695 1 aesni_intel ablk_helper12572 1 aesni_intel snd_hda_codec_hdmi 45118 1 iwlwifi92451 1 iwldvm cfg80211 405538 3 iwlwifi,mac80211,iwldvm cryptd 14516 3 ghash_clmulni_intel,aesni_intel,ablk_helper i915 836937 2 thinkpad_acpi 69119 1 drm_kms_helper 49210 1 i915 drm 249955 4 i915,drm_kms_helper snd_hda_codec_realtek63031 1 evdev 17445 5 psmouse98616 0 serio_raw 12849 0 pcspkr 12595 0 ac 12715 0 i2c_algo_bit 12751 1 i915 tpm_tis17182 0 nvram 13034 1 thinkpad_acpi snd_hda_codec_generic63107 1 snd_hda_codec_realtek i2c_i801 16965 0 mei_me 17941 0 tpm31511 1 tpm_tis i2c_core 46012 7 drm,i915,i2c_i801,drm_kms_helper,i2c_algo_bit,v4l2_common,videodev wmi17339 0 mei74977 1 mei_me lpc_ich20768 0 snd_hda_intel 26327 0 snd_hda_controller 26727 1 snd_hda_intel snd_hda_codec 104463 5 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel,snd_hda_controller snd_hwdep 13148 1 snd_hda_codec snd_pcm88662 4 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_controller snd_timer 26614 1 snd_pcm snd65244 9 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel,thinkpad_acpi shpchp 31121 0 mfd_core 12601 1 lpc_ich battery13356 0 rfkill 18867 5 cfg80211,thinkpad_acpi,bluetooth button 12944 1 i915 video 18030 1 i915 soundcore 13026 2 snd,snd_hda_codec processor 28221 0 loop 26605 0 fuse 83350 1 parport_pc 26300 0 ppdev 16782 0 lp 17074 0 parport35749 3 lp,ppdev,parport_pc autofs435529 2 ext4 469572 6 crc16 12343 2 ext4,bluetooth mbcache17171 1 ext4 jbd2
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Here is another draft patch for hw-detect. This one is tested, and
find the missing firmware on my X200 test laptop.
This approach keep the non-functioning code and add two new
approaches, one looking at the meta information for loadmed modules,
and one parsing the dmesg output. The union from all three methods
are then presented as the list of wanted firmware.
diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
index 60c6ff4..74db55b 100755
--- a/check-missing-firmware.sh
+++ b/check-missing-firmware.sh
@@ -61,6 +61,18 @@ nic_is_configured() {
return 1
}
+add_if_fw_missing() {
+fwfile="$1"
+if [ ! -e /lib/firmware/$fwfile ] ; then
+if grep -q "^$fwfile$" $DENIED 2>/dev/null; then
+ log "listed in $DENIED"
+continue
+fi
+files="${files:+$files }$fwfile"
+modules="$module${modules:+ $modules}"
+fi
+}
+
check_missing () {
upnics
@@ -117,11 +129,30 @@ check_missing () {
done
done
+# Workaround for bug #725714, the kernel and udev no longer
+# let us know via /dev/.udev/firmware-missing and
+# /run/udev/firmware-missing which firmware files the kernel
+# drivers look for. This approach will only find firmware for
+# the loaded kernel modules. Modules refusing to
+# register/load when the firmware is missing will be missed.
+for module in $(cut -d" " -f1 /proc/modules); do
+for fwfile in $(modinfo $module | grep ^firmware: | cut -d: -f2);
do
+log "looking for firmware file $fwfile needed by $module"
+add_if_fw_missing "$fwfile"
+done
+done
+for fwfile in $(dmesg | grep 'firmware: failed' | sed 's/.*firmware:
failed to load //' | cut -d" " -f1); do
+# Dummy make sure '-n "$modules"' test below find something
+module=kernel
+log "looking for firmware file $fwfile requested by kernel"
+add_if_fw_missing "$fwfile"
+done
+
if [ -n "$modules" ]; then
log "missing firmware files ($files) for $modules"
return 0
else
- log "no missing firmware in $MISSING"
+ log "no missing firmware for any kernel module"
return 1
fi
}
--
Happy hacking
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141007135247.gp10...@ulrik.uio.no
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
On Tue, 2014-10-07 at 15:52 +0200, Petter Reinholdtsen wrote:
> Here is another draft patch for hw-detect. This one is tested, and
> find the missing firmware on my X200 test laptop.
>
> This approach keep the non-functioning code
The firmware agent is never coming back, so please do remove the related
code.
> and add two new
> approaches, one looking at the meta information for loadmed modules,
> and one parsing the dmesg output. The union from all three methods
> are then presented as the list of wanted firmware.
>
> diff --git a/check-missing-firmware.sh b/check-missing-firmware.sh
> index 60c6ff4..74db55b 100755
> --- a/check-missing-firmware.sh
> +++ b/check-missing-firmware.sh
[...]
> @@ -117,11 +129,30 @@ check_missing () {
> done
> done
>
> +# Workaround for bug #725714, the kernel and udev no longer
> +# let us know via /dev/.udev/firmware-missing and
> +# /run/udev/firmware-missing which firmware files the kernel
> +# drivers look for.
This belongs in the changelog not the code.
> This approach will only find firmware for
> +# the loaded kernel modules. Modules refusing to
> +# register/load when the firmware is missing will be missed.
> +for module in $(cut -d" " -f1 /proc/modules); do
> +for fwfile in $(modinfo $module | grep ^firmware: | cut -d:
> -f2); do
> +log "looking for firmware file $fwfile needed by $module"
> +add_if_fw_missing "$fwfile"
> +done
> +done
> +for fwfile in $(dmesg | grep 'firmware: failed' | sed 's/.*firmware:
> failed to load //' | cut -d" " -f1); do
Redundant use of grep; sed can do that (sed -n 's/.../.../p').
> +# Dummy make sure '-n "$modules"' test below find something
> +module=kernel
The driver name should appear at the start of the log line (after the
timestamp). Use that instead of 'kernel'.
> +log "looking for firmware file $fwfile requested by kernel"
> +add_if_fw_missing "$fwfile"
> +done
> +
Indentation of the above is inconsistent with the surrounding code (4
spaces vs hard tab).
Ben.
> if [ -n "$modules" ]; then
> log "missing firmware files ($files) for $modules"
> return 0
> else
> - log "no missing firmware in $MISSING"
> + log "no missing firmware for any kernel module"
> return 1
> fi
> }
>
> --
> Happy hacking
> Petter Reinholdtsen
>
>
--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky
signature.asc
Description: This is a digitally signed message part
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
Thank you for the code review. :) [Ben Hutchings] > The firmware agent is never coming back, so please do remove the related > code. I know and agree, but https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714#163 > asked for the non-working code to be kept to work with older kernels. I do not have any strong feelings, so I left it as it was. > This belongs in the changelog not the code. Actually, as long as there are several blocks doing similar things, I believe an explanation should be close to the code to explain why. I will wonder when I return in a few years time. :) > The driver name should appear at the start of the log line (after > the timestamp). Use that instead of 'kernel'. Yeah, but did not find a simple way to do it, and it is not affecting the functionallity, only the user messages. Should probably be fixed in the final version. > Redundant use of grep; sed can do that (sed -n 's/.../.../p'). Yeah. > Indentation of the above is inconsistent with the surrounding code > (4 spaces vs hard tab). It will happen before any commit is done. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007150911.gq10...@ulrik.uio.no
Bug#616689: The bug now reaches the "separate /usr on lvm" case
Hello, This bug is now also a problem with the new version of initramfs-tools in the case of a separate /usr partition on a lvm, as /usr is also being mounting early in the boot sequence by initramfs (this problem wasn't hitting me beforehand as I did put a small root partition on a non-lvm partition for "avoiding such problems" ... :/) Actually, the solutions proposed there were not working for me, I still had to "vgchange -ay" on the initramfs prompt. My working solution ended up to add the scsi_mod.scan=sync option to be passed by grub, and forced the lvm scanning by adding to /usr/share/initramfs-tools/scripts/local-top/lvm2 the lines: lvm pvscan lvm vgscan lvm vgchange -ay before the "activate_vg" lines. Note that I added the "lvm vgchange -ay" line on top of the other one, as suggested previously. It seemed that the volume /groups/ were correctly scanned and identified during the initial boot-up, as I could read the following lines: PV /dev/sdb1 VG lv_data lvm2 [1.82 TiB / 0free] PV /dev/sda3 VG lv_system lvm2 [235.68 GiB / 0free] Total: 2 [2.05 TiB] / in use: 2 [2.05 TiB] / in no VG: 0 [0 ] Reading all physical volumes. This may take a while... Found volume group "lv_data" using metadata type lvm2 Found volume group "lv_system" using metadata type lvm2 But the lvm /volumes/ were not activated, as initramfs was waiting for the /usr partition, until complaing and falling back to the prompt were the vgchange command had to be performed... so that I ended up adding the vgchange command in a "why not" mood, that ended up to work for me. I do not know if this is a solution or a dirty hack, but at least it is working for me. I don't know neither if /all/ the modifications are indeed necessary, as I added them incrementally until it worked. I hope that I could help... -- Raphaël -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/543401cc.4070...@gmail.com
Bug#725714: Partial fix using hw-setup for the missing firmware problem in d-i?
On Tue, 2014-10-07 at 17:09 +0200, Petter Reinholdtsen wrote: > Thank you for the code review. :) > > [Ben Hutchings] > > The firmware agent is never coming back, so please do remove the related > > code. > > I know and agree, but > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725714#163 > > asked for the non-working code to be kept to work with older kernels. Actually it is udev that removed this feature originally. Anyway, I shan't argue this with KiBi. > I do not have any strong feelings, so I left it as it was. > > > This belongs in the changelog not the code. > > Actually, as long as there are several blocks doing similar things, I > believe an explanation should be close to the code to explain why. I > will wonder when I return in a few years time. :) Perhaps this would be better placed above the old code, as that is what should be cleaned up at some later date. > > The driver name should appear at the start of the log line (after > > the timestamp). Use that instead of 'kernel'. > > Yeah, but did not find a simple way to do it, and it is not affecting > the functionallity, only the user messages. Should probably be fixed > in the final version. > > > Redundant use of grep; sed can do that (sed -n 's/.../.../p'). > > Yeah. > > > Indentation of the above is inconsistent with the surrounding code > > (4 spaces vs hard tab). > > It will happen before any commit is done. Thanks. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Processed: unarchive bug that I'm about to reopen
Processing commands for cont...@bugs.debian.org:
> unarchive 751238
Bug #751238 {Done: Andreas Henriksson } [util-linux,linux]
util-linux/linux: ignores RTC when the RTC driver is a module
Unarchived Bug 751238
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
751238: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/handler.s.c.141269605423604.transcr...@bugs.debian.org
Processed: tagging 764162
Processing commands for cont...@bugs.debian.org: > tags 764162 + moreinfo Bug #764162 [src:linux] linux-image-3.16-2-kirkwood: [regression 3.14->3.16] file data corruption, via network Added tag(s) moreinfo. > thanks Stopping processing here. Please contact me if you need assistance. -- 764162: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764162 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.141269631825325.transcr...@bugs.debian.org
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Control: reopen -1 Control: found -1 2.25.1-4 Hello! I'm reopening this bug report regarding using --hctosys in the util-linux hwclock-set script. The change was proposed for the benefit of arm systems where RTC drivers are built as modules and when they get loaded the previous scheme didn't work. Unfortunately it was reported that the new scheme breaks systems which (AIUI) the hardware clock is set to local time (and using the new initramfs-tools 0.118 scheme where time set set up in the initramfs). As I overheard discussions about building the RTC drivers on ARM into the kernel I'm going to revert this change in hwclock-set as well. This should unbreak all versions for now. I'm thus reopening this bug and hope for feedback on how we best handle this in the future or if it's just ok to have a requirement on RTC drivers needing to be built-in. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007171421.ga12...@fatal.se
Processed: Reopen bug report for switching hwclock-set to use hctosys
Processing control commands:
> reopen -1
Bug #751238 {Done: Andreas Henriksson } [util-linux,linux]
util-linux/linux: ignores RTC when the RTC driver is a module
'reopen' may be inappropriate when a bug has been closed with a version;
all fixed versions will be cleared, and you may need to re-add them.
Bug reopened
No longer marked as fixed in versions util-linux/2.25-2.
> found -1 2.25.1-4
Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC
driver is a module
There is no source info for the package 'util-linux' at version '2.25.1-4' with
architecture ''
There is no source info for the package 'linux' at version '2.25.1-4' with
architecture ''
Unable to make a source version for version '2.25.1-4'
Marked as found in versions 2.25.1-4.
--
751238: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751238
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/handler.s.b751238.14127021186227.transcr...@bugs.debian.org
Bug#764377: linux-image-3.2.0-4-686-pae: Kernel crash with tulip in the stack trace
Package: src:linux Version: 3.2.60-1+deb7u3 Severity: normal Dear Maintainer, * What led up to the situation? The computer was running as a NAT bridge and firewall between the internet and my home LAN. The computer crashed with the following output in /var/log/kern.log and on the computers console: Oct 7 05:53:29 doohan kernel: [5639460.859566] [ cut here ] Oct 7 05:53:29 doohan kernel: [5639460.859678] WARNING: at /build/linux-oDe0QO/linux-3.2.60/kernel/timer.c:1015 del_timer_sync+0x22/0x33() Oct 7 05:53:29 doohan kernel: [5639460.859752] Modules linked in: parport_pc ppdev xt_tcpudp xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack ip_tables x_tables dm_mod fuse ext3 jbd usb_storage lp ppa parport usblp sg sr_mod cdrom uhci_hcd 3c59x ehci_hcd psmouse i2c_piix4 pcspkr usbcore i2c_core usb_common tulip mii serio_raw shpchp evdev ext2 mbcache sd_mod crc_t10dif ata_generic ata_piix libata scsi_mod Oct 7 05:53:29 doohan kernel: [5639460.860305] Pid: 0, comm: swapper/0 Tainted: GW3.2.0-4-686-pae #1 Debian 3.2.60-1+deb7u3 Oct 7 05:53:29 doohan kernel: [5639460.860378] Call Trace: Oct 7 05:53:29 doohan kernel: [5639460.860463] [] ? warn_slowpath_common+0x68/0x79 Oct 7 05:53:29 doohan kernel: [5639460.860525] [] ? del_timer_sync+0x22/0x33 Oct 7 05:53:29 doohan kernel: [5639460.860586] [] ? warn_slowpath_null+0xd/0x10 Oct 7 05:53:29 doohan kernel: [5639460.860645] [] ? del_timer_sync+0x22/0x33 Oct 7 05:53:29 doohan kernel: [5639460.860736] [] ? t21142_lnk_change+0x320/0x463 [tulip] Oct 7 05:53:29 doohan kernel: [5639460.860815] [] ? tulip_interrupt+0x402/0x5c4 [tulip] Oct 7 05:53:29 doohan kernel: [5639460.860902] [] ? add_interrupt_randomness+0x2d/0x12a Oct 7 05:53:29 doohan kernel: [5639460.860984] [] ? handle_irq_event_percpu+0x47/0x155 Oct 7 05:53:29 doohan kernel: [5639460.861063] [] ? arch_local_irq_save+0xf/0x14 Oct 7 05:53:29 doohan kernel: [5639460.861132] [] ? cond_unmask_irq+0x1f/0x1f Oct 7 05:53:29 doohan kernel: [5639460.861191] [] ? handle_irq_event+0x21/0x3a Oct 7 05:53:29 doohan kernel: [5639460.861251] [] ? cond_unmask_irq+0x1f/0x1f Oct 7 05:53:29 doohan kernel: [5639460.861310] [] ? handle_level_irq+0x4a/0x56 Oct 7 05:53:29 doohan kernel: [5639460.861359][] ? do_IRQ+0x2e/0x76 Oct 7 05:53:29 doohan kernel: [5639460.861484] [] ? common_interrupt+0x30/0x38 Oct 7 05:53:29 doohan kernel: [5639460.861561] [] ? spi_register_master+0x8b/0xdc Oct 7 05:53:29 doohan kernel: [5639460.861651] [] ? native_safe_halt+0x2/0x3 Oct 7 05:53:29 doohan kernel: [5639460.861720] [] ? default_idle+0x40/0x6d Oct 7 05:53:29 doohan kernel: [5639460.861780] [] ? cpu_idle+0x95/0xaf Oct 7 05:53:29 doohan kernel: [5639460.861844] [] ? start_kernel+0x325/0x32a Oct 7 05:53:29 doohan kernel: [5639460.861893] ---[ end trace 1221efb964543d7c ]--- * What exactly did you do (or not do) that was effective (or ineffective)? Switched off and on the computer's power switch. * What was the outcome of this action? The computer booted. * What outcome did you expect instead? This was the outcome I was hoping for. *** End of the template - remove these lines *** -- Package-specific info: ** Version: Linux version 3.2.0-4-686-pae (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.60-1+deb7u3 ** Command line: auto BOOT_IMAGE=Linux ro root=UUID=0ec425dc-ed3d-4226-9670-14a9800e98b5 ** Not tainted ** Kernel log: [1.785969] Switching to clocksource tsc [1.830529] ata2.00: ATAPI: TOSHIBA CD-ROM XM-6202B, 1110, max MWDMA2 [1.846111] ata2.00: configured for MWDMA2 [1.902233] ata1.00: ATA-3: QUANTUM FIREBALL SE6.4A, API.0C00, max UDMA/33 [1.902361] ata1.00: 12594960 sectors, multi 16: LBA [1.902865] ata1.01: ATA-6: ST340014A, 3.06, max UDMA/100 [1.902972] ata1.01: 78165360 sectors, multi 16: LBA48 [1.918126] ata1.00: configured for UDMA/33 [1.934351] ata1.01: configured for UDMA/33 [1.935462] scsi 0:0:0:0: Direct-Access ATA QUANTUM FIREBALL API. PQ: 0 ANSI: 5 [1.937364] scsi 0:0:1:0: Direct-Access ATA ST340014A3.06 PQ: 0 ANSI: 5 [1.942376] scsi 1:0:0:0: CD-ROMTOSHIBA CD-ROM XM-6202B 1110 PQ: 0 ANSI: 5 [2.050565] sd 0:0:0:0: [sda] 12594960 512-byte logical blocks: (6.44 GB/6.00 GiB) [2.051428] sd 0:0:0:0: [sda] Write Protect is off [2.051539] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [2.051861] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [2.078483] sd 0:0:1:0: [sdb] 78165360 512-byte logical blocks: (40.0 GB/37.2 GiB) [2.097504] sda: sda1 sda2 < sda5 sda6 sda7 > [2.098203] sd 0:0:1:0: [sdb] Write Protect is off [2.098342] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00 [2.099041] sd 0:0:1:0: [sdb] Write cache: enabled, read cache: enabled, doesn'
Processed: found in more versions
Processing commands for cont...@bugs.debian.org: > found 751238 2.20.1-5 Bug #751238 [util-linux,linux] util-linux/linux: ignores RTC when the RTC driver is a module There is no source info for the package 'linux' at version '2.20.1-5' with architecture '' Marked as found in versions util-linux/2.20.1-5. > thanks Stopping processing here. Please contact me if you need assistance. -- 751238: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751238 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/handler.s.c.141270346616310.transcr...@bugs.debian.org
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 07.10.2014 um 19:14 schrieb Andreas Henriksson: > Control: reopen -1 > Control: found -1 2.25.1-4 > > Hello! > > I'm reopening this bug report regarding using --hctosys in the util-linux > hwclock-set script. The change was proposed for the benefit of arm > systems where RTC drivers are built as modules and when they get loaded > the previous scheme didn't work. > > Unfortunately it was reported that the new scheme breaks systems which > (AIUI) the hardware clock is set to local time (and using the new > initramfs-tools 0.118 scheme where time set set up in the initramfs). > > As I overheard discussions about building the RTC drivers on ARM into > the kernel I'm going to revert this change in hwclock-set as well. > This should unbreak all versions for now. > > I'm thus reopening this bug and hope for feedback on how we best handle > this in the future or if it's just ok to have a requirement on RTC drivers > needing to be built-in. Fwiw, it was me, how experiences this issue. After the switch from systz to hctosys in /lib/udev/hwclock-set, my hardware clock is no longer properly set under systemd. Afaics, this is because systemd set's the clock internally and doesn't care for the flag file that is created by hwclock-set. Under sysvinit, I don't encounter this problem. When switching hwclock-set back to systz, it works properly for both systemd and sysvinit. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
On Tue, Oct 07, 2014 at 08:21:51PM +0200, Michael Biebl wrote: > Am 07.10.2014 um 19:14 schrieb Andreas Henriksson: > > Control: reopen -1 > > Control: found -1 2.25.1-4 > > > > Hello! > > > > I'm reopening this bug report regarding using --hctosys in the util-linux > > hwclock-set script. The change was proposed for the benefit of arm > > systems where RTC drivers are built as modules and when they get loaded > > the previous scheme didn't work. > > > > Unfortunately it was reported that the new scheme breaks systems which > > (AIUI) the hardware clock is set to local time (and using the new > > initramfs-tools 0.118 scheme where time set set up in the initramfs). > > > > As I overheard discussions about building the RTC drivers on ARM into > > the kernel I'm going to revert this change in hwclock-set as well. > > This should unbreak all versions for now. Yes, the next upload of the kernel will have the RTC drivers built-in. If we keep this policy I think this change is fine. > > I'm thus reopening this bug and hope for feedback on how we best handle > > this in the future or if it's just ok to have a requirement on RTC drivers > > needing to be built-in. > > Fwiw, it was me, how experiences this issue. > After the switch from systz to hctosys in /lib/udev/hwclock-set, my > hardware clock is no longer properly set under systemd. > > Afaics, this is because systemd set's the clock internally and doesn't > care for the flag file that is created by hwclock-set. > Under sysvinit, I don't encounter this problem. > > When switching hwclock-set back to systz, it works properly for both > systemd and sysvinit. I don't really see how it can happen, this file is not supposed to be run under systemd, due to the following code at the beginning: | if [ -e /run/systemd/system ] ; then |exit 0 | fi Therefore it should not be run on systemd. It was actually one of the problem I reported on IRC before we switched all the RTC drivers to built-in. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007183728.gd24...@hall.aurel32.net
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 07.10.2014 um 20:37 schrieb Aurelien Jarno: > On Tue, Oct 07, 2014 at 08:21:51PM +0200, Michael Biebl wrote: >> Fwiw, it was me, how experiences this issue. >> After the switch from systz to hctosys in /lib/udev/hwclock-set, my >> hardware clock is no longer properly set under systemd. >> >> Afaics, this is because systemd set's the clock internally and doesn't >> care for the flag file that is created by hwclock-set. >> Under sysvinit, I don't encounter this problem. >> >> When switching hwclock-set back to systz, it works properly for both >> systemd and sysvinit. > > I don't really see how it can happen, this file is not supposed to be > run under systemd, due to the following code at the beginning: > > | if [ -e /run/systemd/system ] ; then > |exit 0 > | fi > > Therefore it should not be run on systemd. It was actually one of the > problem I reported on IRC before we switched all the RTC drivers to > built-in. Keep in mind, that /run/systemd/system does not exist in the initramfs as we don't use systemd in the initramfs (yet). So afaics what happens is, that we run hwclock twice under systemd: once in the initramfs, a second time by systemd itself. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Am 07.10.2014 um 20:40 schrieb Michael Biebl: > Am 07.10.2014 um 20:37 schrieb Aurelien Jarno: >> I don't really see how it can happen, this file is not supposed to be >> run under systemd, due to the following code at the beginning: >> >> | if [ -e /run/systemd/system ] ; then >> |exit 0 >> | fi >> >> Therefore it should not be run on systemd. It was actually one of the >> problem I reported on IRC before we switched all the RTC drivers to >> built-in. > > Keep in mind, that /run/systemd/system does not exist in the initramfs > as we don't use systemd in the initramfs (yet). > So afaics what happens is, that we run hwclock twice under systemd: > once in the initramfs, a second time by systemd itself. systemd set's the system clock internally [1]. And this code doesn't take into account that the initramfs might already have run hwclock --hctosys. [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=7948c4dfbea73ac21250b588089039aa17a90386 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
On Tue, Oct 07, 2014 at 08:40:26PM +0200, Michael Biebl wrote: > Am 07.10.2014 um 20:37 schrieb Aurelien Jarno: > > On Tue, Oct 07, 2014 at 08:21:51PM +0200, Michael Biebl wrote: > >> Fwiw, it was me, how experiences this issue. > >> After the switch from systz to hctosys in /lib/udev/hwclock-set, my > >> hardware clock is no longer properly set under systemd. > >> > >> Afaics, this is because systemd set's the clock internally and doesn't > >> care for the flag file that is created by hwclock-set. > >> Under sysvinit, I don't encounter this problem. > >> > >> When switching hwclock-set back to systz, it works properly for both > >> systemd and sysvinit. > > > > I don't really see how it can happen, this file is not supposed to be > > run under systemd, due to the following code at the beginning: > > > > | if [ -e /run/systemd/system ] ; then > > |exit 0 > > | fi > > > > Therefore it should not be run on systemd. It was actually one of the > > problem I reported on IRC before we switched all the RTC drivers to > > built-in. > > Keep in mind, that /run/systemd/system does not exist in the initramfs > as we don't use systemd in the initramfs (yet). > So afaics what happens is, that we run hwclock twice under systemd: > once in the initramfs, a second time by systemd itself. > Oh running hwclock from the initramfs is something new then. At the time I reported the bug this was not the case. I still don't get why it doesn't work though. Running hwclock --hctosys in the initramfs should not be different than what the kernel does for built-in modules. -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141007184456.gf24...@hall.aurel32.net
Bug#764388: initramfs-tools: wrong default TMPDIR in mkinitramfs manpage
Package: initramfs-tools Version: 0.118 Severity: normal Dear Maintainer, in the manpage of mkinitramfs you find the TMPDIR variable. There the detault is documented as /tmp, but actually mkinitramfs uses /var/tmp. Please update the manpage. Thanks Achim -- Package-specific info: *** End of the template - remove these template lines *** -- initramfs sizes -rw-r--r-- 1 root root 5.8M Aug 25 11:23 /boot/initrd.img-3.14-2-amd64 -rw-r--r-- 1 root root 6.2M Oct 5 09:49 /boot/initrd.img-3.16-2-amd64 -- /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-3.16-2-amd64 root=UUID=ca312c5e-886f-4174-b9ca-ae83eadec9e5 ro rootdelay=3 quiet -- resume RESUME=/dev/mapper/vg_WD1002FBYS-swap -- /proc/filesystems ext3 ext2 ext4 fuseblk btrfs -- lsmod Module Size Used by bnep 17431 2 pci_stub 12429 1 vboxpci23077 0 vboxnetadp 25443 0 vboxnetflt 23324 0 vboxdrv 340067 3 vboxnetadp,vboxnetflt,vboxpci nf_conntrack_netbios_ns12445 0 nf_conntrack_broadcast12365 1 nf_conntrack_netbios_ns xt_tcpudp 12527 15 cfg80211 405538 0 ip6t_rpfilter 12468 1 ip6t_REJECT12468 2 ipt_REJECT 12465 2 xt_conntrack 12681 19 binfmt_misc16949 1 ebtable_nat12580 0 ebtable_broute 12541 0 bridge106104 1 ebtable_broute stp12437 1 bridge llc12745 2 stp,bridge ebtable_filter 12591 0 ebtables 34122 3 ebtable_broute,ebtable_nat,ebtable_filter ip6table_nat 12649 1 nf_conntrack_ipv6 13605 11 nf_defrag_ipv6 33358 1 nf_conntrack_ipv6 nf_nat_ipv612920 1 ip6table_nat ip6table_mangle12540 1 ip6table_security 12548 1 ip6table_raw 12528 1 ip6table_filter12540 1 ip6_tables 26025 5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw iptable_nat12646 1 nf_conntrack_ipv4 18455 10 nf_defrag_ipv4 12483 1 nf_conntrack_ipv4 nf_nat_ipv412912 1 iptable_nat nf_nat 18241 4 nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat nf_conntrack 87432 10 nf_conntrack_netbios_ns,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,nf_conntrack_broadcast,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6 iptable_mangle 12536 1 iptable_security 12544 1 iptable_raw12524 1 iptable_filter 12536 1 ip_tables 26011 5 iptable_security,iptable_filter,iptable_mangle,iptable_nat,iptable_raw x_tables 27111 16 iptable_security,ip6table_filter,ip6table_mangle,ip6t_rpfilter,ip_tables,xt_tcpudp,ip6table_security,xt_conntrack,iptable_filter,ip6table_raw,ebtables,ipt_REJECT,iptable_mangle,ip6_tables,iptable_raw,ip6t_REJECT zfs 1033585 3 zunicode 328627 1 zfs zavl 13115 1 zfs zcommon40036 1 zfs znvpair58792 2 zfs,zcommon spl 144863 5 zfs,zavl,zunicode,zcommon,znvpair ecb12737 1 btusb 29721 0 bluetooth 374429 23 bnep,btusb 6lowpan_iphc 16588 1 bluetooth rfkill 18867 3 cfg80211,bluetooth joydev 17063 0 hid_generic12393 0 usbhid 44467 0 hid 102264 2 hid_generic,usbhid btrfs 859433 1 xor21040 1 btrfs raid6_pq 95238 1 btrfs x86_pkg_temp_thermal12951 0 intel_powerclamp 17159 0 intel_rapl 17356 0 coretemp 12820 0 kvm_intel 139077 0 kvm 388597 1 kvm_intel snd_hda_codec_hdmi 45118 1 crc32_pclmul 12915 0 evdev 17445 30 crc32c_intel 21809 1 ghash_clmulni_intel12978 0 iTCO_wdt 12831 0 iTCO_vendor_support12649 1 iTCO_wdt aesni_intel 151423 1 aes_x86_64 16719 1 aesni_intel lrw12757 1 aesni_intel gf128mul 12970 1 lrw glue_helper12695 1 aesni_intel ablk_helper12572 1 aesni_intel sr_mod 21903 0 cryptd 14516 3 ghash_clmulni_intel,aesni_intel,ablk_helper ehci_pci 12512 0 i915 836937 7 cdrom 47424 1 sr_mod xhci_hcd 148941 0 ehci_hcd 69837 1 ehci_pci tpm_tis17182 0 usbcore 195340 5 btusb,ehci_hcd,ehci_pci,usbhid,xhci_hcd drm_kms_helper 49210 1 i915 drm 249955 6 i915,drm_kms_helper battery13356 0 tpm31511 1 tpm_tis pcspkr 12595 0 snd_hda_codec_rea
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
On Tue, 2014-10-07 at 20:21 +0200, Michael Biebl wrote: > Am 07.10.2014 um 19:14 schrieb Andreas Henriksson: > > Control: reopen -1 > > Control: found -1 2.25.1-4 > > > > Hello! > > > > I'm reopening this bug report regarding using --hctosys in the util-linux > > hwclock-set script. The change was proposed for the benefit of arm > > systems where RTC drivers are built as modules and when they get loaded > > the previous scheme didn't work. > > > > Unfortunately it was reported that the new scheme breaks systems which > > (AIUI) the hardware clock is set to local time (and using the new > > initramfs-tools 0.118 scheme where time set set up in the initramfs). > > > > As I overheard discussions about building the RTC drivers on ARM into > > the kernel I'm going to revert this change in hwclock-set as well. > > This should unbreak all versions for now. > > > > I'm thus reopening this bug and hope for feedback on how we best handle > > this in the future or if it's just ok to have a requirement on RTC drivers > > needing to be built-in. > > Fwiw, it was me, how experiences this issue. > After the switch from systz to hctosys in /lib/udev/hwclock-set, my > hardware clock is no longer properly set under systemd. It works for me. Which version of systemd are you using? > Afaics, this is because systemd set's the clock internally and doesn't > care for the flag file that is created by hwclock-set. Also hwclock-set explicitly checks for running under systemd and then does nothing. Ben. > Under sysvinit, I don't encounter this problem. > > When switching hwclock-set back to systz, it works properly for both > systemd and sysvinit. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky signature.asc Description: This is a digitally signed message part
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
On Tue, 2014-10-07 at 19:14 +0200, Andreas Henriksson wrote:
> Control: reopen -1
> Control: found -1 2.25.1-4
Where is -4?
> Hello!
>
> I'm reopening this bug report regarding using --hctosys in the util-linux
> hwclock-set script. The change was proposed for the benefit of arm
> systems where RTC drivers are built as modules and when they get loaded
> the previous scheme didn't work.
>
> Unfortunately it was reported that the new scheme breaks systems which
> (AIUI) the hardware clock is set to local time (and using the new
> initramfs-tools 0.118 scheme where time set set up in the initramfs).
[...]
I have tested the new initramfs-tools (0.118) and util-linux (2.25.1-3)
with 'LOCAL' in /etc/adjtime, and all combinations of {busybox,klibc} in
initramfs and {systemd,sysvinit} as init system. And I got the right
system time in all cases (and we are still at UTC+0100 here).
(With older versions of util-linux this would not work, and the
versioned dependency in initramfs-tools doesn't force an upgrade from
the experimental 2.25 versions. I can bump the dependency if you think
that's worthwhile.)
Ben.
--
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky
signature.asc
Description: This is a digitally signed message part
Bug#751238: Reopen bug report for switching hwclock-set to use hctosys
Hi Ben Am 07.10.2014 um 21:00 schrieb Ben Hutchings: > On Tue, 2014-10-07 at 20:21 +0200, Michael Biebl wrote: >> Fwiw, it was me, how experiences this issue. >> After the switch from systz to hctosys in /lib/udev/hwclock-set, my >> hardware clock is no longer properly set under systemd. > > It works for me. Which version of systemd are you using? $ apt-cache policy systemd util-linux initramfs-tools systemd: Installiert: 215-5+b1 Installationskandidat: 215-5+b1 Versionstabelle: *** 215-5+b1 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status util-linux: Installiert: 2.25.1-3 Installationskandidat: 2.25.1-3 Versionstabelle: *** 2.25.1-3 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status initramfs-tools: Installiert: 0.118 Installationskandidat: 0.118 Versionstabelle: *** 0.118 0 500 http://ftp.de.debian.org/debian/ sid/main amd64 Packages 100 /var/lib/dpkg/status > >> Afaics, this is because systemd set's the clock internally and doesn't >> care for the flag file that is created by hwclock-set. > > Also hwclock-set explicitly checks for running under systemd and then > does nothing. Right, but if hwclock-set is run in the initramfs, there is no /run/systemd/system yet, so hwclock-set will be run, irregardless if sysvinit or systemd will be PID 1 later on. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#764422: linux-image-3.16-2-armmp: reloading ci_hdrc_imx module oopses
Package: src:linux Version: 3.16.3-2 Severity: normal Hello, while trying to get up usb on an i.MX6 based machine I noticed that reloading the ci_hdrc_imx module results in an oops. See below. Best regards Uwe root@amore820:/home/uwe# rmmod ci_hdrc_imx [ 193.205033] ci_hdrc ci_hdrc.0: remove, state 4 [ 193.209897] usb usb1: USB disconnect, device number 1 [ 193.215660] usb 1-1: USB disconnect, device number 2 [ 193.222592] ci_hdrc ci_hdrc.0: USB bus 1 deregistered root@amore820:/home/uwe# modprobe ci_hdrc_imx [ 198.710337] 2184200.usb supply vbus not found, using dummy regulator [ 198.718624] [ cut here ] [ 198.723251] kernel BUG at /build/linux-ul0Dnb/linux-3.16.3/mm/slab.c:2954! [ 198.730128] Internal error: Oops - BUG: 0 [#1] SMP ARM [ 198.735269] Modules linked in: ci_hdrc_imx(+) nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc imx_ipuv3_crtc(C) ci_hdrc ehci_hcd imx_ipu_v3 usbmisc_imx phy_mxs_usb imxdrm(C) drm_kms_helper imx2_wdt pwm_imx spi_imx drm autofs4 ext4 crc16 mbcache jbd2 sdhci_esdhc_imx sdhci_pltfm sdhci [last unloaded: ci_hdrc_imx] [ 198.764594] CPU: 2 PID: 681 Comm: modprobe Tainted: G C 3.16-2-armmp #1 Debian 3.16.3-2 [ 198.773558] task: ed334280 ti: ed20c000 task.ti: ed20c000 [ 198.778968] PC is at cache_alloc_refill+0x2b4/0x5a0 [ 198.783848] LR is at cache_alloc_refill+0x80/0x5a0 [ 198.788642] pc : []lr : []psr: a00e0093 [ 198.788642] sp : ed20da38 ip : ed20da38 fp : ed20da7c [ 198.800120] r10: ee001504 r9 : ee001500 r8 : c0908928 [ 198.805346] r7 : ee000440 r6 : ee154800 r5 : 0004 r4 : ef59cb94 [ 198.811875] r3 : r2 : 0001 r1 : 00100100 r0 : ee001500 [ 198.818405] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 198.825629] Control: 10c5387d Table: 3d03404a DAC: 0015 [ 198.831376] Process modprobe (pid: 681, stack limit = 0xed20c250) [ 198.837472] Stack: (0xed20da38 to 0xed20e000) [ 198.841832] da20: 0200 02184200 [ 198.850015] da40: 80d0 ee001514 00200200 ed20da7c ee000440 ee62bc10 80d0 [ 198.858195] da60: 80d0 10b0 bf1ee5a4 600e0013 ed20dab4 ed20da80 c0173c3c c0173560 [ 198.866376] da80: ed20daac ed20da90 c0296c70 ee62bc10 ee62bc10 ee62bc10 ee62bc00 ed2c3d40 [ 198.874557] daa0: 0022 ed20dad4 ed20dab8 c037a4f0 c0173b00 0006 ee62bc10 [ 198.882738] dac0: ee62bc10 f0904200 ed20db04 ed20dad8 bf1ee5a4 c037a4d4 bf1f43c4 [ 198.890919] dae0: ee62bc10 bf1f43c4 c09c58d8 bf1f43c4 0022 ed20db1c ed20db08 [ 198.899100] db00: c03790f0 bf1ee54c ee62bc10 c0a23e10 ed20db4c ed20db20 c0376fe8 c03790d4 [ 198.907281] db20: ed20db4c ed20db30 bf1f43c4 ee62bc10 c0377244 ee29c010 [ 198.915461] db40: ed20db64 ed20db50 c0377294 c0376e98 ee62bc10 ed20db8c ed20db68 [ 198.923644] db60: c03750d8 c0377250 ee19c970 ee73bab8 c05abddc ee62bc10 ee62bc44 c0998fb8 [ 198.931824] db80: ed20dbac ed20db90 c0376e18 c037507c ee19c900 ee62bc18 ee62bc10 c0998fb8 [ 198.940005] dba0: ed20dbcc ed20dbb0 c0376298 c0376da0 ee62bc18 c0907514 ee62bc10 [ 198.948186] dbc0: ed20dc14 ed20dbd0 c03741bc c0376210 ed2c3d40 0002 ed20dc04 ed20dbe8 [ 198.956366] dbe0: c005a7ac bd94282d 0200 0002 ee62bc00 ee62bc10 0002 ee29e7c0 [ 198.964547] dc00: ee62bc00 ed20dc34 ed20dc18 c0378de8 c0373d4c [ 198.972728] dc20: ed20dc6c 0002 ed20dc64 ed20dc38 bf1eed60 c0378d1c ed20dc6c ee29c010 [ 198.980909] dc40: ee29c000 ed2c3e90 bf36b734 0022 ee59c200 ed20dcb4 ed20dc68 [ 198.989090] dc60: bf36b374 bf1eebac ed20dc9c ee29e780 0100 ee7a5690 [ 198.997271] dc80: 000a 0001 ed39af80 ed20dcac ee29c010 bf36b8f0 c09c58d8 [ 199.005452] dca0: bf36b8f0 ed20dccc ed20dcb8 c03790f0 bf36b158 ee29c010 c0a23e10 [ 199.013633] dcc0: ed20dcfc ed20dcd0 c0376fe8 c03790d4 ed20dcfc c05abddc ee29c010 bf36b8f0 [ 199.021814] dce0: ee29c044 bf36b940 ed3787e4 ed20dd1c ed20dd00 c0377334 c0376e98 [ 199.029995] dd00: ee19c95c bf36b8f0 c0377298 ed20dd44 ed20dd20 c0375010 c03772a4 [ 199.038175] dd20: ee19c95c ee28d1b4 ee19c970 bf36b8f0 ed278900 c0998fb8 ed20dd54 ed20dd48 [ 199.046355] dd40: c0376984 c0374fac ed20dd7c ed20dd58 c0376584 c0376964 bf36b8a4 ed20dd68 [ 199.054535] dd60: bf36b8f0 c090bba0 c0907514 bf36d000 ed20dd94 ed20dd80 c0377b50 c0376420 [ 199.062716] dd80: c090bba0 c090bba0 ed20dda4 ed20dd98 c03790c0 c0377ad4 ed20ddb4 ed20dda8 [ 199.070896] dda0: bf36d020 c0379068 ed20de54 ed20ddb8 c0008cf4 bf36d00c ed20dde4 ef59ee80 [ 199.079076] ddc0: ed20c038 c01375c0 ef59ee80 ed20de0c ed20dde8 [ 199.087256] dde0: c01375c0 c0134c00 ef59ee90 0003 ee59c200 f090 0001 c01661ec [ 199.095436] de00: 0002 0003 ee59c200 f090 ed20de3c ed20de20 c01661ec c01745a0 [ 199.103615] de
