Bug#980164: nicholas

2021-01-21 Thread Nicholas D Steeves
Hi Alain, alain writes: > I think I finally figured it out, Nicholas. > > Here is the report that you asked me (as root), nomodeset enabled > otherwise, I don't start. > > I will submit the idea of vincent (and you too, nicholas) in another bug > report for the kernel. Thank you for your

Bug#980164: tries resume

2021-01-20 Thread Nicholas D Steeves
Hi Alain and Vincent, Vincent Blut writes: > Hi Alain, > > Le 2021-01-20 12:52, alain a écrit : >> tried this : >> >> - firmware-amd-graphics 20201118-1 testing >> >> - firmware-amd-graphics 20201218-1 sid >> >> - firmware-amd-graphics 20201218-1 testing >> >> - firmware-amd-graphics

Bug#980164: firmware-amd-graphics: amd rx 6800 compatibility

2021-01-16 Thread Nicholas D Steeves
Hi, alain writes: > Package: firmware-amd-graphics > Version: 20201118-1 > Followup-For: Bug #980164 > X-Debbugs-Cc: compte.perso.de-al...@bbox.fr > > here is my last try . > > installed firmware-amd-graphics 20201118-1 (testing) > copied sienna_cichlid* from git . > > nothing . RX6800 support

Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

2021-01-12 Thread Nicholas D Steeves
Hi, Ryutaroh Matsumoto writes: > Hi Nicholas, > Thank you very much for your attention! > You're welcome :-) [snip] > Boot failures themselves are unreliable... > This is the key to the most important issue. To solve this bug, we will need to figure out the steps to reproduce it, and it's

Bug#977647: 5.10.1 Debian kernel does not boot on amd64 with btrfs rootfs

2020-12-18 Thread Nicholas D Steeves
Control: tag -1 moreinfo Control: severity -1 important Justification: does not affect all users Hi, Ryutaroh Matsumoto writes: > Package: linux-image-5.10.0-trunk-amd64-unsigned > Version: 5.10.1-1~exp1 > Severity: grave > Justification: renders package unusable > I just confirmed that

Re: Next Kernel update for Buster

2020-07-28 Thread Nicholas D Steeves
vincent.deb...@free.fr writes: > On 2020-07-28T17:47+0200, gianluca wrote: >>On 7/28/20 3:35 PM, Salvatore Bonaccorso wrote: Have a look at: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/nilfs2?h=v4.19.129=1b6f42200b8313d3895c26f6553bbc8380bf1c35

Re: Debian 10.0 works with 3rd generation Ryzen

2020-06-04 Thread Nicholas D Steeves
Hi, Michel Dänzer writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2020-05-31 12:16 a.m., Nicholas D Steeves wrote: >> Ben Hutchings writes: >>> >>> I believe the latest AMD *GPUs* won't work with Debian 10, >>> though. They requir

Re: Debian 10.0 works with 3rd generation Ryzen

2020-05-30 Thread Nicholas D Steeves
Hi, Ben Hutchings writes: > On Fri, 2020-05-29 at 15:00 +0100, Mick Ab wrote: >> https://www.phoronix.com/scan.php?page=article=3900x-linux-distros=1 >> >> The above article shows that Debian 10.0 will work with a third generation >> Ryzen CPU. >> >> I understood that the stable release of

Re: Recurrent alerts "Package temperature above threshold, cpu clock throttled"

2020-01-20 Thread Nicholas D Steeves
Hi L0f4r0, Ben (or other team members), if you're reading this and are short on time, would you please skip to the question at the bottom and reply to it? writes: > At least, Internet resources indicate that's it's safer this way with > HT deactivated (regarding MDS attacks) but I don't know

Bug#949256: linux-image-5.4.0-2-amd64: zram-tools blocks shutdown (regression since 5.2)

2020-01-19 Thread Nicholas D Steeves
Hi Nick, Nick Shaforostoff writes: > Package: src:linux > Version: 5.4.8-1 [snip] > either removing zram-tools package or using linux-image-5.2.0-3-amd64 @ > 5.2.17-1 > which I had before the dist-upgrade makes the problem go away. > > Since 5.4 changelog mentions zram, I suspect that it was the

Re: Recurrent alerts "Package temperature above threshold, cpu clock throttled"

2020-01-05 Thread Nicholas D Steeves
Hi l0f4r0, Reply follows inline. writes: > Hi team, > > Multiple times per hour (despite no notable CPU-consuming activity), I > get something like the following journalctl crit/2 entry: > > kernel: CPUX: Package temperature above threshold, cpu clock throttled > (total events = Y) where

Bug#941284: Wishlist/RFC: Use CONFIG_HZ=100 in linux-image-cloud-*

2019-09-27 Thread Nicholas D Steeves
Noah Meyerhans writes: > On Fri, Sep 27, 2019 at 01:15:29PM -0700, Flavio Veloso wrote: >> Since linux-image-cloud-* packages are created for cloud environments -- >> read: servers which do not need desktop-level responsiveness --, wouldn't it >> be beneficial to build the kernels with CONFIG_HZ

Bug#932159: drm:i915_gem_init_stolen *ERROR* Stolen reserved area outside stolen memory zone

2019-07-19 Thread Nicholas D Steeves
Update: Confirmed that enabling CSM does not solve this stolen memory issue. Additionally, neither does i915.fastboot=1 <- that one was only tried for the sake of completeness, because several forum posts said it did the trick. $ cat /proc/mtrr reg00: base=0x0 (0MB), size=32768MB,

Bug#932159: drm:i915_gem_init_stolen *ERROR* Stolen reserved area outside stolen memory zone

2019-07-19 Thread Nicholas D Steeves
Control: affects -1 linux-image-4.19.0-5-amd64 linux-image-4.19.0-1-amd64 linux-image-4.9.0-9-amd64 linux-image-4.9.0-1-amd64 Adding the specific kernel packages as well as attaching /proc/iomem the /proc/iomem output that is probably necessary to resolve this bug. Cheers, Nicholas

Bug#932159: drm:i915_gem_init_stolen *ERROR* Stolen reserved area outside stolen memory zone

2019-07-15 Thread Nicholas D Steeves
Package: src:linux Version: 4.19.37-5 Severity: normal Hi, I should have filed this bug two years ago, because I'm guessing a fix for this hardware requires an upstream quirk. I forget how old the original installation was...probably squeeze, but I upgraded to each stable release since then,

Bug#926967: Don't recommend irqbalance (was: Re: Handling irqbalance in virtual environments)

2019-04-14 Thread Nicholas D Steeves
On Fri, Apr 12, 2019 at 10:56:29PM +0200, Bastian Blank wrote: > > On Fri, 2019-04-12 at 10:53 +0200, Bastian Blank wrote: > > > It turns out we got again problems with irqbalance. > > > > > > It was added as recommends of the main image in 3.16, as it was reported > > > that older kernels move

Bug#908216: btrfs blocked for more than 120 seconds

2019-03-08 Thread Nicholas D Steeves
On Wed, Mar 06, 2019 at 07:55:45AM -0600, Russell Mosemann wrote: >The four most problematic servers were hanging nearly every day. They each >have a dedicated hard drive and are running 4.19.0-0.bpo.2-amd64. I >installed btrfs-progs 4.20.1 on each and recreated the file system on the

Bug#908216: btrfs blocked for more than 120 seconds

2019-03-02 Thread Nicholas D Steeves
On Sat, Mar 02, 2019 at 05:12:42PM -0600, Russell Mosemann wrote: >I used btrfs-progs (4.17-1~bpo9+1) from the backports repository, which >does have zstd support. btrfs-check does need zstd support. Otherwise, it >will error out with unsupported feature (10). > Unfortunately

Bug#908216: btrfs blocked for more than 120 seconds

2019-03-02 Thread Nicholas D Steeves
. On Tue, Feb 26, 2019 at 11:29:25AM -0600, Russell Mosemann wrote: >On Monday, February 25, 2019 10:17pm, "Nicholas D Steeves" > said: > >> On Mon, Feb 25, 2019 at 12:33:51PM -0600, Russell Mosemann wrote: >> > >In every case, th

Bug#908216: btrfs blocked for more than 120 seconds

2019-02-25 Thread Nicholas D Steeves
Control: tags -1 -unreproducible Hi Russell, Thank you for providing more info. Now I see where you're running into known limitations with btrfs (all versions). Reply follows inline. BTW, you're not using SMR and/or USB disks, right? On Mon, Feb 25, 2019 at 12:33:51PM -0600, Russell Mosemann

Bug#908216: btrfs blocked for more than 120 seconds

2019-02-24 Thread Nicholas D Steeves
Control: tags -1 + unreproducible moreinfo Hi Russell, On Sun, Feb 24, 2019 at 06:34:59PM -0600, Russell Mosemann wrote: > > >Package: src:linux >Version: 4.19.16-1~bpo9+1 >Severity: important > > > > > >If the btrfs fixes will not be backported to 4.19, then

Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178

2018-10-08 Thread Nicholas D Steeves
On Wed, Oct 03, 2018 at 09:56:13AM +, Michael Firth wrote: > > > > As far as I know, if 'btrfs check' is clean then you're in the clear for > > any known > > issues involving the fs structure. Of course, a 'btrfs scrub' is necessary > > to > > check for data and metadata corruption...

Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178

2018-10-08 Thread Nicholas D Steeves
Hi Hans, On Wed, Oct 03, 2018 at 12:05:31AM +0200, Hans van Kranenburg wrote: > Hi, > > On 10/02/2018 10:08 PM, Nicholas D Steeves wrote: > > Hi Michael, > > > > On Tue, Oct 02, 2018 at 11:37:45AM +0100, Michael Firth wrote: > >> > >> BTRFS may not b

Bug#910074: linux-image-4.9.0-8-amd64: BTRFS data loss - kernel BUG at .../linux-4.9.110/fs/btrfs/ctree.c:3178

2018-10-02 Thread Nicholas D Steeves
Hi Michael, On Tue, Oct 02, 2018 at 11:37:45AM +0100, Michael Firth wrote: > > After this, there was a file that was errored on the filesystem (as > reported by 'btrfs check'), and it seems BTRFS doesn't have any tools to > resolve the error. Deleting the file at the reported inode has cleared >

Bug#863290: src:linux: no warning that btrfs RAID5/6 is buggered up

2017-06-04 Thread Nicholas D Steeves
On 4 June 2017 at 05:46, Svein Engelsgjerd wrote: > > I would like voice my concern as well. Btrfs RAID5/6 really needs a warning. > These days most (if not all) of the problems you see with Btrfs is caused by > the unstable features

Re: Next d-i alpha release: late June

2016-06-28 Thread Nicholas D Steeves
On 24 June 2016 at 18:22, Cyril Brulebois wrote: > Hi, > > I've just checked with Ben, it seems we could be getting a 4.6 kernel > suitable for testing (no regressions reported from previous version + > mips* FTBFS fix) shortly. We could think about urgenting it into testing >

Bug#821308: Bug doesn't appear in 4.5.4-1

2016-06-05 Thread Nicholas D Steeves
control: notfound -1 linux/4.3.5-1 control: fixed -1 linux/4.5.0-2 Hi Markus, Thank you for the confirmation! :-) Cheers, Nicholas

Re: LTS kernel in jessie-backports

2016-05-31 Thread Nicholas D Steeves
Hi Sebastian, On 24 May 2016 at 23:35, Sebastian Kuzminsky wrote: > On 05/24/2016 08:23 PM, Ben Hutchings wrote: > > I maintain forks of debian kernels for the LinuxCNC project. The workflow i > use may be useful to you if you want to maintain your own fork, Nicholas. > As Ben

Re: LTS kernel in jessie-backports

2016-05-31 Thread Nicholas D Steeves
On 24 May 2016 at 22:23, Ben Hutchings <b...@decadent.org.uk> wrote: > On Tue, 2016-05-24 at 21:51 -0400, Nicholas D Steeves wrote: >> Dear Debian Kernel Team, >> >> My primary area of interest is btrfs on Debian. The most reliable way >> of limiting one's risk w

Bug#821308: Bug doesn't appear in 4.3.5-1

2016-05-30 Thread Nicholas D Steeves
Hi Markus, Just to confirm, a downgrade to linux-image-4.3.5-1 fixed this? Is it also fixed in one of linux-image-4.5.3-1, 4.5.4-1, or 4.5.5-1 (if you're running unstable)? Thanks, Nicholas

Re: VM crashes with linux-image-4.5.0-0.bpo.2-amd64:amd64/jessie-backports on KVM-Host

2016-05-30 Thread Nicholas D Steeves
Hi Rolf, "On 30 May 2016 at 03:32, Rolf Kutz wrote: > > After installing linux-image-4.5.0-0.bpo.2-amd64 on my KVM Host, I > experience > problems with a virtual machine. The virtual machine starts up ok moѕt of > the > time, but crashes after rebooting the VM. Switching the VM

LTS kernel in jessie-backports

2016-05-24 Thread Nicholas D Steeves
Dear Debian Kernel Team, My primary area of interest is btrfs on Debian. The most reliable way of limiting one's risk while using this experimental file system is to run the most recent LTS kernel, and to minimize the use of exotic features, or in some cases not use them at all (eg: RAID56 which