Re: kernel errors
On 06/02/2023 00:11, Richmond wrote: Max Nikulin writes: On 05/02/2023 03:12, Richmond wrote: The errors about sr0 come before the stuff about resume. Does the following command generate similar errors (taken from initrd scripts, UUID is intentionally not from the set of existing partitions)? blkid -l -t UUID=---- -o device It didn't produce any output. Sorry, I have no motivation to dig into /usr/share/initramfs-tools deeper. Perhaps you may try debug kernel option in combination with bad UUID for resume from grub ... debug resume=UUID=---- with hope to get more verbose output around of optical drive access. You may try to report a bug against initramfs-tools that errors messages are unhelpful and even confusing when resume configuration is inconsistent due to a mistake. Perhaps resume argument may be validated during generation of initrd, however in some cases it will give false positive.
Re: kernel errors
Max Nikulin writes: > On 05/02/2023 03:12, Richmond wrote: >> The errors about sr0 come before the stuff about resume. > > Does the following command generate similar errors (taken from initrd > scripts, UUID is intentionally not from the set of existing > partitions)? > > blkid -l -t UUID=---- -o device > > I would try it at first in normally running system. Perhaps some > caches may be involved preventing query to the optical drive. I have > no bright idea how to cause drop to initrd shell to try the command > there, perhaps root=... kernel command line parameter may be removed > or changed to non-existing device from grub prompt. > > I am unsure which particular command from initrd scans devices, my > guess may be wrong. It didn't produce any output.
Re: kernel errors
On 05/02/2023 03:12, Richmond wrote: The errors about sr0 come before the stuff about resume. Does the following command generate similar errors (taken from initrd scripts, UUID is intentionally not from the set of existing partitions)? blkid -l -t UUID=---- -o device I would try it at first in normally running system. Perhaps some caches may be involved preventing query to the optical drive. I have no bright idea how to cause drop to initrd shell to try the command there, perhaps root=... kernel command line parameter may be removed or changed to non-existing device from grub prompt. I am unsure which particular command from initrd scans devices, my guess may be wrong.
Re: kernel errors
Richmond wrote: > David Wright writes: > >> On Sat 04 Feb 2023 at 17:38:25 (+), Richmond wrote: >>> David Wright writes: On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: > Max Nikulin writes: >> On 03/02/2023 01:47, Richmond wrote: >>> It might be a good way for someone to reproduce the error on some >>> other >>> machine. I have no problems with the CD/DVD writer and have used it a >>> few times recently. >> Do you see the same errors if kernel command line is edited from grub >> to pass non-existing UUID specified in the resume=UUID=... argument? >> It might be a quick way to reproduce the issue. > I looked in grub but couldn't see any resume parameter. I think the way > things work has changed, and this is hidden away somewhere. There are hundreds and hundreds of kernel command-line parameters, so I'm not sure how you expect to see any evidence of each one in Grub's configuration. >>> We were talking about editing from grub during boot time, not looking in >>> grubs configuration. >> You wrote: "I looked in grub". >> >> My interpretation: "I looked in grub.cfg by typing 'E' on one or more >> of the entries in Grub's blue screen when booting the computer". >> > I see. Max (and you) mean add the resume parameter, not edit an existing one. > I > was looking for an existing one. I will try this. > It worked, I recreated the error, including the stuff about sr0. The errors about sr0 come before the stuff about resume.
Re: kernel errors
David Wright writes: > On Sat 04 Feb 2023 at 17:38:25 (+), Richmond wrote: >> David Wright writes: >> > On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: >> >> Max Nikulin writes: >> >> > On 03/02/2023 01:47, Richmond wrote: >> >> >> It might be a good way for someone to reproduce the error on some >> >> >> other >> >> >> machine. I have no problems with the CD/DVD writer and have used it a >> >> >> few times recently. >> >> > >> >> > Do you see the same errors if kernel command line is edited from grub >> >> > to pass non-existing UUID specified in the resume=UUID=... argument? >> >> > It might be a quick way to reproduce the issue. >> >> >> >> I looked in grub but couldn't see any resume parameter. I think the way >> >> things work has changed, and this is hidden away somewhere. >> > >> > There are hundreds and hundreds of kernel command-line parameters, >> > so I'm not sure how you expect to see any evidence of each one in >> > Grub's configuration. >> >> We were talking about editing from grub during boot time, not looking in >> grubs configuration. > > You wrote: "I looked in grub". > > My interpretation: "I looked in grub.cfg by typing 'E' on one or more > of the entries in Grub's blue screen when booting the computer". > I see. Max (and you) mean add the resume parameter, not edit an existing one. I was looking for an existing one. I will try this.
Re: kernel errors
On Sat 04 Feb 2023 at 17:38:25 (+), Richmond wrote: > David Wright writes: > > On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: > >> Max Nikulin writes: > >> > On 03/02/2023 01:47, Richmond wrote: > >> >> It might be a good way for someone to reproduce the error on some > >> >> other > >> >> machine. I have no problems with the CD/DVD writer and have used it a > >> >> few times recently. > >> > > >> > Do you see the same errors if kernel command line is edited from grub > >> > to pass non-existing UUID specified in the resume=UUID=... argument? > >> > It might be a quick way to reproduce the issue. > >> > >> I looked in grub but couldn't see any resume parameter. I think the way > >> things work has changed, and this is hidden away somewhere. > > > > There are hundreds and hundreds of kernel command-line parameters, > > so I'm not sure how you expect to see any evidence of each one in > > Grub's configuration. > > We were talking about editing from grub during boot time, not looking in > grubs configuration. You wrote: "I looked in grub". My interpretation: "I looked in grub.cfg by typing 'E' on one or more of the entries in Grub's blue screen when booting the computer". If my interpretation is correct, please reread my post and, if you think Max's suggested action would be productive, try it out. If not, please elaborate on your use of the word "grub" in "I looked in grub". Cheers, David.
Re: kernel errors
David Wright writes: > On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote: >> Max Nikulin writes: >> > On 03/02/2023 01:47, Richmond wrote: >> >> It might be a good way for someone to reproduce the error on some >> >> other >> >> machine. I have no problems with the CD/DVD writer and have used it a >> >> few times recently. >> > >> > Do you see the same errors if kernel command line is edited from grub >> > to pass non-existing UUID specified in the resume=UUID=... argument? >> > It might be a quick way to reproduce the issue. >> >> I looked in grub but couldn't see any resume parameter. I think the way >> things work has changed, and this is hidden away somewhere. > > There are hundreds and hundreds of kernel command-line parameters, > so I'm not sure how you expect to see any evidence of each one in > Grub's configuration. We were talking about editing from grub during boot time, not looking in grubs configuration.
Re: kernel errors
Hi, i wrote: > > Maybe the script which runs blkid or alike has vanished during the recent > > reconstruction of the initrd which fixed the problems ? Richmond wrote: > I didn't need to reconstruct initrd to cause the problems. As far as I > remember all I did was destroy the swap space, having commented-it-out > of fstab. So I imagin that the scripts are the same. I rather meant the run which you meantioned in your mail of Thu, 02 Feb 2023 14:05:37 +: > > > sudo update-initramfs -u > > > After I did this, the errors went away. It is possible that there were files in /scripts/local-block before this run. > find /tmp/initrd21/ -print|xargs grep -i blkid|less > /tmp/initrd21/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || > return 1 This is the kind of blkid run which i expect to cause the mislead read attempts to the pseudo-end of /dev/sr0. If the given attribute is not found, then it cycles over all block devices, not knowing about the purpose of resuming and the usefulness of the device types. It is in function resolve_device() which obviously shall find a device matching either LABEL, UUID, PARTLABEL, or PARTUUID. A plausible caller of resolve_device() would be in hooks/resume: if resume_dev_node="$(resolve_device "$RESUME")" && \ blkid -p -n swap "$resume_dev_node" >/dev/null 2>&1; then But i fail to make the connection to the loop with the messages about /scripts/local-block. Have a nice day :) Thomas
Re: kernel errors
On Sat 04 Feb 2023 at 12:37:27 (+), Richmond wrote:
> Max Nikulin writes:
> > On 03/02/2023 01:47, Richmond wrote:
> >> It might be a good way for someone to reproduce the error on some
> >> other
> >> machine. I have no problems with the CD/DVD writer and have used it a
> >> few times recently.
> >
> > Do you see the same errors if kernel command line is edited from grub
> > to pass non-existing UUID specified in the resume=UUID=... argument?
> > It might be a quick way to reproduce the issue.
>
> I looked in grub but couldn't see any resume parameter. I think the way
> things work has changed, and this is hidden away somewhere.
There are hundreds and hundreds of kernel command-line parameters,
so I'm not sure how you expect to see any evidence of each one in
Grub's configuration. Imagine how often any one particular parameter
is employed by someone, eg,
earlycon= [KNL] Output early console device and options.
When used with no options, the early console is
determined by stdout-path property in device tree's
chosen node or the ACPI SPCR table if supported by
the platform.
lpuart,
lpuart32,
Use early console provided by Freescale LP UART driver
found on Freescale Vybrid and QorIQ LS1021A processors.
A valid base address must be provided, and the serial
port must already be setup and configured.
https://www.kernel.org/doc/html/v5.10/admin-guide/kernel-parameters.html
One caveat, though, about adding resume= in Grub. If a system has no
mention of resume when the initrd is built, I don't know whether the
scripts are included for handling it. In your case, you appear to
have these scripts, so it should be ok. Mind you, have you reported
what's in /etc/initramfs-tools/conf.d/resume? I've asked this before
(see last point below).
> > Is it realistic that usually optical drives are skipped during UUID
> > searches, but specific driver exposes a wrong property, so the device
> > is considered as a regular disk drive?
>
> I don't know.
Much of what I see grepped in this thread is stuff that I could read
off my machine. For example:
$ grep -r -I blkid
main/usr/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{builtin}="blkid"
main/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid
--offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
main/usr/lib/udev/rules.d/60-persistent-storage.rules: IMPORT{builtin}="blkid
--noraid"
main/usr/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*",
IMPORT{builtin}="blkid"
main/usr/lib/cryptsetup/functions:elif blk_t="$(blkid -s TYPE -o value
-- "$s")" && [ "$blk_t" = "BitLocker" ]; then
main/usr/lib/cryptsetup/functions:spec="$(blkid -l -t "$spec" -o
device)" || spec=
main/usr/lib/cryptsetup/functions:if uuid="$(blkid -s UUID -o value --
"$device")" && [ -n "$uuid" ]; then
main/scripts/local: # device in /dev and isn't resolvable by blkid (e.g.
mtd0)
main/scripts/functions: # blkid has a more complete list of file systems,
main/scripts/functions: FSTYPE=$(blkid -o value -s TYPE "${FS}") ||
return
main/scripts/functions: DEV="$(blkid -l -t "$DEV" -o device)" || return
1
$
(I have a few extra crypto lines.)
I wouldn't mind seeing a few properties and configuration parameters
from your machine, which will obviously differ from mine. (See my
previous post.)
Cheers,
David.
Re: kernel errors
Max Nikulin writes: > On 03/02/2023 01:47, Richmond wrote: >> It might be a good way for someone to reproduce the error on some >> other >> machine. I have no problems with the CD/DVD writer and have used it a >> few times recently. > > Do you see the same errors if kernel command line is edited from grub > to pass non-existing UUID specified in the resume=UUID=... argument? > It might be a quick way to reproduce the issue. I looked in grub but couldn't see any resume parameter. I think the way things work has changed, and this is hidden away somewhere. > > Is it realistic that usually optical drives are skipped during UUID > searches, but specific driver exposes a wrong property, so the device > is considered as a regular disk drive? I don't know.
Re: kernel errors
"Thomas Schmitt" writes:
> Hi,
>
> Richmond wrote:
>> /tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg
>> "Running /scripts/local-block"
>> [...]
>> local_block()
>> {
>>[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
>>run_scripts /scripts/local-block "$@"
>> [...]
>> Then later this, which would explain the delays: (The video shows
>> "waiting for suspend/resume device")
>> [...]
>> log_begin_msg "Waiting for ${name}"
>> [...]
>> while true; do
>> sleep 1
>> time_elapsed="$(time_elapsed)"
>>
>> local_block "${dev_id}"
>
> I remember to have seen this code under
> https://sources.debian.org/src/initramfs-tools/unstable/
> when i looked for occurences of "local-block". (This URL is currently not
> working for me.)
> I did not find any built-in runs of programs like blkid or lsblk. Thus i
> concluded that such runs would be in files of /scripts/local-block or other
> local customization of the initrd.
>
> We are most probably at the right spot of initramfs-tools.
> Maybe the script which runs blkid or alike has vanished during the recent
> reconstruction of the initrd which fixed the problems ?
I didn't need to reconstruct initrd to cause the problems. As far as I
remember all I did was destroy the swap space, having commented-it-out
of fstab. So I imagin that the scripts are the same. But I could test
that as suggested by Max Nikulin by altering the resume parameter from
grub before booting.
>
> Does fgrep find anything about "blkid" in /tmp/initrd21 ?
I did it like this:
find /tmp/initrd21/ -print|xargs grep -i blkid|less
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:
IMPORT{builtin}="blkid --offset=$env{ID_CDROM_MEDIA_SESSION_LAST_OFFSET}"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:
IMPORT{builtin}="blkid --noraid"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage.rules:KERNEL!="sr*",
IMPORT{builtin}="blkid"
/tmp/initrd21/usr/lib/udev/rules.d/60-persistent-storage-dm.rules:IMPORT{builtin}="blkid"
/tmp/initrd21/scripts/functions:# blkid has a more complete list of
file systems,
/tmp/initrd21/scripts/functions:FSTYPE=$(blkid -o value -s TYPE
"${FS}") || return
/tmp/initrd21/scripts/functions:DEV="$(blkid -l -t "$DEV" -o
device)" || return 1
/tmp/initrd21/scripts/local:# device in /dev and isn't resolvable by blkid
(e.g. mtd0)
Re: kernel errors
Hi,
Richmond wrote:
> /tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg
> "Running /scripts/local-block"
> [...]
> local_block()
> {
>[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
>run_scripts /scripts/local-block "$@"
> [...]
> Then later this, which would explain the delays: (The video shows
> "waiting for suspend/resume device")
> [...]
> log_begin_msg "Waiting for ${name}"
> [...]
> while true; do
> sleep 1
> time_elapsed="$(time_elapsed)"
>
> local_block "${dev_id}"
I remember to have seen this code under
https://sources.debian.org/src/initramfs-tools/unstable/
when i looked for occurences of "local-block". (This URL is currently not
working for me.)
I did not find any built-in runs of programs like blkid or lsblk. Thus i
concluded that such runs would be in files of /scripts/local-block or other
local customization of the initrd.
We are most probably at the right spot of initramfs-tools.
Maybe the script which runs blkid or alike has vanished during the recent
reconstruction of the initrd which fixed the problems ?
Does fgrep find anything about "blkid" in /tmp/initrd21 ?
Have a nice day :)
Thomas
Re: kernel errors
On 03/02/2023 01:47, Richmond wrote: It might be a good way for someone to reproduce the error on some other machine. I have no problems with the CD/DVD writer and have used it a few times recently. Do you see the same errors if kernel command line is edited from grub to pass non-existing UUID specified in the resume=UUID=... argument? It might be a quick way to reproduce the issue. Is it realistic that usually optical drives are skipped during UUID searches, but specific driver exposes a wrong property, so the device is considered as a regular disk drive?
Re: kernel errors
sorry, replied to wrong list. On Fri, 03 Feb 2023 16:55:18 -0500, John Covici wrote: > > For instance I just got a post from Freedom Scientific which had the > announcement in the Email and also link to the post. > On Fri, 03 Feb 2023 15:28:55 -0500, > David Wright wrote: > > > > On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote: > > > David Wright writes: > > > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > > > >> "Thomas Schmitt" writes: > > > >> > > > > >> > (If not there, then in the /scripts/local-block directory of the > > > >> > initrd ?) > > > >> > > > >> I don't know how I would look in that. Is it in RAM at boot time? > > > > > > > >Choose your kernel ↓↓Pick any name > > > > > > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > > > > $ ls -GlgR /tmp/initrd21/main/scripts/ > > > > /tmp/initrd21/main/scripts/: > > > > total 48 > > > > -rw-r--r-- 1 11152 Jan 14 2021 functions > > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > > > > -rw-r--r-- 1 5303 Jan 14 2021 local > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > > > > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > > > > > > > /tmp/initrd21/main/scripts/init-bottom: > > > > total 8 > > > > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > > > > > > > /tmp/initrd21/main/scripts/init-top: > > > > total 20 > > > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > > > > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > > > > -rwxr-xr-x 1 167 Jan 14 2021 keymap > > > > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > > > > > > > /tmp/initrd21/main/scripts/local-block: > > > > total 8 > > > > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > > > > > > > /tmp/initrd21/main/scripts/local-bottom: > > > > total 20 > > > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > > > > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > > > > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > > > > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > > > > > > > /tmp/initrd21/main/scripts/local-premount: > > > > total 12 > > > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > > > > -rwxr-xr-x 1 863 Jan 14 2021 resume > > > > > > > > /tmp/initrd21/main/scripts/local-top: > > > > total 20 > > > > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > > > > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > > > > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > > > > $ > > > > > > > > This is a desktop with random-key swap, so no resume. > > > > There are encrypted partitions present. YMMV. > > > > > > > > Cheers, > > > > David. > > > > > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > > ~$ find /tmp/initrd21/ -print|grep "local-block" > > > ~$ find /tmp/initrd21/ -print|grep "local" > > > > > > /tmp/initrd21/usr/local > > > /tmp/initrd21/usr/local/share > > > /tmp/initrd21/usr/local/share/fonts > > > /tmp/initrd21/usr/local/share/fonts/.uuid > > > /tmp/initrd21/scripts/local-bottom > > > /tmp/initrd21/scripts/local-bottom/ntfs_3g > > > /tmp/initrd21/scripts/local-bottom/ORDER > > > /tmp/initrd21/scripts/local > > > /tmp/initrd21/scripts/local-premount > > > /tmp/initrd21/scripts/local-premount/ntfs_3g > > > /tmp/initrd21/scripts/local-premount/ORDER > > > /tmp/initrd21/scripts/local-premount/resume > > > > > > No local block. :-? > > > > > > find /tmp/initrd21/ -print|grep local|grep block > > > > > > No output here. > > > > Well, no, but there is a resume sitting there in local-premount, > > which suggests to me¹ that you perhaps have something in > > /etc/initramfs-tools/conf.d/resume. Has that been reported? > > > > I'd also be interested to see the output from: > > > > $ ls -lR /dev/disk | grep sr > > > > and > > > > $ grep -e sr -e sw /etc/fstab > > > > The intent of that last pattern is to see the swap lines that you > > have been commenting out. > > > > Of course, we might not see anything unusual anywhere while the > > machines are in their "fixed" state (whatever that means). > > > > ¹ This is a guess, based on the fact that I also have that file in > > initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume, > > and something somewhere has to read the word "none". > > > > Cheers, > > David. > > > > -- > Your life is like a penny. You're going to lose it. The question is: > How do > you spend it? > > John Covici wb2una > cov...@ccs.covici.com > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: kernel errors
For instance I just got a post from Freedom Scientific which had the announcement in the Email and also link to the post. On Fri, 03 Feb 2023 15:28:55 -0500, David Wright wrote: > > On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote: > > David Wright writes: > > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > > >> "Thomas Schmitt" writes: > > >> > > > >> > (If not there, then in the /scripts/local-block directory of the > > >> > initrd ?) > > >> > > >> I don't know how I would look in that. Is it in RAM at boot time? > > > > > >Choose your kernel ↓↓Pick any name > > > > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > > > $ ls -GlgR /tmp/initrd21/main/scripts/ > > > /tmp/initrd21/main/scripts/: > > > total 48 > > > -rw-r--r-- 1 11152 Jan 14 2021 functions > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > > > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > > > -rw-r--r-- 1 5303 Jan 14 2021 local > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > > > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > > > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > > > > > /tmp/initrd21/main/scripts/init-bottom: > > > total 8 > > > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > > > > > /tmp/initrd21/main/scripts/init-top: > > > total 20 > > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > > > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > > > -rwxr-xr-x 1 167 Jan 14 2021 keymap > > > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > > > > > /tmp/initrd21/main/scripts/local-block: > > > total 8 > > > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > > > > > /tmp/initrd21/main/scripts/local-bottom: > > > total 20 > > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > > > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > > > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > > > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > > > > > /tmp/initrd21/main/scripts/local-premount: > > > total 12 > > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > > > -rwxr-xr-x 1 863 Jan 14 2021 resume > > > > > > /tmp/initrd21/main/scripts/local-top: > > > total 20 > > > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > > > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > > > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > > > $ > > > > > > This is a desktop with random-key swap, so no resume. > > > There are encrypted partitions present. YMMV. > > > > > > Cheers, > > > David. > > > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > ~$ find /tmp/initrd21/ -print|grep "local-block" > > ~$ find /tmp/initrd21/ -print|grep "local" > > > > /tmp/initrd21/usr/local > > /tmp/initrd21/usr/local/share > > /tmp/initrd21/usr/local/share/fonts > > /tmp/initrd21/usr/local/share/fonts/.uuid > > /tmp/initrd21/scripts/local-bottom > > /tmp/initrd21/scripts/local-bottom/ntfs_3g > > /tmp/initrd21/scripts/local-bottom/ORDER > > /tmp/initrd21/scripts/local > > /tmp/initrd21/scripts/local-premount > > /tmp/initrd21/scripts/local-premount/ntfs_3g > > /tmp/initrd21/scripts/local-premount/ORDER > > /tmp/initrd21/scripts/local-premount/resume > > > > No local block. :-? > > > > find /tmp/initrd21/ -print|grep local|grep block > > > > No output here. > > Well, no, but there is a resume sitting there in local-premount, > which suggests to me¹ that you perhaps have something in > /etc/initramfs-tools/conf.d/resume. Has that been reported? > > I'd also be interested to see the output from: > > $ ls -lR /dev/disk | grep sr > > and > > $ grep -e sr -e sw /etc/fstab > > The intent of that last pattern is to see the swap lines that you > have been commenting out. > > Of course, we might not see anything unusual anywhere while the > machines are in their "fixed" state (whatever that means). > > ¹ This is a guess, based on the fact that I also have that file in > initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume, > and something somewhere has to read the word "none". > > Cheers, > David. > -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: kernel errors
On Fri 03 Feb 2023 at 13:12:05 (+), Richmond wrote: > David Wright writes: > > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > >> "Thomas Schmitt" writes: > >> > > >> > (If not there, then in the /scripts/local-block directory of the initrd > >> > ?) > >> > >> I don't know how I would look in that. Is it in RAM at boot time? > > > >Choose your kernel ↓↓Pick any name > > > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > > $ ls -GlgR /tmp/initrd21/main/scripts/ > > /tmp/initrd21/main/scripts/: > > total 48 > > -rw-r--r-- 1 11152 Jan 14 2021 functions > > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > > -rw-r--r-- 1 5303 Jan 14 2021 local > > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > > > /tmp/initrd21/main/scripts/init-bottom: > > total 8 > > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > > > /tmp/initrd21/main/scripts/init-top: > > total 20 > > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > > -rwxr-xr-x 1 167 Jan 14 2021 keymap > > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > > > /tmp/initrd21/main/scripts/local-block: > > total 8 > > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > > > /tmp/initrd21/main/scripts/local-bottom: > > total 20 > > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > > > /tmp/initrd21/main/scripts/local-premount: > > total 12 > > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > > -rwxr-xr-x 1 863 Jan 14 2021 resume > > > > /tmp/initrd21/main/scripts/local-top: > > total 20 > > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > > $ > > > > This is a desktop with random-key swap, so no resume. > > There are encrypted partitions present. YMMV. > > > > Cheers, > > David. > > ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > ~$ find /tmp/initrd21/ -print|grep "local-block" > ~$ find /tmp/initrd21/ -print|grep "local" > > /tmp/initrd21/usr/local > /tmp/initrd21/usr/local/share > /tmp/initrd21/usr/local/share/fonts > /tmp/initrd21/usr/local/share/fonts/.uuid > /tmp/initrd21/scripts/local-bottom > /tmp/initrd21/scripts/local-bottom/ntfs_3g > /tmp/initrd21/scripts/local-bottom/ORDER > /tmp/initrd21/scripts/local > /tmp/initrd21/scripts/local-premount > /tmp/initrd21/scripts/local-premount/ntfs_3g > /tmp/initrd21/scripts/local-premount/ORDER > /tmp/initrd21/scripts/local-premount/resume > > No local block. :-? > > find /tmp/initrd21/ -print|grep local|grep block > > No output here. Well, no, but there is a resume sitting there in local-premount, which suggests to me¹ that you perhaps have something in /etc/initramfs-tools/conf.d/resume. Has that been reported? I'd also be interested to see the output from: $ ls -lR /dev/disk | grep sr and $ grep -e sr -e sw /etc/fstab The intent of that last pattern is to see the swap lines that you have been commenting out. Of course, we might not see anything unusual anywhere while the machines are in their "fixed" state (whatever that means). ¹ This is a guess, based on the fact that I also have that file in initrd, and I have RESUME=none in /etc/initramfs-tools/conf.d/resume, and something somewhere has to read the word "none". Cheers, David.
Re: kernel errors
"Thomas Schmitt" writes:
> Hi,
>
> Richmond wrote:
>> No local block. :-?
>
> Maybe you can find our from where the message comes:
>
> grep -r 'Running.*scripts.*local-block' /tmp/initrd21
>
>
grep -r 'Running.*scripts.*local-block' /tmp/initrd21
/tmp/initrd21/scripts/local:[ "${quiet?}" != "y" ] && log_begin_msg
"Running /scripts/local-block"
This contains:
===
local_block()
{
[ "${quiet?}" != "y" ] && log_begin_msg "Running /scripts/local-block"
run_scripts /scripts/local-block "$@"
[ "$quiet" != "y" ] && log_end_msg
}
===
Then later this, which would explain the delays: (The video shows
"waiting for suspend/resume device")
===
# If the root device hasn't shown up yet, give it a little while
# to allow for asynchronous device discovery (e.g. USB). We
# also need to keep invoking the local-block scripts in case
# there are devices stacked on top of those.
if ! real_dev=$(resolve_device "${dev_id}") ||
! get_fstype "${real_dev}" >/dev/null; then
log_begin_msg "Waiting for ${name}"
# Timeout is max(30, rootdelay) seconds (approximately)
slumber=30
if [ "${ROOTDELAY:-0}" -gt $slumber ]; then
slumber=$ROOTDELAY
fi
while true; do
sleep 1
time_elapsed="$(time_elapsed)"
local_block "${dev_id}"
# If mdadm's local-block script counts the
# number of times it is run, make sure to
# run it the expected number of times.
while true; do
if [ -f /run/count.mdadm.initrd ]; then
count="$(cat /run/count.mdadm.initrd)"
elif [ -n "${count}" ]; then
# mdadm script deleted it; put it back
count=$((count + 1))
echo "${count}" >/run/count.mdadm.initrd
else
:
Re: kernel errors
Hi, Richmond wrote: > No local block. :-? Maybe you can find our from where the message comes: grep -r 'Running.*scripts.*local-block' /tmp/initrd21 Have a nice day :) Thomas
Re: kernel errors
David Wright writes: > On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: >> "Thomas Schmitt" writes: >> > >> > (If not there, then in the /scripts/local-block directory of the initrd ?) >> >> I don't know how I would look in that. Is it in RAM at boot time? > >Choose your kernel ↓↓Pick any name > > $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 > cpio: etc/console-setup/null: Cannot mknod: Operation not permitted > $ ls -GlgR /tmp/initrd21/main/scripts/ > /tmp/initrd21/main/scripts/: > total 48 > -rw-r--r-- 1 11152 Jan 14 2021 functions > drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom > drwxr-xr-x 2 4096 Feb 2 18:45 init-top > -rw-r--r-- 1 5303 Jan 14 2021 local > drwxr-xr-x 2 4096 Feb 2 18:45 local-block > drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom > drwxr-xr-x 2 4096 Feb 2 18:45 local-premount > drwxr-xr-x 2 4096 Feb 2 18:45 local-top > -rw-r--r-- 1 3093 Jan 14 2021 nfs > > /tmp/initrd21/main/scripts/init-bottom: > total 8 > -rw-r--r-- 1 77 Jan 23 21:46 ORDER > -rwxr-xr-x 1 611 Aug 7 08:25 udev > > /tmp/initrd21/main/scripts/init-top: > total 20 > -rw-r--r-- 1 314 Jan 23 21:46 ORDER > -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide > -rwxr-xr-x 1 296 Jan 14 2021 blacklist > -rwxr-xr-x 1 167 Jan 14 2021 keymap > -rwxr-xr-x 1 568 Aug 7 08:25 udev > > /tmp/initrd21/main/scripts/local-block: > total 8 > -rw-r--r-- 1 82 Jan 23 21:46 ORDER > -rwxr-xr-x 1 246 Feb 1 2022 cryptroot > > /tmp/initrd21/main/scripts/local-bottom: > total 20 > -rw-r--r-- 1 336 Jan 23 21:46 ORDER > -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc > -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc > -rwxr-xr-x 1 307 Feb 1 2022 cryptroot > -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g > > /tmp/initrd21/main/scripts/local-premount: > total 12 > -rw-r--r-- 1 165 Jan 23 21:46 ORDER > -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g > -rwxr-xr-x 1 863 Jan 14 2021 resume > > /tmp/initrd21/main/scripts/local-top: > total 20 > -rw-r--r-- 1 162 Jan 23 21:46 ORDER > -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc > -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot > $ > > This is a desktop with random-key swap, so no resume. > There are encrypted partitions present. YMMV. > > Cheers, > David. ~$ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 ~$ find /tmp/initrd21/ -print|grep "local-block" ~$ find /tmp/initrd21/ -print|grep "local" /tmp/initrd21/usr/local /tmp/initrd21/usr/local/share /tmp/initrd21/usr/local/share/fonts /tmp/initrd21/usr/local/share/fonts/.uuid /tmp/initrd21/scripts/local-bottom /tmp/initrd21/scripts/local-bottom/ntfs_3g /tmp/initrd21/scripts/local-bottom/ORDER /tmp/initrd21/scripts/local /tmp/initrd21/scripts/local-premount /tmp/initrd21/scripts/local-premount/ntfs_3g /tmp/initrd21/scripts/local-premount/ORDER /tmp/initrd21/scripts/local-premount/resume No local block. :-? find /tmp/initrd21/ -print|grep local|grep block No output here.
Re: kernel errors
Michel Verdier writes: > Le 2 février 2023 Richmond a écrit : > >> There is no such file. Earlier I ran this: >> >> find / -print|grep "scripts/local-block" >> >> and it found nothing, which led me to believe it is some temporary file... >>> >>> (If not there, then in the /scripts/local-block directory of the initrd ?) > > its part of initramfs-tools to build initrd when you use cryptsetup, > mdadm, etc > > $ locate local-block > /usr/share/initramfs-tools/scripts/local-block > /usr/share/initramfs-tools/scripts/local-block/cryptroot > > $ apt-file search /usr/share/initramfs-tools/scripts/local-block > cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot > lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 > mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm > osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl sudo locate local-block produced no output. sudo apt-file search /usr/share/initramfs-tools/scripts/local-block cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl I don't have an encrypted file system. sudo aptitude show cryptsetup-initramfs|grep State State: not installed sudo aptitude show lvm2|grep State State: not installed sudo aptitude show mdadm|grep State State: not installed sudo aptitude show osk-sdl|grep State State: not installed
Re: kernel errors
On Thu 02 Feb 2023 at 21:58:54 (+), Richmond wrote: > "Thomas Schmitt" writes: > > > > (If not there, then in the /scripts/local-block directory of the initrd ?) > > I don't know how I would look in that. Is it in RAM at boot time? Choose your kernel ↓↓Pick any name $ unmkinitramfs /boot/initrd.img-5.10.0-21-amd64 /tmp/initrd21 cpio: etc/console-setup/null: Cannot mknod: Operation not permitted $ ls -GlgR /tmp/initrd21/main/scripts/ /tmp/initrd21/main/scripts/: total 48 -rw-r--r-- 1 11152 Jan 14 2021 functions drwxr-xr-x 2 4096 Feb 2 18:45 init-bottom drwxr-xr-x 2 4096 Feb 2 18:45 init-top -rw-r--r-- 1 5303 Jan 14 2021 local drwxr-xr-x 2 4096 Feb 2 18:45 local-block drwxr-xr-x 2 4096 Feb 2 18:45 local-bottom drwxr-xr-x 2 4096 Feb 2 18:45 local-premount drwxr-xr-x 2 4096 Feb 2 18:45 local-top -rw-r--r-- 1 3093 Jan 14 2021 nfs /tmp/initrd21/main/scripts/init-bottom: total 8 -rw-r--r-- 1 77 Jan 23 21:46 ORDER -rwxr-xr-x 1 611 Aug 7 08:25 udev /tmp/initrd21/main/scripts/init-top: total 20 -rw-r--r-- 1 314 Jan 23 21:46 ORDER -rwxr-xr-x 1 384 Jan 14 2021 all_generic_ide -rwxr-xr-x 1 296 Jan 14 2021 blacklist -rwxr-xr-x 1 167 Jan 14 2021 keymap -rwxr-xr-x 1 568 Aug 7 08:25 udev /tmp/initrd21/main/scripts/local-block: total 8 -rw-r--r-- 1 82 Jan 23 21:46 ORDER -rwxr-xr-x 1 246 Feb 1 2022 cryptroot /tmp/initrd21/main/scripts/local-bottom: total 20 -rw-r--r-- 1 336 Jan 23 21:46 ORDER -rwxr-xr-x 1 253 Feb 1 2022 cryptgnupg-sc -rwxr-xr-x 1 449 Feb 1 2022 cryptopensc -rwxr-xr-x 1 307 Feb 1 2022 cryptroot -rwxr-xr-x 1 345 Nov 2 16:46 ntfs_3g /tmp/initrd21/main/scripts/local-premount: total 12 -rw-r--r-- 1 165 Jan 23 21:46 ORDER -rwxr-xr-x 1 226 Nov 2 16:46 ntfs_3g -rwxr-xr-x 1 863 Jan 14 2021 resume /tmp/initrd21/main/scripts/local-top: total 20 -rw-r--r-- 1 162 Jan 23 21:46 ORDER -rwxr-xr-x 1 757 Feb 1 2022 cryptopensc -rwxr-xr-x 1 8630 Feb 1 2022 cryptroot $ This is a desktop with random-key swap, so no resume. There are encrypted partitions present. YMMV. Cheers, David.
Re: kernel errors
Le 2 février 2023 Richmond a écrit : > There is no such file. Earlier I ran this: > > find / -print|grep "scripts/local-block" > > and it found nothing, which led me to believe it is some temporary file... >> >> (If not there, then in the /scripts/local-block directory of the initrd ?) its part of initramfs-tools to build initrd when you use cryptsetup, mdadm, etc $ locate local-block /usr/share/initramfs-tools/scripts/local-block /usr/share/initramfs-tools/scripts/local-block/cryptroot $ apt-file search /usr/share/initramfs-tools/scripts/local-block cryptsetup-initramfs: /usr/share/initramfs-tools/scripts/local-block/cryptroot lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm osk-sdl: /usr/share/initramfs-tools/scripts/local-block/osk-sdl
Re: kernel errors
"Thomas Schmitt" writes: > Indeed. But why should only the kernel be brain damaged ? > > (I expect some generic UUID searcher for block devices. Probably the sr > devices are near the end of its iteration. So one would not see any > protest in the log if the UUID is found on the device which is tried > earlier.) It crossed my mind that someone could conceivably be using the Universal Disk Format on a DVD RW. > Still missing is the code which wants to inspect sr. I tried to learn > about /scripts/local-block in initramfs-tools. Regrettably it seems to > be about a local customization of the initrd, which is not done by > initramfs-tools but by its customers. > A search for "local-block" in Debian's source collection by > https://codesearch.debian.net/search?q=local-block > did not yield good candidates. > > Do you see something related to resume in the output of > ls /usr/share/initramfs-tools/scripts/local-block There is no such file. Earlier I ran this: find / -print|grep "scripts/local-block" and it found nothing, which led me to believe it is some temporary file... > > (If not there, then in the /scripts/local-block directory of the initrd ?) I don't know how I would look in that. Is it in RAM at boot time? In the log which appears on the screen it says: Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ... done. random: crng init done /scripts/local-block ... done. Then this last line was repeated 17 times and much time was spent. Then it gave up.
Re: kernel errors
Hi, Richmond wrote: > Perhaps the system was looking for resume space on sr0? That's my guess too. We already knew that the read address and block size come from the kernel's brain damaged representation of a drive which has not seen a medium since boot. My suspicion was that libblkid is involved. But it was not clear what software wanted the service of libblkid. Now we have a candidate for that. > It seems a strange thing to do. Indeed. But why should only the kernel be brain damaged ? (I expect some generic UUID searcher for block devices. Probably the sr devices are near the end of its iteration. So one would not see any protest in the log if the UUID is found on the device which is tried earlier.) > But also it is quite a coincidence if the errors > occur when the resume space is messed up, and they go away when it is > fixed. That has happened twice. Empirically the situation is clear. Still missing is the code which wants to inspect sr. I tried to learn about /scripts/local-block in initramfs-tools. Regrettably it seems to be about a local customization of the initrd, which is not done by initramfs-tools but by its customers. A search for "local-block" in Debian's source collection by https://codesearch.debian.net/search?q=local-block did not yield good candidates. Do you see something related to resume in the output of ls /usr/share/initramfs-tools/scripts/local-block (If not there, then in the /scripts/local-block directory of the initrd ?) Have a nice day :) Thomas
Re: kernel errors - SOLVED
piorunz writes: > On 02/02/2023 14:05, Richmond wrote: >> After I did this, the errors went away. >> I don't know why the errors reference sr0, it's a mystery. > > They will most likely come back, this error is related to optical > drive, nothing to do with swap space. Perhaps the system was looking for resume space on sr0? It seems a strange thing to do. But also it is quite a coincidence if the errors occur when the resume space is messed up, and they go away when it is fixed. That has happened twice. It might be a good way for someone to reproduce the error on some other machine. I have no problems with the CD/DVD writer and have used it a few times recently.
Re: kernel errors - SOLVED
On 02/02/2023 14:05, Richmond wrote: After I did this, the errors went away. I don't know why the errors reference sr0, it's a mystery. They will most likely come back, this error is related to optical drive, nothing to do with swap space. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors - SOLVED
Richmond writes: > It may be a coincidence but yesterday I installed some > libguestfs-tools. Now I see errors when booting, which also appear in > /var/log/messages: > > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer > kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer These errors started occurring again. This time I knew what I had done, I commented out a line in fstab referencing a swap space, because the system had two swap spaces defined and I wanted to use one for something else. What I overlooked was that this swap space was also the resume space. During the boot there were other messages which did not appear in the journal so I filmed them with a smart phone: Running /scripts/local-block.. These occurred over and over, but allowed me to find this site: https://tipstricks.itmatrix.eu/solving-the-running-scripts-local-block-loop-while-booting-in-linux/ Which explained the problem and how to fix it. I had already edited: /etc/initramfs-tools/conf.d/resume To use the other swap space. But this did not help because I missed this crucial step: sudo update-initramfs -u After I did this, the errors went away. I don't know why the errors reference sr0, it's a mystery.
Re: kernel errors
Hi, Thomas Amm wrote: > First you might remove the pktcdvd module: > Not sure if it causes this specific problem but it is for pre- > growisofs CD-RW writing. The packet writing device bundles smaller write requests in larger chunks and ensures to write only at addresses and with sizes which are aligned to the medium's Fixed Packet Size. With CD this size can be chosen. With DVD it is 16 = 32 KiB. With BD it is 32 = 64 KiB. > Nobody uses that anymore Packet writing is life prolonging with random access writing to formatted CD-RW and maybe to DVD-RAM, DVD+RW, and BD-RE. It is needed for random access writing to formatted DVD-RW, which only accept write operations with 32 KiB granularity. Burn programs do not need /dev/pktcdvd, because they usually write sequentially with a suitable alignment. (.. and sequential writing is the most life prolonging way of writing.) > and it interferes with "straight" CD/DVD-burning. Not necessarily. The /dev/pktcdvd device uses the /dev/sr device when it performs its operations. But as long as it is not used, the /dev/sr device will not be disturbed. And even if so, then the media types which are suitable for /dev/pktcdvd can stand WRITE commands from two uncoordinated processes. Have a nice day :) Thomas
Re: kernel errors
On Mon, 2023-01-23 at 17:34 +, Richmond wrote: > Sven Joachim writes: > > > On 2023-01-23 16:13 +, Richmond wrote: > > > > > I put a dvd in and mounted it. Then rebooted. I saw these > > > messages: > > > > > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > > > [ 3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer > > > dvd-ram cd/rw xa/form2 cdda tray > > > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 > > > > > > Then removed the DVD and rebooted, back to these: > > > > > > [ 4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer > > > dvd-ram cd/rw xa/form2 cdda tray > > > [ 9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: > > > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > > > [ 9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready > > > [current] > > > [ 9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not > > > present - tray closed > > > [ 9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 > > > ff fc 00 00 02 00 > > > [ 9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer > > > > > > I am starting to consider re-installing, although everything is > > > working, > > > I don't like the look of it. Perhaps I should just re-install the > > > kernel? > > > > This would most likely not help. Instead you should try to figure > > out > > what process is trying to read from your empty drive, and why. > > Consulting journalctl might help with that. > > > > Cheers, > > Sven > > re-installing kernel didn't work. > > I looked in journalctl and saw this: > > kernel: PM: Image not found (code -22) > > It's looking for a resume from hibernate maybe. > > So then it became apparent that the kernel parameter to resume is a > disk > by id which looks different from the ones in /etc/fstab. I am not > sure > how that came about. > First you might remove the pktcdvd module: pktsetup -d /dev/sr0 -q Not sure if it causes this specific problem but it is for pre- growisofs CD-RW writing. Nobody uses that anymore and it interferes with "straight" CD/DVD-burning. If the error messages still show up after that it's most likely an unreadable DVD or your DVD-drive is beginning to fail. Usually the tracking lasers in these devices get deadjusted after a few years and readjusting them would be too much effort.
Re: kernel errors
Hi, piorunz wrote: > read attempts continue, Obviously your drive groper is different from Richmond's. Both get lured into their activities by the kernel bugs. > Inserting blank disc on every reboot is not a solution in my opinion. And I > didn't verified it myself, It would be interesting to know, nevertheless. > so I don't know if its going to work in my case, > or Linux at some point will realize the trick. :D It might last a while until Linux gets to a better behavior. My patches from 2020 are not totally trivial. So even if they still are applicable and there is a sponsor who gets them reviewed, i doubt that they would easily get accepted. Richmond reports from OpenSUSE with kernel 5.3 that the handling of blank media seems to have changed. But i still see it with 5.10. If you can identify the program which gets lured into probing the drive, then you could ask its developer to ignore optical drives of which the kernel reports sector size 512. But as soon as a medium was in the drive, the deception begins again. Have a nice day :) Thomas
Re: kernel errors
On 25/01/2023 15:26, Thomas Schmitt wrote: it might be that there are no further (periodic) read attempts. If the messages only appear once during the boot procedure, then i think the issue is explored as far as possible without starting kernel programming. Just to briefly comment on this - read attempts continue, please see my earlier messages in this thread, including original bug report 2 years ago. dmesg is infested with these errors in red, periodically there is another one, triggered by something, it goes on forever. Inserting blank disc on every reboot is not a solution in my opinion. And I didn't verified it myself, so I don't know if its going to work in my case, or Linux at some point will realize the trick. :D -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors
Hi, Richmond wrote: > VENDOR MODEL SIZE PHY-SEC LOG-SEC > HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 > It has stayed like this after I removed it. Next question would be whether the error messages stopped after this. But re-reading your initial post: > > I see errors when booting, which also appear in /var/log/messages: it might be that there are no further (periodic) read attempts. If the messages only appear once during the boot procedure, then i think the issue is explored as far as possible without starting kernel programming. The Linux kernel is buggy in respect to sector size and readable capacity of empty optical drives or drives with unreadable media. Ignore the error messages during system startup. You could try whether having a CD or DVD in the drive while booting silences the error messages. But i would not consider this as a workable long term solution. It is still not known what change on your system caused the read attempts to begin. The involved software could be made smarter to ignore sr devices which bear the impossible sector size 512. This size indicates that no medium was seen in the device since the device was started up. > I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting > the blank disk in did not change the values, it still showed 512. It's a vivid bug, then. So my proposal to have a CD or DVD in the tray while booting would need the additional prescription that the medium must really be readable. And the possible workaround for periodic read attempts would not work any more. Have a nice day :) Thomas
Re: kernel errors
Richmond writes: > "Thomas Schmitt" writes: > >> Hi, >> >> i wrote: >>> > If you have some blank optical medium, then try whether the emitter of >>> > the read attempt can be discouraged if the drive is perceived as offering >>> > just one block of 2048 bytes. >> >> Richmond wrote: >>> I don't know how to do that. Do you mean make a DVD with 1 block of data? >> >> Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW. >> The size perception will change to >> VENDOR MODEL SIZE PHY-SEC LOG-SEC >> HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 >> >> Pull it out again, and this state will persist until you put in a medium >> which is readable, or until you reboot. >> > > I put in a blank DVD+RW. > > lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* > VENDOR MODEL SIZE PHY-SEC LOG-SEC > HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 > > It has stayed like this after I removed it. I tried this on the same PC, but OpenSUSE 15.2, kernel 5.3 and putting the blank disk in did not change the values, it still showed 512.
Re: kernel errors
"Thomas Schmitt" writes: > Hi, > > i wrote: >> > If you have some blank optical medium, then try whether the emitter of >> > the read attempt can be discouraged if the drive is perceived as offering >> > just one block of 2048 bytes. > > Richmond wrote: >> I don't know how to do that. Do you mean make a DVD with 1 block of data? > > Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW. > The size perception will change to > VENDOR MODEL SIZE PHY-SEC LOG-SEC > HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 > > Pull it out again, and this state will persist until you put in a medium > which is readable, or until you reboot. > I put in a blank DVD+RW. lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 It has stayed like this after I removed it.
Re: kernel errors
Hi, i wrote: > > If you have some blank optical medium, then try whether the emitter of > > the read attempt can be discouraged if the drive is perceived as offering > > just one block of 2048 bytes. Richmond wrote: > I don't know how to do that. Do you mean make a DVD with 1 block of data? Just put in a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW. The size perception will change to VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST HL-DT-ST_DVDRAM_GH15F 204820482048 Pull it out again, and this state will persist until you put in a medium which is readable, or until you reboot. > > There are many motivations to read the start of the device and fewer to > > read its end. One reason to read the end is the GPT backup header, which > > would sit 512 bytes before the end. > > The main GPT header block is at byte 512 of the storage device. > I am not using GPT on any systems. They all have ext4 root partitions. GPT might be used to mark partitions. It is the newer partition table format, which replaced most usages of the old MBR partition table. Whatever, it is not about what you actually use, but what the yet unknown software is looking for. libblkid would check for properties like PARTTYPE, PARTLABEL, or PARTUUID. Therefore it would look for GPT header blocks, regardless whether they are there. Have a nice day :) Thomas
Re: kernel errors
"Thomas Schmitt" writes: > I assume that you will see the same result there. lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST HL-DT-ST_DVDRAM_GH15F 1073741312 512 512 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux > > If you have some blank optical medium, then try whether the emitter of > the read attempt can be discouraged if the drive is perceived as offering > just one block of 2048 bytes. I don't know how to do that. Do you mean make a DVD with 1 block of data? > There are many motivations to read the start of the device and fewer to > read its end. One reason to read the end is the GPT backup header, which > would sit 512 bytes before the end. > The main GPT header block is at byte 512 of the storage device. I am not using GPT on any systems. They all have ext4 root partitions.
Re: kernel errors
On 25/01/2023 10:38, Thomas Schmitt wrote: Are users of Debian 10 (actually of kernel 4.19) here who are willing to run lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* directly after booting with empty drive tray ? $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODELSIZE PHY-SEC LOG-SEC hp hp_DVDRW_GUE1N 1073741312 512 512 $ sudo dmesg | grep sr0 [2.635585] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [2.707836] sr 1:0:0:0: Attached scsi CD-ROM sr0 Invisible medium seen by kernel is exactly 1GiB in size minus 512 bytes. But no errors in dmesg yet. By the way this is after power off, power on, with freshly upgraded stable kernel 5.10.0-21. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors
Hi, i wrote: > > Back in 2020 i would quite surely have noticed > > if that behavior had been shown. Richmond wrote: > lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* > VENDOR MODELSIZE PHY-SEC LOG-SEC > TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512 512 > > 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux So this behavior is not new. > This is a laptop where I rarely use the CD/DVD. Note it is not the same > computer as was getting errors before, that was debian 11. I assume that you will see the same result there. It would explain the block address of the first read attempt and the log messages about unaligned access. kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer If you have some blank optical medium, then try whether the emitter of the read attempt can be discouraged if the drive is perceived as offering just one block of 2048 bytes. -- The unresolved riddle is which software began to try reading from the optical drive after your recent package installations or upgrades. It might be a different one than the software which does similar read attempts on piorunz' machine since years. In any case these softwares inquire the device capacity from systemd or directly from the kernel. Then they try to read end and start of the obtained capacity. There are many motivations to read the start of the device and fewer to read its end. One reason to read the end is the GPT backup header, which would sit 512 bytes before the end. The main GPT header block is at byte 512 of the storage device. This would explain the next failed read attempt: kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 I wonder why the caller did not want only 512 or 1024 bytes. The number of 2 requested blocks cannot come from the read-ahead mechanism of the Linux block layer. I would still place my bet on something like blkid, which wants to know whether there is a partition table. Maybe there was a change about a customer of libblkid. Have a nice day :) Thomas
Re: kernel errors
"Thomas Schmitt" writes: > > Are users of Debian 10 (actually of kernel 4.19) here who are willing to > run > lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* > directly after booting with empty drive tray ? lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODELSIZE PHY-SEC LOG-SEC TSSTcorp TSSTcorp_DVD+_-RW_TS-L632H 1073741312 512 512 4.19.0-23-amd64 #1 SMP Debian 4.19.269-1 (2022-12-20) x86_64 GNU/Linux This is a laptop where I rarely use the CD/DVD. Note it is not the same computer as was getting errors before, that was debian 11.
Re: kernel errors
Hi, piorunz wrote: > CD inserted: > $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 > VENDOR MODEL SIZE PHY-SEC LOG-SEC > hp hp_DVDRW_GUE1N 62765670420482048 > DVD inserted: > $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 > VENDOR MODELSIZE PHY-SEC LOG-SEC > hp hp_DVDRW_GUE1N 335334604820482048 So we know that the kernel-perceived block size is correctly 2048 when a medium is inserted. Do the complaints continue to appear in the logs while the medium is loaded ? The remaining question is what the kernel perceives after the system has booted and no medium was inserted since then. And for completeness, what the kernel perceives when the tray is empty after the running system already saw a medium in it (I'll give my own answers to that question further below.) > I noticed it when DVD disc was loading and until it did, lsblk was happily > reporting that 627656704 bytes CD is still there for every userspace app to > use and send queries to. The problem is actually that the size does not get set to 0 when the medium gets unloaded. (Further bug: Blank media get attributed size 2048.) In preparation of a fix, Karel Zak of util-linux changed lsblk so that it would report devices of SIZE 0. But after getting no feedback on other bug fix patches for Linux, i did not submit my fix for the size problem to the kernel developers. Back in september 2020 it would have consisted of four patches: cdrom: introduce new exported function cdrom_disc_information() sr: introduce resetter functions for sr_cd_check() and get_sectorsize() sr: attribute size 0 to "empty" (aka blank) media sr: attribute size 0 to not loaded or unusable media > And queries are being sent, my guess is from file > manager, to query and display CD name etc. if there is one, because it > thinks everything is fine and its okay to ask. That's my suspicion too. I now am baffled by the result on a Debian 11 with drives not used since booting it: $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* VENDOR MODEL SIZE PHY-SEC LOG-SEC PIONEER PIONEER_BD-RW_BDR-S09 1073741312 512 512 TSSTcorp CDDVDW_SH-S223B 1073741312 512 512 The first one is a built-in SATA drive, the second is SATA in a USB box. All are perceived with wrong block size and a fictional capacity of 1 GiB - 512 bytes. I'd say that this is some clueless default setting that must be new since kernel 4.19 of Debian 10. Back in 2020 i would quite surely have noticed if that behavior had been shown. $ uname -a Linux ... 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux Are users of Debian 10 (actually of kernel 4.19) here who are willing to run lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr* directly after booting with empty drive tray ? Whatever, when i let a DVD+RW wander through the drives and then put it back on the shelf, i afterwards get the usual outdated capacity and the correct block size: VENDOR MODEL SIZE PHY-SEC LOG-SEC PIONEER PIONEER_BD-RW_BDR-S09 470037299220482048 TSSTcorp CDDVDW_SH-S223B 470037299220482048 >From now on the system seems to behave like i am used from older Debian versions. Wrong but reliable. I know of no way to bring the capacity perception to 0. But the size can be reduced to 2048 bytes by inserting a blank CD-R, CD-RW, DVD-R, DVD+R, or unformatted blank DVD-RW or BD-R medium. A totally unused BD-RE or DVD+RW might do the trick too (do not allow a burn program to format them). Here i used a blank BD-R on the Pioneer and a blank DVD-R on the Samsung: VENDOR MODEL SIZE PHY-SEC LOG-SEC PIONEER PIONEER_BD-RW_BDR-S09 204820482048 TSSTcorp CDDVDW_SH-S223B204820482048 This state remains when the medium is removed until the next medium is inserted and fully assessed by the drive. The drive groping software on your machine seems to want to read more than just a single block of 2048 bytes. So reducing the perceived size to 2048 by inserting a blank medium once after booting might already do the trick. (I wonder why the "VENDOR" name gets prepended to the actual "MODEL" name with the Pioneer drive and probably the HP one of piorunz but not to the Samsung drive CDDVDW_SH-S223B. I know that the Pioneer identifies its model name as "BD-RW BDR-S09", not as "PIONEER BD-RW BDR-S09".) Have a nice day :) Thomas
Re: kernel errors
On 24/01/2023 18:58, Thomas Schmitt wrote: Hi, the log messages about "unaligned transfer" would be explained if indeed the block size of the drive would be mistaken as 512 bytes rather than 2048 bytes. So it might be interesting to let lsblk report "sector" sizes as perceived by the kernel: lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 I get from the empty drive (last medium in was a CD-RW): VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 28748390420482048 and with a BD-RE loaded: VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 2475687936020482048 CD inserted: $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 VENDOR MODEL SIZE PHY-SEC LOG-SEC hp hp_DVDRW_GUE1N 62765670420482048 DVD inserted: $ lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 VENDOR MODELSIZE PHY-SEC LOG-SEC hp hp_DVDRW_GUE1N 335334604820482048 I noticed that when there is no disc or disc is loading, this command above is still reporting last used disc even when it's already gone. Meaning, kernel does not know there is no disc. I noticed it when DVD disc was loading and until it did, lsblk was happily reporting that 627656704 bytes CD is still there for every userspace app to use and send queries to. And queries are being sent, my guess is from file manager, to query and display CD name etc. if there is one, because it thinks everything is fine and its okay to ask. -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄
Re: kernel errors
Hi, the log messages about "unaligned transfer" would be explained if indeed the block size of the drive would be mistaken as 512 bytes rather than 2048 bytes. So it might be interesting to let lsblk report "sector" sizes as perceived by the kernel: lsblk -b -o VENDOR,MODEL,SIZE,PHY-SEC,LOG-SEC /dev/sr0 I get from the empty drive (last medium in was a CD-RW): VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 28748390420482048 and with a BD-RE loaded: VENDOR MODEL SIZE PHY-SEC LOG-SEC HL-DT-ST BDDVDRW GGC-H20L 2475687936020482048 Have a nice day :) Thomas
Re: kernel errors
Hi, piorunz wrote: > Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D > > $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 > VENDOR MODELSIZE > hp hp_DVDRW_GUE1N 1073741312 Now that's a strange size: 1 GiB - 512 bytes. The readable data capacity of an optical drive should be divisible by 2048, but the reported size is not. (I remember to have read of very old CD drives with a hardware switch which changes the data block size from 2048 to 512 bytes.) What do you get from the lsblk command when a readable DVD is inserted and later when the medium is out of the drive again ? Have a nice day :) Thomas
Re: kernel errors
On 23/01/2023 15:01, Thomas Schmitt wrote: I wonder what might have caused this. But this line brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 where pior...@gmail.com tried to get this processed as bug of udev. No solution was found. That would be me. Over three years ago, on kernel 4.19. Today, kernel 5.10, Debian 11 Bullseye, and problem still exists :D However, error message has since changed, word udev is not present in the message. Old format: udev: Buffer I/O error on dev sr0, logical block 0, async page read New format: Buffer I/O error on dev sr0, logical block 0, async page read As I've removed optical drive from my desktop computer, this now happens on a laptop computer, which has not seen a CD inserted into the tray for about 6 months. There should be absolutely no errors, just one read attempt - "sorry, no medium". But dmesg is infested with read attempt errors. This particular laptop now, is with KDE, 100% clean and updated Debian stable. For those interested, filtered "sudo dmesg | grep sr0" is attached and model of the drive is below. $ lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 VENDOR MODELSIZE hp hp_DVDRW_GUE1N 1073741312 -- With kindest regards, Piotr. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄ [2.603616] sr 1:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray [2.675633] sr 1:0:0:0: Attached scsi CD-ROM sr0 [ 658.218324] sr 1:0:0:0: [sr0] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 658.218328] sr 1:0:0:0: [sr0] tag#29 Sense Key : Not Ready [current] [ 658.218331] sr 1:0:0:0: [sr0] tag#29 Add. Sense: Medium not present - tray closed [ 658.218333] sr 1:0:0:0: [sr0] tag#29 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 658.218336] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 658.250926] sr 1:0:0:0: [sr0] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 658.250932] sr 1:0:0:0: [sr0] tag#14 Sense Key : Not Ready [current] [ 658.250936] sr 1:0:0:0: [sr0] tag#14 Add. Sense: Medium not present - tray closed [ 658.250939] sr 1:0:0:0: [sr0] tag#14 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 [ 658.250942] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 658.250947] Buffer I/O error on dev sr0, logical block 0, async page read [ 658.250950] Buffer I/O error on dev sr0, logical block 1, async page read [ 658.250952] Buffer I/O error on dev sr0, logical block 2, async page read [ 658.250954] Buffer I/O error on dev sr0, logical block 3, async page read [ 658.250956] Buffer I/O error on dev sr0, logical block 4, async page read [ 658.250958] Buffer I/O error on dev sr0, logical block 5, async page read [ 658.250960] Buffer I/O error on dev sr0, logical block 6, async page read [ 658.250962] Buffer I/O error on dev sr0, logical block 7, async page read [ 667.549410] sr 1:0:0:0: [sr0] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 667.549415] sr 1:0:0:0: [sr0] tag#0 Sense Key : Not Ready [current] [ 667.549419] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Medium not present - tray closed [ 667.549422] sr 1:0:0:0: [sr0] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 667.549425] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 4 prio class 0 [ 667.602070] sr 1:0:0:0: [sr0] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 667.602075] sr 1:0:0:0: [sr0] tag#31 Sense Key : Not Ready [current] [ 667.602078] sr 1:0:0:0: [sr0] tag#31 Add. Sense: Medium not present - tray closed [ 667.602080] sr 1:0:0:0: [sr0] tag#31 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 [ 667.602083] blk_update_request: I/O error, dev sr0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 8 prio class 0 [ 667.602090] Buffer I/O error on dev sr0, logical block 0, async page read [ 667.602094] Buffer I/O error on dev sr0, logical block 1, async page read [ 667.602096] Buffer I/O error on dev sr0, logical block 2, async page read [ 667.602097] Buffer I/O error on dev sr0, logical block 3, async page read [ 667.602099] Buffer I/O error on dev sr0, logical block 4, async page read [ 667.602101] Buffer I/O error on dev sr0, logical block 5, async page read [ 667.602104] Buffer I/O error on dev sr0, logical block 6, async page read [ 667.602106] Buffer I/O error on dev sr0, logical block 7, async page read [ 1874.677595] sr 1:0:0:0: [sr0] tag#31 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s [ 1874.677600] sr 1:0:0:0: [sr0] tag#31 Sense Key : Not Ready [current] [ 1874.677604] sr 1:0:0:0: [sr0] tag#31 Add. Sense: Medium not present - tray closed [ 1874.677607] sr 1:0:0:0: [sr0] tag#31 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 [ 1874.677611] blk_update_request: I/O error, dev
Re: kernel errors
David Wright writes: > On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote: >> It may be a coincidence but yesterday I installed some >> libguestfs-tools. Now I see errors when booting, which also appear in >> /var/log/messages: >> >> kernel: [ 9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s >> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready >> [current] >> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not >> present - tray closed >> kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff >> fc 00 00 02 00 >> kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer >> kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer >> kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer >> kernel: [ 9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s >> kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready >> [current] >> kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not >> present - tray closed >> kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 >> 00 00 00 02 00 >> kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer >> kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer >> >> I removed the toos, and also disabled udiskd or udisk2d: >> >> systemctl stop udisks2.service >> systemctl disable udisks2.service >> >> But the errors are still occuring. How can I stop them? >> >> Installing the tools did some strange things like regenerating the grub >> menu. > > When you've removed the packages, keep a copy of your grub.cfg for > comparison and then reconfigure grub (grub-mkconfig). See if the > messages go away. The messages didn't go away. And I tried to reconfigure swap and resume, and got more errors, so I reinstalled the system, formatting the root partition. > > Did you have something strange in your optical drive when you > installed these tools, in anticipation of using the latter on > the former? No, but I did have a usb stick plugged in, and it had ChromeOS Flex on it. In fact that appeared on the grub menu yesterday and I tried to boot ChromeOS Flex from it. That was no doubt a big mistake.
Re: kernel errors
On Mon 23 Jan 2023 at 13:34:50 (+), Richmond wrote: > It may be a coincidence but yesterday I installed some > libguestfs-tools. Now I see errors when booting, which also appear in > /var/log/messages: > > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer > kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer > kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=0s > kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready > [current] > kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present > - tray closed > kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 > 00 00 00 02 00 > kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer > kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer > > I removed the toos, and also disabled udiskd or udisk2d: > > systemctl stop udisks2.service > systemctl disable udisks2.service > > But the errors are still occuring. How can I stop them? > > Installing the tools did some strange things like regenerating the grub > menu. When you've removed the packages, keep a copy of your grub.cfg for comparison and then reconfigure grub (grub-mkconfig). See if the messages go away. Did you have something strange in your optical drive when you installed these tools, in anticipation of using the latter on the former? Cheers, David.
Re: kernel errors
Sven Joachim writes: > On 2023-01-23 16:13 +, Richmond wrote: > >> I put a dvd in and mounted it. Then rebooted. I saw these messages: >> >> [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 >> [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram >> cd/rw xa/form2 cdda tray >> [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 >> >> Then removed the DVD and rebooted, back to these: >> >> [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram >> cd/rw xa/form2 cdda tray >> [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK >> driverbyte=DRIVER_SENSE cmd_age=2s >> [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] >> [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - >> tray closed >> [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 >> 00 02 00 >> [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer >> >> I am starting to consider re-installing, although everything is working, >> I don't like the look of it. Perhaps I should just re-install the >> kernel? > > This would most likely not help. Instead you should try to figure out > what process is trying to read from your empty drive, and why. > Consulting journalctl might help with that. > > Cheers, >Sven re-installing kernel didn't work. I looked in journalctl and saw this: kernel: PM: Image not found (code -22) It's looking for a resume from hibernate maybe. So then it became apparent that the kernel parameter to resume is a disk by id which looks different from the ones in /etc/fstab. I am not sure how that came about.
Re: kernel errors
Hi, Richmond wrote: > I put a dvd in and mounted it. Then rebooted. I saw these messages: > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram > cd/rw xa/form2 cdda tray > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 Looks normal. > Then removed the DVD and rebooted, back to these: I wonder what happens if you simply put in and out the medium, without rebooting. It looks somewhat as if the kernel perceives a wrong medium status and size and so lures some software like blkid into trying to read the last 4 KiB before the end of the first GiB. What do you get from: lsblk -b -o VENDOR,MODEL,SIZE /dev/sr0 I get: VENDOR MODEL SIZE HL-DT-ST BDDVDRW GGC-H20L 4700372992 (It is a known bug of Linux to report the size of the last loaded medium if the drive tray is empty. But exactly 1 GiB is a strange size for a DVD medium and rebooting should clear this misperception.) > I am starting to consider re-installing, although everything is working, > I don't like the look of it. Perhaps I should just re-install the kernel? If you do, then check whether the messages are not there after base system installation and then try to find out which further package causes those read attempts. Have a nice day :) Thomas
Re: kernel errors
On 2023-01-23 16:13 +, Richmond wrote: > I put a dvd in and mounted it. Then rebooted. I saw these messages: > > [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 > [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram > cd/rw xa/form2 cdda tray > [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 > > Then removed the DVD and rebooted, back to these: > > [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram > cd/rw xa/form2 cdda tray > [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=2s > [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] > [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray > closed > [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 > 02 00 > [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer > > I am starting to consider re-installing, although everything is working, > I don't like the look of it. Perhaps I should just re-install the > kernel? This would most likely not help. Instead you should try to figure out what process is trying to read from your empty drive, and why. Consulting journalctl might help with that. Cheers, Sven
Re: kernel errors
"Thomas Schmitt" writes: > Hi, > > Richmond wrote: >> kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s >> kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready >> [current] >> kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not >> present - tray closed >> kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff >> fc 00 00 02 00 > > Your optical drive gets asked for 2 blocks iand answers that there is no > medium recognized in the tray. The request was to read from block 0x07fffc > = 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB. > This is not a usual medium capcity. So i wonder from where the caller had > that block address. > > >> kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer > > I wonder what might have caused this. But this line brings me to > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 > where pior...@gmail.com tried to get this processed as bug of udev. > No solution was found. > > >> kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: >> hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s >> kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready >> [current] >> kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not >> present - tray closed >> kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 >> 00 00 00 02 00 > > This read attempt wanted to get 2 blocks from block address 0. > More plausible as a wild guess, than 1 GiB - 4 KiB. > > > What happens if you give the drive a readable DVD ? > Maybe the software which issues the READ commands shows up with some more > enlightening complaint. > > > Have a nice day :) > > Thomas I put a dvd in and mounted it. Then rebooted. I saw these messages: [ 756.539018] pktcdvd: pktcdvd0: writer mapped to sr0 [3.744658] sr 3:0:0:0: [sr0] scsi3-mmc drive: 62x/62x writer dvd-ram cd/rw xa/form2 cdda tray [ 19.585098] pktcdvd: pktcdvd0: writer mapped to sr0 Then removed the DVD and rebooted, back to these: [4.006759] sr 3:0:0:0: [sr0] scsi3-mmc drive: 40x/40x writer dvd-ram cd/rw xa/form2 cdda tray [9.434955] sr 3:0:0:0: [sr0] tag#1 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s [9.439990] sr 3:0:0:0: [sr0] tag#1 Sense Key : Not Ready [current] [9.444968] sr 3:0:0:0: [sr0] tag#1 Add. Sense: Medium not present - tray closed [9.449918] sr 3:0:0:0: [sr0] tag#1 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 [9.459897] sr 3:0:0:0: [sr0] tag#18 unaligned transfer I am starting to consider re-installing, although everything is working, I don't like the look of it. Perhaps I should just re-install the kernel?
Re: kernel errors
Hi, Richmond wrote: > kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s > kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready > [current] > kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not > present - tray closed > kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff > fc 00 00 02 00 Your optical drive gets asked for 2 blocks iand answers that there is no medium recognized in the tray. The request was to read from block 0x07fffc = 524284 = 1023.9921875 MiB = 1 GiB - 4 KiB. This is not a usual medium capcity. So i wonder from where the caller had that block address. > kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer I wonder what might have caused this. But this line brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948358 where pior...@gmail.com tried to get this processed as bug of udev. No solution was found. > kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK > driverbyte=DRIVER_SENSE cmd_age=0s > kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current] > kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present > - tray closed > kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 > 00 00 00 02 00 This read attempt wanted to get 2 blocks from block address 0. More plausible as a wild guess, than 1 GiB - 4 KiB. What happens if you give the drive a readable DVD ? Maybe the software which issues the READ commands shows up with some more enlightening complaint. Have a nice day :) Thomas
kernel errors
It may be a coincidence but yesterday I installed some libguestfs-tools. Now I see errors when booting, which also appear in /var/log/messages: kernel: [9.506798] sr 3:0:0:0: [sr0] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=2s kernel: [9.507009] sr 3:0:0:0: [sr0] tag#12 Sense Key : Not Ready [current] kernel: [9.507146] sr 3:0:0:0: [sr0] tag#12 Add. Sense: Medium not present - tray closed kernel: [9.507304] sr 3:0:0:0: [sr0] tag#12 CDB: Read(10) 28 00 00 07 ff fc 00 00 02 00 kernel: [9.507731] sr 3:0:0:0: [sr0] tag#31 unaligned transfer kernel: [9.513520] sr 3:0:0:0: [sr0] tag#13 unaligned transfer kernel: [9.529995] sr 3:0:0:0: [sr0] tag#14 unaligned transfer kernel: [9.602797] sr 3:0:0:0: [sr0] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s kernel: [9.608514] sr 3:0:0:0: [sr0] tag#3 Sense Key : Not Ready [current] kernel: [9.614297] sr 3:0:0:0: [sr0] tag#3 Add. Sense: Medium not present - tray closed kernel: [9.620170] sr 3:0:0:0: [sr0] tag#3 CDB: Read(10) 28 00 00 00 00 00 00 00 02 00 kernel: [9.631993] sr 3:0:0:0: [sr0] tag#4 unaligned transfer kernel: [9.650464] sr 3:0:0:0: [sr0] tag#5 unaligned transfer I removed the toos, and also disabled udiskd or udisk2d: systemctl stop udisks2.service systemctl disable udisks2.service But the errors are still occuring. How can I stop them? Installing the tools did some strange things like regenerating the grub menu.
kernel errors only showing on reboot - nouveau & tpm_crb
Every time that I reboot this shows up in my daily logwatch - --8<---cut here---start->8--- WARNING: Kernel Errors Present intel-lpss: probe of :00:1e.0 failed with error -22 ...: 2 Time(s) nouveau: probe of :01:00.0 failed with error -12 ...: 2 Time(s) tpm_crb: probe of MSFT0101:00 failed with error -16 ...: 2 Time(s) --8<---cut here---end--->8--- According to dmidecode my CPU is -'Version: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz' so I would guess that I do need 'intel-lpss' but not need anything 'nouveau*'? Is that correct please? But what about 'tpm_crb'? I've done 'lsmod | grep tpm' and 'dmesg | grep -w tpm' and 'dmesg | grep -i tpm' but nothing is showing up, so I'm guessing that I don't need 'tpm_crb' either, am I correct? I've been using [fn:1] as a guide for me to investigate TPM. I'm sorry if it seems like I'm asking very basic questions, but I just want to be sure that I'm not going to ask my machine to commit suicide by me actually removing them! Thanks Sharon. [Fn:1] https://unix.stackexchange.com/questions/341629/how-to-determine-if-computer-has-tpm-trusted-platform-module-available -- A taste of linux = http://www.sharons.org.uk TGmeds = http://www.tgmeds.org.uk DrugFacts = https://www.drugfacts.org.uk Debian 9.0, fluxbox 1.3.5-2, emacs 25.1.1, org-mode 9.0.9 signature.asc Description: PGP signature
kernel errors present - how to resolve them please?
Every day the following appears in my logwatch email --8---cut here---start-8--- WARNING: Kernel Errors Present EXT4-fs (sde1): error count: 1 ...: 1 Time(s) EXT4-fs (sde1): initial error at 1397381477: _ ...: 1 Time(s) EXT4-fs (sde1): last error at 1397381477: _ ...: 1 Time(s) --8---cut here---end---8--- sde1 is an external usb drive formatted ext4 which is rather important as it is my backup drive. How should I resolve this situation please? Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.3.92.1 signature.asc Description: PGP signature
Re: kernel errors present - how to resolve them please?
On 2014-07-25, Sharon Kimble boudic...@skimble.plus.com wrote: Every day the following appears in my logwatch email =2D-8---cut here---start-8--- WARNING: Kernel Errors Present EXT4-fs (sde1): error count: 1 ...: 1 Time(s) EXT4-fs (sde1): initial error at 1397381477: _ ...: 1 Time(s) EXT4-fs (sde1): last error at 1397381477: _ ...: 1 Time(s)=20 =2D-8---cut here---end---8--- sde1 is an external usb drive formatted ext4 which is rather important as it is my backup drive. How should I resolve this situation please? Purely informational, apparently: http://serverfault.com/questions/475273/kernel-errors-present-ext4-fs https://lkml.org/lkml/2010/9/26/105 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnlt4inr.2cv.cu...@einstein.electron.org
Re: kernel errors present - how to resolve them please?
Curt cu...@free.fr writes: On 2014-07-25, Sharon Kimble boudic...@skimble.plus.com wrote: Every day the following appears in my logwatch email =2D-8---cut here---start-8--- WARNING: Kernel Errors Present EXT4-fs (sde1): error count: 1 ...: 1 Time(s) EXT4-fs (sde1): initial error at 1397381477: _ ...: 1 Time(s) EXT4-fs (sde1): last error at 1397381477: _ ...: 1 Time(s)=20 =2D-8---cut here---end---8--- sde1 is an external usb drive formatted ext4 which is rather important as it is my backup drive. How should I resolve this situation please? Purely informational, apparently: http://serverfault.com/questions/475273/kernel-errors-present-ext4-fs https://lkml.org/lkml/2010/9/26/105 Thanks for this Curt, its put my mind at rest :) Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.3.92.1 signature.asc Description: PGP signature
kernel errors
Bonjour, In logwatch report, I have some kenel errors: 1-ACPI: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT3._GTF] (Node 88040e097ec0), AE_NOT_FOUND (20110623/psparse-536 ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20110623/psargs-359) 2- Ext4: EXT4EXT4-fs (dm-0): re-mounted. Opts: discard,errors=remount-ro 3- uvesafb: uvesafb: probe of uvesafb.0 failed with error -22 uvesafb: probe of uvesafb.0 failed with error -5 How to correct this? Thanks. -- François Patte UFR de mathématiques et informatique Laboratoire CNRS MAP5, UMR 8145 Université Paris Descartes 45, rue des Saints Pères F-75270 Paris Cedex 06 Tél. +33 (0)1 8394 5849 http://www.math-info.univ-paris5.fr/~patte signature.asc Description: OpenPGP digital signature
Re: kernel errors
Hello, On 20/08/13 11:39, François Patte wrote: Bonjour, In logwatch report, I have some kenel errors: 1-ACPI: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT3._GTF] (Node 88040e097ec0), AE_NOT_FOUND (20110623/psparse-536 ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20110623/psargs-359) 2- Ext4: EXT4EXT4-fs (dm-0): re-mounted. Opts: discard,errors=remount-ro 3- uvesafb: uvesafb: probe of uvesafb.0 failed with error -22 uvesafb: probe of uvesafb.0 failed with error -5 How to correct this? for [2], you may change some mount option in your /etc/fstab : I am suspected [2] concert `/' mount: is ext4 a good choice for `/' ? hth, Jerome Thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/521342f6.2020...@rezozer.net
Re: kernel errors
On Tue, Aug 20, 2013 at 11:39:52AM +0200, François Patte wrote: Bonjour, In logwatch report, I have some kenel errors: 1-ACPI: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SAT0.SPT3._GTF] (Node 88040e097ec0), AE_NOT_FOUND (20110623/psparse-536 ACPI Error: [DSSP] Namespace lookup failure, AE_NOT_FOUND (20110623/psargs-359) I believe this indicates a missing procedure if your ACPI. If you're experiencing problems (the \_SB_.PCI0.SAT0.SPT3._GTF would suggest that it's to do with one of your SATA ports), then you should A) upgrade your BIOS, B) search the internet for Custom DSDT (this is definitely a sledgehammer approach, though). If you're not experiencing any problems, then don't worry about it. 2- Ext4: EXT4EXT4-fs (dm-0): re-mounted. Opts: discard,errors=remount-ro Not actually an error. Well, it's an error with logwatch, really. You'll probably find that /dev/dm-0 is your root filesystem, which is being remounted as the boot sequence comes out of the initramfs. The errors=remount-ro is a flag to say If an error occurs with this filesytem remount it read-only, other options there are continue or panic. 3- uvesafb: uvesafb: probe of uvesafb.0 failed with error -22 uvesafb: probe of uvesafb.0 failed with error -5 Not sure about that one. Are you getting high-resolution text during boot? Perhaps try letting grub set the resolution and use GRUB_GFXPAYLOAD_LINUX=keep...? signature.asc Description: Digital signature
Re: Help needed fixing kernel errors
On Tue, 26 Apr 2011 14:37:24 +1000, Steven wrote in message 1303792644.6192.14.camel@square: Hi folks, I have a problem that's now beyond my expertise to fault properly. I get random intermittent kernel errors. Usually when the system is under stress. System specs; AMD X4 840 (Badged phenomii but it's really an athlon core) ASUS M4A88TD-M EVO/USB3 2x 2GB sticks of Corsair 1600 DDR3 500TB WD Caviar Blue. Below are some example of the errors. square kernel: [ 683.271626] Pid: 6593, comm: rsync Tainted: P D 2.6.32-5-amd64 #1 Apr 24 14:51:38 square kernel: [ 683.271631] Call Trace: Apr 24 14:51:38 square kernel: [ 683.271648] [810cad37] ? print_bad_pte+0x232/0x24a Apr 24 14:51:38 square kernel: [ 683.271660] [810cbde7] ? unmap_vmas+0x62d/0x931 Apr 24 14:51:38 square kernel: [ 683.271672] [8118e194] ? cpumask_any_but+0x28/0x34 Apr 24 14:51:38 square kernel: [ 683.271682] [810d04c4] ? exit_mmap+0xc4/0x148 Apr 24 14:51:38 square kernel: [ 683.271690] [8104bc6d] ? mmput+0x3c/0xdf Apr 24 14:51:38 square kernel: [ 683.271698] [8104f866] ? exit_mm+0x102/0x10d Apr 24 14:51:38 square kernel: [ 683.271705] [8105128b] ? do_exit+0x1f8/0x6c6 Apr 24 14:51:38 square kernel: [ 683.271712] [810517cf] ? do_group_exit+0x76/0x9d Apr 24 14:51:38 square kernel: [ 683.271720] [81051808] ? sys_exit_group+0x12/0x16 Apr 24 14:51:38 square kernel: [ 683.271727] [81010b42] ? system_call_fastpath+0x16/0x1b Apr 24 14:51:44 square kerneloops: Submitted 1 kernel oopses to www.kerneloops.org Another from minecraft; d: 6742, comm: java Tainted: PB D2.6.32-5-amd64 #1 Apr 24 15:12:02 square kernel: [ 1907.726033] Call Trace: Apr 24 15:12:02 square kernel: [ 1907.726039] [810b7a11] ? bad_page+0x116/0x129 Apr 24 15:12:02 square kernel: [ 1907.726042] [810b9b2e] ? get_page_from_freelist+0x4fd/0x760 Apr 24 15:12:02 square kernel: [ 1907.726098] [a0246f02] ? firegl_trace+0x72/0x1e0 [fglrx] Apr 24 15:12:02 square kernel: [ 1907.726100] [810ba0f8] ? __alloc_pages_nodemask+0x11c/0x5f4 Apr 24 15:12:02 square kernel: [ 1907.726104] [81036605] ? native_flush_tlb_others+0xb6/0xe3 Apr 24 15:12:02 square kernel: [ 1907.726107] [810bc479] ? pagevec_lru_add+0x160/0x176 Apr 24 15:12:02 square kernel: [ 1907.726110] [810cc981] ? handle_mm_fault+0x27a/0x80f Apr 24 15:12:02 square kernel: [ 1907.726113] [812fe6b6] ? do_page_fault+0x2e0/0x2fc Apr 24 15:12:02 square kernel: [ 1907.726116] [812fc555] ? page_fault+0x25/0x30 Another one from stress. stressD 0 5972 5963 0x Apr 25 21:16:11 square kernel: [ 360.740389] 88011b04dbd0 0082 880114f40150 000e Apr 25 21:16:11 square kernel: [ 360.740392] 0007 f9e0 880100329fd8 Apr 25 21:16:11 square kernel: [ 360.740395] 00015780 00015780 88011b04f100 88011b04f3f8 Apr 25 21:16:11 square kernel: [ 360.740397] Call Trace: Apr 25 21:16:11 square kernel: [ 360.740404] [8104001f] ? check_preempt_wakeup+0x1dd/0x268 Apr 25 21:16:11 square kernel: [ 360.740408] [812fb65b] ? __mutex_lock_common+0x122/0x192 Apr 25 21:16:11 square kernel: [ 360.740411] [810493e0] ? update_rq_clock+0xf/0x28 Apr 25 21:16:11 square kernel: [ 360.740413] [812fb783] ? mutex_lock+0x1a/0x31 Apr 25 21:16:11 square kernel: [ 360.740416] [8110be35] ? sync_filesystems+0x13/0xe3 Apr 25 21:16:11 square kernel: [ 360.740418] [8110bf4a] ? sys_sync+0x1c/0x2e Apr 25 21:16:11 square kernel: [ 360.740420] [81010b42] ? system_call_fastpath+0x16/0x1b Apr 25 21:18:11 square kernel: [ 480.740375] stressD 8800cf609c40 0 5965 5963 0x Apr 25 21:18:11 square kernel: [ 480.740378] 8800cf609c40 0086 810414d5 0001000e Apr 25 21:18:11 square kernel: [ 480.740381] 00015780 880100383e68 f9e0 880100383fd8 Apr 25 21:18:11 square kernel: [ 480.740383] 00015780 00015780 8800cf60f100 8800cf60f3f8 Apr 25 21:18:11 square kernel: [ 480.740385] Call Trace: Apr 25 21:18:11 square kernel: [ 480.740392] [810414d5] ? select_task_rq_fair+0x472/0x836 Apr 25 21:18:11 square kernel: [ 480.740395] [8101650e] ? native_sched_clock+0x2e/0x66 Apr 25 21:18:11 square kernel: [ 480.740397] [8103fc8e] ? update_curr+0xa6/0x147 Apr 25 21:18:11 square kernel: [ 480.740399] [8101654b] ? sched_clock+0x5/0x8 Apr 25 21:18:11 square kernel: [ 480.740402] [812fb65b] ? __mutex_lock_common+0x122/0x192 Apr 25 21:18:11 square kernel: [ 480.740404] [812fb783] ? mutex_lock+0x1a/0x31 Apr 25 21:18:11 square kernel: [ 480.740407
Re: Help needed fixing kernel errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 26 Apr 2011 14:14:46 +0200 Arnt Karlsen a...@c2i.net wrote: On Tue, 26 Apr 2011 14:37:24 +1000, Steven wrote in message 1303792644.6192.14.camel@square: Hi folks, I have a problem that's now beyond my expertise to fault properly. I get random intermittent kernel errors. Usually when the system is under stress. System specs; AMD X4 840 (Badged phenomii but it's really an athlon core) ASUS M4A88TD-M EVO/USB3 2x 2GB sticks of Corsair 1600 DDR3 500TB WD Caviar Blue. Below are some example of the errors. square kernel: [ 683.271626] Pid: 6593, comm: rsync Tainted: P D 2.6.32-5-amd64 #1 /big snip/ Same problem here on a desktop - Intel MB 865. But it has only happened once...just a few hours after the kernel update. It required a hard reset...after similar errors were sprayed all over my screen. Hasn't happened since, which is really weird. - -- - -- Frank -- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJNttaeAAoJEMEDyLTvrVhjD0AH/jxwNROAbvKFX/K6RjBP5Kvj gLEEW6u5yHSo/fPespVxLELrLa6Hl6U5rupveXwe6Za2rA28nE51A8dv5aNWJyuN 9vxty7ak7OynbSPVa6qOS7nQ1cwiIwYXyZuc5uygcfomhnv6Jva5Nxy9z9zgHHwq FkQsgJw0zfNW4bxNmfVZtmQuAIQapbDaih70eot27WuUu3GIubZd670gfn0pyN0w JhEQ8dNKtKynhyeOMnCKBTJYlulygzTNcT2a7e52ojFNykaOzNkMtKk0W96tgnPE FFNtYlTkE32cF94IDTPhBOUJn0EmPBUpIrymdVUeMwO2BjBUFne/EwbUxrA82E4= =zJBd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426102846.4561b7fc.debianl...@videotron.ca
Re: Help needed fixing kernel errors
On Tue, 26 Apr 2011 14:14:46 +0200 Arnt Karlsen a...@c2i.net wrote: On Tue, 26 Apr 2011 14:37:24 +1000, Steven wrote in message 1303792644.6192.14.camel@square: Hi folks, I have a problem that's now beyond my expertise to fault properly. I get random intermittent kernel errors. Usually when the system is under stress. System specs; AMD X4 840 (Badged phenomii but it's really an athlon core) ASUS M4A88TD-M EVO/USB3 2x 2GB sticks of Corsair 1600 DDR3 500TB WD Caviar Blue. Below are some example of the errors. square kernel: [ 683.271626] Pid: 6593, comm: rsync Tainted: P D 2.6.32-5-amd64 #1 /big snip/ Same problem here on a desktop - Intel MB 865. But it has only happened once...just a few hours after the kernel update. It required a hard reset...after similar errors were sprayed all over my screen. Hasn't happened since, which is really weird. -- -- Frank -- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426095108.bb79c6c9.debianl...@videotron.ca
Help needed fixing kernel errors
Hi folks, I have a problem that's now beyond my expertise to fault properly. I get random intermittent kernel errors. Usually when the system is under stress. System specs; AMD X4 840 (Badged phenomii but it's really an athlon core) ASUS M4A88TD-M EVO/USB3 2x 2GB sticks of Corsair 1600 DDR3 500TB WD Caviar Blue. Below are some example of the errors. square kernel: [ 683.271626] Pid: 6593, comm: rsync Tainted: P D 2.6.32-5-amd64 #1 Apr 24 14:51:38 square kernel: [ 683.271631] Call Trace: Apr 24 14:51:38 square kernel: [ 683.271648] [810cad37] ? print_bad_pte+0x232/0x24a Apr 24 14:51:38 square kernel: [ 683.271660] [810cbde7] ? unmap_vmas+0x62d/0x931 Apr 24 14:51:38 square kernel: [ 683.271672] [8118e194] ? cpumask_any_but+0x28/0x34 Apr 24 14:51:38 square kernel: [ 683.271682] [810d04c4] ? exit_mmap+0xc4/0x148 Apr 24 14:51:38 square kernel: [ 683.271690] [8104bc6d] ? mmput+0x3c/0xdf Apr 24 14:51:38 square kernel: [ 683.271698] [8104f866] ? exit_mm+0x102/0x10d Apr 24 14:51:38 square kernel: [ 683.271705] [8105128b] ? do_exit+0x1f8/0x6c6 Apr 24 14:51:38 square kernel: [ 683.271712] [810517cf] ? do_group_exit+0x76/0x9d Apr 24 14:51:38 square kernel: [ 683.271720] [81051808] ? sys_exit_group+0x12/0x16 Apr 24 14:51:38 square kernel: [ 683.271727] [81010b42] ? system_call_fastpath+0x16/0x1b Apr 24 14:51:44 square kerneloops: Submitted 1 kernel oopses to www.kerneloops.org Another from minecraft; d: 6742, comm: java Tainted: PB D2.6.32-5-amd64 #1 Apr 24 15:12:02 square kernel: [ 1907.726033] Call Trace: Apr 24 15:12:02 square kernel: [ 1907.726039] [810b7a11] ? bad_page+0x116/0x129 Apr 24 15:12:02 square kernel: [ 1907.726042] [810b9b2e] ? get_page_from_freelist+0x4fd/0x760 Apr 24 15:12:02 square kernel: [ 1907.726098] [a0246f02] ? firegl_trace+0x72/0x1e0 [fglrx] Apr 24 15:12:02 square kernel: [ 1907.726100] [810ba0f8] ? __alloc_pages_nodemask+0x11c/0x5f4 Apr 24 15:12:02 square kernel: [ 1907.726104] [81036605] ? native_flush_tlb_others+0xb6/0xe3 Apr 24 15:12:02 square kernel: [ 1907.726107] [810bc479] ? pagevec_lru_add+0x160/0x176 Apr 24 15:12:02 square kernel: [ 1907.726110] [810cc981] ? handle_mm_fault+0x27a/0x80f Apr 24 15:12:02 square kernel: [ 1907.726113] [812fe6b6] ? do_page_fault+0x2e0/0x2fc Apr 24 15:12:02 square kernel: [ 1907.726116] [812fc555] ? page_fault+0x25/0x30 Another one from stress. stressD 0 5972 5963 0x Apr 25 21:16:11 square kernel: [ 360.740389] 88011b04dbd0 0082 880114f40150 000e Apr 25 21:16:11 square kernel: [ 360.740392] 0007 f9e0 880100329fd8 Apr 25 21:16:11 square kernel: [ 360.740395] 00015780 00015780 88011b04f100 88011b04f3f8 Apr 25 21:16:11 square kernel: [ 360.740397] Call Trace: Apr 25 21:16:11 square kernel: [ 360.740404] [8104001f] ? check_preempt_wakeup+0x1dd/0x268 Apr 25 21:16:11 square kernel: [ 360.740408] [812fb65b] ? __mutex_lock_common+0x122/0x192 Apr 25 21:16:11 square kernel: [ 360.740411] [810493e0] ? update_rq_clock+0xf/0x28 Apr 25 21:16:11 square kernel: [ 360.740413] [812fb783] ? mutex_lock+0x1a/0x31 Apr 25 21:16:11 square kernel: [ 360.740416] [8110be35] ? sync_filesystems+0x13/0xe3 Apr 25 21:16:11 square kernel: [ 360.740418] [8110bf4a] ? sys_sync+0x1c/0x2e Apr 25 21:16:11 square kernel: [ 360.740420] [81010b42] ? system_call_fastpath+0x16/0x1b Apr 25 21:18:11 square kernel: [ 480.740375] stressD 8800cf609c40 0 5965 5963 0x Apr 25 21:18:11 square kernel: [ 480.740378] 8800cf609c40 0086 810414d5 0001000e Apr 25 21:18:11 square kernel: [ 480.740381] 00015780 880100383e68 f9e0 880100383fd8 Apr 25 21:18:11 square kernel: [ 480.740383] 00015780 00015780 8800cf60f100 8800cf60f3f8 Apr 25 21:18:11 square kernel: [ 480.740385] Call Trace: Apr 25 21:18:11 square kernel: [ 480.740392] [810414d5] ? select_task_rq_fair+0x472/0x836 Apr 25 21:18:11 square kernel: [ 480.740395] [8101650e] ? native_sched_clock+0x2e/0x66 Apr 25 21:18:11 square kernel: [ 480.740397] [8103fc8e] ? update_curr+0xa6/0x147 Apr 25 21:18:11 square kernel: [ 480.740399] [8101654b] ? sched_clock+0x5/0x8 Apr 25 21:18:11 square kernel: [ 480.740402] [812fb65b] ? __mutex_lock_common+0x122/0x192 Apr 25 21:18:11 square kernel: [ 480.740404] [812fb783] ? mutex_lock+0x1a/0x31 Apr 25 21:18:11 square kernel: [ 480.740407] [8110be35] ? sync_filesystems+0x13/0xe3 Apr 25 21:18:11 square kernel: [ 480.740409] [8110bf40] ? sys_sync+0x12/0x2e Apr 25 21:18:11 square kernel: [ 480.740411] [81010b42
tape drive writing and kernel errors
Hi, I'm running debian Etch on a no name server with a Quantum DLT-v4 SATA drive. All my backups on tape are failing with kernel errors (see below). The tape is fresh, so it isn't a bad medium I guess. After googling I tried appending irqpoll acpi=noirq, but that didn't make any difference. Any suggestions? --- Apr 1 10:39:42 debian kernel: ata2.00: qc timeout (cmd 0xa0) Apr 1 10:39:42 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 1 10:39:42 debian kernel: ata2.00: (BMDMA stat 0x20) Apr 1 10:39:42 debian kernel: ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) Apr 1 10:39:49 debian kernel: ata2: port is slow to respond, please be patient Apr 1 10:40:12 debian kernel: ata2: port failed to respond (30 secs) Apr 1 10:40:12 debian kernel: ata2: soft resetting port Apr 1 10:40:13 debian kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 1 10:40:13 debian kernel: ata2.00: configured for UDMA/133 Apr 1 10:40:13 debian kernel: ata2: EH complete Apr 1 10:40:13 debian kernel: st0: Current [descriptor]: sense key: Medium Error Apr 1 10:40:13 debian kernel: Additional sense: Address mark not found for data field Apr 1 10:40:13 debian kernel: Descriptor sense data with sense descriptors (in hex): Apr 1 10:40:13 debian kernel: 72 03 13 00 00 00 00 0e 09 0e 00 51 00 03 00 00 Apr 1 10:40:13 debian kernel: 00 00 00 00 a0 51 Apr 1 10:40:25 debian kernel: st0: Current: sense key: Unit Attention Apr 1 10:40:25 debian kernel: Additional sense: Scsi bus reset occurred Apr 1 10:41:08 debian kernel: ata2.00: qc timeout (cmd 0xa0) Apr 1 10:41:08 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 1 10:41:08 debian kernel: ata2.00: (BMDMA stat 0x20) Apr 1 10:41:08 debian kernel: ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) Apr 1 10:41:15 debian kernel: ata2: port is slow to respond, please be patient Apr 1 10:41:39 debian kernel: ata2: port failed to respond (30 secs) Apr 1 10:41:39 debian kernel: ata2: soft resetting port Apr 1 10:41:39 debian kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 1 10:41:39 debian kernel: ata2.00: configured for UDMA/133 Apr 1 10:41:39 debian kernel: ata2: EH complete Apr 1 10:41:39 debian kernel: st0: Current [descriptor]: sense key: Medium Error Apr 1 10:41:39 debian kernel: Additional sense: Address mark not found for data field Apr 1 10:41:39 debian kernel: Descriptor sense data with sense descriptors (in hex): Apr 1 10:41:39 debian kernel: 72 03 13 00 00 00 00 0e 09 0e 00 51 00 03 00 00 Apr 1 10:41:39 debian kernel: 00 00 00 00 a0 51 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tape drive writing and kernel errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/07 04:43, Sebastiaan Veldhuisen wrote: Hi, I'm running debian Etch on a no name server with a Quantum DLT-v4 SATA drive. All my backups on tape are failing with kernel errors (see below). The tape is fresh, so it isn't a bad medium I guess. After googling I tried appending irqpoll acpi=noirq, but that didn't make any difference. Any suggestions? --- Apr 1 10:39:42 debian kernel: ata2.00: qc timeout (cmd 0xa0) Apr 1 10:39:42 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 1 10:39:42 debian kernel: ata2.00: (BMDMA stat 0x20) Apr 1 10:39:42 debian kernel: ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) Apr 1 10:39:49 debian kernel: ata2: port is slow to respond, please be patient Apr 1 10:40:12 debian kernel: ata2: port failed to respond (30 secs) Apr 1 10:40:12 debian kernel: ata2: soft resetting port Apr 1 10:40:13 debian kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 1 10:40:13 debian kernel: ata2.00: configured for UDMA/133 Apr 1 10:40:13 debian kernel: ata2: EH complete Apr 1 10:40:13 debian kernel: st0: Current [descriptor]: sense key: Medium Error Apr 1 10:40:13 debian kernel: Additional sense: Address mark not found for data field Apr 1 10:40:13 debian kernel: Descriptor sense data with sense descriptors (in hex): Apr 1 10:40:13 debian kernel: 72 03 13 00 00 00 00 0e 09 0e 00 51 00 03 00 00 Apr 1 10:40:13 debian kernel: 00 00 00 00 a0 51 Apr 1 10:40:25 debian kernel: st0: Current: sense key: Unit Attention Apr 1 10:40:25 debian kernel: Additional sense: Scsi bus reset occurred Apr 1 10:41:08 debian kernel: ata2.00: qc timeout (cmd 0xa0) Apr 1 10:41:08 debian kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Apr 1 10:41:08 debian kernel: ata2.00: (BMDMA stat 0x20) Apr 1 10:41:08 debian kernel: ata2.00: tag 0 cmd 0xa0 Emask 0x5 stat 0x51 err 0x51 (timeout) Apr 1 10:41:15 debian kernel: ata2: port is slow to respond, please be patient Apr 1 10:41:39 debian kernel: ata2: port failed to respond (30 secs) Apr 1 10:41:39 debian kernel: ata2: soft resetting port Apr 1 10:41:39 debian kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) Apr 1 10:41:39 debian kernel: ata2.00: configured for UDMA/133 Apr 1 10:41:39 debian kernel: ata2: EH complete Apr 1 10:41:39 debian kernel: st0: Current [descriptor]: sense key: Medium Error Apr 1 10:41:39 debian kernel: Additional sense: Address mark not found for data field Apr 1 10:41:39 debian kernel: Descriptor sense data with sense descriptors (in hex): Apr 1 10:41:39 debian kernel: 72 03 13 00 00 00 00 0e 09 0e 00 51 00 03 00 00 Apr 1 10:41:39 debian kernel: 00 00 00 00 a0 51 Maybe the SATA controller isn't compatible with the tape drive? Or vice versa... Maybe you need a SCSI version of the tape drive? (Being a long-time user of DLT drives, SATA DLT IV kinda gives me the willies.) - -- Ron Johnson, Jr. Jefferson LA USA Give a man a fish, and he eats for a day. Hit him with a fish, and he goes away for good! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGEQI4S9HxQb37XmcRAh+bAKCzdt8USMXWUEbFFeZwgf2CfkF2kACgjXqp gMQlK7ENCqD55OiFdaq1OTo= =hFXf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
tape writing and kernel errors
Hi,I am running debian 3.1 on dell power edge 2650 with power vault 114T and i am running bacula backup for my tape backup.My backup is not working because of the following errorkernel: st0: Error with sense data: Current st09:00: sense key Unit Attention kernel: Additional sense indicates Not ready to ready change,medium may have changed kernel: st0: Error with sense data: Current st09:00: sense key Not Ready kernel: Additional sense indicates Logical unit is in process of becoming ready kernel: st0: Error with sense data: Current st09:00: sense key Not Ready kernel varsion 2.4.27-2-686-smp #1 SMP and bacula is giving the following error30-Mar 15:38 backup-sd: NightlySave1.2006-03-30_15.21.00 Error: block.c:552 Write error at 5:6714 on device /dev/nst0. ERR=Input/output error.30-Mar 15:38 backup-sd: NightlySave1.2006-03-30_15.21.00 Error: Error writing final EOF to tape. This tape may not be readable.dev.c:1213 ioctl MTWEOF error on /dev/nst0. ERR=Input/output error.can some one help me why my backup is not completting and the solution for this problemthank you Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with voicemail
Re: printing a certain .ps causes usb kernel errors
On Fri, Oct 28, 2005 at 12:18:40PM -0400, David Morse wrote: All this is news to me, and interesting. How can one, in general, tell good and bad postscript apart? The one doesn't crash the target printer, the other does. That's not a joke, that's just the way it is today. It used to be that if you were Postscript, you were Adobe Postscript, and you knew how the interpreter worked and code that didn't crash one printer, didn't crash another, and if you DID crash the printer, you got reasonable feedback back from it telling you so. Nowadays, with many printers doing Postscript emulation rather than true Adobe, you're subject to the whims of whoever wrote the firmware for the printer. Just as a data point... my HP LaserJet 1320, with Postscript Level 2 *emulation*, prints this two page document with no errors. Gv doesn't like it much, though. In general, *avoid Xprint*. Not that Xprint is specifically at fault here, it's just generally evil and should be buried in an unmarked grave in ground sown with salt by the light of a new moon. I would be interested to see what the Postscript generated natively by Firefox looked like, though. Now... what happened when you ran the .ps file through ps2ps? Can your printer now interpret the document properly? I did it here and note that gv can actually view it properly, and it prints with no differences. -- Marc Wilson | Sorry. I just realized this sentance makes no sense [EMAIL PROTECTED] | :) -- Ian Main -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
printing a certain .ps causes usb kernel errors
Perhaps I should send this to some other mailing list (suggestions?), but my user has been generating a series of .ps files through firefox that, when printed, cause the printer to stop printing. Its red LED starts flashing, and when I go to examine /var/log/kern.log I see many entries of the form: Oct 27 22:16:30 abu kernel: usb_control/bulk_msg: timeout Oct 27 22:16:30 abu kernel: printer.c: usblp0: error -110 reading printer statusO The evil .ps file can be downloaded from http://www.osaurus.us/~dm/tmp/mozilla.ps and the kernel config on the server machine is here: http://www.osaurus.us/~dm/tmp/config-2.4.28 (I'm no longer sure if this is a debian stock kernel).
Re: printing a certain .ps causes usb kernel errors
On Thu, Oct 27, 2005 at 10:30:29PM -0400, David Morse wrote: description of how to crash a Postscript printer deleted I don't see why you think this is a problem with the kernel. You generated bad Postscript, you sent bad Postscript to an unsuspecting printer, that printer crashed. It stopped communicating with the rest of the world, and the kernel is trying to tell you that. A really high-end printer will have a watchdog that restarts the event loop if you manage to crash it. Others... don't. Now. Mozilla/Firefox are renowned for the lousy Postscript they produce. Usually the printer survives... in your case, not so much. You can either stop generating the Postscript with Firefox, or you can massage the Postscript before you send it to the printer. Try taking the .ps file and running it through ps2ps. I imagine it won't crash the printer any more. -- Marc Wilson | Beware of low-flying butterflies. [EMAIL PROTECTED] | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
DRM kernel errors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is starting to get really annoying. Whenever a window pops up in front of flightgear, my machine freezes and I get this little tidbit in my logs: Jul 27 19:43:43 ursine kernel: [drm:radeon_lock_take] *ERROR* 4 holds heavyweight lock I'm running PenguinPPC's version of XF86, on a Radeon 7000/VE. The only information I could find at google about this was for FreeBSD. 8:oP Anybody else having this problem here? Anybody have any luck fixing it? - -- .''`. Paul Johnson [EMAIL PROTECTED] : :' :proud Debian admin and user `. `'` `- Debian - when you have better things to do than fix a system -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/JJJhJ5vLSqVpK2kRAgToAJ4oyWSJb0ESwqTGz11N8qahZKHmtgCZAaq1 fpobN0c+Vc/Ip45+lwcnLpk= =FVpu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel errors
On Tue, Mar 04, 2003 at 09:41:52PM -0500, Joel Konkle-Parker wrote: I just compiled a fresh 2.2.20 kernel and rebooted into it for the first time. During the boot, the kernel went into an endless cycle of the same error message, something to the effect of cannot modprobe switch switch switch binfmt###c; error=8. That's from memory, so I forget what the switches are, and 'modprobe' could have been cannot insert module. I also can't remember the exact name, I just know it started with binfmtnumberc. The error code is correct. Did I set a configuration setting wrong? Possibly, I've never seen that error before. It looks like a misconfiguration, though. Upon seeing 'binfmt' in the error, I remember I set up the kernel to use MISC binaries, and unset ELF and JAVA binaries. But the help said I could do that... Just because the help said you could doesn't mean you should. ELF is what your kernel and modules are probably compiled as; ELF support should be compiled in, while a.out and misc could just be modules. -- Seneca [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: Kernel errors
Joel Konkle-Parker wrote: I just compiled a fresh 2.2.20 kernel and rebooted into it for the first time. During the boot, the kernel went into an endless cycle of the same error message, something to the effect of cannot modprobe switch switch switch binfmt###c; error=8. That's from memory, so I forget what the switches are, and 'modprobe' could have been cannot insert module. I also can't remember the exact name, I just know it started with binfmtnumberc. The error code is correct. Did I set a configuration setting wrong? Did you remember to do make modules and make modules_install ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OT: AMD chips cause kernel errors and hangs?
We have a Linux cluster of 1000 nodes. I wasn't involved in setting it up. They use RedHat 6.2 kernel 2.2.19. Dual AMD 1.2GHz, 2GB memory, 2GB swap, GB ethernet. Several nodes hang and/or get kernel errors every day. The first causes that come to mind are bad RAM and running out of virtual memory. I've pasted some logs below. The slaves mostly run FORTRAN code compiled with Lahey F95 v6.0 and g77 (0.5.24-19981002). What else could cause these errors? Are there special kernel config issues for AMD chips? I've run Linux for 9 years, always used Intel CPUs, used Debian since before the first official release (buzz), but never heard of so many problems. ch_binary_handler+67/168] [do_execve+417/516] [sys_execve+75/124] [system_call+52/56] Aug 21 06:35:07 hou000752cs kernel: Code: f6 46 24 01 74 52 8b 4c 24 68 39 4e 14 75 49 8b 4c 24 64 31 Aug 21 06:35:07 hou000752cs inetd[458]: pid 11124: exit signal 11 Aug 21 06:35:07 hou000752cs kernel: Unable to handle kernel paging request at virtual address 00ff0024 Aug 21 06:35:07 hou000752cs kernel: current-tss.cr3 = 1463e000, %cr3 = 1463e000 Aug 21 06:35:07 hou000752cs kernel: *pde = Aug 21 06:35:07 hou000752cs kernel: Oops: Aug 21 06:35:07 hou000752cs kernel: CPU:0 Aug 21 06:35:07 hou000752cs kernel: EIP: 0010:[locks_remove_posix+44/152] Aug 21 06:35:07 hou000752cs kernel: EFLAGS: 00010206 Aug 21 06:35:07 hou000752cs kernel: eax: 94629b04 ebx: be6b35a0 ecx: 94629a94 edx: 947f6920 Aug 21 06:35:07 hou000752cs kernel: esi: 00ff edi: 942157c0 ebp: 94629b04 esp: 93a9bc28 Aug 21 06:35:07 hou000752cs kernel: ds: 0018 es: 0018 ss: 0018 Aug 21 06:35:07 hou000752cs kernel: Process in.ftpd (pid: 11125, process nr: 30, stackpage=93a9b000) Aug 21 06:35:07 hou000752cs kernel: Stack: 942157c0 bcc13f60 94629b04 94629a94 8012699a 94785f00 93a9a000 94785f00 Aug 21 06:35:07 hou000752cs kernel:fff7 0202 93f45aa0 00013000 93f45a40 2aabf000 93f45adc 80135619 Aug 21 06:35:07 hou000752cs kernel:80135626 93f45a40 08085fc0 0806b800 bcc13f60 80126991 be6b35a0 Aug 21 06:35:07 hou000752cs kernel: Call Trace: [filp_close+82/92] [load_elf_interp+677/708] [load_elf_interp+690/708] [filp Aug 21 04:02:00 hou000721cs anacron[5515]: Updated timestamp for job `cron.daily' to 2001-08-21 Aug 21 04:02:01 hou000721cs kernel: Unable to handle kernel paging request at virtual address 11008010 Aug 21 04:02:01 hou000721cs kernel: current-tss.cr3 = 145aa000, %cr3 = 145aa000 Aug 21 04:02:01 hou000721cs kernel: *pde = Aug 21 04:02:01 hou000721cs kernel: Oops: Aug 21 04:02:01 hou000721cs kernel: CPU:0 Aug 21 04:02:01 hou000721cs kernel: EIP:0010:[d_lookup+100/224] Aug 21 04:02:01 hou000721cs kernel: EFLAGS: 00010217 Aug 21 04:02:01 hou000721cs kernel: eax: beee9a88 ebx: 11007ff8 ecx: 0022 edx: bee0 Aug 21 04:02:01 hou000721cs kernel: esi: 322f6ef6 edi: ac72f00a ebp: 11008010 esp: 8542bf3c Aug 21 04:02:01 hou000721cs kernel: ds: 0018 es: 0018 ss: 0018 Aug 21 04:02:01 hou000721cs kernel: Process slocate (pid: 5612, process nr: 18, stackpage=8542b000) Aug 21 04:02:01 hou000721cs kernel: Stack: ac72f00a beee9a88 ac72f000 322f6ef6 000a 8012df0c aa7363e0 Aug 21 04:02:01 hou000721cs kernel:8542bf84 8542bf84 8012e187 aa7363e0 8542bf84 ac72f000 ac72f000 Aug 21 04:02:01 hou000721cs kernel:8542a000 7c38 ac72f000 000a 322f6ef6 8012e284 ac72f000 aa7363e0 Aug 21 04:02:01 hou000721cs kernel: Call Trace: [cached_lookup+16/84] [lookup_dentry+275/488] [__namei+40/88] [sys_newlstat+42/140] [system_call+52/56] Aug 21 04:02:01 hou000721cs kernel: Code: 8b 6d 00 8b 74 24 18 39 73 48 75 5c 8b 74 24 24 39 73 0c 75 Aug 19 12:10:00 hou000669cs kernel: Unable to handle kernel paging request at virtual address d2040200 Aug 19 12:10:00 hou000669cs kernel: current-tss.cr3 = 11c09000, %cr3 = 11c09000 Aug 19 12:10:00 hou000669cs kernel: *pde = Aug 19 12:10:00 hou000669cs kernel: Oops: Aug 19 12:10:00 hou000669cs kernel: CPU:0 Aug 19 12:10:00 hou000669cs kernel: EIP:0010:[flush_old_exec+196/552] Aug 19 12:10:00 hou000669cs kernel: EFLAGS: 00010246 Aug 19 12:10:00 hou000669cs kernel: eax: ebx: 9b04 ecx: 9b041e5c edx: 11c09000 Aug 19 12:10:00 hou000669cs kernel: esi: edi: 801e59c3 ebp: 9a5c4000 esp: 9b041ca0 Aug 19 12:10:00 hou000669cs kernel: ds: 0018 es: 0018 ss: 0018 Aug 19 12:10:00 hou000669cs kernel: Process crond (pid: 15182, process nr: 24, stackpage=9b041000) Aug 19 12:10:00 hou000669cs kernel: Stack: 801e59c3 befddf80 9b04 80135d52 9b041e5c 8021e718 fff 8 Aug 19 12:10:00 hou000669cs kernel:9b04 00030003 0001 1990 003 4 Aug 19 12:10:00
Re: OT: AMD chips cause kernel errors and hangs?
On Aug 21 2001, Rick Macdonald wrote: Several nodes hang and/or get kernel errors every day. The first causes that come to mind are bad RAM and running out of virtual memory. I've pasted some logs below. (...) I guess that the best solution would be for you to run these Oops through ksymoops (apt-get install ksymoops) and send some detailed reports of the situations with the decoded Oops attached to the Linux Kernel mailing list. They would have more potential to solve your problems. []s, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogério Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: OT: AMD chips cause kernel errors and hangs?
I just got an AMD chip and noticed that witht the RAM set to 133MHz in the BIOS it would lock under Debian or Win98. It happened on my box and my girlfriend's identical box. I'd suggest checking the memory settings. On Tue, Aug 21, 2001 at 11:59:06PM -0600, Rick Macdonald scribbled... We have a Linux cluster of 1000 nodes. I wasn't involved in setting it up. They use RedHat 6.2 kernel 2.2.19. Dual AMD 1.2GHz, 2GB memory, 2GB swap, GB ethernet. Several nodes hang and/or get kernel errors every day. The first causes that come to mind are bad RAM and running out of virtual memory. I've pasted some logs below. The slaves mostly run FORTRAN code compiled with Lahey F95 v6.0 and g77 (0.5.24-19981002). What else could cause these errors? Are there special kernel config issues for AMD chips? I've run Linux for 9 years, always used Intel CPUs, used Debian since before the first official release (buzz), but never heard of so many problems. ch_binary_handler+67/168] [do_execve+417/516] [sys_execve+75/124] [system_call+52/56] Aug 21 06:35:07 hou000752cs kernel: Code: f6 46 24 01 74 52 8b 4c 24 68 39 4e 14 75 49 8b 4c 24 64 31 Aug 21 06:35:07 hou000752cs inetd[458]: pid 11124: exit signal 11 Aug 21 06:35:07 hou000752cs kernel: Unable to handle kernel paging request at virtual address 00ff0024 Aug 21 06:35:07 hou000752cs kernel: current-tss.cr3 = 1463e000, %cr3 1463e000 Aug 21 06:35:07 hou000752cs kernel: *pde = Aug 21 06:35:07 hou000752cs kernel: Oops: Aug 21 06:35:07 hou000752cs kernel: CPU:0 Aug 21 06:35:07 hou000752cs kernel: EIP: 0010:[locks_remove_posix+44/152] Aug 21 06:35:07 hou000752cs kernel: EFLAGS: 00010206 Aug 21 06:35:07 hou000752cs kernel: eax: 94629b04 ebx: be6b35a0 ecx: 94629a94 edx: 947f6920 Aug 21 06:35:07 hou000752cs kernel: esi: 00ff edi: 942157c0 ebp: 94629b04 esp: 93a9bc28 Aug 21 06:35:07 hou000752cs kernel: ds: 0018 es: 0018 ss: 0018 Aug 21 06:35:07 hou000752cs kernel: Process in.ftpd (pid: 11125, process nr: 30, stackpage=93a9b000) Aug 21 06:35:07 hou000752cs kernel: Stack: 942157c0 bcc13f60 94629b04 94629a94 8012699a 94785f00 93a9a000 94785f00 Aug 21 06:35:07 hou000752cs kernel:fff7 0202 93f45aa0 00013000 93f45a40 2aabf000 93f45adc 80135619 Aug 21 06:35:07 hou000752cs kernel:80135626 93f45a40 08085fc0 0806b800 bcc13f60 80126991 be6b35a0 Aug 21 06:35:07 hou000752cs kernel: Call Trace: [filp_close+82/92] [load_elf_interp+677/708] [load_elf_interp+690/708] [filp Aug 21 04:02:00 hou000721cs anacron[5515]: Updated timestamp for job `cron.daily' to 2001-08-21 Aug 21 04:02:01 hou000721cs kernel: Unable to handle kernel paging request at virtual address 11008010 Aug 21 04:02:01 hou000721cs kernel: current-tss.cr3 = 145aa000, %cr3 145aa000 Aug 21 04:02:01 hou000721cs kernel: *pde = Aug 21 04:02:01 hou000721cs kernel: Oops: Aug 21 04:02:01 hou000721cs kernel: CPU:0 Aug 21 04:02:01 hou000721cs kernel: EIP:0010:[d_lookup+100/224] Aug 21 04:02:01 hou000721cs kernel: EFLAGS: 00010217 Aug 21 04:02:01 hou000721cs kernel: eax: beee9a88 ebx: 11007ff8 ecx: 0022 edx: bee0 Aug 21 04:02:01 hou000721cs kernel: esi: 322f6ef6 edi: ac72f00a ebp: 11008010 esp: 8542bf3c Aug 21 04:02:01 hou000721cs kernel: ds: 0018 es: 0018 ss: 0018 Aug 21 04:02:01 hou000721cs kernel: Process slocate (pid: 5612, process nr: 18, stackpage=8542b000) Aug 21 04:02:01 hou000721cs kernel: Stack: ac72f00a beee9a88 ac72f000 322f6ef6 000a 8012df0c aa7363e0 Aug 21 04:02:01 hou000721cs kernel:8542bf84 8542bf84 8012e187 aa7363e0 8542bf84 ac72f000 ac72f000 Aug 21 04:02:01 hou000721cs kernel:8542a000 7c38 ac72f000 000a 322f6ef6 8012e284 ac72f000 aa7363e0 Aug 21 04:02:01 hou000721cs kernel: Call Trace: [cached_lookup+16/84] [lookup_dentry+275/488] [__namei+40/88] [sys_newlstat+42/140] [system_call+52/56] Aug 21 04:02:01 hou000721cs kernel: Code: 8b 6d 00 8b 74 24 18 39 73 48 75 5c 8b 74 24 24 39 73 0c 75 Aug 19 12:10:00 hou000669cs kernel: Unable to handle kernel paging request at virtual address d2040200 Aug 19 12:10:00 hou000669cs kernel: current-tss.cr3 = 11c09000, %cr3 11c09000 Aug 19 12:10:00 hou000669cs kernel: *pde = Aug 19 12:10:00 hou000669cs kernel: Oops: Aug 19 12:10:00 hou000669cs kernel: CPU:0 Aug 19 12:10:00 hou000669cs kernel: EIP:0010:[flush_old_exec+196/552] Aug 19 12:10:00 hou000669cs kernel: EFLAGS: 00010246 Aug 19 12:10:00 hou000669cs kernel: eax: ebx: 9b04 ecx: 9b041e5c edx: 11c09000 Aug 19 12:10:00 hou000669cs kernel: esi: edi
Re: OT: AMD chips cause kernel errors and hangs?
On Tue, Aug 21, 2001 at 11:59:06PM -0600, Rick Macdonald wrote: We have a Linux cluster of 1000 nodes. I wasn't involved in setting it up. They use RedHat 6.2 kernel 2.2.19. Dual AMD 1.2GHz, 2GB memory, 2GB swap, GB ethernet. Quoting the latest Kernel Traffic (kt.zork.net), which summerizes the kernel development list: 'But Alan Cox pointed out, Athlon SMP will actually not always work with 2.2.' I suggest pointing this out to the one who *did* set up the cluster, and perhaps persuading him/her to move to 2.4 and a distro that supports it. As for your hardware, I am jelous. Where do I sign up for an account? :) Mike
Re: OT: AMD chips cause kernel errors and hangs?
Jason Majors wrote: I just got an AMD chip and noticed that witht the RAM set to 133MHz in the BIOS it would lock under Debian or Win98. It happened on my box and my girlfriend's identical box. I'd suggest checking the memory settings. On Tue, Aug 21, 2001 at 11:59:06PM -0600, Rick Macdonald scribbled... snip re: someone else having lockups also I got an FIC motherboard with an AMD 1.2GHz Athlon; the mobo has a jumper to switch between 100MHz and 133MHz bus speed. If I set it to 133, I can then go into CMOS and watch the temperature monitor climb and climb until the machine locks solid. Switching it back down to 100 allows the machine to work properly. I later got a hint that there's a 233-FSB flavor of 1.2 GHz Athlon, and a normal flavor. I suspect I got the wrong flavor. Mind you, I'm not very literate on modern hardware, so I may be speaking complete nonsense. Kent
Re: OT: AMD chips cause kernel errors and hangs?
On Wed, Aug 22, 2001 at 01:03:05PM -0500, Kent West wrote: I got an FIC motherboard with an AMD 1.2GHz Athlon; the mobo has a jumper to switch between 100MHz and 133MHz bus speed. If I set it to 133, I can then go into CMOS and watch the temperature monitor climb and climb until the machine locks solid. Switching it back down to 100 allows the machine to work properly. That's right, there are two separate types of Athlons - 100/200 MHz FSB and 133/266 MHz FSB. The speed that the chip is actually running at is determined by the FSB and the fixed[1] multiplier in the chip. Since you have a 1.2 GHz part, it's running a 12x multiplier (12 x 100). When you set the FSB to 133 MHz, you're essentially increasing (overclocking) your chip speed to 12 x 133, or 1.6 GHz. Without adequate cooling, you *will* cook your chip. In other words, unless you know for sure what you are doing, don't do it. Another consideration is memory. If you have PC100 memory and are trying to run it at 133, it may not work. For more information on overclocking, see http://www.anandtech.com and http://www.tomshardware.com. [1] There are ways to change the multiplier on the Slot A and Socket A Athlons, but vary from simple to not so simple. See the above sites for more info. -B -- Brandon High [EMAIL PROTECTED] Drink your Coffee! There are people in India sleeping. pgpRXUo7IAqAI.pgp Description: PGP signature
kernel errors with PPP
I after installing the base Debain 2.1 using the cdrom I rebooted and
attempted to continue the package installation process via apt PPP.
When I attempted to dial up (pon provider) after pppconfig I got weird
kernel error to standard out. So I decied to install from the CD instead.
After doing this and rebooting I noticed that 'pon provider' started to
work!! Maybe I installed something necessary?! ANYWAYS after dialing up
and installing some packages via apt PPP my dialup STOPPED working.
This time the errors showed up in /var/log/messages so I've appended them
to the end of this email incase anybody can help.
I'd really like to not have to keep rebooting to RedHat to dial up.
Thanks for any help sombody might bestow on me. Marlon
Apr 19 11:32:40 crow pppd[979]: pppd 2.3.5 started by root, uid 0
Apr 19 11:32:41 crow kernel: invalid operand:
Apr 19 11:32:41 crow kernel: CPU:0
Apr 19 11:32:41 crow kernel: EIP:0010:[0007]
Apr 19 11:32:41 crow kernel: EFLAGS: 00010282
Apr 19 11:32:41 crow kernel: eax: ebx: 0004 ecx: 0064
edx: 0008
Apr 19 11:32:41 crow kernel: esi: 001f3ef0 edi: 0001 ebp: 001d5238 esp:
001d5220
Apr 19 11:32:41 crow kernel: ds: 0018 es: 0018 fs: 002b gs: ss: 0018
Apr 19 11:32:41 crow kernel: Process swapper (pid: 0, process nr: 0,
stackpage=001d3658)
Apr 19 11:32:41 crow kernel: Stack: 00112e1c 0001 0001
0001 001d5254 001f3de0 0011884b
Apr 19 11:32:41 crow kernel:001d5254 0014 001d52fc0010ab57
Apr 19 11:32:41 crow kernel:0014 001d52fc 001d5e0c0018
0018
Apr 19 11:32:41 crow kernel: Call Trace:
[wake_up_process+68/112][sys_wait4+695/840] [lcall7+15/84] [show_regs+110/156]
[get_module_list+374/424] [die_if_ker
nel+592/680] [0500]
Apr 19 11:32:41 crow kernel:[serial:register_serial_R3425f38c+-232580/324]
[do_bounds+73/92][do_bounds+12/92] [v86_signal_return+44/52] [isofs_find_e
ntry+188
/1368] [wake_up_process+68/112] [sys_wait4+695/840] [lcall7+15/84]
Apr 19 11:32:41 crow kernel:[read_ldt+96/168]
[paging_init+191/228] [get_module_list+22/424] [die_if_kernel+592/680]
[0500] [serial:register_ser
ial_R342
5f38c+-232580/324] [do_bounds+73/92] [do_bounds+12/92]
Apr 19 11:32:41 crow kernel:[v86_signal_return+44/52]
[wake_up_process+68/112] [sys_wait4+695/840] [lcall7+15/84]
[read_ldt+72/168] [get_ksyms_list+25
/244] [d
ie_if_kernel+592/680] [0500]
Apr 19 11:32:41 crow kernel:
[serial:register_serial_R3425f38c+-232580/324] [do_bounds+73/92]
[do_bounds+12/92] [v86_signal_return+44/52] [wake_up_proc
ess+68/1
12] [sys_wait4+695/840] [lcall7+15/84] [sys_idle+12/112]
Apr 19 11:32:41 crow kernel:[system_call+5/124]
[do_linuxrc+128/196] [read_ldt+96/168] [start_kernel+409/500]
[kill_proc+20/76]
Apr 19 11:32:41 crow kernel: Code: f0 f8 f8 00 f0 d0 7a 00 f0 d0 7a 00 f0
54 ff 00 f0 79 ea 00
Apr 19 11:32:41 crow kernel: Aiee, killing interrupt handler
Apr 19 11:32:42 crow chat[980]: send (ATZ^M)
Apr 19 11:32:42 crow kernel: general protection:
Apr 19 11:32:42 crow kernel: CPU:0
Apr 19 11:32:42 crow kernel: EIP:
0010:[serial:register_serial_R3425f38c+-11991/324]
Apr 19 11:32:42 crow kernel: EFLAGS: 00010202
Apr 19 11:32:42 crow kernel: eax: ebx: 0011884b ecx: 018c1634
edx: 018c1600
Apr 19 11:32:42 crow kernel: esi: 01dd2810 edi: b9ad ebp: 0804b600
esp: 0123afc8
Apr 19 11:32:42 crow kernel: ds: 0018 es: 0018 fs: 002b gs: 002b
ss: 0018
Apr 19 11:32:42 crow kernel: Process chat (pid: 980, process nr: 39,
stackpage=0123a000)
Apr 19 11:32:42 crow kernel: Stack: b9ad 0804b600 b938 0001
002b 0010002b 002b 002b
Apr 19 11:32:42 crow kernel:0004 40077a94 0023 0202
b918 002b
Apr 19 11:32:42 crow kernel: Call Trace:
Apr 19 11:32:42 crow kernel: Code: c3 89 f6 8b 4c 24 2c 8a 09 83 e1 0f 89
4c 24 20 83 f9 04 77
Apr 19 11:32:42 crow kernel: Aiee, killing interrupt handler
Apr 19 11:32:43 crow pppd[979]: Exit.
Re: kernel errors with PPP
Marlon Urias writes: ANYWAYS after dialing up and installing some packages via apt PPP my dialup STOPPED working. What packages did you install? This time the errors showed up in /var/log/messages so I've appended them to the end of this email incase anybody can help. Can't tell much from this immediately. Can you reproduce this? Just try running 'pon'. No need to use apt. -- John HaslerThis posting is in the public domain. [EMAIL PROTECTED] Do with it what you will. Dancing Horse Hill Make money from it if you can; I don't mind. Elmwood, Wisconsin Do not send email advertisements to this address.
kernel errors under Linux pre-patch-2.0.31-3
I tested the kernel pre-patch-2.0.31-3 from www.linuxhq.com because it's got support for hardware I use. I use Debian 1.3 with upgrades for 2.1.X kernels. Under this kernel, I'm logging errors like: Unable to handle kernel paging request at virtual address e0202024 current-tss.cr3 = 00742000, Lr3 = 00742000 *pde = Oops: CPU:0 EIP:0010:[free_wait+40/68] EFLAGS: 00010007 eax: 033b3000 ebx: 033b3018 ecx: 20202020 edx: 20202020 esi: 0207 edi: 0070ce9c ebp: esp: 0070ce74 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process emacs (pid: 186, process nr: 37, stackpage=0070c000) Stack: 0006 0037d180 0012c66e 0070ce9c 0100 b638 0816c0a4 033b3000 0002 033b3000 0012c8c7 0006 0070cf54 0070cf14 0070ced4 0070cf74 0070cf34 0070cef4 0816c0a4 0400 b5dc b6d0 Call Trace: [do_select+414/484] [sys_select+387/596] [old_select+63/80] [system_call+85/128] Code: 8b 42 04 39 d8 74 05 89 c2 eb f5 90 89 4a 04 56 9d 8b 0f 85 Unable to handle kernel paging request at virtual address e0202020 current-tss.cr3 = 00101000, Lr3 = 00101000 *pde = Oops: CPU:0 EIP:0010:[wake_up_interruptible+53/220] EFLAGS: 00010012 eax: 0112ff50 ebx: 20202030 ecx: 0112ff50 edx: 20202020 esi: 0112fec4 edi: 0112ff4c ebp: 0070cd84 esp: 0070cd78 ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Process emacs (pid: 186, process nr: 37, stackpage=0070c000) Stack: 03928580 0112fec4 0112fec4 03c50810 00129f71 0112ff50 00122384 0112fec4 03928580 03928580 001223f4 03928580 0112fec4 0027 0003 0001 00116782 03928580 002b 0014 0070d000 0070ce38 0010aba3 Call Trace: [pipe_read_release+21/28] [__fput+28/64] [close_fp+76/92] [do_exit+274/492] [die_if_kernel+695/704] [0500] [0480] [pmgr_read+12/352] [do_page_fault+698/716] [do_page_fault+0/716] [tty_select+145/164] [error_code+64/80] [free_wait+40/68] [do_select+414/484] [sys_select+387/596] [old_select+63/80] [system_call+85/128] Code: 8b 02 83 f8 01 75 5e 9c 5e fa c7 02 00 00 00 00 83 7a 4c 00 The errors have caused X to freeze up and die, but not no system crash so far. The first time I booted this kernel, `su' and `bash' would seg fault, but I'm haven't been able to reproduce this. Is this worth a bug report to kernel developers? (Linus?) What should I track down? What info should be included, and where should the report be sent? -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice-Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada 418-775-0852 - FAX 418-775-0546 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
