Re: Problem with USB after r349133
Nick Wolff [darkfiber...@gmail.com] wrote: > Thomas/HPS, > > I did manage to get a boot with hw.usb.no_boot_wait=1 set in loader.conf. > So if any debugging information off a running system would be helpful let > me know. > > Thanks, > Nick: That was the same workaround that I used. I had not filed a bug report since adding that line to my loader.conf fixed my laptop. This issue only affects a single Dell laptop and does not seem to happen on 5 of my desktop PC's all running the same version of 13-CURRENT. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Problem with USB after r349133
Nick Wolff [darkfiber...@gmail.com] wrote: > Sorry for email spam but I was wrong. Just gets stuck now during reproping > a pci device after init happens(this is actually a trueos build which is > why you see openrc). That device it's getting stuck on is "Sky Lake-E CBDMA > Registers" which shouldn't have a driver attached. > https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing > > Though it maybe something else getting stuck at this point and that just > happens to be the last thing on the screen. > I don't see this problem on any of my Skylake desktops. It is only on my Dell Core2-duo laptop. My Skylake and Kabylake desktops are all 100 percent OK without the loader.conf change. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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: Problem with USB after r349133
Hans, I'm building r350003 at the moment which is after the acpi change was moved into an unloaded module. On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky wrote: > On 2019-07-22 17:23, Nick Wolff wrote: > > Sorry for email spam but I was wrong. Just gets stuck now during > reproping > > a pci device after init happens(this is actually a trueos build which is > > why you see openrc). That device it's getting stuck on is "Sky Lake-E > CBDMA > > Registers" which shouldn't have a driver attached. > > > https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing > > > > Though it maybe something else getting stuck at this point and that just > > happens to be the last thing on the screen. > > > > There was a recent change to add an ACPI wrapper for the USB HUB driver, > but that was a bit premature and introduced some bugs. For now the ACPI > USB HUB wrapper is not enabled by default. Do you experience issues with > the latest -current ? > > --HPS > > ___ 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: Problem with USB after r349133
On 2019-07-22 17:23, Nick Wolff wrote: Sorry for email spam but I was wrong. Just gets stuck now during reproping a pci device after init happens(this is actually a trueos build which is why you see openrc). That device it's getting stuck on is "Sky Lake-E CBDMA Registers" which shouldn't have a driver attached. https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing Though it maybe something else getting stuck at this point and that just happens to be the last thing on the screen. There was a recent change to add an ACPI wrapper for the USB HUB driver, but that was a bit premature and introduced some bugs. For now the ACPI USB HUB wrapper is not enabled by default. Do you experience issues with the latest -current ? --HPS ___ 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: Problem with USB after r349133
Sorry for email spam but I was wrong. Just gets stuck now during reproping a pci device after init happens(this is actually a trueos build which is why you see openrc). That device it's getting stuck on is "Sky Lake-E CBDMA Registers" which shouldn't have a driver attached. https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing Though it maybe something else getting stuck at this point and that just happens to be the last thing on the screen. On Mon, Jul 22, 2019 at 10:52 AM Nick Wolff wrote: > Thomas/HPS, > > I did manage to get a boot with hw.usb.no_boot_wait=1 set in loader.conf. > So if any debugging information off a running system would be helpful let > me know. > > Thanks, > > Nick Wolff > > On Mon, Jul 22, 2019 at 10:27 AM Nick Wolff > wrote: > >> Hello Thomas, >> >> Any updates? Did you get a bugzilla ticket filed? >> >> Thanks, >> >> Nick Wolff >> >> On Sat, Jul 6, 2019 at 2:48 PM Thomas Laus wrote: >> >>> On 2019-07-06 10:17, Graham Perrin wrote: >>> > >>> > I had the almost same (different bus numbers), just once, after >>> updating >>> > -CURRENT from r349099 to r349762. >>> > >>> > The subsequent boot of r349762 was free from the symptom. >>> > >>> > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech >>> > trackball connected to USB ports at the side of the dock. >>> > >>> > At one of the USB ports at the rear of the dock was a rechargeable >>> > motorised device, which I disconnected after the (one) USB issue. >>> > >>> I just built and installed r349161 and observed the same problem with >>> the rc.conf probe for USBUS7 ... USBUS0. >>> >>> I will build r349160 and make a report. >>> >>> Tom >>> >>> >>> -- >>> Public Keys: >>> PGP KeyID = 0x5F22FDC1 >>> GnuPG KeyID = 0x620836CF >>> ___ >>> 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: Problem with USB after r349133
Thomas/HPS, I did manage to get a boot with hw.usb.no_boot_wait=1 set in loader.conf. So if any debugging information off a running system would be helpful let me know. Thanks, Nick Wolff On Mon, Jul 22, 2019 at 10:27 AM Nick Wolff wrote: > Hello Thomas, > > Any updates? Did you get a bugzilla ticket filed? > > Thanks, > > Nick Wolff > > On Sat, Jul 6, 2019 at 2:48 PM Thomas Laus wrote: > >> On 2019-07-06 10:17, Graham Perrin wrote: >> > >> > I had the almost same (different bus numbers), just once, after updating >> > -CURRENT from r349099 to r349762. >> > >> > The subsequent boot of r349762 was free from the symptom. >> > >> > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech >> > trackball connected to USB ports at the side of the dock. >> > >> > At one of the USB ports at the rear of the dock was a rechargeable >> > motorised device, which I disconnected after the (one) USB issue. >> > >> I just built and installed r349161 and observed the same problem with >> the rc.conf probe for USBUS7 ... USBUS0. >> >> I will build r349160 and make a report. >> >> Tom >> >> >> -- >> Public Keys: >> PGP KeyID = 0x5F22FDC1 >> GnuPG KeyID = 0x620836CF >> ___ >> 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: Problem with USB after r349133
Hello Thomas, Any updates? Did you get a bugzilla ticket filed? Thanks, Nick Wolff On Sat, Jul 6, 2019 at 2:48 PM Thomas Laus wrote: > On 2019-07-06 10:17, Graham Perrin wrote: > > > > I had the almost same (different bus numbers), just once, after updating > > -CURRENT from r349099 to r349762. > > > > The subsequent boot of r349762 was free from the symptom. > > > > HP EliteBook 8570p, docked, with a Kensington keyboard and Logitech > > trackball connected to USB ports at the side of the dock. > > > > At one of the USB ports at the rear of the dock was a rechargeable > > motorised device, which I disconnected after the (one) USB issue. > > > I just built and installed r349161 and observed the same problem with > the rc.conf probe for USBUS7 ... USBUS0. > > I will build r349160 and make a report. > > Tom > > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > ___ > 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: filesystem mount problem
On July 21, 2019 1:44:13 PM PDT, Ian Lepore wrote: >On Sun, 2019-07-21 at 15:07 -0400, AN wrote: >> Hi: >> >> FreeBSD FreeBSD_13 13.0-CURRENT FreeBSD 13.0-CURRENT #102 r350187: >> Sat Jul >> 20 19:04:30 EDT 2019 >> root@FreeBSD_13:/usr/obj/usr/src/amd64.amd64/sys/MYKERNEL amd64 >> 1300036 >> >> I would appreciate some help with the following problem. >> >> /etc/fstab: >> # Device Mountpoint FStype Options DumpPass# >> /dev/ada0p2 noneswapsw 0 0 >> /dev/ada0p3 / ufs rw 1 1 >> linprocfs /compat/linux/proc linprocfs rw 0 0 >> tmpfs/compat/linux/dev/shm tmpfs rw,mode=17770 >> 0 >> >> >> # df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/ada0p3428G245G149G62%/ >> devfs 1.0K1.0K 0B 100%/dev >> linprocfs 4.0K4.0K 0B 100%/compat/linux/proc >> tmpfs 47G4.0K 47G 0%/compat/linux/dev/shm >> tmpfs 20M604K 19M 3%/tmp >> >> I don't understand why the /tmp is being mounted. It is causing >> problems >> because when I try to run portupgrade it fails for lack of space. If >> I >> forcibly unmount it everything breaks. >> >> # umount -v /tmp >> umount: unmount of /tmp failed: Device busy >> [root@FreeBSD_13 ~]# umount -vf /tmp >> tmpfs: unmount from /tmp >> [root@FreeBSD_13 ~]# df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/ada0p3428G245G149G62%/ >> devfs 1.0K1.0K 0B 100%/dev >> linprocfs 4.0K4.0K 0B 100%/compat/linux/proc >> tmpfs 47G4.0K 47G 0%/compat/linux/dev/shm >> [root@FreeBSD_13 ~]# vinagre >> Unable to init server: Could not connect to 127.0.0.1: Connection >> refused >> >> (vinagre:27111): Gtk-WARNING **: 15:04:21.599: cannot open display: >> :0 >> >> Any help would be appreciated, thanks in advance. >> > >The problem isn't that /tmp is tmpfs, the problem is that it's being >mounted by /etc/rc.d/tmp as a 20MB filesystem because tmpsize="20m" is >the default. You could set tmpsize to some bigger value in rc.conf, or >you can add an explicit mount for /tmp in fstab so that you get the >full (47G on your system) capacity that's available: > > tmpfs /tmp tmpfs rw 0 0 > >-- Ian > > >___ >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" I've seen clients inadvertently DoS themselves when I was a Solaris admin. Solaris never used limits for tmpfs. As to how we arrived at 20m, I recall an OSF/1 course where the instructor intimated that 20m was industry best practice at the time and OSF/1 being BSD. That was a lifetime ago. Maybe it's time to consider a higher default for 2019. Anticipating a memory constrained embedded argument, people designing products would customize it anyway. -- 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: mmap port from 9 not working
Van: Laurie Jennings
Datum: maandag, 22 juli 2019 14:56
Aan: Ronald Klop
Onderwerp: Re: mmap port from 9 not working
Van: Laurie Jennings
Datum: zondag, 21 juli 2019 16:58
Aan: Konstantin Belousov
CC: FreeBSD Current
Onderwerp: Re: mmap port from 9 not working
On Sunday, July 21, 2019, 10:44:14 AM EDT, Konstantin Belousov
wrote:
On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote:
> I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a
pointer from the kernel via an ioctl and I map it into a shared buffer.
> char *kptr; // mem ptr from kernel
>
fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t)
ptr);
>
> This worked perfectly in 9; memp I had a shared block of memory between the kernel and user space.
> In 11.3 this returns an errno 22, which is pretty murky. I did notice that off_t doesnt yield an actual offset; I've tried putting in the correct value manuallybut it just fails and fails.I've tried read only also.
> Please Help!
| Start with providing (and looking yourself) at the output of kdump/ktrace
| around the failing mmap. The checks for correctness of the mmap(2) arguments
| were greatly improved during years after FreeBSD 9.
Since posting this I found a thread that said something about mmap no longer supporting /dev/kmem. If that's that case I need to find another method. No sense spending a day debugging something thatisn't supposed to work.
SHOULD this still work? This always worked fine with non-wired memory but maybe things have changed since 9.
On Monday, July 22, 2019, 8:03:33 AM EDT, Ronald Klop wrote: "
It looks like this is not possible anymore. Here is the code change with some explanation.
https://svnweb.freebsd.org/base?view=revision&revision=307332
https://reviews.freebsd.org/D8248
Just a question of my site out of interest to people who know more about this
than I do. Does Page Table Isolation (PTI) also prevent mapping /dev/kmem in
user space?
https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities#Meltdown_.28CVE-2017-5754.29
Regards,
Ronald.
"
Just FYI, I got this to work using '/dev/mem' by passing up the physical address of the block. Probably more intuitive.
Just a question; the docs say contigmalloc() returns wired memory; is this guaranteed to be the case or do I need to run vm_map_wire() on it to be sure? vm_map_lookup() doesnt return "wired" as true after a contigmalloc(); but maybe all kernel_map memory is wired?
LJ
Laurie,
I have no idea. I'll cc the mailinglist back into the conversation.
Ronald.
___
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: mmap port from 9 not working
On Mon, Jul 22, 2019 at 02:03:26PM +0200, Ronald Klop wrote:
>
> Van: Laurie Jennings
> Datum: zondag, 21 juli 2019 16:58
> Aan: Konstantin Belousov
> CC: FreeBSD Current
> Onderwerp: Re: mmap port from 9 not working
> >
> > On Sunday, July 21, 2019, 10:44:14 AM EDT, Konstantin Belousov
> > wrote:
> >
> > On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote:
> > > I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a
> > > pointer from the kernel via an ioctl and I map it into a shared buffer.
> > > char *kptr; // mem ptr from kernel
> > > fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t)
> > > ptr);
> > >
> > > This worked perfectly in 9; memp I had a shared block of memory between
> > > the kernel and user space.
> > > In 11.3 this returns an errno 22, which is pretty murky. I did notice
> > > that off_t doesnt yield an actual offset; I've tried putting in the
> > > correct value manuallybut it just fails and fails.I've tried read only
> > > also.
> > > Please Help!
> >
> > | Start with providing (and looking yourself) at the output of kdump/ktrace
> > | around the failing mmap. The checks for correctness of the mmap(2)
> > arguments
> > | were greatly improved during years after FreeBSD 9.
> > Since posting this I found a thread that said something about mmap no
> > longer supporting /dev/kmem. If that's that case I need to find another
> > method. No sense spending a day debugging something thatisn't supposed to
> > work.
> > SHOULD this still work? This always worked fine with non-wired memory but
> > maybe things have changed since 9.
> >
> It looks like this is not possible anymore. Here is the code change with some
> explanation.
> https://svnweb.freebsd.org/base?view=revision&revision=307332
> https://reviews.freebsd.org/D8248
>
> Just a question of my site out of interest to people who know more about this
> than I do. Does Page Table Isolation (PTI) also prevent mapping /dev/kmem in
> user space?
> https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities#Meltdown_.28CVE-2017-5754.29
KPTI has nothing to do with that.
___
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: mmap port from 9 not working
Van: Laurie Jennings
Datum: zondag, 21 juli 2019 16:58
Aan: Konstantin Belousov
CC: FreeBSD Current
Onderwerp: Re: mmap port from 9 not working
On Sunday, July 21, 2019, 10:44:14 AM EDT, Konstantin Belousov
wrote:
On Sun, Jul 21, 2019 at 03:48:03AM +, Laurie Jennings wrote:
> I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a
pointer from the kernel via an ioctl and I map it into a shared buffer.
> char *kptr; // mem ptr from kernel
>
fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t)
ptr);
>
> This worked perfectly in 9; memp I had a shared block of memory between the kernel and user space.
> In 11.3 this returns an errno 22, which is pretty murky. I did notice that off_t doesnt yield an actual offset; I've tried putting in the correct value manuallybut it just fails and fails.I've tried read only also.
> Please Help!
| Start with providing (and looking yourself) at the output of kdump/ktrace
| around the failing mmap. The checks for correctness of the mmap(2) arguments
| were greatly improved during years after FreeBSD 9.
Since posting this I found a thread that said something about mmap no longer supporting /dev/kmem. If that's that case I need to find another method. No sense spending a day debugging something thatisn't supposed to work.
SHOULD this still work? This always worked fine with non-wired memory but maybe things have changed since 9.
It looks like this is not possible anymore. Here is the code change with some
explanation.
https://svnweb.freebsd.org/base?view=revision&revision=307332
https://reviews.freebsd.org/D8248
Just a question of my site out of interest to people who know more about this
than I do. Does Page Table Isolation (PTI) also prevent mapping /dev/kmem in
user space?
https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities#Meltdown_.28CVE-2017-5754.29
Regards,
Ronald.
___
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"
