Re: Suspend/resume (to/from RAM), kern.vty, and x11/nvidia-driver
David Wolfskill writes: > I have a couple of Dell laptops -- an older (Precision M4800) and > a newer (Precision 7520) on which I've been tracking FreeBSD > stable/12, head, and (lately) stable/13 (with a daily cadence). I > also update installed ports on each every day. Each uses > x11/nvidia-driver for graphics. > > Each runs FreeBSD itself ... well. And I recently found out that the > mouse/touchpad on the 7520 now works under head and stable/13 (by > loading the iichid.ko kernel module, as the device communicates over > I2C). (I tried the sysutils/iichid port under stable/12, but have not > been able to get the mouse to work yet under stable/12.) > > And suspend/resume works... under stable/12, where I have been using > kern.vty="sc" (in /boot/loader.conf). (I recall having tried letting > kern.vty default to "vt" -- that seems to cause resume to fail: the > screen never lights up again, nor can I ssh into the laptop. Yes, I > configured the laptops to be able to ssh into them for various reasons > -- such as testing suspend/resume.) > > In order to test some recent (vbe-related) loader changes, however, I > needed to change kern.vty back to the default value of "vt" -- and that > appears to cause resume to fail (still). > > How may I help figure out what's wrong? The newer (7520) laptop, in > particular, is idle most of the day, so experimenting with it should be > OK. I recently stumbled over this post that provides an explanation: https://forums.freebsd.org/threads/what-to-backup.63727/#post-372549 That post says that "options VESA" is the problem, and that vt will not work! I have a desktop with nvidia that used to suspend/resume just fine with stable/9 (maybe also stable/10), but then failed to resume properly. I have not yet tried the suggestions in that post, though. Bengt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable
Dear All, On Tue, Mar 02, 2021 at 10:55:15AM +0200, Andriy Gapon wrote: > On 02/03/2021 09:50, Arrigo Marchiori via freebsd-stable wrote: > > Dear All, > > > > On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via > > freebsd-stable wrote: > > > >> Hello Helge, and thank you for replying again. > >> > >> On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote: > >> > >>> Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 > >>> +0100 (CET): > On the memstick, the root filesystem is mounted read-only. I > apologize, I should have told it explicitly. The ``invalid'' attempt > is to mount it read-write (no mode is indicated on the command line). > >>> > >>> Try to make it r/w mounted (which I suspect you are attempting to > >>> achieve): > >>> > >>> mount -uw / > >> > >> Ok, I will try this. > >> > >> But just for the record: I am not try to achieve anything. I gave the > >> ``invalid'' mount command by mistake (I wanted to mount a partition > >> from another disk and wrote "da0" instead of "da1") and I saw that the > >> system became unstable. I thought that this should not happen and I > >> reported it here. > > > > I have two updates. > > > > 1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2. > > bsdlabel(8) output (copied by hand): > > # /dev/da0s2: > > 8 partitions: > > # size offsetfstype[fsize bsize bps/cpg] > > a: 1491200 164.2BSD 0 0 0 > > c: 1491216 0unused 0 0 # "raw" part, don't > > edit > > > > 2- if I mount the partition rw, then the mount command _always_ fails > > with error "operation not permitted" and the system _always_ remains > > stable. This is independent from mounting from /dev/ufs/label or > > /dev/da0s2a. > > > > Therefore I can change the description of this problem report as: > > > > 8<8<8<8<8<8<8<- > > > > When a BSD partition is mounted _read_only_ to / (suppose > > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I > > receive a ``strange'' error message, and from that moment the mounted > > filesystem becomes unreadable. > > > > - If the partition is mounted from /dev/ufs/label, then mount(8) > > reports "Operation not permitted" and the system remains stable. > > This is the expected behavior IMHO. > > > > - If the partition is mounted read_write, from any special device, > >then mount(8) reports: > > - "Operation not permitted" if I try to mount the slice rw, > > - the same strange error message if I try to mount the slice ro, > >and the system remains stable. > > > > - The "strange error message" is "invalid argument" on 11.4-STABLE. > > > > 8<8<8<8<8<8<8<- > > > > Now to the question: is this worth a PR? Was it already reported? Or > > is it just something that ``should not happen'' because root should be > > allowed to shoot themselves in the foot? > > > > Thank you in advance and best regards, > > I think that this is worth a PR. Just reported: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254005 > I think that even when mounting read-only the underlying GEOM object should be > marked for exclusive use. > I vaguely recall that UFS has some quirk in this respect to allow for > modifications by fsck. That is supposed to be limited to the root filesystem. > Maybe it should further be limited to certain boot stages to prevent > foot-shooting after a system is fully booted. Thank you and best regards, -- Arrigo http://rigo.altervista.org ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Suspend/resume (to/from RAM), kern.vty, and x11/nvidia-driver
I have a couple of Dell laptops -- an older (Precision M4800) and a newer (Precision 7520) on which I've been tracking FreeBSD stable/12, head, and (lately) stable/13 (with a daily cadence). I also update installed ports on each every day. Each uses x11/nvidia-driver for graphics. Each runs FreeBSD itself ... well. And I recently found out that the mouse/touchpad on the 7520 now works under head and stable/13 (by loading the iichid.ko kernel module, as the device communicates over I2C). (I tried the sysutils/iichid port under stable/12, but have not been able to get the mouse to work yet under stable/12.) And suspend/resume works... under stable/12, where I have been using kern.vty="sc" (in /boot/loader.conf). (I recall having tried letting kern.vty default to "vt" -- that seems to cause resume to fail: the screen never lights up again, nor can I ssh into the laptop. Yes, I configured the laptops to be able to ssh into them for various reasons -- such as testing suspend/resume.) In order to test some recent (vbe-related) loader changes, however, I needed to change kern.vty back to the default value of "vt" -- and that appears to cause resume to fail (still). How may I help figure out what's wrong? The newer (7520) laptop, in particular, is idle most of the day, so experimenting with it should be OK. Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org It is supremely disingenuous to claim a lack of jurisdiction, then proceed to participate in a decision on the same matter. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: uchcom update
Thank You, Andriy! It solved the problem for me too. Also this can be applied without reboot via command: sysctl hw.usb.no_cs_fail=1 вс, 28 февр. 2021 г. в 14:21, Andriy Gapon : > On 28/02/2021 11:03, KOT MATPOCKuH wrote: > > Hello! > > > > I'm using FreeBSD 12.2-STABLE r368656 and got usb-to-rs232 with this > > controller. > > I see /dev/cuaU0 after plugging in adapter, I can attach to serial line > > using cu, but after sending any symbol to device I have device > reconnection: > > uchcom0 on uhub0 > > uchcom0: on usbus0 > > uchcom0: CH340 detected > > uchcom0: at uhub0, port 9, addr 17 (disconnected) > > uchcom0: detached > > uchcom0 on uhub0 > > uchcom0: on usbus0 > > uchcom0: CH340 detected > > I have this in my loader.conf: > > # Ignore result of "clear stall" (clearing halt on endpoints) > # CH340 USB<->RS232 requires this > # and it seems that Linux and Windows do this by default > hw.usb.no_cs_fail=1 > > I recall that without that tuning I had a similar problem. > > > вт, 5 июн. 2018 г. в 15:05, Ian FREISLICH >: > > > >> On 05/22/2018 09:44 AM, Andriy Gapon wrote: > >>> Yesterday I committed some changes to uchcom (so far, only in CURRENT). > >>> Commits are r333997 - r334002. > >>> > >>> If you have a CH340/341 based USB<->RS232 adapter and it works for you, > >> could > >>> you please test that it still does? > >>> If you tried your adapter in the past and it did not work, there is a > >> chance it > >>> might start working now. Could you please test that as well? > >> > >> ugen5.4: at usbus5, cfg=0 md=HOST spd=FULL > >> (12Mbps) pwr=ON (96mA) > >> ugen5.4.0: uchcom0: > >> > >> It's not made it any worse. I'm not using this adapter by choice - it's > >> a USB to Maxim (Dallas) one-wire bus adapter. The manual used to state > >> that these are possibly the worst chips ever. Is that still the > >> prevailing opinion? > > > -- > Andriy Gapon > -- MATPOCKuH ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
