compiled and booted 6.17.12-rc1+ Version: AMD A4-4000 APU with Radeon(tm) HD Graphics

sudo dmesg -l errr shows error

j$sudo dmesg -l err [ 39.915487] Error: Driver 'pcspkr' is already registered, aborting... $

Tested-by: Jeffrin Jose T jeffrin@rajagiritech.edu.in

-- software engineer rajagiri school of engineering and technology

On Wed, Dec 10, 2025 at 04:22:21PM +0530, Jeffrin Thalakkottoor wrote:

compiled and booted 6.17.12-rc1+ Version: AMD A4-4000 APU with Radeon(tm) HD Graphics

sudo dmesg -l errr shows error

j$sudo dmesg -l err [ 39.915487] Error: Driver 'pcspkr' is already registered, aborting... $

Is ths new? if so, can you bisect?

On Wed, Dec 10, 2025 at 6:17 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

On Wed, Dec 10, 2025 at 04:22:21PM +0530, Jeffrin Thalakkottoor wrote:

...

compiled and booted 6.17.12-rc1+ Version: AMD A4-4000 APU with Radeon(tm) HD Graphics

sudo dmesg -l errr shows error

j$sudo dmesg -l err [ 39.915487] Error: Driver 'pcspkr' is already registered, aborting... $

Is ths new? if so, can you bisect?

this is new related. Previous stable release err and warn disappeared (i think i changed .config)

can you give me a step by step tutorial for git bisect

t

On 12/9/25 23:29, Greg Kroah-Hartman wrote:

This is the start of the stable review cycle for the 6.17.12 release. There are 60 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri, 12 Dec 2025 07:29:37 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.12-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.17.y and the diffstat can be found below.

thanks,

greg k-h

On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:

Tested-by: Florian Fainelli florian.fainelli@broadcom.com

On Wed, 10 Dec 2025 at 13:03, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

This is the start of the stable review cycle for the 6.17.12 release. There are 60 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri, 12 Dec 2025 07:29:37 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.12-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.17.y and the diffstat can be found below.

thanks,

greg k-h

Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.

Tested-by: Linux Kernel Functional Testing lkft@linaro.org

## Build * kernel: 6.17.12-rc1 * git: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git * git commit: e7c0ca6d291c41a8a9648a5016ce9b73e492aa3d * git describe: v6.17.10-208-ge7c0ca6d291c * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.17.y/build/v6.17....

## Test Regressions (compared to v6.17.10-147-gc434a9350a1d)

## Metric Regressions (compared to v6.17.10-147-gc434a9350a1d)

## Test Fixes (compared to v6.17.10-147-gc434a9350a1d)

## Metric Fixes (compared to v6.17.10-147-gc434a9350a1d)

## Test result summary total: 116299, pass: 98676, fail: 3761, skip: 13862, xfail: 0

## Build Summary * arc: 5 total, 5 passed, 0 failed * arm: 139 total, 139 passed, 0 failed * arm64: 57 total, 54 passed, 3 failed * i386: 18 total, 18 passed, 0 failed * mips: 34 total, 33 passed, 1 failed * parisc: 4 total, 4 passed, 0 failed * powerpc: 40 total, 39 passed, 1 failed * riscv: 25 total, 25 passed, 0 failed * s390: 22 total, 22 passed, 0 failed * sh: 5 total, 5 passed, 0 failed * sparc: 4 total, 3 passed, 1 failed * x86_64: 49 total, 48 passed, 1 failed

## Test suites summary * boot * commands * kselftest-arm64 * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-exec * kselftest-fpu * kselftest-ftrace * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-kcmp * kselftest-kvm * kselftest-livepatch * kselftest-membarrier * kselftest-memfd * kselftest-mincore * kselftest-mm * kselftest-mqueue * kselftest-net * kselftest-net-mptcp * kselftest-openat2 * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-rust * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-tc-testing * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user_events * kselftest-vDSO * kselftest-x86 * kunit * kvm-unit-tests * lava * libgpiod * libhugetlbfs * log-parser-boot * log-parser-build-clang * log-parser-build-gcc * log-parser-test * ltp-capability * ltp-commands * ltp-containers * ltp-controllers * ltp-cpuhotplug * ltp-crypto * ltp-cve * ltp-dio * ltp-fcntl-locktests * ltp-fs * ltp-fs_bind * ltp-fs_perms_simple * ltp-hugetlb * ltp-math * ltp-mm * ltp-nptl * ltp-pty * ltp-sched * ltp-smoke * ltp-syscalls * ltp-tracing * perf * rcutorture * rt-tests-cyclicdeadline * rt-tests-pi-stress * rt-tests-pmqtest * rt-tests-rt-migrate-test * rt-tests-signaltest

-- Linaro LKFT https://lkft.linaro.org

On Wed, Dec 10, 2025 at 1:05 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

This is the start of the stable review cycle for the 6.17.12 release. There are 60 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Fri, 12 Dec 2025 07:29:37 +0000. Anything received after that time might be too late.

The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.17.12-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.17.y and the diffstat can be found below.

thanks,

greg k-h

Build and Boot Report for 6.17.12-rc1

The kernel version 6.17.12 was built and boot-tested using qemu-x86_64 and qemu-arm64 with the default configuration (defconfig). The build and boot processes completed successfully, and the kernel operated as expected in the virtualized environments without any issues. No dmesg regressions found.

Build Details : Builds : arm64, x86_64 Kernel Version: 6.17.12 Configuration : defconfig Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit : e7c0ca6d291c41a8a9648a5016ce9b73e492aa3d

Tested-by: Dileep Malepu dileep.debian@gmail.com

Best regards, Dileep Malepu

On 2025-12-11 21:09, Jeffrin Thalakkottoor wrote:

On Thu, Dec 11, 2025 at 12:35 AM Brett A C Sheffield bacs@librecast.net wrote:

...

On 2025-12-10 19:13, Jeffrin Thalakkottoor wrote:

...

On Wed, Dec 10, 2025 at 6:17 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

...

On Wed, Dec 10, 2025 at 04:22:21PM +0530, Jeffrin Thalakkottoor wrote:

...

compiled and booted 6.17.12-rc1+ Version: AMD A4-4000 APU with Radeon(tm) HD Graphics

sudo dmesg -l errr shows error

j$sudo dmesg -l err [ 39.915487] Error: Driver 'pcspkr' is already registered, aborting... $

Is ths new? if so, can you bisect?

this is new related. Previous stable release err and warn disappeared (i think i changed .config)

can you give me a step by step tutorial for git bisect

1. cd to wherever you have your kernel checked out

2. `git bisect start`

3. if you're already on a known-bad commit, then mark it as such:

`git bisect bad`

4. Mark the last known good commit as such:

`git bisect good <commit / tag>`

git bisect will choose a commit to test.

5. Build, install and boot your kernel as you usually do

6. Run whatever test you need to determine if the booted kernel is good or bad

(check dmesg in this case)

7. Mark the commit as good or bad. Git will choose another commit for you.

8. Goto 5.

`git help bisect` will give you more information.

At the end of the process git will tell you the first bad commit found. You can dump the bisection log with:

`git bisect log`

which you can reply here with.

HTH.

Cheers,

Brett

Thnaks for the tutorial :)

1. should i start with the bad commit first ?

You start by marking one good (past) commit and one bad commit. It doesn't matter what order.

You have at least one "bad" commit you know of: 4112049d7836ad4233321c3d2b6853db1627c49c

This is the 6.12.62-rc1 commit that you reported had the error.

So, in your kernel worktree:

`git bisect start` `git bisect bad 4112049d7836ad4233321c3d2b6853db1627c49c`

Now we need to tell git bisect the most recent "good" commit we know of (where the error didn't occur).

If you already know the commit or tag of a previous version where you did not get the error, mark that as good. If not, pick a previous release, check it out, and go to step 5.

2. how to move forward or backward in commits ?

git bisect will do that for you as soon as you mark a good and bad commit. If you want to manually test a specific commit, just `git checkout <ref>` as usual, and continue at step 5 in the instructions I gave you.

3. what is the point in re-compiling the kernel if it cannot narrow

down and test news lines of code

We're narrowing down the error to a specific kernel commit. Once we know which specific commit introduced the error, we can look at the lines changed and try to understand why. We need your help to find that commit, because it's happening on your system.

Please do read `git help bisect` (man 1 git-bisect). It explains all this better than I can.

Thanks for testing and good luck!

Brett

On Thu, Dec 11, 2025 at 10:11 PM Brett A C Sheffield bacs@librecast.net wrote:

On 2025-12-11 21:09, Jeffrin Thalakkottoor wrote:

...

On Thu, Dec 11, 2025 at 12:35 AM Brett A C Sheffield bacs@librecast.net wrote:

...

On 2025-12-10 19:13, Jeffrin Thalakkottoor wrote:

...

On Wed, Dec 10, 2025 at 6:17 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:

...

On Wed, Dec 10, 2025 at 04:22:21PM +0530, Jeffrin Thalakkottoor wrote:

...

compiled and booted 6.17.12-rc1+ Version: AMD A4-4000 APU with Radeon(tm) HD Graphics

sudo dmesg -l errr shows error

j$sudo dmesg -l err [ 39.915487] Error: Driver 'pcspkr' is already registered, aborting... $

Is ths new? if so, can you bisect?

this is new related. Previous stable release err and warn disappeared (i think i changed .config)

can you give me a step by step tutorial for git bisect

1. cd to wherever you have your kernel checked out

2. `git bisect start`

3. if you're already on a known-bad commit, then mark it as such:

`git bisect bad`

4. Mark the last known good commit as such:

`git bisect good <commit / tag>`

git bisect will choose a commit to test.

5. Build, install and boot your kernel as you usually do

6. Run whatever test you need to determine if the booted kernel is good or bad

(check dmesg in this case)

7. Mark the commit as good or bad. Git will choose another commit for you.

8. Goto 5.

`git help bisect` will give you more information.

At the end of the process git will tell you the first bad commit found. You can dump the bisection log with:

`git bisect log`

which you can reply here with.

HTH.

Cheers,

Brett

Thnaks for the tutorial :)

1. should i start with the bad commit first ?

You start by marking one good (past) commit and one bad commit. It doesn't matter what order.

You have at least one "bad" commit you know of: 4112049d7836ad4233321c3d2b6853db1627c49c

This is the 6.12.62-rc1 commit that you reported had the error.

So, in your kernel worktree:

`git bisect start` `git bisect bad 4112049d7836ad4233321c3d2b6853db1627c49c`

Now we need to tell git bisect the most recent "good" commit we know of (where the error didn't occur).

If you already know the commit or tag of a previous version where you did not get the error, mark that as good. If not, pick a previous release, check it out, and go to step 5.

...

2. how to move forward or backward in commits ?

git bisect will do that for you as soon as you mark a good and bad commit. If you want to manually test a specific commit, just `git checkout <ref>` as usual, and continue at step 5 in the instructions I gave you.

...

3. what is the point in re-compiling the kernel if it cannot narrow

down and test news lines of code

We're narrowing down the error to a specific kernel commit. Once we know which specific commit introduced the error, we can look at the lines changed and try to understand why. We need your help to find that commit, because it's happening on your system.

Please do read `git help bisect` (man 1 git-bisect). It explains all this better than I can.

Thanks for testing and good luck!

Brett

I do not see that error anymore. may be i have made changes in configuration. THANKS

-- software engineer rajagiri school of engineering and technology