system starts, but display seems to deactivate

sukolyn · 2024-10-22 02:58:14

it's not been too long : it 's bad at first run.

here's BISECT_LOG:

git bisect start
# status : en attente d'un commit bon et d'un commit mauvais
# good: [0c3836482481200ead7b416ca80c68a29cfdaabd] Linux 6.10
git bisect good 0c3836482481200ead7b416ca80c68a29cfdaabd
# status : en attente d'un mauvais commit, 1 commit bon connu
# bad: [98f7e32f20d28ec452afb208f9cffc08448a2652] Linux 6.11
git bisect bad 98f7e32f20d28ec452afb208f9cffc08448a2652
# bad: [b3ce7a30847a54a7f96a35e609303d8afecd460b] Merge tag 'drm-next-2024-07-18' of https://gitlab.freedesktop.org/drm/kernel
git bisect bad b3ce7a30847a54a7f96a35e609303d8afecd460b

what do we do now ?

sukolyn · 2024-10-22 09:48:57

now

You repeat those steps #Bad bisect and #Good bisect until it shows the content of the bad patch

sukolyn · 2024-10-23 21:18:21

so.

every 13 commits were "bad".
last `git bisect bad' outputs this:

$ git bisect bad                                                                                                                                                 
5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6 is the first bad commit                                                                                                                                                                               
avertissement : refname 'HEAD' is ambiguous.                                                                                                                                                                                                   
commit 5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6                                                                                                                                                                                                
Author: Christoph Hellwig <hch@lst.de>                                                                                                                                                                                                         
Date:   Fri May 31 09:47:56 2024 +0200                                                                                                                                                                                                         
                                                                                                                                                                                                                                               
    ubd: refactor the interrupt handler                                                                                                                                                                                                        
                                                                                                                                                                                                                                               
    Instead of a separate handler function that leaves no work in the                                                                                                                                                                          
    interrupt hanler itself, split out a per-request end I/O helper and                                                                                                                                                                        
    clean up the coding style and variable naming while we're at it.                                                                                                                                                                           
                                                                                                                                                                                                                                               
    Signed-off-by: Christoph Hellwig <hch@lst.de>                                                                                                                                                                                              
    Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>                                                                                                                                                                               
    Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>                                                                                                                                                                                   
    Link: https://lore.kernel.org/r/20240531074837.1648501-2-hch@lst.de                                                                                                                                                                        
    Signed-off-by: Jens Axboe <axboe@kernel.dk>                                                                                                                                                                                                
                                                                                                                                                                                                                                               
 arch/um/drivers/ubd_kern.c | 49 ++++++++++++++++++-------------------------------                                                                                                                                                             
 1 file changed, 18 insertions(+), 31 deletions(-)

I'm not quite sure I didn't miss something because every `makepkg -ef' ended with kernel linux-drm-tip-git 6.12.r1310446.f277db2ed74a-1.

seth · 2024-10-23 21:43:15

Did you "git bisect start" every single time again?
That's not how this works, you start the process once and then only git bisect good/bad

Also 5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6 is in 6.10-rc4 and older than the commit originally tagged "good"… not sure how you bisected yourself there
Can you post the bisection log?

sukolyn · 2024-10-23 22:48:39

Did you "git bisect start" every single time again?

no, the `man' says it resets bisect.

That's not how this works, you start the process once and then only git bisect good/bad

that's what I did.

here's BISECT_LOG:

git bisect start
# status : en attente d'un commit bon et d'un commit mauvais
# good: [0c3836482481200ead7b416ca80c68a29cfdaabd] Linux 6.10
git bisect good 0c3836482481200ead7b416ca80c68a29cfdaabd
# status : en attente d'un mauvais commit, 1 commit bon connu
# bad: [98f7e32f20d28ec452afb208f9cffc08448a2652] Linux 6.11
git bisect bad 98f7e32f20d28ec452afb208f9cffc08448a2652
# bad: [b3ce7a30847a54a7f96a35e609303d8afecd460b] Merge tag 'drm-next-2024-07-18' of https://gitlab.freedesktop.org/drm/kernel
git bisect bad b3ce7a30847a54a7f96a35e609303d8afecd460b
# bad: [51835949dda3783d4639cfa74ce13a3c9829de00] Merge tag 'net-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
git bisect bad 51835949dda3783d4639cfa74ce13a3c9829de00
# bad: [e3950967f6e6b74a3606739ec50ed19f3398c7d8] Merge tag 'soc-dt-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
git bisect bad e3950967f6e6b74a3606739ec50ed19f3398c7d8
# bad: [1d86d352411dab9bf9312c9eb4b2d4020195be45] Merge tag 'x86_build_for_v6.11_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
git bisect bad 1d86d352411dab9bf9312c9eb4b2d4020195be45
# bad: [bbb3556c014dc8ed1645b725ad84477603553743] Merge tag 'keys-next-6.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd
git bisect bad bbb3556c014dc8ed1645b725ad84477603553743
# bad: [3c1743a685b19bc17cf65af4a2eb149fd3b15c50] floppy: add missing MODULE_DESCRIPTION() macro
git bisect bad 3c1743a685b19bc17cf65af4a2eb149fd3b15c50
# bad: [bf4ae8f2e6407a779c0368eb0f3e047a8333be17] scsi: sd: Atomic write support
git bisect bad bf4ae8f2e6407a779c0368eb0f3e047a8333be17
# bad: [7f91ccd8a608dbe39b97a6e43d635378d493f77e] dm: Call dm_revalidate_zones() after setting the queue limits
git bisect bad 7f91ccd8a608dbe39b97a6e43d635378d493f77e
# bad: [c6e56cf6b2e79a463af21286ba951714ed20828c] block: move integrity information into queue_limits
git bisect bad c6e56cf6b2e79a463af21286ba951714ed20828c
# bad: [1652b0bafeaa8281ca9a805d81e13d7647bd2f44] block: remove unused queue limits API
git bisect bad 1652b0bafeaa8281ca9a805d81e13d7647bd2f44
# bad: [b0dadb86a90bd5a7b723f9d3a6cf69da9b596496] sd: add a sd_disable_discard helper
git bisect bad b0dadb86a90bd5a7b723f9d3a6cf69da9b596496
# bad: [a00d4bfce7c6d7fa4712b8133ec195c9bd142ae6] rbd: increase io_opt again
git bisect bad a00d4bfce7c6d7fa4712b8133ec195c9bd142ae6
# bad: [31ade7d4fdcf382beb8cb229a1f5d77e0f239672] ubd: untagle discard vs write zeroes not support handling
git bisect bad 31ade7d4fdcf382beb8cb229a1f5d77e0f239672
# bad: [5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6] ubd: refactor the interrupt handler
git bisect bad 5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6
# first bad commit: [5db755fbb1a0de4a4cfd5d5edfaa19853b9c56e6] ubd: refactor the interrupt handle

I repeated these commands:

cd linux-drm.../linux-drm...
git bisect bad
cd ..
makepkg -ef

then, as root, installed same named kernel, updated grub (uselessly, I guess, but I did it anyway), and rebooted to linux-drm-git's "brand new" compiled kernel.
And, because I didn't get login prompt at boot, I told again bisect so, and again (13 times ) .

seth · 2024-10-24 06:29:20

It's probably because of the multi-parentage
Quick sanity check: "git bisect reset; git checkout 0c3836482481200ead7b416ca80c68a29cfdaabd" (the "6.10 release) - that kernel is fine?

It's probably much easier to bisect the arch kernel (and in doubt manually install the kernel, but hold on w/ that for a moment)

sukolyn · 2024-10-24 12:10:33

$ git checkout 0c3836482481200ead7b416ca80c68a29cfdaabd
fatal: this operation must be run in a work tree

It's probably much easier to bisect the arch kernel

let's go.

what do I do ?
clone git's repository
then make && sudo make install
?

seth · 2024-10-24 12:54:31

Wait.
I pinged loqs, who's frequently providing bisection packages and probably has a production pipeline (ie. a pkgbuild for you

fatal: this operation must be run in a work tree

In what directory did you run this?

sukolyn · 2024-10-24 14:23:28

in linux-drm-tip-git/linux-drm-tip-git/

seth · 2024-10-24 14:45:39

Did you "git bisect reset"?

sukolyn · 2024-10-24 15:57:24

yes.

sukolyn · 2024-10-25 21:51:40

I don't understand git's repository is archLinux's kernel, but it doesn't have a PKGBUILD file.

why is PKGBUILD prefered to Makefile ?

Last edited by sukolyn (2024-10-25 21:52:08)

seth · 2024-10-26 07:10:41

Because it spares you having to install kernels bypassing the package manager and makes the clean-up easier.

loqs just builds the stable tree w/ and skips the arch patches
PKGBUILD: http://0x0.st/XUOW.txt
arch config: https://gitlab.archlinux.org/archlinux/ … line=false

Put those into a directory, "makepkg" should™ successfully build 6.11.3
The stable tree is tagged, so you can "git bisect good v6.10.9 # I guess the last one you ran" and "git bisect bad v6.11", the rest of the process is the same

sukolyn · 2024-10-26 13:12:37

thank you.

to be sure I don't do wrong:

mkdir src
cd src/
git clone https://github.com/archlinux/linux
cd linux/
wget -qO PKGBUILD http://0x0.st/XUOW.txt
wget -qO config https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/raw/main/config?ref_type=heads&inline=false
makepkg

then bisect start/good/bad...

right ?

seth · 2024-10-26 14:03:50

mkdir linux-stable
cd linux-stable
wget -qO PKGBUILD http://0x0.st/XUOW.txt
wget -qO config https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/raw/main/config
makepkg # this will clone the linux-stable repo, ~6-7GB and build a kernel package

You can also edit the PKGBUILD and change "pkgver=6.11.3" to sth. else "pkgver=6.10.9" if you want to try that first.
Set the first value of sha256sums and b2sums to "SKIP" or run "makepkg -g >> PHGBUILD" to update the checksums.

Don't forget to "makepkg -e" when running the bisection.

sukolyn · 2024-10-26 19:33:37

PKGBUILD: line 82: cd: linux: No such file or directory

here's what I did:

~ $ mkdir -p build/linux-stable
~ $ cd build/linux-stable
~/build/linux-stable $ wget -qO PKGBUILD http://0x0.st/XUOW.txt
~/build/linux-stable $ wget -qO config https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/raw/main/config
~/build/linux-stable $ makepkg 
==> Making package: linux 6.11.3-1 (Sat Oct 26 18:41:35 2024)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Cloning linux git repo...
Cloning into bare repository '/home/sukolyn/build/linux-stable/linux'...
remote: Enumerating objects: 12900870, done.
remote: Total 12900870 (delta 0), reused 0 (delta 0), pack-reused 12900870
Receiving objects: 100% (12900870/12900870), 5.11 GiB | 27.61 MiB/s, done.
Resolving deltas: 100% (10310588/10310588), done.
  -> Found config
==> Validating source files with sha256sums...
    linux ... Passed
    config ... FAILED
==> ERROR: One or more files did not pass the validity check!
~/build/linux-stable $ makepkg -g >>PKGBUILD 
==> Retrieving sources...
  -> Updating linux git repo...
  -> Found config
==> Generating checksums for source files...
~/build/linux-stable $ cd linux/
~/build/linux-stable/linux $ git bisect start
status: waiting for both good and bad commits
~/build/linux-stable/linux $ git bisect good v6.10.9
status: waiting for bad commit, 1 good commit known
~/build/linux-stable/linux $ git bisect bad v6.11.3
Bisecting: a merge base must be tested
[0c3836482481200ead7b416ca80c68a29cfdaabd] Linux 6.10
~/build/linux-stable/linux $ cd ..
~/build/linux-stable $ makepkg -e
==> Making package: linux 6.11.3-1 (Sat Oct 26 21:27:07 2024)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> WARNING: Using existing $srcdir/ tree
==> Starting pkgver()...
/home/sukolyn/build/linux-stable/PKGBUILD: line 82: cd: linux: No such file or directory
==> ERROR: A failure occurred in pkgver().
    Aborting...

why ?

seth · 2024-10-26 19:58:58

stat /home/sukolyn/build/linux-stable/linux

Though I guess we can assume it's still there.
Add "pwd" above the "cd $_srcname" in line 82

Edit: that will just print the current directory from where the cd fails.

Last edited by seth (2024-10-26 19:59:24)

sukolyn · 2024-10-26 20:35:19

working directory is not printed from pkgver()
putting `pwd' at the beginning of PKGBUILD prints correctly /home/sukolyn/build/linux-stable
yes, linux/ is there:

$ stat linux
  File: linux                                                                                                                                                                                                                                  
  Size: 4096            Blocks: 8          IO Block: 4096   directory                                                                                                                                                                          
Device: 8,17    Inode: 18907830    Links: 7                                                                                                                                                                                                    
Access: (0755/drwxr-xr-x)  Uid: ( 1000/    sukolyn)   Gid: ( 1000/    sukolyn)                                                                                                                                                                 
Access: 2024-10-26 21:26:11.123775820 +0200                                                                                                                                                                                                    
Modify: 2024-10-26 21:26:44.970300091 +0200                                                                                                                                                                                                    
Change: 2024-10-26 21:26:44.970300091 +0200                                                                                                                                                                                                    
 Birth: 2024-10-26 18:41:35.747841316 +0200

seth · 2024-10-26 21:02:27

Try

pwd > /tmp/wtf 2>&1

and then check /tmp/wtf

sukolyn · 2024-10-26 21:53:29

cat /tmp/wtf
/home/sukolyn/build/linux-stable/src

and src/ is empty

seth · 2024-10-26 21:55:52

F$%CK

"makepkg --noprepare"

sukolyn · 2024-10-26 22:11:05

makepkg -e --noprepare

same error

seth · 2024-10-26 22:11:49

Not "-e", only "--noprepare"

sukolyn · 2024-10-26 22:24:38

do I `bisect reset' ?

sukolyn · 2024-10-26 22:47:09

==> ERROR: A failure occurred in build().
    Aborting.

Arch Linux

#76 2024-10-22 02:58:14

Re: system starts, but display seems to deactivate

#77 2024-10-22 09:48:57

Re: system starts, but display seems to deactivate

#78 2024-10-23 21:18:21

Re: system starts, but display seems to deactivate

#79 2024-10-23 21:43:15

Re: system starts, but display seems to deactivate

#80 2024-10-23 22:48:39

Re: system starts, but display seems to deactivate

#81 2024-10-24 06:29:20

Re: system starts, but display seems to deactivate

#82 2024-10-24 12:10:33

Re: system starts, but display seems to deactivate

#83 2024-10-24 12:54:31

Re: system starts, but display seems to deactivate

#84 2024-10-24 14:23:28

Re: system starts, but display seems to deactivate

#85 2024-10-24 14:45:39

Re: system starts, but display seems to deactivate

#86 2024-10-24 15:57:24

Re: system starts, but display seems to deactivate

#87 2024-10-25 21:51:40

Re: system starts, but display seems to deactivate

#88 2024-10-26 07:10:41

Re: system starts, but display seems to deactivate

#89 2024-10-26 13:12:37

Re: system starts, but display seems to deactivate

#90 2024-10-26 14:03:50

Re: system starts, but display seems to deactivate

#91 2024-10-26 19:33:37

Re: system starts, but display seems to deactivate

#92 2024-10-26 19:58:58

Re: system starts, but display seems to deactivate

#93 2024-10-26 20:35:19

Re: system starts, but display seems to deactivate

#94 2024-10-26 21:02:27

Re: system starts, but display seems to deactivate

#95 2024-10-26 21:53:29

Re: system starts, but display seems to deactivate

#96 2024-10-26 21:55:52

Re: system starts, but display seems to deactivate

#97 2024-10-26 22:11:05

Re: system starts, but display seems to deactivate

#98 2024-10-26 22:11:49

Re: system starts, but display seems to deactivate

#99 2024-10-26 22:24:38

Re: system starts, but display seems to deactivate

#100 2024-10-26 22:47:09

Re: system starts, but display seems to deactivate

Board footer