Re: panic: Unaligned free (was: kernel panic while copying files)
On 0705T1833, Gary Jennejohn wrote: > On Mon, 5 Jul 2021 15:04:48 +0100 > Edward Tomasz Napiera__a wrote: > > > On 0701T1330, Gary Jennejohn wrote: > > > Gary Jennejohn wrote: > > > > I noticed that the value of vm.debug.divisor affects what value is > > > > returned in uma_core.c:uma_dbg_kskip(), so I decided to try a few > > > > different values. > > > > > > > > The returned value is used to set skipdbg in uma_core.c:item_dtor(). > > > > > > > > The default is vm.debug.divisor=1. > > > > > > > > vm.debug.divisor is only present when INVARIANTS is defined. > > > > > > > > kskipdbg eventually affects the value of freei. > > > > > > > > With these values: > > > > vm.debug.divisor: 0 > > > > kern.cam.da.enable_uma_ccbs: 1 > > > > I can turn on the disk and it comes up without a panic! > > > > > > > > However, I didn't try to do any large data transfers to the disk. > > > > > > > > So, it appears that at least vm.debug.divisor is a big factor in > > > > whether or not a panic happens with INVARIANTS. > > > > > > > > > > I decided to do a real test. So I built a kernel w/o INVARIANTS and > > > installed it to /boot/test. > > > > > > Then I stuck a 160GB disk I had around into an external USB3 enclosure > > > and put a filesystem on it. > > > > > > The I booted the new kernel from /boot/test and set the sysctls so: > > > kern.cam.da.enable_uma_ccbs: 1 > > > kern.cam.ada.enable_uma_ccbs: 1 > > > > > > After that I plugged in the external USB3 enclosure and copied about > > > 114GiB of data from an internal SSD to it - without a kernel panic: > > > FilesystemSizeUsed Avail Capacity Mounted on > > > /dev/da0p1144G114G 18G86%/mnt > > > > > > I'm pretty sure that's more than I could copy without a kernel panic > > > prior to the recent changes made in cam and umass. > > > > > > My test may not be real proof that all bugs have been squashed, but it > > > certainly seems to be a better situation than we had before. > > > > I think the vm.debug.divisor simply masks the problem; the underlying > > bug is still there. > > > > Could you go back to the setup which panics, and then test the patch > > at https://reviews.freebsd.org/D31054? It fixes the scenario described > > by Warner. > > > > It looks like this patch fixes things. > > I used the default value vm.debug.divisor=1 and both enable_uma_ccbs=1 > (which are now the default values on my system). > > I used the 8TiB disk, which spins up very slowly and usually resulted very > quickly in a panic - no panic with the patch. > > Then using dd to /dev/null (bs=1m) I transferred: > > 308755+0 records in > 308755+0 records out > 323753082880 bytes transferred in 1366.162410 secs (236979938 bytes/sec) > > from the disk, so about 324GiB without a panic. Perfect, I've committed the fix. Thank you!
Re: regression suspend/resume on Lenovo T420
On 0515T1256, Konstantin Belousov wrote:
> On Sun, May 14, 2017 at 08:02:52PM +, Poul-Henning Kamp wrote:
> >
> > In message <20170514193006.GA1298@brick>, Edward Tomasz
> > =?utf-8?Q?Napiera=C5=82
> > a?= writes:
> >
> > >I've tried to verify that, and sadly it wasn't it for me. The commit
> > >that does break resume for me is r316767. The current -CURRENT with
> > >this one commit reverted ("svn merge -c -r316767 .") suspends and resumes
> > >correctly, at least in VT; I decided to take X out of the picture for
> > >now.
> >
> > I can confirm that this also makes resume work on my T430s running:
> >
> > FreeBSD 12.0-CURRENT #0 r318250M amd64
>
> Try this. If it works, I will write a proper patch.
>
> diff --git a/sys/amd64/amd64/cpu_switch.S b/sys/amd64/amd64/cpu_switch.S
> index 33437ad16e6..9c0cd05ebea 100644
> --- a/sys/amd64/amd64/cpu_switch.S
> +++ b/sys/amd64/amd64/cpu_switch.S
> @@ -369,6 +369,11 @@ END(savectx)
> * Resuming processor state from pcb.
> */
> ENTRY(resumectx)
> + movl$MSR_EFER,%ecx
> + rdmsr
> + orl $EFER_NXE,%eax
> + wrmsr
> +
> /* Switch to KPML4phys. */
> movqKPML4phys,%rax
> movq%rax,%cr3
Thanks! The patch fixes resume for me, for both vt(4) and X11.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r298143: something wrong with autofs?
On 0506T1408, O. Hartmann wrote:
> Am Wed, 4 May 2016 20:41:51 +0200
> Edward Tomasz Napiera?a schrieb:
>
> > On 0503T1849, O. Hartmann wrote:
> > > Am Sun, 17 Apr 2016 12:39:44 +0200
> > > Edward Tomasz Napierała schrieb:
> > >
> > > > On 0417T1057, O. Hartmann wrote:
> > > > >
> > > > > Running FreeBSD 11.0-CURRENT #32 r298143: Sun Apr 17 09:48:26 CEST
> > > > > 2016 amd64, on
> > > > > both server and client, reveals today that AUTOFS seems not to work.
> > > > > Did something
> > > > > changed unnoticed?
> > > > >
> > > > > I realized, that no exported filesystem is bound so far. On the
> > > > > server's side,
> > > > > all
> > > >
> > > > "Bound"?
> > >
> > > ... means: the cleint does not mount/bind the NFS exported filesystem
> > > anymore.
> >
> > Ok.
> >
> > > > > daemons necessary are configured as they were before in a working
> > > > > state and as I
> > > > > can see so far, they are up and running and also listening to their
> > > > > sockets/IPs.
> > > >
> > > > Could you describe in more detail what are you seeing? Also, the usual
> > > > autofs
> > > > debugging technique ("pkill automountd && while :; do automountd -d;
> > > > done") might
> > > > sched some light.
> > >
> > > Well, I see nothing! That is my problem. I setup several NFSv4 exported
> > > filesystems
> > > which were mounted on demand via autofs - that workd. Since I do not
> > > use/need those
> > > filesystems on a dailt basis, I realized too late that in the meanwhile
> > > those
> > > filesystems are not present on the client (autofs) anymore. I'm not aware
> > > of having
> > > changed anything in the configuration and I didn't receive any heads-ups
> > > that
> > > essential changes had been made.
> >
> > Hm, it certainly seems weird. Are the autofs instances mounted where
> > there should be? Could you send me your /etc/auto_master, the maps,
> > and dmesg output? Thanks!
>
> Hello Edward,
>
> sorry for the late answer. I can not (I'm not allowed!) offer config data
> from any of the
> lab's/bureaus computers, so I decided to check again the whole config, since
> several
> boxes do as expected and others not (which is the weird part). I found a
> simple culprit:
> somewhere in the near past, /etc/auto_master received an update and I simply
> have
> overwritten the old one with the new one. So the autofs system never checked
> the exported
> filessystem's list given by a mandatory /etc/auto_ext file and in the logical
> consequence,
> no filesystem defined there was mounted.
>
> After simply adding the missing line the mounting of the expected filesystems
> worked
> again.
Huh, that explains. IIRC some time (few weeks?) ago there was a problem
in 11-CURRENT that made "make installworld" overwrite some of the config
files, as if there were binaries. Looks like you got bitten by this.
Let me know if you find anything else with autofs that looks suspicious.
Thanks :-)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r298143: something wrong with autofs?
On 0503T1849, O. Hartmann wrote:
> Am Sun, 17 Apr 2016 12:39:44 +0200
> Edward Tomasz Napierała schrieb:
>
> > On 0417T1057, O. Hartmann wrote:
> > >
> > > Running FreeBSD 11.0-CURRENT #32 r298143: Sun Apr 17 09:48:26 CEST 2016
> > > amd64, on
> > > both server and client, reveals today that AUTOFS seems not to work. Did
> > > something
> > > changed unnoticed?
> > >
> > > I realized, that no exported filesystem is bound so far. On the server's
> > > side, all
> >
> > "Bound"?
>
> ... means: the cleint does not mount/bind the NFS exported filesystem anymore.
Ok.
> > > daemons necessary are configured as they were before in a working state
> > > and as I can
> > > see so far, they are up and running and also listening to their
> > > sockets/IPs.
> >
> > Could you describe in more detail what are you seeing? Also, the usual
> > autofs
> > debugging technique ("pkill automountd && while :; do automountd -d; done")
> > might
> > sched some light.
>
> Well, I see nothing! That is my problem. I setup several NFSv4 exported
> filesystems which
> were mounted on demand via autofs - that workd. Since I do not use/need those
> filesystems
> on a dailt basis, I realized too late that in the meanwhile those filesystems
> are not
> present on the client (autofs) anymore. I'm not aware of having changed
> anything in the
> configuration and I didn't receive any heads-ups that essential changes had
> been made.
Hm, it certainly seems weird. Are the autofs instances mounted where
there should be? Could you send me your /etc/auto_master, the maps,
and dmesg output? Thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwn driver issue
On 0613T1058, David Wolfskill wrote:
> On Fri, Jun 13, 2014 at 12:34:00PM -0500, Adrian Chadd wrote:
> > This isn't this first time this has been reported, right?
> >
> > I think we may need to back this patch out until it's better resolved.
> >
>
> I normally don't spend a huge amount of time in head -- enough to build
> it & do a quick smoke-test. So it's certainly possible that it merits
> further exploration. And I'm willing experiment, but I cannot test it
> while I'm at work (as I don't use the wireless NIC at work -- I use it
> almost exclusively while I'm at home (and other places), though).
It would be great if you could help me with this. Basically you need
to enable crashdumps, as described below, and obtain a backtrace.
http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html
Just for the record, the easiest way to make iwn firmware panic
is to enter ddb (ctrl-alt-esc), wait five seconds and exit it
("c").
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
