sdhci timeout on wakeup
Hello Any time I wake my laptop from sleep, I get these errors a dozen times on the console. sdhci_pci0-slot0: Controller timeout sdhci_pci0-slot0: == REGISTER DUMP == sdhci_pci0-slot0: Sys addr: 0x | Version: 0xc001 sdhci_pci0-slot0: Blk size: 0x | Blk cnt: 0x sdhci_pci0-slot0: Argument: 0x | Trn mode: 0x sdhci_pci0-slot0: Present: 0x01f7 | Host ctl: 0x0001 sdhci_pci0-slot0: Power:0x000f | Blk gap: 0x sdhci_pci0-slot0: Wake-up: 0x | Clock:0x4007 sdhci_pci0-slot0: Timeout: 0x | Int stat: 0x0001 sdhci_pci0-slot0: Int enab: 0x01ff00fb | Sig enab: 0x01ff00fb sdhci_pci0-slot0: AC12 err: 0x | Host ctl2:0x sdhci_pci0-slot0: Caps: 0x21fe32b2 | Caps2:0x0077 sdhci_pci0-slot0: Max curr: 0x0064 | ADMA err: 0x sdhci_pci0-slot0: ADMA addr:0x | Slot int: 0x0001 sdhci_pci0-slot0: === Eventually it stops and then everything is working without issues, the annoying part is that it takes a few minutes to wake. This is running current at r367762, however this issue lasts since sleeping with drm started working for me a few months ago. The laptop is a Latitude E5430 booting through UEFI. The sd slot is empty. Anything I could do to prevent this from happening? 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: objcopy "text file busy" build failure with populated /usr/obj
Le dim. 20 sept. 2020 à 16:59, Mark Murray a écrit :
>
> Hi *
>
> I've been getting these build failures for a while (weeks/months). The
> machine is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and
> zfs filesystem. If I empty out /usr/obj, then the build works, but takes a
> few hours. If I do a no-clean build with /obj/obj populated with he contents
> of a previous build, and /usr/src with updated ("svn update") sources, then
> the below nearly always happens early in the rebuild. It is in "stage 4.4:
> building everything" that this happens. The build is parallel (-j8), and I
> have manually de-threaded the output.
>
> The generated command-line from the logfile is:
>
> cd /usr/src; _PARALLEL_SUBDIR_OK=1 MACHINE_ARCH=aarch64 MACHINE=arm64
> CPUTYPE=cortex-a72 CC="/usr/local/bin/ccache cc -target
> aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++
> -target aarch64-unknown-freebsd13.0
> --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" CPP="cpp -target
> aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp
> -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin" AS="as" AR="ar" LD="ld"
> LLVM_LINK="" NM=nm OBJCOPY="objcopy" RANLIB=ranlib STRINGS= SIZE="size"
> STRIPBIN="strip" INSTALL="install -U"
> PATH=/usr/obj/usr/src/arm64.aarch64/tmp/bin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/sbin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/usr/src/arm64.aarch64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
> SYSROOT=/usr/obj/usr/src/arm64.aarch64/tmp make -f Makefile.inc1
> BWPHASE=everything DESTDIR=/usr/obj/usr/src/arm64.aarch64/tmp all
>
> Anyone else seeing this?
>
> objcopy --strip-debug --add-gnu-debuglink=objcopy.debug objcopy.full objcopy
> objcopy: open objcopy failed: Text file busy
> --- all_subdir_usr.bin/objcopy ---
> *** [objcopy] Error code 1
>
> make[4]: stopped in /usr/src/usr.bin/objcopy
>
> M
> --
Hi
I got the same on amd64 with a meta mode build, on zfs as well. Oddly
(or not), it happens only if I make buildworld as a normal user, but
not as root. A second make buildworld always succeed.
___
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"
Regression with revision 303970 (was kern.proc.pathname failure while booting from zfs)
2016-08-25 13:29 GMT+02:00 Frederic Chardon <chardon.frede...@gmail.com>:
>
> Le 23 août 2016 20:24, "Frederic Chardon" <chardon.frede...@gmail.com> a
> écrit :
>>
>> 2016-08-23 19:35 GMT+02:00 Frederic Chardon <chardon.frede...@gmail.com>:
>> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kostik...@gmail.com>:
>> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon"
>> >>> <chardon.frede...@gmail.com> a
>> >>> ??crit :
>> >>> >
>> >>> > Hi
>> >>> >
>> >>> > I see a strange interaction between zfs on root and
>> >>> > kern.proc.pathname
>> >>> > on my laptop. Whenever I try to use gcore it fails with:
>> >>> > gcore 1023
>> >>> > gcore: kern.proc.pathname failure
>> >>> >
>> >>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>> >>> >
>> >>> > I made some tests booting from usb stick (fresh installworld, no
>> >>> > src.conf, no make.conf, GENERIC kernel)
>> >>> > What works: having / on ufs and importing a zfs pool later on.
>> >>> > What doesn't: having / on zfs, whatever the settings for checksum,
>> >>> > compression, or normalization.
>> >>> >
>> >>> > Both 11-stable and 12-current behave this way. Current from may-june
>> >>> > worked properly.
>> >>> > adb, chromium and virtualbox as well stopped working at
>> >>> > approximately
>> >>> > the same time, however I don't know if it is linked ("truss -f adb
>> >>> > start-server" shows that garbage is passed to execl after forking).
>> >>> >
>> >>> > Any idea what's going on? Does anybody else see this?
>> >>> >
>> >>> > Thanks!
>> >>>
>> >>> Nobody else have this problem? I reinstalled the system from scratch
>> >>> and
>> >>> still gcore fails with the same error, even in single user mode.
>> >>
>> >> Do you have a property on your root fs which forces it to ignore case
>> >> in
>> >> the file names ?
>> >
>> > No. I do have normalization set to formC though. I observed the same
>> > behavior with the property unset (in fact, with no property set to
>> > anything but default as well).
>> > If I boot from usb stick and import the pool afterwards it works
>> > properly.
>> >
>> > zpool get all zbase
>> > NAME PROPERTY VALUE
>> > SOURCE
>> > zbase size 9,94G -
>> > zbase capacity 43%-
>> > zbase altroot-
>> > default
>> > zbase health ONLINE -
>> > zbase guid 8964242380523899513
>> > default
>> > zbase version-
>> > default
>> > zbase bootfs zbase/bootenv/11-STABLE
>> > local
>> > zbase delegation on
>> > default
>> > zbase autoreplaceoff
>> > default
>> > zbase cachefile -
>> > default
>> > zbase failmode wait
>> > default
>> > zbase listsnapshots off
>> > default
>> > zbase autoexpand off
>> > default
>> > zbase dedupditto 0
>> > default
>> > zbase dedupratio 1.00x -
>> > zbase free 5,65G -
>> > zbase allocated 4,29G -
>> > zbase readonly off-
>> > zbase comment-
>> > default
>> > zbase expandsize - -
>> > zbase freeing0
>> > default
>> > zbase fragmentation 41%-
>> > zbase leaked 0
>> > default
>> > zbase feature@async_destroy enable
Re: kern.proc.pathname failure while booting from zfs
Le 23 août 2016 20:24, "Frederic Chardon" <chardon.frede...@gmail.com> a
écrit :
>
> 2016-08-23 19:35 GMT+02:00 Frederic Chardon <chardon.frede...@gmail.com>:
> > 2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kostik...@gmail.com>:
> >> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
> >>> Le 20 ao??t 2016 22:03, "Frederic Chardon" <chardon.frede...@gmail.com>
a
> >>> ??crit :
> >>> >
> >>> > Hi
> >>> >
> >>> > I see a strange interaction between zfs on root and
kern.proc.pathname
> >>> > on my laptop. Whenever I try to use gcore it fails with:
> >>> > gcore 1023
> >>> > gcore: kern.proc.pathname failure
> >>> >
> >>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
> >>> >
> >>> > I made some tests booting from usb stick (fresh installworld, no
> >>> > src.conf, no make.conf, GENERIC kernel)
> >>> > What works: having / on ufs and importing a zfs pool later on.
> >>> > What doesn't: having / on zfs, whatever the settings for checksum,
> >>> > compression, or normalization.
> >>> >
> >>> > Both 11-stable and 12-current behave this way. Current from may-june
> >>> > worked properly.
> >>> > adb, chromium and virtualbox as well stopped working at
approximately
> >>> > the same time, however I don't know if it is linked ("truss -f adb
> >>> > start-server" shows that garbage is passed to execl after forking).
> >>> >
> >>> > Any idea what's going on? Does anybody else see this?
> >>> >
> >>> > Thanks!
> >>>
> >>> Nobody else have this problem? I reinstalled the system from scratch
and
> >>> still gcore fails with the same error, even in single user mode.
> >>
> >> Do you have a property on your root fs which forces it to ignore case
in
> >> the file names ?
> >
> > No. I do have normalization set to formC though. I observed the same
> > behavior with the property unset (in fact, with no property set to
> > anything but default as well).
> > If I boot from usb stick and import the pool afterwards it works
properly.
> >
> > zpool get all zbase
> > NAME PROPERTY VALUE
SOURCE
> > zbase size 9,94G -
> > zbase capacity 43%-
> > zbase altroot-
default
> > zbase health ONLINE -
> > zbase guid 8964242380523899513
default
> > zbase version-
default
> > zbase bootfs zbase/bootenv/11-STABLE
local
> > zbase delegation on
default
> > zbase autoreplaceoff
default
> > zbase cachefile -
default
> > zbase failmode wait
default
> > zbase listsnapshots off
default
> > zbase autoexpand off
default
> > zbase dedupditto 0
default
> > zbase dedupratio 1.00x -
> > zbase free 5,65G -
> > zbase allocated 4,29G -
> > zbase readonly off-
> > zbase comment-
default
> > zbase expandsize - -
> > zbase freeing0
default
> > zbase fragmentation 41%-
> > zbase leaked 0
default
> > zbase feature@async_destroy enabled
local
> > zbase feature@empty_bpobjactive
local
> > zbase feature@lz4_compress active
local
> > zbase feature@multi_vdev_crash_dump enabled
local
> > zbase feature@spacemap_histogram active
local
> > zbase feature@enabled_txgactive
local
> > zbase feature@hole_birth active
local
> > zbase feature@extensible_dataset enabled
local
> > zbase feature@embedded_data active
local
> > zbase feature@bookmarks enabled
local
> > zbase feature@filesystem_limits enabled
local
> > zbase feature@large_blocks enabled
local
> > zb
Re: kern.proc.pathname failure while booting from zfs
2016-08-23 19:35 GMT+02:00 Frederic Chardon <chardon.frede...@gmail.com>:
> 2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kostik...@gmail.com>:
>> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>>> Le 20 ao??t 2016 22:03, "Frederic Chardon" <chardon.frede...@gmail.com> a
>>> ??crit :
>>> >
>>> > Hi
>>> >
>>> > I see a strange interaction between zfs on root and kern.proc.pathname
>>> > on my laptop. Whenever I try to use gcore it fails with:
>>> > gcore 1023
>>> > gcore: kern.proc.pathname failure
>>> >
>>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>>> >
>>> > I made some tests booting from usb stick (fresh installworld, no
>>> > src.conf, no make.conf, GENERIC kernel)
>>> > What works: having / on ufs and importing a zfs pool later on.
>>> > What doesn't: having / on zfs, whatever the settings for checksum,
>>> > compression, or normalization.
>>> >
>>> > Both 11-stable and 12-current behave this way. Current from may-june
>>> > worked properly.
>>> > adb, chromium and virtualbox as well stopped working at approximately
>>> > the same time, however I don't know if it is linked ("truss -f adb
>>> > start-server" shows that garbage is passed to execl after forking).
>>> >
>>> > Any idea what's going on? Does anybody else see this?
>>> >
>>> > Thanks!
>>>
>>> Nobody else have this problem? I reinstalled the system from scratch and
>>> still gcore fails with the same error, even in single user mode.
>>
>> Do you have a property on your root fs which forces it to ignore case in
>> the file names ?
>
> No. I do have normalization set to formC though. I observed the same
> behavior with the property unset (in fact, with no property set to
> anything but default as well).
> If I boot from usb stick and import the pool afterwards it works properly.
>
> zpool get all zbase
> NAME PROPERTY VALUE SOURCE
> zbase size 9,94G -
> zbase capacity 43%-
> zbase altroot- default
> zbase health ONLINE -
> zbase guid 8964242380523899513default
> zbase version- default
> zbase bootfs zbase/bootenv/11-STABLElocal
> zbase delegation on default
> zbase autoreplaceoffdefault
> zbase cachefile - default
> zbase failmode wait default
> zbase listsnapshots offdefault
> zbase autoexpand offdefault
> zbase dedupditto 0 default
> zbase dedupratio 1.00x -
> zbase free 5,65G -
> zbase allocated 4,29G -
> zbase readonly off-
> zbase comment- default
> zbase expandsize - -
> zbase freeing0 default
> zbase fragmentation 41%-
> zbase leaked 0 default
> zbase feature@async_destroy enabledlocal
> zbase feature@empty_bpobjactive local
> zbase feature@lz4_compress active local
> zbase feature@multi_vdev_crash_dump enabledlocal
> zbase feature@spacemap_histogram active local
> zbase feature@enabled_txgactive local
> zbase feature@hole_birth active local
> zbase feature@extensible_dataset enabledlocal
> zbase feature@embedded_data active local
> zbase feature@bookmarks enabledlocal
> zbase fe
Re: kern.proc.pathname failure while booting from zfs
2016-08-23 9:35 GMT+02:00 Konstantin Belousov <kostik...@gmail.com>:
> On Tue, Aug 23, 2016 at 09:27:56AM +0200, Frederic Chardon wrote:
>> Le 20 ao??t 2016 22:03, "Frederic Chardon" <chardon.frede...@gmail.com> a
>> ??crit :
>> >
>> > Hi
>> >
>> > I see a strange interaction between zfs on root and kern.proc.pathname
>> > on my laptop. Whenever I try to use gcore it fails with:
>> > gcore 1023
>> > gcore: kern.proc.pathname failure
>> >
>> > However, gcore /usr/local/bin/zsh 1023 is working properly.
>> >
>> > I made some tests booting from usb stick (fresh installworld, no
>> > src.conf, no make.conf, GENERIC kernel)
>> > What works: having / on ufs and importing a zfs pool later on.
>> > What doesn't: having / on zfs, whatever the settings for checksum,
>> > compression, or normalization.
>> >
>> > Both 11-stable and 12-current behave this way. Current from may-june
>> > worked properly.
>> > adb, chromium and virtualbox as well stopped working at approximately
>> > the same time, however I don't know if it is linked ("truss -f adb
>> > start-server" shows that garbage is passed to execl after forking).
>> >
>> > Any idea what's going on? Does anybody else see this?
>> >
>> > Thanks!
>>
>> Nobody else have this problem? I reinstalled the system from scratch and
>> still gcore fails with the same error, even in single user mode.
>
> Do you have a property on your root fs which forces it to ignore case in
> the file names ?
No. I do have normalization set to formC though. I observed the same
behavior with the property unset (in fact, with no property set to
anything but default as well).
If I boot from usb stick and import the pool afterwards it works properly.
zpool get all zbase
NAME PROPERTY VALUE SOURCE
zbase size 9,94G -
zbase capacity 43%-
zbase altroot- default
zbase health ONLINE -
zbase guid 8964242380523899513default
zbase version- default
zbase bootfs zbase/bootenv/11-STABLElocal
zbase delegation on default
zbase autoreplaceoffdefault
zbase cachefile - default
zbase failmode wait default
zbase listsnapshots offdefault
zbase autoexpand offdefault
zbase dedupditto 0 default
zbase dedupratio 1.00x -
zbase free 5,65G -
zbase allocated 4,29G -
zbase readonly off-
zbase comment- default
zbase expandsize - -
zbase freeing0 default
zbase fragmentation 41%-
zbase leaked 0 default
zbase feature@async_destroy enabledlocal
zbase feature@empty_bpobjactive local
zbase feature@lz4_compress active local
zbase feature@multi_vdev_crash_dump enabledlocal
zbase feature@spacemap_histogram active local
zbase feature@enabled_txgactive local
zbase feature@hole_birth active local
zbase feature@extensible_dataset enabledlocal
zbase feature@embedded_data active local
zbase feature@bookmarks enabledlocal
zbase feature@filesystem_limits enabledlocal
zbase feature@large_blocks enabledlocal
zbase feature@sha512 enabledlocal
zbase feature@skein enabledlocal
zfs get all zbase/bootenv/11-STABLE
NAME PROPERTY VALUE SOURCE
zbase/bootenv/11-STABLE
Re: kern.proc.pathname failure while booting from zfs
Le 20 août 2016 22:03, "Frederic Chardon" <chardon.frede...@gmail.com> a
écrit :
>
> Hi
>
> I see a strange interaction between zfs on root and kern.proc.pathname
> on my laptop. Whenever I try to use gcore it fails with:
> gcore 1023
> gcore: kern.proc.pathname failure
>
> However, gcore /usr/local/bin/zsh 1023 is working properly.
>
> I made some tests booting from usb stick (fresh installworld, no
> src.conf, no make.conf, GENERIC kernel)
> What works: having / on ufs and importing a zfs pool later on.
> What doesn't: having / on zfs, whatever the settings for checksum,
> compression, or normalization.
>
> Both 11-stable and 12-current behave this way. Current from may-june
> worked properly.
> adb, chromium and virtualbox as well stopped working at approximately
> the same time, however I don't know if it is linked ("truss -f adb
> start-server" shows that garbage is passed to execl after forking).
>
> Any idea what's going on? Does anybody else see this?
>
> Thanks!
Nobody else have this problem? I reinstalled the system from scratch and
still gcore fails with the same error, even in single user mode.
___
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"
kern.proc.pathname failure while booting from zfs
Hi
I see a strange interaction between zfs on root and kern.proc.pathname
on my laptop. Whenever I try to use gcore it fails with:
gcore 1023
gcore: kern.proc.pathname failure
However, gcore /usr/local/bin/zsh 1023 is working properly.
I made some tests booting from usb stick (fresh installworld, no
src.conf, no make.conf, GENERIC kernel)
What works: having / on ufs and importing a zfs pool later on.
What doesn't: having / on zfs, whatever the settings for checksum,
compression, or normalization.
Both 11-stable and 12-current behave this way. Current from may-june
worked properly.
adb, chromium and virtualbox as well stopped working at approximately
the same time, however I don't know if it is linked ("truss -f adb
start-server" shows that garbage is passed to execl after forking).
Any idea what's going on? Does anybody else see this?
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"
