Re: serial/ulscom: response timeout using pySerial/esptool.py
Can you isolate out the extraneous stuff and loop tx and rx on a CP2101 board and send bytes through? I did a bunch of development on an esp8266 board in the last few weeks and had no issues, but I’ve no idea if it were the same usb serial chip. I’ll have a dig around and see if I have something matching On Thu, Apr 25, 2024, at 20:17, FreeBSD User wrote: > Hello, > > Host: 15.0-CURRENT FreeBSD 15.0-CURRENT #36 main-n269703-54c3aa02e926: > Thu Apr 25 18:48:56 > CEST 2024 amd64 or 14-STABLE recently compiled (dmesg/uname not at > hand). > > Hardware: oldish Z77Pro 4 based Asrock mainboard, a Lenovo T560 > notebook, Fujitsu Esprimo Q5XX > (simple desktop, Pentium Gold) or an oldish Fujitsu Celsius 7XX > workstation, 6 core Haswell > XEON. > > Phenomenon: a couple of weeks now I try to connect to several Xtensa > ESP32 dev boards > (ESP32-WROOM32 with CP2101 or CP2104 UART) via comms/py-esptool > (doesn't matter whether it is > tho port's py39-esptool 4.5 or the latest py-esptool 4.7.0, doesn't > matter whether pkg package > or self compiled on CURRENT and 14-STABLE, on all hardware platforms > same result). > > Attaching the ESP devel module via Micro USB cable (several type, > differnt vendors tried ...) > show > > dmesg: > [...] > ugen0.4: at usbus0 > uslcom0 on uhub3 > uslcom0: rev 1.10/1.00, addr 4> > on usbus0 > [...] > > When trying to connect to the ESP32 via below shown command (--trace > not every time issued), I > get no connection: > > [ohartmann]: esptool.py --trace --chip esp32 --baud 115200 --port > /dev/cuaU1 flash_id > esptool.py v4.7.0 > Loaded custom configuration from /pool/home/ohartmann/esptool.cfg > Serial port /dev/cuaU1 > Connecting...TRACE +0.000 command op=0x08 data len=36 wait_response=1 > timeout=0.100 data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > TRACE +0.102 No serial data received. > TRACE +0.052 command op=0x08 data len=36 wait_response=1 timeout=0.100 > data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > TRACE +0.107 No serial data received. > TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 > data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > TRACE +0.107 No serial data received. > TRACE +0.054 command op=0x08 data len=36 wait_response=1 timeout=0.100 > data= > 07071220 | ... > | > | > TRACE +0.000 Write 46 bytes: > c824 000707122055 | ...$ UUU > | > 55c0 | U. > > > A serial exception error occurred: device reports readiness to read but > returned no data > (device disconnected or multiple access on port?) Note: This error > originates from pySerial. > It is likely not a problem with esptool, but with the hardware > connection or drivers. For > troubleshooting steps visit: > https://docs.espressif.com/projects/esptool/en/latest/troubleshooting.html > [...] > > > Whatever baud rate issued, in most cases on all tested OS versions and > almost all hardware > platforms except the Fujistu Celsius 7XX (2015 model) I do not get any > connection! And it get > more weird: To avoid out-of-sync-software I recompiled everything via > "portmaster -df > comms/py-pyserial comms/py-esptool" and after that, everything was > fine, the connection was > made, I got results out of the chip. Seconds later same problems. > > I exchanged cablings, exchanged the ESP32 model and vendor. Invariants > are 14-STABLE, daily > compiled, CURRENT. daily compiled. On my private box (old Z77 based > IvyBridge ASRock crap), a > couple of Lenovo T560 running 14-STABLE and several Fujitsu Esprimo > Q5XX boxes there is always > this weird error message, but in very rare cases I get connection. > > Only exception: the Fujsitus Celsius 7XX workstation (14-STABLE, last > complied today noon). No > matter what ESP32, no
Re: diff(1) goes into cpu-hogging endless loop
On Sat, Mar 25, 2023 at 09:55:14PM +, Jamie Landeg-Jones wrote: > Hi, A "diff" of 2 files: > > 1 77,933,904 bytes > 2 63,013,818 bytes > > , goes into an endless loop, whilst "gdiff" completes the operation in > about 5 seconds. > > I tested using the latest "diff" from current, and get the same result. > > Splitting both files into 10Mb chunks, and diffing these was successful. > > A ktrace of the "diff" actually stops producing any output after about > 5 seconds, whilst the cpu looping continues. > > Any ideas on what to do next? Does anyone else get the same result? > > The files are just utf-8 freebsd git logs, and are available here if > anyone would like to test: > > http://www.catflap.org/jamie/1.xz (13,282,864 bytes) > http://www.catflap.org/jamie/2.xz (12,221,164 bytes) > > Cheers, Jamie My guess is that you are hitting a worst case in the stone algorithm. I have a WIP review to integrate the Myers algorithm from libdiff here: https://reviews.freebsd.org/D36860 - Tom
Re: [HEADSUP] making /bin/sh the default shell for root
On Wed, Sep 22, 2021 at 08:34:58AM -0700, John Baldwin wrote: > On 9/22/21 1:36 AM, Baptiste Daroussin wrote: > > Hello, > > > > TL;DR: this is not a proposal to deorbit csh from base!!! > > > > For years now, csh is the default root shell for FreeBSD, csh can be > > confusing > > as a default shell for many as all other unix like settled on a bourne shell > > compatible interactive shell: zsh, bash, or variant of ksh. > > > > Recently our sh(1) has receive update to make it more user friendly in > > interactive mode: > > * command completion (thanks pstef@) > > * improvement in the emacs mode, to make it behave by default like other > > shells > > * improvement in the vi mode (in particular the vi edit to respect $EDITOR) > > * support for history as described by POSIX. > > > > This makes it a usable shell by default, which is why I would like to > > propose to > > make it the default shell for root starting FreeBSD 14.0-RELEASE (not MFCed) > > > > If no strong arguments has been raised until October 15th, I will make this > > proposal happen. > > > > Again just in case: THIS IS NOT A PROPOSAL TO REMOVE CSH FROM BASE! > > I think this is fine. I would also be fine with either removing 'toor' from > the > default password file or just leaving it as-is for POLA. (I would probably > prefer removing it outright.) I support both of these suggestions, when I first installed FreeBSD ~2006 toor already felt like a strange an anachronism. - Tom
[no subject]
r...@freebsd.org Bcc: Subject: Re: How to enable tcp bbr in FreeBSD??? Reply-To: In-Reply-To: <6042155a-297b-d85e-1d64-24d93da32...@gmail.com> ... snip ... > > Maybe it is not ready for prime time, i do not know why it is not in the > default build. > Maybe ask the committer. > I have added rrs@ in cc and the freebsd-transport list. Does anyone know if there are plans to enable alternate TCP stacks in generic? Is there a stability point we need to hit first? - Tom ___ 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: ThinkPad: reboots after successful shutdown -p
On Mon, Nov 18, 2019 at 11:47:18AM -0800, Oleksandr Tymoshenko wrote: > Bjoern A. Zeeb (bzeeb-li...@lists.zabbadoz.net) wrote: > > On 18 Nov 2019, at 7:14, Xin Li wrote: > > > > > Hi, > > > > > > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the > > > system would shut down and seemingly powered off, then it would > > > restart > > > after about 5-10 seconds. > > > > Interesting. I have the opposite problem that a reboot does a shutdown > > but never resets (also no reset from ddb>). I’ve seen this on the > > X270 and the T480. > > I had this issue on my Thinkpad too. The "solution" was to disable > bluetooth chip in BIOS. I didn't try to find the root cause of this > behavior. There was a related bluetooth update in September after which my x270 was able to reboot. You might want to reenable and try again - [tj] ___ 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: hang up with r352239 and r352386 with i5-7500
On Mon, Sep 16, 2019 at 01:24:12PM +0200, Niclas Zeising wrote: > On 2019-09-16 13:09, Masachika ISHIZUKA wrote: > >Hi. > > > >My machine (with core i5-7500) is hangup when loading i915kms.ko > > on r352239 and r352386 (1300047). > >This machine was working good with r351728 (1300044). > > > >/etc/rc.conf has the following line. > > kld_list="i915kms.ko" > > > >It is good wowking with core i7-4500U on r352239 (1300047). > > > > Hi! > Which version of drm-current are you using? Have you recompiled it > after updating the kernel? What happens if you change to > kld_list="/boot/modules/i915kms.ko"? > > There is a patch here: > https://github.com/FreeBSDDesktop/kms-drm/pull/175/commits/7b8fab2461262b22f64425146b60608bb0e0240d > > that might solve the issue, can you apply that and recompile > drm-current-kmod and see if it works? Hi Niclas, I can report that the above patch fixes lock ups when loading i915kms on my x270 - [tj] ___ 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: wlan can't discover known networks after relocating
On Tue, Sep 17, 2019 at 04:36:28PM +, Poul-Henning Kamp wrote: > > In message <707bcd3f-fa6b-82eb-fa8f-09c4b800f...@freebsd.org>, Johannes > Lundber > g writes: > > >For a long time now I have had this problem with iwm and wlan0. Whenever > >I move between work and home it won't reconnect automatically and I have > >to do wlan0 scan manually for it to pick up the different network. > > I suffer from the dreaded "reason=0" when I move inside my house: > > > scan > OK > <3>CTRL-EVENT-SCAN-RESULTS > <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' > freq=2452 MHz) > <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:3d:a2:e9 reason=0 > <3>CTRL-EVENT-SCAN-RESULTS > <3>Trying to associate with 6c:3b:6b:ab:ce:d4 (SSID='Palombia' > freq=2412 MHz) > <3>Associated with 6c:3b:6b:ab:ce:d4 > > a2:e9 is the loudest AP here in my office, but my I have been in the > other end of the house iwn consistently fails to associate with it and > and keeps picking the weaker AP in the far end. > > Eventually (hours!) it disconnects from the weaker ap, also with > "reason=0" and gets it right: > > <3>WPA: Group rekeying completed with 6c:3b:6b:ab:ce:d4 [GTK=CCMP] > <3>CTRL-EVENT-DISCONNECTED bssid=6c:3b:6b:ab:ce:d4 reason=0 > <3>CTRL-EVENT-SCAN-RESULTS > <3>Trying to associate with 6c:3b:6b:3d:a2:e9 (SSID='Palombia' > freq=2452 MHz) > <3>Associated with 6c:3b:6b:3d:a2:e9 > <3>WPA: Key negotiation completed with 6c:3b:6b:3d:a2:e9 [PTK=CCMP > GTK=CCMP] > <3>CTRL-EVENT-CONNECTED - Connection to 6c:3b:6b:3d:a2:e9 completed > [id=3 id_str=] > <3>WPA: Group rekeying completed with 6c:3b:6b:3d:a2:e9 [GTK=CCMP] > > And yes, working roaming would be nice too... I have the problem that when roaming networks become disabled $ wpa_cli Selected interface 'wlan0' Interactive mode > list_networks network id / ssid / bssid / flags 0 network1any [CURRENT] 1 network2 any[DISABLED] 2 network3 any[DISABLED] 3 network4 any[DISABLED] 4 network5 any[DISABLED] Selected interface 'wlan0' I address this by doing network_enable x in wpa_cli and it all comes back. I asked Adrian about this in the past, but it needs some debugging to pin down. - [tj] ___ 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: Rotating (efi) framebuffer
On Thu, May 02, 2019 at 09:06:28AM -0700, Johannes Lundberg wrote: > Hi > > I have a Lenovo Ideapad where the screen is rotated 90 degrees and I > can't rotate it to landscape mode until I'm in X. How many of you are in > the same situation and would like a fix? Seeing how development is going > with small (tiny) computers it will probably be more and more common > with ultra portables having a "phone screen" which most likely is in > portrait mode by default. This also applies to embedded and home brew / > prototype devices. > > It would certainly be nice if we could have a boot time parameter that > could rotate the framebuffer (just as a data point, I'm pretty sure > Linux can do this). How many would be interested in this? Is there > anyone working on this atm? Not sure I will have the time to develop > this all of my own but thought I'd check the interest at least. Perhaps > a GSoC project? > This is an issue on the GPD Pocket and many other devices that use a tablet screen. A boot parameter for this would be fine, Linux does it with a parameter. A quick search shows it is probably: 'fbcon=rotate:1' I think you could probably detect that the dimensions are swapped, i.e. taller than you are wide, but there should still be a parameter to allow manual config. - [tj] ___ 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: axp288 on Intel HW
On Thu, Nov 22, 2018 at 06:17:45AM +0100, Emmanuel Vadot wrote: > > Hi, > > Allwinner PMIC on X86, interesting :) > > On Fri, 16 Nov 2018 08:51:31 + > Johannes Lundberg wrote: > > > Hi > > > > I have a Lenovo Ideapad Miix 310 that has a Intel CherryTrail CPU and it > > runs FreeBSD quite nicely (with accelerated graphics). What I'm missing is > > battery life status.. > > > > I can get this information using smb (for some reason i2c just returns > > error sending start condition) > > smbmsg -f /dev/smb6 -s 0x68 -c 0xB9 -i 1 -F %d > > > > In emergency this works but it would be nice to have a kernel driver for > > it. > > > > I found the axp2xx driver for Allwinner in the tree. Would it be possible > > to share this with amd64 with not too much effort? > > The first step would be to add acpi attach functions (no idea how this > works), then compare the registers with the pmics supported by the > axp2xx driver to check what regulators are present and controllable (if > any) and also checking the registers for talking to the battery > controller part. > I don't see why it wouldn't work but I haven't checked details on how > supported chips differs with this one. > > > > > If not, all I'm really interested in is battery status so I might just hack > > together a simple driver for that report values to hw.acpi.battery (because > > I don't think there is a sysctl for battery info that aggregates different > > sources?) > > We don't have a generic battery/power supply framework yes. On an ACPI there is an IOCTL that will collate battery information from anything in the battery devclass. There is an acpi_battery_register function, but what it actually does is set up sysctls. I have a patch to land (hopefully this week) that you would need first. I have a driver for a maxim fuel gauge on a unreasonably complicated laptop that includes an example of what you have to do to be a battery: https://github.com/adventureloop/gpdpocket/blob/master/chvpower/chvpower.c#L148 To support battery on arm (say for the pinebook) we need a more general system. I plan to extract out the current battery code from acpi as a first attempt at this. - [tj] ___ 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"
