Re: Building freebsd on another OS
On Tue, Mar 19, 2019 at 2:04 AM Eric Joyner wrote: > On Sun, Mar 17, 2019 at 6:35 AM Hans Petter Selasky > wrote: > > > > > See the freebsd-build utils package for Linux. > > > > --HPS > > > > > Is there anything for Windows? > > > FreeBSD uses ELF binaries. Microsoft's compilers only generate PE binaries. Cygwin also generates PE binaries, optionally linked to its libraries. Mingw and mingw-w64, same story. You need some sort of cross-compiler that generates ELF binaries. That new "Windows Subsystem for Linux" (WSL) found on Windows 10 might be a good starting point, as it uses ELF binaries natively, and its C compiler (GCC?) presumably generates ELF. ___ 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: leaked swap?
In message <2b27d1b6-b956-c27e-709b-08fa5d54e...@freebsd.org>, Andriy Gapon writes: > On 18/03/2019 17:30, Cy Schubert wrote: > > Top did not report any swap used by git and GB of swap were used. > > Last time I checked top reported something very different as swap. > IIRC, its notion of swap usage comes from the age when the swap granularity > was > a whole process. OK, in the strictest sense. The BSD definition of swap is the same as IBM's z/OS, a whole address space. ___ 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: Building freebsd on another OS
On Sun, Mar 17, 2019 at 6:35 AM Hans Petter Selasky wrote: > > See the freebsd-build utils package for Linux. > > --HPS > > Is there anything for Windows? - Eric ___ 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: leaked swap?
On 18/03/2019 20:01, Andrey Fesenko wrote: > Not this? ZFS use wired and not clean only reboot? > https://reviews.freebsd.org/D7538?id=25108 Wired memory surely has nothing to do with swap. -- Andriy Gapon ___ 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: Switching fb backend back to default
On Mon, Mar 18, 2019 at 19:48 Oliver Pinter wrote: > > > On Sunday, March 17, 2019, Johannes Lundberg wrote: > >> On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot >> wrote: >> >> > On Sun, 17 Mar 2019 16:32:43 + >> > Johannes Lundberg wrote: >> > >> > > >> > > On 3/17/19 3:34 PM, Greg V wrote: >> > > > >> > > > >> > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg >> > > > wrote: >> > > >> Hi >> > > >> >> > > >> I'm working on making i915kms unload properly. I've come to what I >> > think >> > > >> is the last issue. The drm driver unloads ok, the "efifb" backend >> is >> > > >> restored (according to logs) and vt_efifb_init() is being called >> but >> > the >> > > >> screen (laptop built in display) stays black. The system seems >> > > >> operational otherwise. If I load i915kms again in this state I get >> > back >> > > >> a visible (i915kms) framebuffer. >> > > >> >> > > >> Did we ever have this working so it's known to work? >> > > > >> > > > Recently on the linux kernel mailing list: >> > > > >> > > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html >> > > > >> > > > > Of course, once native drivers like i915 or radeon take over, >> such a >> > > > framebuffer is toast... [6] >> > > > >> > > > > [6] >> > linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() >> > > > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() >> > > > >> > > > So it seems like efifb is not supposed to work after a driver has >> been >> > > > loaded at least once. >> > > > >> > > > >> > > Hmm, well the code is there to handle switching back to the boot time >> > > fb. What I think is happening is that i915 powers off the displays at >> > > unload and vt doesn't know how to power on (or that it should). >> > > >> > >> > That and if the display pipeline is de-configured or the resolution >> > changed you cannot reset it to the original state. >> > Unloading drm modules is only useful for testing (and finding leaks). >> >> >> Yeah a normal user would never unload it. Since I mostly ssh to my test >> machines I think I’m fine personally with losing the display while >> unloading. >> >> Keyboard input still works though and at least it doesn’t crash anymore :) > > > > As workaround, can't you turn on the display with intel_backlight? > AFAIK, that can only adjust brightness. The display panel is completely shut off. >> >> > >> > > >> > > ___ >> > > 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" >> > >> > >> > -- >> > Emmanuel Vadot >> > >> ___ >> 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 >> " >> > ___ 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: Switching fb backend back to default
On Mon, Mar 18, 2019 at 19:28 Pete Wright wrote: > > > On 3/17/19 2:50 PM, Johannes Lundberg wrote: > > On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot > wrote: > > > >> On Sun, 17 Mar 2019 16:32:43 + > >> Johannes Lundberg wrote: > >> > >>> On 3/17/19 3:34 PM, Greg V wrote: > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > wrote: > > Hi > > > > I'm working on making i915kms unload properly. I've come to what I > >> think > > is the last issue. The drm driver unloads ok, the "efifb" backend is > > restored (according to logs) and vt_efifb_init() is being called but > >> the > > screen (laptop built in display) stays black. The system seems > > operational otherwise. If I load i915kms again in this state I get > >> back > > a visible (i915kms) framebuffer. > > > > Did we ever have this working so it's known to work? > Recently on the linux kernel mailing list: > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html > > > Of course, once native drivers like i915 or radeon take over, such a > framebuffer is toast... [6] > > > [6] > >> linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() > So it seems like efifb is not supposed to work after a driver has been > loaded at least once. > > > >>> Hmm, well the code is there to handle switching back to the boot time > >>> fb. What I think is happening is that i915 powers off the displays at > >>> unload and vt doesn't know how to power on (or that it should). > >>> > >> That and if the display pipeline is de-configured or the resolution > >> changed you cannot reset it to the original state. > >> Unloading drm modules is only useful for testing (and finding leaks). > > > > Yeah a normal user would never unload it. Since I mostly ssh to my test > > machines I think I’m fine personally with losing the display while > > unloading. > > > > Keyboard input still works though and at least it doesn’t crash anymore > :) > > > > that's awesome, so in theory we will be able to upgrade the drm-kmod and > use the new driver without a reboot. i like that as a hacker and > end-user You probably have to exit X to unload the driver so I’m not sure it’s that much better than a reboot :) Either way, it will make simple testing a lot easier. > > -pete > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ 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: Switching fb backend back to default
On Sunday, March 17, 2019, Johannes Lundberg wrote: > On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot > wrote: > > > On Sun, 17 Mar 2019 16:32:43 + > > Johannes Lundberg wrote: > > > > > > > > On 3/17/19 3:34 PM, Greg V wrote: > > > > > > > > > > > > On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg > > > > wrote: > > > >> Hi > > > >> > > > >> I'm working on making i915kms unload properly. I've come to what I > > think > > > >> is the last issue. The drm driver unloads ok, the "efifb" backend is > > > >> restored (according to logs) and vt_efifb_init() is being called but > > the > > > >> screen (laptop built in display) stays black. The system seems > > > >> operational otherwise. If I load i915kms again in this state I get > > back > > > >> a visible (i915kms) framebuffer. > > > >> > > > >> Did we ever have this working so it's known to work? > > > > > > > > Recently on the linux kernel mailing list: > > > > > > > > http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html > > > > > > > > > Of course, once native drivers like i915 or radeon take over, such > a > > > > framebuffer is toast... [6] > > > > > > > > > [6] > > linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() > > > > > linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() > > > > > > > > So it seems like efifb is not supposed to work after a driver has > been > > > > loaded at least once. > > > > > > > > > > > Hmm, well the code is there to handle switching back to the boot time > > > fb. What I think is happening is that i915 powers off the displays at > > > unload and vt doesn't know how to power on (or that it should). > > > > > > > That and if the display pipeline is de-configured or the resolution > > changed you cannot reset it to the original state. > > Unloading drm modules is only useful for testing (and finding leaks). > > > Yeah a normal user would never unload it. Since I mostly ssh to my test > machines I think I’m fine personally with losing the display while > unloading. > > Keyboard input still works though and at least it doesn’t crash anymore :) As workaround, can't you turn on the display with intel_backlight? > > > > > > > > > > ___ > > > 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" > > > > > > -- > > Emmanuel Vadot > > > ___ > 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" > ___ 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: Switching fb backend back to default
On 3/17/19 2:50 PM, Johannes Lundberg wrote: On Sun, Mar 17, 2019 at 21:35 Emmanuel Vadot wrote: On Sun, 17 Mar 2019 16:32:43 + Johannes Lundberg wrote: On 3/17/19 3:34 PM, Greg V wrote: On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg wrote: Hi I'm working on making i915kms unload properly. I've come to what I think is the last issue. The drm driver unloads ok, the "efifb" backend is restored (according to logs) and vt_efifb_init() is being called but the screen (laptop built in display) stays black. The system seems operational otherwise. If I load i915kms again in this state I get back a visible (i915kms) framebuffer. Did we ever have this working so it's known to work? Recently on the linux kernel mailing list: http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html Of course, once native drivers like i915 or radeon take over, such a framebuffer is toast... [6] [6] linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb() linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe() So it seems like efifb is not supposed to work after a driver has been loaded at least once. Hmm, well the code is there to handle switching back to the boot time fb. What I think is happening is that i915 powers off the displays at unload and vt doesn't know how to power on (or that it should). That and if the display pipeline is de-configured or the resolution changed you cannot reset it to the original state. Unloading drm modules is only useful for testing (and finding leaks). Yeah a normal user would never unload it. Since I mostly ssh to my test machines I think I’m fine personally with losing the display while unloading. Keyboard input still works though and at least it doesn’t crash anymore :) that's awesome, so in theory we will be able to upgrade the drm-kmod and use the new driver without a reboot. i like that as a hacker and end-user :) -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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: leaked swap?
On Mon, Mar 18, 2019 at 6:23 PM Andriy Gapon wrote: > > > First, a note that this was observed on a system that runs a fairly old > current > (~ 1 year old) with a fairly long uptime (> 6 months). > I noticed that the system was nearly out of memory, 98% of swap was in use, > there was less than 1 GB of free memory, several GBs of each of active, > inactive > and laundry memory, and many GBs of wired (mostly ZFS). > I decided to pro-actively reboot the system, but to speed that up I put the > system to the single-user mode (via shutdown) and then back to multi-user. So, > there was no real hardware reboot and the kernel kept running. However, all > userland processes were terminated. > > To my surprise, even while in the single-user mode the swap utilization didn't > go below 70%. Also, laundry memory remained in multi-GB area, but let's > ignore > this for now. > > I think that the swap could be used only for anonymous memory, so I expected > it > go to zero after the shutdown to the single user mode. > Does anyone have any ideas? > Maybe that's something that has already been fixed? > If not, any ideas on what to look for? > Thanks! > Not this? ZFS use wired and not clean only reboot? https://reviews.freebsd.org/D7538?id=25108 ___ 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: leaked swap?
On March 18, 2019 8:57:03 AM PDT, Andriy Gapon wrote: >On 18/03/2019 17:55, Alan Somers wrote: >> Try "ipcs -a" > >Thank you. I will do it while in the single-user again. Right now it's >too long >a list. Shared memory segments are not necessarily deleted by applications. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: leaked swap?
On 18/03/2019 17:55, Alan Somers wrote: > Try "ipcs -a" Thank you. I will do it while in the single-user again. Right now it's too long a list. -- Andriy Gapon ___ 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: leaked swap?
On Mon, Mar 18, 2019 at 9:38 AM Andriy Gapon wrote: > > On 18/03/2019 17:32, Konstantin Belousov wrote: > > On Mon, Mar 18, 2019 at 05:20:35PM +0200, Andriy Gapon wrote: > >> > >> First, a note that this was observed on a system that runs a fairly old > >> current > >> (~ 1 year old) with a fairly long uptime (> 6 months). > >> I noticed that the system was nearly out of memory, 98% of swap was in use, > >> there was less than 1 GB of free memory, several GBs of each of active, > >> inactive > >> and laundry memory, and many GBs of wired (mostly ZFS). > >> I decided to pro-actively reboot the system, but to speed that up I put the > >> system to the single-user mode (via shutdown) and then back to multi-user. > >> So, > >> there was no real hardware reboot and the kernel kept running. However, > >> all > >> userland processes were terminated. > >> > >> To my surprise, even while in the single-user mode the swap utilization > >> didn't > >> go below 70%. Also, laundry memory remained in multi-GB area, but let's > >> ignore > >> this for now. > >> > >> I think that the swap could be used only for anonymous memory, so I > >> expected it > >> go to zero after the shutdown to the single user mode. > >> Does anyone have any ideas? > >> Maybe that's something that has already been fixed? > >> If not, any ideas on what to look for? > > tmpfs, swap-backed (or even memory backed) md, persistent posix shared > > memory, SysV shared memory. > > > > Thank you. > There is a single tmpfs mount: > $ df -t tmpfs -h > FilesystemSizeUsed Avail Capacity Mounted on > tmpfs 1.0G4.0K1.0G 0%/tmp/tmp > > No md devices at all according to mdconfig. > > Not sure how to check for the shared memory though. Try "ipcs -a" ___ 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: Use mic from headphone jack on freebsd laptop?
Hi Johannes,
I have been wanting the exact same thing on my laptop, so I have been
digging around in the hda code.
I have got to the point where I can use the headset mic, but I have to
manually switch from the internal one.
There is no configuration magic, I had to patch the driver.
It seems nearly impossible to find docs on Realtek codecs, I have looked
at what Linux does in their driver.
They change some mysterious registers in the codec, so I my patch just
does the same.
Which codec do you have? I have the ALC283 ('cat /dev/sndstat' should
tell you)
Jakob
On 3/18/19 4:02 PM, Johannes Lundberg wrote:
Hi
On my Dell laptop the output audio switches to the headphones
automatically when plugged in, however, the same does not seem to be
true for the mic. Is there any configuration magic that can be done to
use the headphone mic instead of the internal one?
Here's pin config:
hdaa0: Dumping AFG pins:
hdaa0: nid 0x as seq device conn jack loc color misc
hdaa0: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1
hdaa0: Caps: IN
hdaa0: 19 4000 0 0 Line-out None Unknown 0x00 Unknown
0 DISA
hdaa0: Caps: IN
hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1
hdaa0: Caps: OUT EAPD Sense: 0x (disconnected)
hdaa0: 24 41f0 15 0 Speaker None 1/8 Rear Black
1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 25 41f0 15 0 Speaker None 1/8 Rear Black
1 DISA
hdaa0: Caps: IN VREF Sense: 0x8000 (connected)
hdaa0: 26 41f0 15 0 Speaker None 1/8 Rear Black
1 DISA
hdaa0: Caps: IN VREF Sense: 0x (disconnected)
hdaa0: 27 41f0 15 0 Speaker None 1/8 Rear Black
1 DISA
hdaa0: Caps: IN OUT EAPD VREF Sense: 0x (disconnected)
hdaa0: 30 421212f2 15 2 Speaker None 1/4 Front Black
2 DISA
hdaa0: Caps: OUT Sense: 0x (disconnected)
hdaa0: 33 0221101f 1 15 Headphones Jack 1/8 Front Black 0
hdaa0: Caps: OUT HP EAPD Sense: 0x8000 (connected)
hdaa0: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1
hdaa0: GPIO0: disabled
hdaa0: GPIO1: disabled
hdaa0: GPIO2: disabled
hdaa1: Dumping AFG pins:
hdaa1: nid 0x as seq device conn jack loc color misc
hdaa1: 3 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0
hdaa1: Caps: OUT hdac0: Command timeout on address 2
Sense: 0x (connected, ELD valid)
hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0
And in /boot/loader.conf I have this (don't remember why I put it there
or if I need it - it might have been copied over from previous laptop)
hint.hdaa.0.nid33.config="as=1 seq=15 device=Headphones"
I'm assuming here that the headphone jack supports mic - it's a 2018
laptop after all.
Cheers
/Johannes
___
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"
___
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: leaked swap?
On 18/03/2019 17:32, Konstantin Belousov wrote: > On Mon, Mar 18, 2019 at 05:20:35PM +0200, Andriy Gapon wrote: >> >> First, a note that this was observed on a system that runs a fairly old >> current >> (~ 1 year old) with a fairly long uptime (> 6 months). >> I noticed that the system was nearly out of memory, 98% of swap was in use, >> there was less than 1 GB of free memory, several GBs of each of active, >> inactive >> and laundry memory, and many GBs of wired (mostly ZFS). >> I decided to pro-actively reboot the system, but to speed that up I put the >> system to the single-user mode (via shutdown) and then back to multi-user. >> So, >> there was no real hardware reboot and the kernel kept running. However, all >> userland processes were terminated. >> >> To my surprise, even while in the single-user mode the swap utilization >> didn't >> go below 70%. Also, laundry memory remained in multi-GB area, but let's >> ignore >> this for now. >> >> I think that the swap could be used only for anonymous memory, so I expected >> it >> go to zero after the shutdown to the single user mode. >> Does anyone have any ideas? >> Maybe that's something that has already been fixed? >> If not, any ideas on what to look for? > tmpfs, swap-backed (or even memory backed) md, persistent posix shared > memory, SysV shared memory. > Thank you. There is a single tmpfs mount: $ df -t tmpfs -h FilesystemSizeUsed Avail Capacity Mounted on tmpfs 1.0G4.0K1.0G 0%/tmp/tmp No md devices at all according to mdconfig. Not sure how to check for the shared memory though. -- Andriy Gapon ___ 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: leaked swap?
On 18/03/2019 17:30, Cy Schubert wrote: > Top did not report any swap used by git and GB of swap were used. Last time I checked top reported something very different as swap. IIRC, its notion of swap usage comes from the age when the swap granularity was a whole process. -- Andriy Gapon ___ 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: leaked swap?
On Mon, Mar 18, 2019 at 05:20:35PM +0200, Andriy Gapon wrote: > > First, a note that this was observed on a system that runs a fairly old > current > (~ 1 year old) with a fairly long uptime (> 6 months). > I noticed that the system was nearly out of memory, 98% of swap was in use, > there was less than 1 GB of free memory, several GBs of each of active, > inactive > and laundry memory, and many GBs of wired (mostly ZFS). > I decided to pro-actively reboot the system, but to speed that up I put the > system to the single-user mode (via shutdown) and then back to multi-user. So, > there was no real hardware reboot and the kernel kept running. However, all > userland processes were terminated. > > To my surprise, even while in the single-user mode the swap utilization didn't > go below 70%. Also, laundry memory remained in multi-GB area, but let's > ignore > this for now. > > I think that the swap could be used only for anonymous memory, so I expected > it > go to zero after the shutdown to the single user mode. > Does anyone have any ideas? > Maybe that's something that has already been fixed? > If not, any ideas on what to look for? tmpfs, swap-backed (or even memory backed) md, persistent posix shared memory, SysV shared memory. ___ 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: leaked swap?
On March 18, 2019 8:20:35 AM PDT, Andriy Gapon wrote: > >First, a note that this was observed on a system that runs a fairly old >current >(~ 1 year old) with a fairly long uptime (> 6 months). >I noticed that the system was nearly out of memory, 98% of swap was in >use, >there was less than 1 GB of free memory, several GBs of each of active, >inactive >and laundry memory, and many GBs of wired (mostly ZFS). >I decided to pro-actively reboot the system, but to speed that up I put >the >system to the single-user mode (via shutdown) and then back to >multi-user. So, >there was no real hardware reboot and the kernel kept running. >However, all >userland processes were terminated. > >To my surprise, even while in the single-user mode the swap utilization >didn't >go below 70%. Also, laundry memory remained in multi-GB area, but >let's ignore >this for now. > >I think that the swap could be used only for anonymous memory, so I >expected it >go to zero after the shutdown to the single user mode. >Does anyone have any ideas? >Maybe that's something that has already been fixed? >If not, any ideas on what to look for? >Thanks! I've had a hunch of this but haven't gone down this rabbit hole to investigate. Related, yesterday I performed a git gc --aggressive. Top did not report any swap used by git and GB of swap were used. I think to help address this we need a reliable reporting tool. Obviously two separate symptoms, not sure if the same cause. -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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"
leaked swap?
First, a note that this was observed on a system that runs a fairly old current (~ 1 year old) with a fairly long uptime (> 6 months). I noticed that the system was nearly out of memory, 98% of swap was in use, there was less than 1 GB of free memory, several GBs of each of active, inactive and laundry memory, and many GBs of wired (mostly ZFS). I decided to pro-actively reboot the system, but to speed that up I put the system to the single-user mode (via shutdown) and then back to multi-user. So, there was no real hardware reboot and the kernel kept running. However, all userland processes were terminated. To my surprise, even while in the single-user mode the swap utilization didn't go below 70%. Also, laundry memory remained in multi-GB area, but let's ignore this for now. I think that the swap could be used only for anonymous memory, so I expected it go to zero after the shutdown to the single user mode. Does anyone have any ideas? Maybe that's something that has already been fixed? If not, any ideas on what to look for? Thanks! -- Andriy Gapon ___ 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"
Use mic from headphone jack on freebsd laptop?
Hi On my Dell laptop the output audio switches to the headphones automatically when plugged in, however, the same does not seem to be true for the mic. Is there any configuration magic that can be done to use the headphone mic instead of the internal one? Here's pin config: hdaa0: Dumping AFG pins: hdaa0: nid 0x as seq device conn jack loc color misc hdaa0: 18 90a60140 4 0 Mic Fixed Digital Internal Unknown 1 hdaa0: Caps: IN hdaa0: 19 4000 0 0 Line-out None Unknown 0x00 Unknown 0 DISA hdaa0: Caps: IN hdaa0: 20 90170110 1 0 Speaker Fixed Analog Internal Unknown 1 hdaa0: Caps: OUT EAPD Sense: 0x (disconnected) hdaa0: 24 41f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: Caps: IN VREF Sense: 0x (disconnected) hdaa0: 25 41f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: Caps: IN VREF Sense: 0x8000 (connected) hdaa0: 26 41f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: Caps: IN VREF Sense: 0x (disconnected) hdaa0: 27 41f0 15 0 Speaker None 1/8 Rear Black 1 DISA hdaa0: Caps: IN OUT EAPD VREF Sense: 0x (disconnected) hdaa0: 30 421212f2 15 2 Speaker None 1/4 Front Black 2 DISA hdaa0: Caps: OUT Sense: 0x (disconnected) hdaa0: 33 0221101f 1 15 Headphones Jack 1/8 Front Black 0 hdaa0: Caps: OUT HP EAPD Sense: 0x8000 (connected) hdaa0: NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdaa0: GPIO0: disabled hdaa0: GPIO1: disabled hdaa0: GPIO2: disabled hdaa1: Dumping AFG pins: hdaa1: nid 0x as seq device conn jack loc color misc hdaa1: 3 18560010 1 0 Digital-out Jack Digital 0x18 Unknown 0 hdaa1: Caps: OUT hdac0: Command timeout on address 2 Sense: 0x (connected, ELD valid) hdaa1: NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 And in /boot/loader.conf I have this (don't remember why I put it there or if I need it - it might have been copied over from previous laptop) hint.hdaa.0.nid33.config="as=1 seq=15 device=Headphones" I'm assuming here that the headphone jack supports mic - it's a 2018 laptop after all. Cheers /Johannes ___ 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"
