Re: serial/ulscom: response timeout using pySerial/esptool.py
CP2102 are pretty good ones and never let me down :-) Is your UART connection to ESP32 working correctly? Can you see the boot message and whatever happens next in terminal (cu / minicom)? Are RX TX pins not swapped? Power supply okay? Are boards generic devkits of custom hardware? ESP32 in addition to RX TX needs two control lines Reset and Boot that will switch the chip to bootloader / flashing mode. Most USB-to-UART use RTS/CTS lines for that. Are you sure these lines are available on your board and connected to the target correctly? Do you have Reset and Boot buttons on the board so you could trigger bootloader by hand (hold Boot, press and release Reset, device will be in bootloader upload mode, retry esptool flashing now). You can also play with the buttons with active terminal attached (i.e. minicom) to see if they work as expected. Minicom serial terminal is pretty cool as it allows you to watch UART behavior on adapter (un)plug. In minicom you can also enable/disable hardware flow control lines (Ctrl+A O -> Serial Port Setup -> (F) Hardware Flow Control). You can switch that easily and watch the target behavior. If this is the problem you may want to use stty (1) to enable/disable hardware flow control on the port. Can you try with another board? ESP32 has fuses that may permanently disable and/or mess up some hardware features. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: 'poweroff' seems to (only) halt as of main-n267841-0b3f9e435f2b
On Tue, Jan 30, 2024 at 3:49 PM David Wolfskill wrote: > The machines where I track head (& stable/14) daily get powered off once > they have finished their work for the day; this is done via "poweroff". > > I noticed (this morning) that one of them never actually powered off > yesterday. After today's exercises (including the reboot & subsequent > poweroff), I saw on the (serial) console: Have you tried hw.efi.poweroff=0 in /boot/loader.conf ? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Removing fdisk and bsdlabel (legacy partition tools)
Yes! Installer is always used in emergency it would be great to provide some servicing tools there too :-) For years I was using bootable Linux to fix people computers and it would be nice to have that in FreeBSD :-) +1 for memstick full with additional service utilities (fix partitions, mount fs, undelete, ntfs support, etc) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Removing fdisk and bsdlabel (legacy partition tools)
On Wed, Jan 24, 2024 at 6:30 PM Warner Losh wrote: The in-kernel gpart copes so much better. > (..) > I wouldn't object to making these ports (..) +1 for moving fdisk and bsdlabel to ports instead deleting :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
On Fri, Jan 12, 2024 at 6:15 PM Dag-Erling Smørgrav wrote: > Tomek CEDRO writes: > > I am reading this interesting discussion and please verify my general > > understanding: > > 1. There is a request for change in core OS / FS mechanism of file > > access time (atime) because of problem with mailing application? > > The atime mechanism is considered harmful by many because every file > access results in a write which (even if coalesced) not only impacts > performance but also increases wear on SSDs. Many people turn it off. > Even the FreeBSD installer turns it off when installing to ZFS, except > on `/var/mail` which is a separate filesystem precisely so that it can > have atime enabled independently of the rest of the system. There is a > proposal to turn it off by default.(..) Okay, the discussion got some (and enough) traction, and its about changing defaults only, not the underlying kernel or filesystem code to change the atime behavior, so this can be done as an option that user will see and can change easily in the installer.. and still good old atime can be used where necessary whoever needs it :-) > > 2. Linux change of approach to atime that keeps its value only around > > last 24h so we should also change it in FreeBSD? > > > > 3. "realtime" is the alternative solution to keep atime intact? > > The Linux approach is an alternative mechanism dubbed “relatime” > (relative access time) which instead of updating the access time on > every access, does so only if the previous atime is either older than > the current mtime or more than 24 h ago. rel-atime roger! :-) :-) Thanks DES :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
On Thu, Jan 11, 2024 at 1:50 AM Rodney W. Grimes wrote: > > Olivier Certner wrote on > > Date: Wed, 10 Jan 2024 10:01:48 UTC : > > > What I'm saying is that, based on others' input so far, my own (long, > > > even if not as long as yours) experience and some late reflection, is > > > that "noatime" should be the default (everywhere, all mounts and all > > > FSes), and that working on "relatime" won't make any real difference for > > > most users (IOW, I think that developing "relatime" is a bad idea *in > > > general*). And I think this is a sufficiently reasonable conclusion that > > > anyone with the same inputs would conclude the same. So, if it's not the > > > case, I would be interested in knowing why, ideally. > > > > I never use atime, always noatime, for UFS. That said, I'd never propose > > changing the long standing defaults for commands and calls. I'd avoid: > > .. Very well said Mark ... > > Please folks stop tweaking defaults, especially long standing ones, > if you feel the need for noatime, set it, by all means, I have been > for 30 years > > .. what Mark said very well removed for brevity ... +1 :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: noatime on ufs2
On Wed, Jan 10, 2024 at 6:36 PM Olivier Certner wrote: > Both the examples above prompt some straight objections on the current > usefulness of "atime". First, unless you've disabled building the locate > database in cron (enabled by default, on a weekly basis), access times on > directories lose most of their usefulness. Second, if using an IDS, I'm > afraid it's just game over. And even if you think you are not, > '460.pkg-checksum' at least is readily there to much complicate, or even > prevent you from, getting package usage information this way (it is enabled > by default, and on a daily basis). > > The general point here is that a single access time is inherently fragile to > interferences by multiple applications for multiple reasons. I am reading this interesting discussion and please verify my general understanding: 1. There is a request for change in core OS / FS mechanism of file access time (atime) because of problem with mailing application? 2. Linux change of approach to atime that keeps its value only around last 24h so we should also change it in FreeBSD? 3. "realtime" is the alternative solution to keep atime intact? Why change well known standardized and widely used mechanism that is here for decades? If there is a problem with an application why change core OS/FS with all possible negative consequences and not fix the application? Wouldn't that break POSIX / backward compatiblity? Thanks :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Seemingly random nvme (nda) write error on new drive (retries exhausted)
what filesystem? is TRIM enabled on that drive? have you tried disabling trim? i had similar ssd related problem on samsung's ssd long time ago that was related to trim. maybe drive firmware can be updated too? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: photo/video on tty console with the new VT/framebuffer
On Fri, May 19, 2023 at 2:51 PM Ivan Quitschal wrote: > could you please tell us how did you do to make mpv working ? > > when i try to run it, i get something like this: > $ mpv --vo=drm video.mp4 > (+) Video --vid=1 (*) (h264 424x240 30.000fps) > (+) Audio --aid=1 (*) (aac 2ch 44100Hz) > [vo/drm] No primary DRM device could be picked! > [vo/drm] Failed to find a usable DRM primary node! > [vo/drm] Failed to create KMS. > Error opening/initializing the selected video_out (--vo) device. > Video: no video I have it working just with mpv file. Do you have drm kernel module installed? Btw. freebsd-questions list is better place for this kind of questions. freebsd-current is specific for CURRENT branch development related discussions :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: photo/video on tty console with the new VT/framebuffer
On Fri, May 19, 2023 at 2:29 PM Yuri wrote: > Tomek CEDRO wrote: > > On Fri, May 19, 2023 at 1:44 PM Alastair Hogge wrote: > >> On 2023-05-19 11:30, Tomek CEDRO wrote: > >>> On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote: > >>>> As long as those packages support DRMKMS and does your GPU, you can to a > >>>> degree. I noticed video works for mpv and games/sdl, tho, I cannot get > >>>> input working. I tried the Doom 3 port, and watched movies with mpv all > >>>> from the vty just a couple of months ago. > >>> > >>> Yeah, I have input problem too, maybe worth investigating as this is > >>> really neat feature to have gfx with no Xorg :-) > >> > >> It is worth investigating! In a long dead ago project, the input, > >> events, and displays were all integrated into the vty and mux'd from > >> there. The kernel provides evdev devices now, and there is a library, > >> tho I do not know how to get vt(4) to integrate with evdev, or if the > >> library is the way to do it? Any other ideas? > > > > Hey there Niclas :-) Do you know how to enable input devices > > (keyboard/mouse) in the console graphical applications? Is it > > possible? :-) > Wayland something? We have graphical applications (i.e. SDL) working on a DRM KMS console with no Xorg nor Wayland.. but no input.. looking for a solution :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: photo/video on tty console with the new VT/framebuffer
On Fri, May 19, 2023 at 1:44 PM Alastair Hogge wrote: > On 2023-05-19 11:30, Tomek CEDRO wrote: > > On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote: > >> As long as those packages support DRMKMS and does your GPU, you can to a > >> degree. I noticed video works for mpv and games/sdl, tho, I cannot get > >> input working. I tried the Doom 3 port, and watched movies with mpv all > >> from the vty just a couple of months ago. > > > > Yeah, I have input problem too, maybe worth investigating as this is > > really neat feature to have gfx with no Xorg :-) > > It is worth investigating! In a long dead ago project, the input, > events, and displays were all integrated into the vty and mux'd from > there. The kernel provides evdev devices now, and there is a library, > tho I do not know how to get vt(4) to integrate with evdev, or if the > library is the way to do it? Any other ideas? Hey there Niclas :-) Do you know how to enable input devices (keyboard/mouse) in the console graphical applications? Is it possible? :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: photo/video on tty console with the new VT/framebuffer
On Fri, May 19, 2023 at 1:28 PM Alastair Hogge wrote: > As long as those packages support DRMKMS and does your GPU, you can to a > degree. I noticed video works for mpv and games/sdl, tho, I cannot get > input working. I tried the Doom 3 port, and watched movies with mpv all > from the vty just a couple of months ago. Yeah, I have input problem too, maybe worth investigating as this is really neat feature to have gfx with no Xorg :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Delay in 14.0-RELEASE cycle and blocking items
Thanks Glen, no rush, quality first, it takes time :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Support for more than 256 CPU cores
On Fri, May 5, 2023 at 3:38 PM Ed Maste wrote: > FreeBSD supports up to 256 CPU cores in the default kernel configuration > (on Tier-1 architectures). Systems with more than 256 cores are > available now, and will become increasingly common over FreeBSD 14’s > lifetime. (..) Congratulations! :-) I am looking after AMD Threadripper with 64 cores 2 threads each that will give 128 CPU to the system.. maybe this year I could afford that beast then I will report back after testing :-) In upcoming years variations of RISC-V will provide unheard before number of CPU in a single SoC (i.e. 1000 CPU) at amazing power efficiency and I saw reports of prototype with 3 x SoC of this kind on a single board :-) https://spectrum.ieee.org/risc-v-ai -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Arm64 Tier 1 FreeBSD 13 Phones
On Sat, Apr 10, 2021 at 10:07 AM grarpamp wrote: > FreeBSD Phones... Not really a "FreeBSD phones" just "phones" or "mobile multimedia capable embedded devices" as anything can run on them :-) For instance NuttX RTOS on PinePhone takes kilobytes in total: https://www.youtube.com/watch?v=kGI_0yK1vws There will be many different operating systems soon available on this kind of inexpensive powerful multimedia embedded systems. The problem is standard and compatibility. Unless vendor does not provide complete set of open source drivers and firmwares there will be no move forward. Unless application written for one won't run on another there will be no move forward. Unless there is no overcomplicated SDK and toolchain with libraries that have lifespan shorter than a bread there will be no move forward. Because who needs bare OS/RTOS with no useful familiar applications. :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: 9.1-RC3 LiveCD missing features
As I get ffs_valloc kernel panic on my / I want to check for badblocks but cannot do that from the system itself so I need another FreeBSD instance to run badblocks on unmounted /. There are no badblocks on LiveCD and I cannot simply download it with pkg_add -r. Installing another system just to test existing one seems silly. It would be nice to finally have swiss army knife on generic LiveCD FreeBSD install, not using linux windows hirens etc :-) I have just started dd if=root of=root from LiveCD, Ill let you know if that worked :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
UTF-8 console
Hello :-) I was wondering if its possible to have UTF-8 console? ISO seems to be a bit outdated these days and less comfortable for multinational applications :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
Re: Failed to switch consoles in 9.0-RC3
Thank you Jean-Sebastien, very useful hint with vidcontrol!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
Re: 9.1-RC3 feels okay :-)
WARNING!!! When AllowEmptyInput = False AND Hal is running really really bad things happen to Xorg!! Keys are messed up and screen is refreshed only after mouse move! Things are slow and the end of the word is near :-) AllowEmptyInput seems to be exclusive with Hal!! Please confirm :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Nov 8, 2012 2:29 PM, CeDeROM cede...@tlen.pl wrote: I was using xorg from package so it is default configuration, which is built with Hal support because it can make use of it I guess... The more important thing is that Xorg starts without autodetecting input devices by default. Maybe this is caused by Hal support being compiled in. This might implict using Hal for devices detection and disabling detection by Xorg. Xorg detection can be enforced by disabling empty input in that case. Disabling empty input shloud be a default for Xorg IMO... Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Nov 8, 2012 10:01 AM, Boris Samorodov b...@passap.ru wrote: 08.11.2012 12:46, CeDeROM пишет: With no hald and dbus mouse and keyboard does not work in xorg Do you mean that if xorg-server is compiled with hal but you do not launch it at startup mouse and keyboard does not work? If yes, I'd say that this is a bit... expected. ;-) -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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
Re: Failed to switch consoles in 9.0-RC3
Thanks for hint :-) For some reasons I need to have console usable after/during xorg is active, for instance at the moment I have problems with xfce4 and no console keeps me away from seeing what is wrong and even getting back into xorg. This is why I don use WITH_NEW_XORG anymore because is forced me to reboot on every issue :-( Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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
Re: 9.1-RC3 feels okay :-)
8-bit scene is still alive and rox! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Nov 8, 2012 6:11 PM, Chuck Burns brea...@gmail.com wrote: On 11/8/2012 10:58 AM, Richard Kuhns wrote: On 11/08/12 10:45, Warren Block wrote: On Thu, 8 Nov 2012, CeDeROM wrote: I have tested additional options in xorg runtime :-) With the patched xorg mouse driver 1.7.1 (or driver version =1.7.2) situation is following: 1. With hald and dbus no xorg.conf file is needed. However it might bo option to pass some additional featutes parameters with xorg.conf. 2. With no hald and dbus mouse and keyboard does not work in xorg unless Option AllowEmptyInput False is added to Section ServerLayout by hand in xorg.conf. Without this option input does not work even if xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced by Xorg at startup. No. AllowEmptyInput is wrong. It was causing so many problems that it has been removed from later xorg-server releases. Option AutoAddDevices Off is the one that means dont' use Hal to detect input devices. Thank you for this hint! This could be added to the handbook :-) AllowEmptyInput=False should be a default for Xorg IMO we can report it to the Xorg project! :-) Really, the simplest solution is to build xorg-server with the HAL option disabled. I agree that this should be the default. __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org freebsd-current-unsubscr...@freebsd.org Just a comment: according to http://wiki.freebsd.org/**VirtualBoxhttp://wiki.freebsd.org/VirtualBox, Hal is still required for VirtualBox in order to have host DVD/CD access. Doesn't mean xorg-server needs hal. Build xorg-server without hal support... install hald for virtualbox. Everything still works as it should... In the meantime, someone should probably write a devd-udisks[12] translation daemon.. for things like gnome, kde, xfce, and virtualbox, which have the udisks linuxisms can actually continue to work in the future.. I'd do it if I had any coding skills... I left those behind when I sold my Commodore64. :P -- Chuck Burns brea...@gmail.com __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org freebsd-current-unsubscr...@freebsd.org ___ 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
