Re: Only 1TB RAM out of 1.5TB on amd64

[Bernd Walter]

On Wed, Mar 27, 2024 at 05:55:20PM +0200, Konstantin Belousov wrote:
> On Wed, Mar 27, 2024 at 03:01:11AM +0100, Bernd Walter wrote:
> > Same Problem with current:
> > reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 
> > 2024
> >  
> > real memory  = 1649265344512 (1572862 MB)
> > avail memory = 1057118396416 (1008146 MB)
> Real memory is really the max physical address of the valid byte.
> If you have holes in the phys map, real memory should reflect these
> holes.  Avail memory is the total memory as reported by EFI map.

Damn - thank you very much.
That was the answer.
I was under the impression that the machine has 1.5T installed, but in
fact it has only 1T installed.
I was expecting holes because of NUMA, but my assumption was more that
the holes would led to memory being outside of the direct map space.

> 
> Verify all that by looking at sysctl machdep.efi_map output.
> > 
> > On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote:
> > > ..
> > > real memory  = 1649265344512 (1572862 MB)
> > > avail memory = 105713704 (1008166 MB)
> > > ..
> > > 
> > > I suspect address space issues, but don't know for sure.
> > > Changing NUMA nodes per socket in the BIOS had an influence to make it
> > > worse, but not better.
> > > 
> > > 
> > > Copyright (c) 1992-2021 The FreeBSD Project.
> > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > > The Regents of the University of California. All rights reserved.
> > > FreeBSD is a registered trademark of The FreeBSD Foundation.
> > > FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64
> > > FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git 
> > > llvmorg-17.0.6-0-g6009708b4367)
> > > VT(efifb): resolution 1024x768
> > > CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz 
> > > K8-class CPU)
> > >   Origin="AuthenticAMD"  Id=0x830f10  Family=0x17  Model=0x31  Stepping=0
> > >   
> > > Features=0x178bfbff
> > >   
> > > Features2=0x7ed8320b
> > >   AMD Features=0x2e500800
> > >   AMD 
> > > Features2=0x75c237ff
> > >   Structured Extended 
> > > Features=0x219c91a9
> > >   Structured Extended Features2=0x44
> > >   XSAVE Features=0xf
> > >   AMD Extended Feature Extensions ID 
> > > EBX=0x18cf757
> > >   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
> > >   TSC: P-state invariant, performance statistics
> > > real memory  = 1649265344512 (1572862 MB)
> > > avail memory = 105713704 (1008166 MB)
> > > Event timer "LAPIC" quality 600
> > > ACPI APIC Table: 
> > > FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs
> > > FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware 
> > > threads
> > > random: registering fast source Intel Secure Key RNG
> > > random: fast provider: "Intel Secure Key RNG"
> > > random: unblocking device.
> > > ioapic0  irqs 0-23
> > > ioapic1  irqs 24-55
> > > ioapic2  irqs 56-87
> > > ioapic3  irqs 88-119
> > > ioapic4  irqs 120-151
> > > ioapic5  irqs 152-183
> > > ioapic6  irqs 184-215
> > > ioapic7  irqs 216-247
> > > ioapic8  irqs 248-279
> > > Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 
> > > 45 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 
> > > 76 92 33 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 
> > > 12 50 38 77 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3
> > > random: entropy device external interface
> > > kbd1 at kbdmux0
> > > ..
> > > 
> > > kern.maxphys: 1048576
> > > hw.physmem: 109930544
> > > hw.usermem: 1091323355136
> > > hw.realmem: 1649265344512
> > > vm.phys_locality: 
> > > 0: 10 32 
> > > 1: 32 10 
> > > 
> > > vm.phys_segs: 
> > > SEGMENT 0:
> > > 
> > > start: 0x1
> > > end:   0xa
> > > domain:0
> > > free list: 0x81ec7ea0
> > > 
> > > SEGMENT 1:
> > > 
> > > start: 0x10
> > > end:   0x100
> > > domain:0
> > > free list: 0x81ec7ea0
> > > 
> > > SEGMENT 2:
> > > 
> > > start: 0x100
> > > end:   0x7400
>

Re: Only 1TB RAM out of 1.5TB on amd64

[Bernd Walter]

Same Problem with current:
reeBSD 15.0-CURRENT #0 main-n268793-220ee18f1964: Thu Mar 14 02:58:39 UTC 2024
 
real memory  = 1649265344512 (1572862 MB)
avail memory = 1057118396416 (1008146 MB)

On Fri, Mar 22, 2024 at 07:54:06PM +0100, Bernd Walter wrote:
> ..
> real memory  = 1649265344512 (1572862 MB)
> avail memory = 105713704 (1008166 MB)
> ..
> 
> I suspect address space issues, but don't know for sure.
> Changing NUMA nodes per socket in the BIOS had an influence to make it
> worse, but not better.
> 
> 
> Copyright (c) 1992-2021 The FreeBSD Project.
> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> The Regents of the University of California. All rights reserved.
> FreeBSD is a registered trademark of The FreeBSD Foundation.
> FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0 GENERIC amd64
> FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git 
> llvmorg-17.0.6-0-g6009708b4367)
> VT(efifb): resolution 1024x768
> CPU: AMD EPYC 7352 24-Core Processor (2300.07-MHz K8-class 
> CPU)
>   Origin="AuthenticAMD"  Id=0x830f10  Family=0x17  Model=0x31  Stepping=0
>   
> Features=0x178bfbff
>   
> Features2=0x7ed8320b
>   AMD Features=0x2e500800
>   AMD 
> Features2=0x75c237ff
>   Structured Extended 
> Features=0x219c91a9
>   Structured Extended Features2=0x44
>   XSAVE Features=0xf
>   AMD Extended Feature Extensions ID 
> EBX=0x18cf757
>   SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=32768
>   TSC: P-state invariant, performance statistics
> real memory  = 1649265344512 (1572862 MB)
> avail memory = 105713704 (1008166 MB)
> Event timer "LAPIC" quality 600
> ACPI APIC Table: 
> FreeBSD/SMP: Multiprocessor System Detected: 96 CPUs
> FreeBSD/SMP: 2 package(s) x 8 cache groups x 3 core(s) x 2 hardware threads
> random: registering fast source Intel Secure Key RNG
> random: fast provider: "Intel Secure Key RNG"
> random: unblocking device.
> ioapic0  irqs 0-23
> ioapic1  irqs 24-55
> ioapic2  irqs 56-87
> ioapic3  irqs 88-119
> ioapic4  irqs 120-151
> ioapic5  irqs 152-183
> ioapic6  irqs 184-215
> ioapic7  irqs 216-247
> ioapic8  irqs 248-279
> Launching APs: 32 30 34 13 14 16 23 21 19 24 28 9 86 10 87 7 26 37 39 41 45 
> 46 43 66 71 69 54 57 59 80 82 78 49 53 51 60 65 62 84 88 91 95 74 73 76 92 33 
> 40 11 2 27 22 20 5 44 18 15 36 6 8 25 89 79 85 93 56 48 70 31 81 12 50 38 77 
> 55 63 75 58 1 90 29 94 52 72 67 83 35 42 61 64 68 47 4 17 3
> random: entropy device external interface
> kbd1 at kbdmux0
> ..
> 
> kern.maxphys: 1048576
> hw.physmem: 109930544
> hw.usermem: 1091323355136
> hw.realmem: 1649265344512
> vm.phys_locality: 
> 0: 10 32 
> 1: 32 10 
> 
> vm.phys_segs: 
> SEGMENT 0:
> 
> start: 0x1
> end:   0xa
> domain:0
> free list: 0x81ec7ea0
> 
> SEGMENT 1:
> 
> start: 0x10
> end:   0x100
> domain:0
> free list: 0x81ec7ea0
> 
> SEGMENT 2:
> 
> start: 0x100
> end:   0x7400
> domain:0
> free list: 0x81ec7c30
> 
> SEGMENT 3:
> 
> start: 0x74043000
> end:   0x75db
> domain:0
> free list: 0x81ec7c30
> 
> SEGMENT 4:
> 
> start: 0x7600
> end:   0x963b8000
> domain:0
> free list: 0x81ec7c30
> 
> SEGMENT 5:
> 
> start: 0x963c2000
> end:   0x963f9000
> domain:0
> free list: 0x81ec7c30
> 
> SEGMENT 6:
> 
> start: 0x9650
> end:   0xa57f7000
> domain:0
> free list: 0x81ec7c30
> 
> SEGMENT 7:
> 
> start: 0xa8e96000
> end:   0xac00
> domain:0
> free list: 0x81ec7c30
> 
> SEGMENT 8:
> 
> start: 0x1e000
> end:   0x7d0780
> domain:0
> free list: 0x81ec79c0
> 
> SEGMENT 9:
> 
> start: 0x1019000
> end:   0x1797de0
> domain:1
> free list: 0x81ec8110
> 
> SEGMENT 10:
> 
> start: 0x17ffdc0
> end:   0x17ffdde7000
> domain:1
> free list: 0x81ec8110
> 
> 
> 
> -- 
> B.Walter  https://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> 

-- 
B.Walter  https://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Re: nvdXpY dissapears while ZFS pool on it is imported

[Bernd Walter]

On Sat, Oct 05, 2019 at 02:50:21PM +0900, Tomoaki AOKI wrote:
> Hi.
> 
> By sets of commits starting from r351355 though r351747, nvd driver
> creates partitioned GEOM provider like /dev/nvd0p1.
> 
> Unfortunately, these partitioned GEOM providers dissapears when
> importing ZFS pool on it leaving /dev/nvd0, and re-appears when
> exporting the pool.
> 
> Mounting filesystems other than ZFS (at least msdosfs) doesn't
> affect.

It is not ZFS itself, it is the use of /dev/diskid/*, which ZFS prefers
to open.
Either explicitly import the volume with /dev/nvd* or use the other
partitions with /dev/diskid/*
What really sucks is that volume labels also disappear - e.g. /dev/msdosfs.

> 
> 
> Details:
> 
> I recently got ThinkPad P52 having one NVMe SSD and one 2.5 inch
> SATA SSD.
> NVMe SSD has stable/12 and SATA SSD has head on it.
> Both are partitioned and installed on old ThinkPad T420, using
> UltraBay slim adapter for SATA, and USB converter for NVMe,
> without using installer and placed into P52, removing Windoze HDD.
> Both are ROOT-on-ZFS.
> Swap on NVMe SSD is specified using diskid in fstab.
> 
> At first, I didn't noticed the problem as head with before-mentioned
> commits gracefully creates nvd0p*.
> But I noticed stable/12 having before-mentioned commits MFC'ed
> (r351903 through r351914) creates only nvd0 just as before.
> 
> Importing pool on SATA SSD from stable/12 on NVMe does NOT affect.
> 
> I tried importing on NVMe SSD from head on SATA, and noticed
> nvd0p* disappears leaving nvd0, and re-appears on export.
> 
> Any solutions?
> 
> Regards.
> 
> -- 
> Tomoaki AOKI
> ___
> 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"

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: ZFS with 32-bit, non-x86 kernel

[Bernd Walter]

On Fri, Oct 04, 2019 at 09:53:07PM +0200, Marek Zarychta wrote:
> On 04.10.2019 21:37, Ian Lepore wrote:
> > On Fri, 2019-10-04 at 13:27 -0600, Warner Losh wrote:
> >> On Fri, Oct 4, 2019, 1:07 PM Dennis Clarke  wrote:
> >>
> >>> On 10/4/19 10:05 AM, Andriy Gapon wrote:
> >>>>
> >>>> Does anyone use ZFS with a 32-bit kernel, that is also not i386 ?
> >>>> If you do, could you please let me know?  Along with uname -rmp output.
> >>>> Thank you!
> >>>>
> >>>
> >>> I don't know if that has even been attempted by anyone. The ZIL and ZFS
> >>> log comonents require substantial amounts of memory and I am not aware
> >>> of anyone with arm devices that have 8GB+ of memory. I have had FreeBSD
> >>> current on RISC-V running fairly well with ZFS however that was a purely
> >>> rv64imafdc architecture.
> >>>
> >>
> >> In the FreeBSD 10 time frame I know people were running ZFS on arm7 boards.
> >> Iirc, there was a long list of tweaks needed to size of the ZIL. A quick
> >> google didn't find it.
> >>
> >> Otoh, I looked at ZFS for NanoBSD when it first came out. I gave up because
> >> the 256MB boards at the time made any kind of storage traffic ran things
> >> out of memory.
> >>
> >> Warner
> >>
> >>
> >> I will watch this thread with curiosity.
> > 
> > There have been several threads about using zfs on armv7 over the
> > years.  Some of them are from 2013 and indicate little sucess.  Others,
> > from 2015, indicate it works...
> > 
> > https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010607.html
> > https://lists.freebsd.org/pipermail/freebsd-arm/2015-March/010649.html
> > 
> > There have also been some bug reports as recently as 2017 indicating
> > that people are still doing this on small armv7 systems.
> > 
> > -- Ian
> 
> Following this thread, where Bernd Walter wrote small howto:
> 
> https://lists.freebsd.org/pipermail/freebsd-arm/2019-February/019455.html
> 
> I had converted root filesystem to ZFS on SD card used with
> RaspberryPi2, then used it with no issues running 13-CURRENT for 6
> months until that old SD card got worn.

Yes, a system with 1G RAM works fine.
I use it mostly on 64 bit systems, like Pi3, Pine64, Pinebook, ...
All of them are 1G-2G RAM.
But I also have a lot of 2GB Wandboards, which are 32bit, have two uSD
slots and work great.
I also have some 1GB Allwinner A20 boards with 1GB RAM and two uSD slots
on which I might do it as well to give those boards a purpose.
SD cards are notorious for problems after power failure.
ZFS works great with flash based media and can handle such media errors
just fine.
I'm running two wandboards in such a zroot mirror setup to programm
microcontrollers with avrdude, openocd, run TTL-UART, ...
A lot of missuse and since they are running headless I often just
powercycle them if something with USB hangs again.
I also found out that reversing an A-Plug can produce a short circuit
on the host 5V rail and zroot survided those spontanous reboots just
fine.
Would be a shame if I couldn't use the wandboards anymore.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: ZFS with 32-bit, non-x86 kernel

[Bernd Walter]

On Fri, Oct 04, 2019 at 05:05:25PM +0300, Andriy Gapon wrote:
> 
> Does anyone use ZFS with a 32-bit kernel, that is also not i386 ?
> If you do, could you please let me know?  Along with uname -rmp output.
> Thank you!

[51]wb1# uname -rmp
12.0-RELEASE arm armv7

It is a wandboard qaud with iMX6 and 2G RAM.
I'm using two uSD cards with zroot.

I'm also using the same setup on a raspberry Pi1:
[13]time1# uname -rmp
12.0-RELEASE arm armv6
But 512MB RAM are to low for zroot.
It technically does work, but hoks up the CPU in arc_reclaim_thread when
a scrub runs and since it takes forever it always runs.

last pid: 80786;  load averages:  6.56,  5.86,  5.75   up 185+05:51:55 11:10:04
372 threads:   5 running, 349 sleeping, 18 waiting
CPU:  0.1% user,  0.0% nice, 86.9% system,  3.8% interrupt,  9.2% idle
Mem: 4960K Active, 38M Inact, 128M Wired, 259M Free
ARC: 24M Total, 8591K MFU, 8896K MRU, 34K Anon, 251K Header, 6888K Other
 2676K Compressed, 74M Uncompressed, 28.31:1 Ratio
Swap: 

  PID USERNAMEPRI NICE   SIZERES STATETIMEWCPU COMMAND
8 root -8-  096K arc_re 1597.2  53.94% 
zfskern{arc_reclaim_thread}
   10 root155 ki31  0   8192 RUN1765.3   9.26% idle
0 root -8-  0  2064K -   75.7H   2.63% 
kernel{dp_sync_taskq}
   11 root-80-  0   144K WAIT67.8H   1.88% intr{intc0,28: 
bcm_dma0}
   20 root -8-  0   8192 mmcreq  39.0H   1.31% mmcsd0: mmc/sd 
card
   12 root -8-  024K -   27.4H   0.87% geom{g_down}
   11 root-60-  0   144K WAIT28.6H   0.74% intr{swi4: clock 
(0)}
   11 root-88-  0   144K WAIT21.1H   0.66% intr{intc0,70: +}
   12 root -8-  024K -   19.3H   0.64% geom{g_up}

[16]time1# zpool status
  pool: zroot
 state: ONLINE
  scan: scrub in progress since Mon Jun 10 03:58:19 2019
34.0G scanned at 3.52K/s, 867M issued at 89/s, 1.77G total
0 repaired, 47.78% done, no estimated completion time
config:

NAME STATE READ WRITE CKSUM
zrootONLINE   0 0 0
  mirror-0   ONLINE   0 0 0
diskid/DISK-081Cs2a  ONLINE   0 0 0
da0s2a   ONLINE   0 0 0

errors: No known data errors

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: What is evdev and autoloading?

[Bernd Walter]

On Mon, Feb 18, 2019 at 01:43:22PM +0100, Niclas Zeising wrote:
> On 2/18/19 12:06 PM, Stefan Blachmann wrote:
> >On 2/18/19, Vladimir Kondratyev  wrote:
> >>On 2019-02-17 21:03, Steve Kargl wrote:
> >>>Anyone have insight into what evdev is?
> >>evdev.ko is a small in-kernel library that makes all your input events
> >>like keyboard presses libinput-compatible.
> >
> >And libinput was created by the Freedesktop Wayland team to create
> >pressure on OS people to make their systems Wayland-compatible.
> >
> >>>I do not need nor what these modules loaded.
> >>I think removing "option EVDEV_SUPPORT" from your kernel config should
> >>disable most of evdev.ko dependencies
> >
> >Shouldn't the EVDEV_SUPPORT default be off on FreeBSD anyway, as well
> >as libinput not be part of the standard packages?
> >
> >The Freedesktop Wayland team consists of people with the Kay Sievers
> >mentality, which made Linus Torvalds ban his contributions. They do
> >not care about the bugs they introduce, forcing others to clean up the
> >mess they create.
> >
> >I'd be glad if FreeBSD would keep clean of following that Wayland fad...
> 
> EVDEV_SUPPORT was enabled in GENERIC on 13 and 12-stable to improve 
> input device handling in X and Wayland.  Not having it means that a lot 
> of input devices stop working, or work much worse.

I use it to run a wmt(4) touchpanel display, which wouldn't work otherwise.
I have to say that I kind of like the evdev system as it also makes it very
easy to place events from userland processes.
What I don't like is that we had no autosetup support in XOrg when I first
used it - in the meantime this might have changed however.

> 
> We in the FreeBSD Graphics Team are working very hard to improve the 
> FreeBSD Desktop experience, since it is an avenue to recruit new users, 
> and make current users use FreeBSD more.
> 
> Evdev and libinput is used by both Wayland and xorg.  You are free to 
> use either one.
> 
> Regards
> -- 
> Niclas Zeising
> FreeBSD Graphics Team
> ___
> 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"

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Mon, Mar 26, 2018 at 01:28:06AM +0200, Bernd Walter wrote:
> I somehow suspect that the device is dropping data, when the driver isn't
> retrieving it fast enough.
> I can't say for sure however, because usbdump has more interupt packets than
> there is events on the /dev/input , although X and Y coordinates come in the
> same packet.
> But I couldn't isolate the button packets yet.

The 10" (not the early model I had before) is working fine now using wmt(4).
I'd tested with wmt(4) before, but it failed.
Interestingly xf86-input-mouse via usbhidlib did work with mouse emulation on
the 7", which the 10" doesn't have, but the emulation of the device was bad
and in touch mode X crashed on both displays during device init.
uep(4) doesn't work at all, it is for a completely different protocol used on
some older eGalax devices - obviously some with resistive touch, but not sure.
Similar the egalax_ts.c in webcamd is only for the older eGalax devices.
Have to see why wmt(4) doesn't like the older devices, maybe this can be fixed.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Mon, Mar 26, 2018 at 01:11:28AM +0200, Bernd Walter wrote:
> On Mon, Mar 12, 2018 at 12:12:47PM +0100, Bernd Walter wrote:
> > On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote:
> > > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> > > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, 
> > > but
> > > it always needed some special binary support for Linux, no surprises here.
> > > The newer Rev 2.1 with the IPS panel claims to be the same and work with
> > > webcamd, at least I get data via /dev/input/event0, which looks reasonable
> > > with evdev-dump.
> > > That's an interesting starting point.
> > 
> > I've got a new model of the 10" HDMI B.
> > It behaves differently.
> > First of all - uep seems to take it, which it didn't for any of
> > the previous displays I'd tested.
> > I had to remove the driver from the loader.conf to have webcamd attach to 
> > it.
> > webcamd attaches fine and it delivers touch events:
> > [29]sa# evdev-dump /dev/input/event0
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x01CF
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x025E
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x0005
> > /dev/input/event0  3041705595.425438 EV_KEY BTN_TOUCH 0x0001
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_X 0x01CF
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_Y 0x025E
> > /dev/input/event0  3041705595.425438 EV_ABS ABS_PRESSURE 0x0005
> > /dev/input/event0  3041705595.425438 EV_SYN SYN_REPORT 0x
> > 
> > Whatever had been the cause for my previous problem, they obviously
> > have fixed them in firmware.
> 
> Unfortunately I still have some problems.
> [63]sa# evdev-dump /dev/input/event1
> /dev/input/event1  3043946310.664423 EV_ABS ABS_MT_TRACKING_ID 0x003F
> /dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_X 0x01C9
> /dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_Y 0x0112
> /dev/input/event1  3043946310.664423 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946310.664423 EV_ABS ABS_X 0x01C9
> /dev/input/event1  3043946310.664423 EV_ABS ABS_Y 0x0112
> /dev/input/event1  3043946310.664423 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946310.784395 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event1  3043946310.784395 EV_KEY BTN_TOUCH 0x
> /dev/input/event1  3043946310.784395 EV_SYN SYN_REPORT 0x
> 
> 
> 
> 
> /dev/input/event1  3043946316.944324 EV_ABS ABS_MT_TRACKING_ID 0x0040
> /dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_X 0x01CE
> /dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_Y 0x00FE
> /dev/input/event1  3043946316.944324 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946316.944324 EV_ABS ABS_X 0x01CE
> /dev/input/event1  3043946316.944324 EV_ABS ABS_Y 0x00FE
> /dev/input/event1  3043946316.944324 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946317.004303 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event1  3043946317.004303 EV_KEY BTN_TOUCH 0x
> /dev/input/event1  3043946317.004303 EV_SYN SYN_REPORT 0x
> 
> 
> 
> /dev/input/event1  3043946319.744283 EV_ABS ABS_MT_TRACKING_ID 0x0041
> /dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_X 0x020E
> /dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_Y 0x00D8
> /dev/input/event1  3043946319.744283 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946319.744283 EV_ABS ABS_X 0x020E
> /dev/input/event1  3043946319.744283 EV_ABS ABS_Y 0x00D8
> /dev/input/event1  3043946319.744283 EV_SYN SYN_REPORT 0x
> /dev/input/event1  3043946319.864240 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event1  3043946319.864240 EV_KEY BTN_TOUCH 0x
> /dev/input/event1  3043946319.864240 EV_SYN SYN_REPORT 0x
> 
> 
> 
> /dev/input/event1  3043946322.004229 EV_ABS ABS_MT_TRACKING_ID 0x0042
> /dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_X 0x0209
> /dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_Y 0x00CD
> /dev/input/event1  3043946322.004229 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event1  3043946322.004229 EV_ABS ABS_X 0x0209
> /dev/input/event1  3043946322.004229 EV_ABS ABS_Y 0x00CD
> /dev/input/event1  3043946322.004229 EV_SYN SYN_REPORT 0x
> 
> 
> 
> 
> /dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_X 0x016A
> /dev/input/event1  3043946325.454187 EV

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Mon, Mar 12, 2018 at 12:12:47PM +0100, Bernd Walter wrote:
> On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote:
> > On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> > So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but
> > it always needed some special binary support for Linux, no surprises here.
> > The newer Rev 2.1 with the IPS panel claims to be the same and work with
> > webcamd, at least I get data via /dev/input/event0, which looks reasonable
> > with evdev-dump.
> > That's an interesting starting point.
> 
> I've got a new model of the 10" HDMI B.
> It behaves differently.
> First of all - uep seems to take it, which it didn't for any of
> the previous displays I'd tested.
> I had to remove the driver from the loader.conf to have webcamd attach to it.
> webcamd attaches fine and it delivers touch events:
> [29]sa# evdev-dump /dev/input/event0
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x01CF
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x025E
> /dev/input/event0  3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x0005
> /dev/input/event0  3041705595.425438 EV_KEY BTN_TOUCH 0x0001
> /dev/input/event0  3041705595.425438 EV_ABS ABS_X 0x01CF
> /dev/input/event0  3041705595.425438 EV_ABS ABS_Y 0x025E
> /dev/input/event0  3041705595.425438 EV_ABS ABS_PRESSURE 0x0005
> /dev/input/event0  3041705595.425438 EV_SYN SYN_REPORT 0x
> 
> Whatever had been the cause for my previous problem, they obviously
> have fixed them in firmware.

Unfortunately I still have some problems.
[63]sa# evdev-dump /dev/input/event1
/dev/input/event1  3043946310.664423 EV_ABS ABS_MT_TRACKING_ID 0x003F
/dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_X 0x01C9
/dev/input/event1  3043946310.664423 EV_ABS ABS_MT_POSITION_Y 0x0112
/dev/input/event1  3043946310.664423 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946310.664423 EV_ABS ABS_X 0x01C9
/dev/input/event1  3043946310.664423 EV_ABS ABS_Y 0x0112
/dev/input/event1  3043946310.664423 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946310.784395 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event1  3043946310.784395 EV_KEY BTN_TOUCH 0x
/dev/input/event1  3043946310.784395 EV_SYN SYN_REPORT 0x




/dev/input/event1  3043946316.944324 EV_ABS ABS_MT_TRACKING_ID 0x0040
/dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_X 0x01CE
/dev/input/event1  3043946316.944324 EV_ABS ABS_MT_POSITION_Y 0x00FE
/dev/input/event1  3043946316.944324 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946316.944324 EV_ABS ABS_X 0x01CE
/dev/input/event1  3043946316.944324 EV_ABS ABS_Y 0x00FE
/dev/input/event1  3043946316.944324 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946317.004303 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event1  3043946317.004303 EV_KEY BTN_TOUCH 0x
/dev/input/event1  3043946317.004303 EV_SYN SYN_REPORT 0x



/dev/input/event1  3043946319.744283 EV_ABS ABS_MT_TRACKING_ID 0x0041
/dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_X 0x020E
/dev/input/event1  3043946319.744283 EV_ABS ABS_MT_POSITION_Y 0x00D8
/dev/input/event1  3043946319.744283 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946319.744283 EV_ABS ABS_X 0x020E
/dev/input/event1  3043946319.744283 EV_ABS ABS_Y 0x00D8
/dev/input/event1  3043946319.744283 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946319.864240 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event1  3043946319.864240 EV_KEY BTN_TOUCH 0x
/dev/input/event1  3043946319.864240 EV_SYN SYN_REPORT 0x



/dev/input/event1  3043946322.004229 EV_ABS ABS_MT_TRACKING_ID 0x0042
/dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_X 0x0209
/dev/input/event1  3043946322.004229 EV_ABS ABS_MT_POSITION_Y 0x00CD
/dev/input/event1  3043946322.004229 EV_KEY BTN_TOUCH 0x0001
/dev/input/event1  3043946322.004229 EV_ABS ABS_X 0x0209
/dev/input/event1  3043946322.004229 EV_ABS ABS_Y 0x00CD
/dev/input/event1  3043946322.004229 EV_SYN SYN_REPORT 0x




/dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_X 0x016A
/dev/input/event1  3043946325.454187 EV_ABS ABS_MT_POSITION_Y 0x00D2
/dev/input/event1  3043946325.454187 EV_ABS ABS_X 0x016A
/dev/input/event1  3043946325.454187 EV_ABS ABS_Y 0x00D2
/dev/input/event1  3043946325.454187 EV_SYN SYN_REPORT 0x
/dev/input/event1  3043946325.574174 EV_ABS ABS_MT_POSITION_X 0x016B
/dev/input/event1  3043946325.574174 EV_ABS ABS_X 0x016B
/dev/input/event1  3043946325.574174 EV_SYN SYN_REPORT 0x

All 5 blocks are a single touch, which means finger on screen for a short
moment.
On the firs

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote:
> On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> > On Fri, Mar 09, 2018 at 01:19:54PM +0100, Hans Petter Selasky wrote:
> > > On 03/09/18 12:40, Bernd Walter wrote:
> > > >Will do the quirk test later.
> > > 
> > > I don't see any stalls during plug-in, so it might be a request webcamd 
> > > issues, which the device doesn't support. Try building webcamd with 
> > > debug support.
> > 
> > It is already build with debug.
> > But I don't see anything of special interest in the output.
> > 
> > [24]sa# webcamd -d ugen0.4
> > Linux video capture interface: v2.00
> > IR NEC protocol handler initialized
> > IR RC5(x/sz) protocol handler initialized
> > IR RC6 protocol handler initialized
> > IR JVC protocol handler initialized
> > IR Sony protocol handler initialized
> > IR SANYO protocol handler initialized
> > IR LIRC bridge handler initialized
> > IR XMP protocol handler initialized
> > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded 
> > successfully
> > USB Video Class driver (1.1.1)
> > cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
> > pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> > pvrusb2: Debug mask is 31 (0x1f)
> > USBVision USB Video Device Driver for Linux : 0.9.11
> > Attached to ugen0.4[0]
> > INFO: 0003:0EEF:0005.0001: input: USB HID v1.10 Mouse [BYZHYYZHY By ZH851] 
> > on usb-/dev/usb-/dev/usb/input0
> > 
> > DBG: 0003:0EEF:0005.0001: Kicking head 1 tail 0
> > Creating /dev/input/event0
> > 
> > I will redo a test with raspbian.
> > Waveshare delivered a binary kernel (so much about GPL) for their 7" HDMI C
> > until they changed something in the device firmware and upgraded for a newer
> > panel about 2-3 years ago.
> > This is the 10.1" HMDI B and it is a very early version I have, which 
> > however
> > should use a firmware similar to the newer 7" HDMI C.
> > I will retest with a stock Raspbian image to be sure I wasn't accidently
> > using a Waveshare image back then.
> > As far as I can see the Linux drivers just quirk the device to the egalaxy
> > driver, so they do know the Waveshare by ID.
> > I couldn't spot a difference between Linux and what is included in the 
> > webcamd
> > source.
> 
> So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but
> it always needed some special binary support for Linux, no surprises here.
> The newer Rev 2.1 with the IPS panel claims to be the same and work with
> webcamd, at least I get data via /dev/input/event0, which looks reasonable
> with evdev-dump.
> That's an interesting starting point.

I've got a new model of the 10" HDMI B.
It behaves differently.
First of all - uep seems to take it, which it didn't for any of
the previous displays I'd tested.
I had to remove the driver from the loader.conf to have webcamd attach to it.
webcamd attaches fine and it delivers touch events:
[29]sa# evdev-dump /dev/input/event0
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x01CF
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x025E
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x0005
/dev/input/event0  3041705595.425438 EV_KEY BTN_TOUCH 0x0001
/dev/input/event0  3041705595.425438 EV_ABS ABS_X 0x01CF
/dev/input/event0  3041705595.425438 EV_ABS ABS_Y 0x025E
/dev/input/event0  3041705595.425438 EV_ABS ABS_PRESSURE 0x0005
/dev/input/event0  3041705595.425438 EV_SYN SYN_REPORT 0x

Whatever had been the cause for my previous problem, they obviously
have fixed them in firmware.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> On Fri, Mar 09, 2018 at 01:19:54PM +0100, Hans Petter Selasky wrote:
> > On 03/09/18 12:40, Bernd Walter wrote:
> > >Will do the quirk test later.
> > 
> > I don't see any stalls during plug-in, so it might be a request webcamd 
> > issues, which the device doesn't support. Try building webcamd with 
> > debug support.
> 
> It is already build with debug.
> But I don't see anything of special interest in the output.
> 
> [24]sa# webcamd -d ugen0.4
> Linux video capture interface: v2.00
> IR NEC protocol handler initialized
> IR RC5(x/sz) protocol handler initialized
> IR RC6 protocol handler initialized
> IR JVC protocol handler initialized
> IR Sony protocol handler initialized
> IR SANYO protocol handler initialized
> IR LIRC bridge handler initialized
> IR XMP protocol handler initialized
> b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded 
> successfully
> USB Video Class driver (1.1.1)
> cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
> pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> pvrusb2: Debug mask is 31 (0x1f)
> USBVision USB Video Device Driver for Linux : 0.9.11
> Attached to ugen0.4[0]
> INFO: 0003:0EEF:0005.0001: input: USB HID v1.10 Mouse [BYZHYYZHY By ZH851] on 
> usb-/dev/usb-/dev/usb/input0
> 
> DBG: 0003:0EEF:0005.0001: Kicking head 1 tail 0
> Creating /dev/input/event0
> 
> I will redo a test with raspbian.
> Waveshare delivered a binary kernel (so much about GPL) for their 7" HDMI C
> until they changed something in the device firmware and upgraded for a newer
> panel about 2-3 years ago.
> This is the 10.1" HMDI B and it is a very early version I have, which however
> should use a firmware similar to the newer 7" HDMI C.
> I will retest with a stock Raspbian image to be sure I wasn't accidently
> using a Waveshare image back then.
> As far as I can see the Linux drivers just quirk the device to the egalaxy
> driver, so they do know the Waveshare by ID.
> I couldn't spot a difference between Linux and what is included in the webcamd
> source.

So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but
it always needed some special binary support for Linux, no surprises here.
The newer Rev 2.1 with the IPS panel claims to be the same and work with
webcamd, at least I get data via /dev/input/event0, which looks reasonable
with evdev-dump.
That's an interesting starting point.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Fri, Mar 09, 2018 at 01:19:54PM +0100, Hans Petter Selasky wrote:
> On 03/09/18 12:40, Bernd Walter wrote:
> >Will do the quirk test later.
> 
> I don't see any stalls during plug-in, so it might be a request webcamd 
> issues, which the device doesn't support. Try building webcamd with 
> debug support.

It is already build with debug.
But I don't see anything of special interest in the output.

[24]sa# webcamd -d ugen0.4
Linux video capture interface: v2.00
IR NEC protocol handler initialized
IR RC5(x/sz) protocol handler initialized
IR RC6 protocol handler initialized
IR JVC protocol handler initialized
IR Sony protocol handler initialized
IR SANYO protocol handler initialized
IR LIRC bridge handler initialized
IR XMP protocol handler initialized
b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded 
successfully
USB Video Class driver (1.1.1)
cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
pvrusb2: Debug mask is 31 (0x1f)
USBVision USB Video Device Driver for Linux : 0.9.11
Attached to ugen0.4[0]
INFO: 0003:0EEF:0005.0001: input: USB HID v1.10 Mouse [BYZHYYZHY By ZH851] on 
usb-/dev/usb-/dev/usb/input0

DBG: 0003:0EEF:0005.0001: Kicking head 1 tail 0
Creating /dev/input/event0

I will redo a test with raspbian.
Waveshare delivered a binary kernel (so much about GPL) for their 7" HDMI C
until they changed something in the device firmware and upgraded for a newer
panel about 2-3 years ago.
This is the 10.1" HMDI B and it is a very early version I have, which however
should use a firmware similar to the newer 7" HDMI C.
I will retest with a stock Raspbian image to be sure I wasn't accidently
using a Waveshare image back then.
As far as I can see the Linux drivers just quirk the device to the egalaxy
driver, so they do know the Waveshare by ID.
I couldn't spot a difference between Linux and what is included in the webcamd
source.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Fri, Mar 09, 2018 at 09:19:11AM +0100, Roberto Fernandez Cueto wrote:
> Roberto Fernandez-Cueto schrieb am 09.03.2018 09:19
> _
> 
> I do not if this helps, but what I usually do when I get to work with a
> new touchscreen is to see if FreeBSD detects it as UHID.

I hadn't loaded uhid, but it detects the device.

> If it is recognized, then I check if the touchscreen send absolute
> coordinates or relative coordinates.
> 
> You can do it with usbhidctl(1). See the collection, items and get the
> values parsed by the HID layer.

Well, this has to wait until I found time to read more about it.
HID is something I've always hated and never really spend much time into.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Fri, Mar 09, 2018 at 09:40:00AM +0100, Hans Petter Selasky wrote:
> On 03/09/18 01:44, Bernd Walter wrote:
> >On Thu, Mar 08, 2018 at 10:10:47PM +0100, Hans Petter Selasky wrote:
> >>You can try running usbdump to capture USB packets.
> >>
> >>ktrace is also your friend.
> >>
> >>dd if=/dev/input/event0 bs=1
> >>
> >>Also check ownership of devices, that X.org can read from them.
> >
> 
> Can you try connecting the device through an external USB HUB?

This test has to wait for me to change the setup

> Can you capture the whole enumeration sequence. Can you also try setting 
> the UQ_NO_STRINGS quirk using usbconfig for this device and re-plug it?

This is on plug in:
[25]sa# usbdump -v -v -v -v -f 4
11:36:27.190408 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   00 05 04 00 00 00 00 00  -- -- -- -- -- -- -- --  ||
 flags 0x50 <PROXY_BUFFER|MANUAL_STATUS|0>
 status 0xc03a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CONTROL_ACT|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.191546 usbus0.4 
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 flags 0x50 <PROXY_BUFFER|MANUAL_STATUS|0>
 status 0xc03a1 
<OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|CONTROL_ACT|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.191568 usbus0.4 SUBM-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0
 frame[0] WRITE 0 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc00a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.192542 usbus0.4 
DONE-CTRL-EP=,SPD=FULL,NFR=1,SLEN=0,IVAL=0,ERR=0
 frame[0] WRITE 0 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc00a1 <OPEN|STARTED|CONTROL_XFR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.203447 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 01 00 00 08 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 8 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.206539 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 8 bytes
   12 01 00 02 00 00 00 40  -- -- -- -- -- -- -- --  |...@|
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a1 
<OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.206618 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 01 00 00 12 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 18 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.209538 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 18 bytes
   12 01 00 02 00 00 00 40  EF 0E 05 00 00 02 01 02  |...@|
 0010  03 01 -- -- -- -- -- --  -- -- -- -- -- -- -- --  |..  |
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a1 
<OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.209578 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 02 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 2 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.212537 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 2 bytes
   04 03 -- -- -- -- -- --  -- -- -- -- -- -- -- --  |..  |
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a1 
<OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.212559 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.215537 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a1 
<OPEN|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_CALLBACK|0>
11:36:27.215561 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 03 03 09 04 02 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 2 bytes
 flags 0x10 <PROXY_BUFFER|0>
 status 0xc01a3 
<OPEN|TRANSFERRING|STARTED|CONTROL_XFR|CONTROL_HDR|CAN_CANCEL_IMMED|DOING_

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 10:10:47PM +0100, Hans Petter Selasky wrote:
> You can try running usbdump to capture USB packets.
> 
> ktrace is also your friend.
> 
> dd if=/dev/input/event0 bs=1
> 
> Also check ownership of devices, that X.org can read from them.

It happens earlier, /dev/input/event0 delivers nothing at all.
But usbdump is interesting.
I've booted with webcamd disabled, started usbdump and started webcamd.

This is what I get:
[22]sa# usbdump -v -f 4
00:30:09.379930 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.382401 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
00:30:09.382448 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.385398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
00:30:09.385439 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 02 03 09 04 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.388398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   12 03 42 00 -- -- -- --  -- -- -- -- -- -- -- --  |..B.|
00:30:09.388434 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 02 03 09 04 12 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 18 bytes
00:30:09.391399 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 18 bytes
   12 03 42 00 79 00 20 00  5A 00 48 00 38 00 35 00  |..B.y. .Z.H.8.5.|
 0010  31 00 -- -- -- -- -- --  -- -- -- -- -- -- -- --  |1.  |
00:30:09.391474 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.394398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
00:30:09.394435 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.397398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
00:30:09.397436 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 01 03 09 04 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.400398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   14 03 42 00 -- -- -- --  -- -- -- -- -- -- -- --  |..B.|
00:30:09.400433 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 01 03 09 04 14 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 20 bytes
00:30:09.403398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=20,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 20 bytes
    14 03 42 00 59 00 5A 00  48 00 59 00 59 00 5A 00  |..B.Y.Z.H.Y.Y.Z.|
 0010  48 00 59 00 -- -- -- --  -- -- -- -- -- -- -- --  |H.Y.|
00:30:09.403440 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.406398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
00:30:09.406437 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 00 03 00 00 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.409397 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 4 bytes
   04 03 09 04 -- -- -- --  -- -- -- -- -- -- -- --  ||
00:30:09.409434 usbus0.4 SUBM-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
 frame[0] WRITE 8 bytes
   80 06 03 03 09 04 04 00  -- -- -- -- -- -- -- --  ||
 frame[1] READ 4 bytes
00:30:09.412398 usbus0.4 
DONE-CTRL-EP=0080,SPD=FULL,NFR=2,SLEN=4,IVAL=0,ERR=0
 frame[0] WRITE 8 bytes
 frame[1] READ 

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 02:41:50PM -0800, Oleksandr Tymoshenko wrote:
> Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > On Thu, Mar 08, 2018 at 02:29:44PM -0800, Oleksandr Tymoshenko wrote:
> > > Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > > > On Thu, Mar 08, 2018 at 12:38:38PM -0800, Oleksandr Tymoshenko wrote:
> > > > > Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > > > > > On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> > > > > > https://github.com/gonzoua/evdev-dump/tree/freebsd
> > > > > > ...
> > > > > > checking for unistd.h... yes
> > > > > > checking linux/input.h usability... no
> > > > > > checking linux/input.h presence... no
> > > > > > checking for linux/input.h... no
> > > > > > checking for /usr/include/linux/input.h... no
> > > > > > configure: error: /usr/include/linux/input.h not found
> > > > > > 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> > > > > > Exit 1
> > > > > 
> > > > > I've just checked, evdev-dump should be buildable:
> > > > > 
> > > > > git clone g...@github.com:gonzoua/evdev-dump.git
> > > > > cd evdev-dump
> > > > > git checkout freebsd
> > > > > sudo pkg install gawk gmake
> > > > > sh bootstrap
> > > > > ./configure
> > > > > gmake
> > > > 
> > > > That's exactly how I did.
> > > > Well - I've used git clone https://github.com/gonzoua/evdev-dump.git
> > > > Even with a fresh clone it failed at the same file.
> > > > 
> > > > I have the following:
> > > > /usr/include/dev/evdev/input.h
> > > > /usr/local/include/linux/input.h
> > > > /usr/local/include/xorg/input.h
> > > 
> > > Could you show output of "git branch" and
> > > "grep -rl /usr/include/linux/input.h ." in cloned directory?
> > 
> > [55]sa# git branch
> > * master
> > [56]sa# grep -rl /usr/include/linux/input.h .
> > ./configure.ac
> > ./autom4te.cache/output.0
> > ./autom4te.cache/output.1
> > ./configure
> > ./config.log
> 
> You need freebsd branch. master branch is unmodified
> version of upstream, all my changes are on freebsd branch.

Lol - that makes sense.

Ok - it works, but I get nothing from my display, which this is more or
less already expected.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 02:29:44PM -0800, Oleksandr Tymoshenko wrote:
> Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > On Thu, Mar 08, 2018 at 12:38:38PM -0800, Oleksandr Tymoshenko wrote:
> > > Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > > > On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> > > > https://github.com/gonzoua/evdev-dump/tree/freebsd
> > > > ...
> > > > checking for unistd.h... yes
> > > > checking linux/input.h usability... no
> > > > checking linux/input.h presence... no
> > > > checking for linux/input.h... no
> > > > checking for /usr/include/linux/input.h... no
> > > > configure: error: /usr/include/linux/input.h not found
> > > > 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> > > > Exit 1
> > > 
> > > I've just checked, evdev-dump should be buildable:
> > > 
> > > git clone g...@github.com:gonzoua/evdev-dump.git
> > > cd evdev-dump
> > > git checkout freebsd
> > > sudo pkg install gawk gmake
> > > sh bootstrap
> > > ./configure
> > > gmake
> > 
> > That's exactly how I did.
> > Well - I've used git clone https://github.com/gonzoua/evdev-dump.git
> > Even with a fresh clone it failed at the same file.
> > 
> > I have the following:
> > /usr/include/dev/evdev/input.h
> > /usr/local/include/linux/input.h
> > /usr/local/include/xorg/input.h
> 
> Could you show output of "git branch" and
> "grep -rl /usr/include/linux/input.h ." in cloned directory?

[55]sa# git branch
* master
[56]sa# grep -rl /usr/include/linux/input.h .
./configure.ac
./autom4te.cache/output.0
./autom4te.cache/output.1
./configure
./config.log

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 12:38:38PM -0800, Oleksandr Tymoshenko wrote:
> Bernd Walter (ti...@cicely7.cicely.de) wrote:
> > On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> > https://github.com/gonzoua/evdev-dump/tree/freebsd
> > ...
> > checking for unistd.h... yes
> > checking linux/input.h usability... no
> > checking linux/input.h presence... no
> > checking for linux/input.h... no
> > checking for /usr/include/linux/input.h... no
> > configure: error: /usr/include/linux/input.h not found
> > 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> > Exit 1
> 
> I've just checked, evdev-dump should be buildable:
> 
> git clone g...@github.com:gonzoua/evdev-dump.git
> cd evdev-dump
> git checkout freebsd
> sudo pkg install gawk gmake
> sh bootstrap
> ./configure
> gmake

That's exactly how I did.
Well - I've used git clone https://github.com/gonzoua/evdev-dump.git
Even with a fresh clone it failed at the same file.

I have the following:
/usr/include/dev/evdev/input.h
/usr/local/include/linux/input.h
/usr/local/include/xorg/input.h

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 09:08:49PM +0100, Bernd Walter wrote:
> On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> > This is what I have right now:
> > [20]sa# cat /etc/X11/xorg.conf 
> > 
> > Section "InputDevice"
> > Identifier  "Touchscreen"
> > Driver  "evdev"
> > Option  "Device" "/dev/input/event0"
> > EndSection
> > 
> > Section "ServerLayout"
> > Identifier  "MyLayout"
> > InputDevice "Touchscreen"
> > EndSection
> > 
> > 
> > Unfortunately now I face the next problem.
> > 
> > [112753.535] (II) Using input driver 'evdev' for 'evdev touchscreen'
> > [112753.536] (**) evdev touchscreen: always reports core events
> > [112753.536] (**) evdev: evdev touchscreen: Device: "/dev/input/event0"
> > [112753.598] (--) evdev: evdev touchscreen: Vendor 0xeef Product 0x5
> > [112753.598] (--) evdev: evdev touchscreen: Found absolute axes
> > [112753.598] (--) evdev: evdev touchscreen: Found absolute multitouch axes
> > [112753.598] (II) evdev: evdev touchscreen: No buttons found, faking one.
> > [112753.598] (--) evdev: evdev touchscreen: Found x and y absolute axes
> > [112753.598] (--) evdev: evdev touchscreen: Found absolute touchscreen
> > [112753.598] (II) evdev: evdev touchscreen: Configuring as touchscreen
> > [112753.598] (**) evdev: evdev touchscreen: YAxisMapping: buttons 4 and 5
> > [112753.598] (**) evdev: evdev touchscreen: EmulateWheelButton: 4, 
> > EmulateWheelInertia: 10, EmulateWheelTimeout: 200
> > [112753.598] (II) XINPUT: Adding extended input device "evdev touchscreen" 
> > (type: TOUCHSCREEN, id 6)
> > [112753.599] (II) evdev: evdev touchscreen: initialized for absolute axes.
> > [112753.600] (**) evdev touchscreen: (accel) keeping acceleration scheme 1
> > [112753.600] (**) evdev touchscreen: (accel) acceleration profile 0
> > [112753.600] (**) evdev touchscreen: (accel) acceleration factor: 2.000
> > [112753.600] (**) evdev touchscreen: (accel) acceleration threshold: 4
> > [112753.601] (WW) fcntl(6, F_SETOWN): Invalid argument
> > 
> > [26]sa-moeller> xinput
> >  Virtual core pointer id=2[master pointer  (3)]
> > Virtual core XTEST pointer   id=4[slave  pointer  (2)]
> > Touchscreen  id=6[slave  pointer  (2)]
> > sysmouse id=8[slave  pointer  (2)]
> >  Virtual core keyboardid=3[master keyboard (2)]
> >  Virtual core XTEST keyboard  id=5[slave  keyboard (3)]
> >  kbdmux   id=7[slave  keyboard (3)]
> > 
> > Everything looks good so far, at least in my eyes.
> > Well - wheel emulation and such sounds a bit strange, as if it is handled
> > as a touchpad and not like a touchscreen.
> > But it says type touchscreen, so I assume that's ok.
> > However, I get no touch events.
> > I've started xev fullscreen and still nothing.
> > 
> > Somewhere else I've read that /dev/input/event0 should deliver something
> > if read and a touch happens, but this is not the case for me.
> > 
> > Any ideas how I can debug this thing?
> > There was a reference somewhere about a commandline programm to run against
> > an evdev, but I can't find it anymore.
> 
> xinput test delivers nothing on the touchscreen.
> 
> Neither evtest nor evdev-dump compiles because they are both missing
> linux include files at some point.
> https://cgit.freedesktop.org/~whot/evtest/
> [48]sa> make
> make  all-am
> cc -DHAVE_CONFIG_H -I.  -g -O2 -MT evtest.o -MD -MP -MF .deps/evtest.Tpo 
> -c -o evtest.o evtest.c
> evtest.c:46:10: fatal error: 'linux/version.h' file not found
> #include 
>  ^
> 1 error generated.
> *** Error code 1
> 
> Stop.
> make[1]: stopped in /home/ticso/evtest
> *** Error code 1
> 
> Stop.
> make: stopped in /home/ticso/evtest
> Exit 1
> 
> https://github.com/gonzoua/evdev-dump/tree/freebsd
> ...
> checking for unistd.h... yes
> checking linux/input.h usability... no
> checking linux/input.h presence... no
> checking for linux/input.h... no
> checking for /usr/include/linux/input.h... no
> configure: error: /usr/include/linux/input.h not found
> 4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
> Exit 1
> 
> The touchscreen itself should be functional as it has a touch area outside
> the display, which is interpr

Re: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 08:11:31PM +0100, Bernd Walter wrote:
> This is what I have right now:
> [20]sa# cat /etc/X11/xorg.conf 
> 
> Section "InputDevice"
> Identifier  "Touchscreen"
> Driver  "evdev"
> Option  "Device" "/dev/input/event0"
> EndSection
> 
> Section "ServerLayout"
> Identifier  "MyLayout"
> InputDevice "Touchscreen"
> EndSection
> 
> 
> Unfortunately now I face the next problem.
> 
> [112753.535] (II) Using input driver 'evdev' for 'evdev touchscreen'
> [112753.536] (**) evdev touchscreen: always reports core events
> [112753.536] (**) evdev: evdev touchscreen: Device: "/dev/input/event0"
> [112753.598] (--) evdev: evdev touchscreen: Vendor 0xeef Product 0x5
> [112753.598] (--) evdev: evdev touchscreen: Found absolute axes
> [112753.598] (--) evdev: evdev touchscreen: Found absolute multitouch axes
> [112753.598] (II) evdev: evdev touchscreen: No buttons found, faking one.
> [112753.598] (--) evdev: evdev touchscreen: Found x and y absolute axes
> [112753.598] (--) evdev: evdev touchscreen: Found absolute touchscreen
> [112753.598] (II) evdev: evdev touchscreen: Configuring as touchscreen
> [112753.598] (**) evdev: evdev touchscreen: YAxisMapping: buttons 4 and 5
> [112753.598] (**) evdev: evdev touchscreen: EmulateWheelButton: 4, 
> EmulateWheelInertia: 10, EmulateWheelTimeout: 200
> [112753.598] (II) XINPUT: Adding extended input device "evdev touchscreen" 
> (type: TOUCHSCREEN, id 6)
> [112753.599] (II) evdev: evdev touchscreen: initialized for absolute axes.
> [112753.600] (**) evdev touchscreen: (accel) keeping acceleration scheme 1
> [112753.600] (**) evdev touchscreen: (accel) acceleration profile 0
> [112753.600] (**) evdev touchscreen: (accel) acceleration factor: 2.000
> [112753.600] (**) evdev touchscreen: (accel) acceleration threshold: 4
> [112753.601] (WW) fcntl(6, F_SETOWN): Invalid argument
> 
> [26]sa-moeller> xinput
>  Virtual core pointer id=2[master pointer  (3)]
> Virtual core XTEST pointer   id=4[slave  pointer  (2)]
> Touchscreen  id=6[slave  pointer  (2)]
> sysmouse id=8[slave  pointer  (2)]
>  Virtual core keyboardid=3[master keyboard (2)]
>  Virtual core XTEST keyboard  id=5[slave  keyboard (3)]
>  kbdmux   id=7[slave  keyboard (3)]
> 
> Everything looks good so far, at least in my eyes.
> Well - wheel emulation and such sounds a bit strange, as if it is handled
> as a touchpad and not like a touchscreen.
> But it says type touchscreen, so I assume that's ok.
> However, I get no touch events.
> I've started xev fullscreen and still nothing.
> 
> Somewhere else I've read that /dev/input/event0 should deliver something
> if read and a touch happens, but this is not the case for me.
> 
> Any ideas how I can debug this thing?
> There was a reference somewhere about a commandline programm to run against
> an evdev, but I can't find it anymore.

xinput test delivers nothing on the touchscreen.

Neither evtest nor evdev-dump compiles because they are both missing
linux include files at some point.
https://cgit.freedesktop.org/~whot/evtest/
[48]sa> make
make  all-am
cc -DHAVE_CONFIG_H -I.  -g -O2 -MT evtest.o -MD -MP -MF .deps/evtest.Tpo -c 
-o evtest.o evtest.c
evtest.c:46:10: fatal error: 'linux/version.h' file not found
#include 
 ^
1 error generated.
*** Error code 1

Stop.
make[1]: stopped in /home/ticso/evtest
*** Error code 1

Stop.
make: stopped in /home/ticso/evtest
Exit 1

https://github.com/gonzoua/evdev-dump/tree/freebsd
...
checking for unistd.h... yes
checking linux/input.h usability... no
checking linux/input.h presence... no
checking for linux/input.h... no
checking for /usr/include/linux/input.h... no
configure: error: /usr/include/linux/input.h not found
4.765u 3.954s 0:08.64 100.8%31397+2201k 0+27io 0pf+0w
Exit 1

The touchscreen itself should be functional as it has a touch area outside
the display, which is interpreted by the USB controller to change the
backlight.
The exact same display also worked fine on Raspbian.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: webcamd based touchscreen problem on Pi3

[Bernd Walter]

On Thu, Mar 08, 2018 at 07:30:26PM +0300, Greg wrote:
> On 03/08, Hans Petter Selasky wrote:
> >On 03/08/18 17:16, Bernd Walter wrote:
> >>Hardware is a Raspberry Pi3 with current r330034.
> >>I'm trying to run a USB touchscreen.
> >>Tested wmt and uep, but neither wants to attach, although the Waveshare
> >>display I'm using is likely running an egalaxy firmware.
> >>However webcamd accepts the device and creates a /dev/input/event0.
> >>But I can't get X to use it.
> >>xf86-input-evdev-2.10.5 is installed and it created an X config file
> >>under /usr/local/share/X11/xorg.conf.d/10-evdev.conf.
> >>I also tried some google results in /etc/X11/xorg.conf, but X never
> >>touches the device:
> >
> >See here:
> >
> >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678
> 
> Or here:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222609
> 
> But that's all about hotplug. It is definitely possible to manually 
> configure the device on the stock xorg-server package. I can't say if 
> the "google results" are correct without actually seeing them, but it 
> should explicitly specify the /dev/input/event0 path.

Thank you both for the links.
I'd already seen them and had been a bit confused if they are required or
not and also found references that a manual configuration should work.

On Thu, Mar 08, 2018 at 05:36:06PM +0100, Roberto Fernandez Cueto wrote:
> Roberto Fernandez-Cueto schrieb am 08.03.2018 17:36
> _
> 
> You have to explicitely tell Xorg that you want to use the touch with
> the layout.
> 
> Something like,
> 
> Section "ServerLayout"
>   Identifier  "MyLayout"
>   InputDevice "touchscreen"
> EndSection

Thank you - this was the missing link, why my static configuration failed.
I'd only setup the InputDevice section.

This is what I have right now:
[20]sa# cat /etc/X11/xorg.conf 

Section "InputDevice"
Identifier  "Touchscreen"
Driver  "evdev"
Option  "Device" "/dev/input/event0"
EndSection

Section "ServerLayout"
Identifier  "MyLayout"
InputDevice "Touchscreen"
EndSection


Unfortunately now I face the next problem.

[112753.535] (II) Using input driver 'evdev' for 'evdev touchscreen'
[112753.536] (**) evdev touchscreen: always reports core events
[112753.536] (**) evdev: evdev touchscreen: Device: "/dev/input/event0"
[112753.598] (--) evdev: evdev touchscreen: Vendor 0xeef Product 0x5
[112753.598] (--) evdev: evdev touchscreen: Found absolute axes
[112753.598] (--) evdev: evdev touchscreen: Found absolute multitouch axes
[112753.598] (II) evdev: evdev touchscreen: No buttons found, faking one.
[112753.598] (--) evdev: evdev touchscreen: Found x and y absolute axes
[112753.598] (--) evdev: evdev touchscreen: Found absolute touchscreen
[112753.598] (II) evdev: evdev touchscreen: Configuring as touchscreen
[112753.598] (**) evdev: evdev touchscreen: YAxisMapping: buttons 4 and 5
[112753.598] (**) evdev: evdev touchscreen: EmulateWheelButton: 4, 
EmulateWheelInertia: 10, EmulateWheelTimeout: 200
[112753.598] (II) XINPUT: Adding extended input device "evdev touchscreen" 
(type: TOUCHSCREEN, id 6)
[112753.599] (II) evdev: evdev touchscreen: initialized for absolute axes.
[112753.600] (**) evdev touchscreen: (accel) keeping acceleration scheme 1
[112753.600] (**) evdev touchscreen: (accel) acceleration profile 0
[112753.600] (**) evdev touchscreen: (accel) acceleration factor: 2.000
[112753.600] (**) evdev touchscreen: (accel) acceleration threshold: 4
[112753.601] (WW) fcntl(6, F_SETOWN): Invalid argument

[26]sa-moeller> xinput
 Virtual core pointer id=2[master pointer  (3)]
Virtual core XTEST pointer   id=4[slave  pointer  (2)]
Touchscreen  id=6[slave  pointer  (2)]
sysmouse id=8[slave  pointer  (2)]
 Virtual core keyboardid=3[master keyboard (2)]
 Virtual core XTEST keyboard  id=5[slave  keyboard (3)]
 kbdmux   id=7[slave  keyboard (3)]

Everything looks good so far, at least in my eyes.
Well - wheel emulation and such sounds a bit strange, as if it is handled
as a touchpad and not like a touchscreen.
But it says type touchscreen, so I assume that's ok.
However, I get no touch events.
I've started xev fullscreen and still nothing.

Somewhere else I've read that /dev/input/event0 should deliver something
if read and a touch happens, but this is not the case for me.

Any ideas how I can debug this thing?

webcamd based touchscreen problem on Pi3

[Bernd Walter]

Hardware is a Raspberry Pi3 with current r330034.
I'm trying to run a USB touchscreen.
Tested wmt and uep, but neither wants to attach, although the Waveshare
display I'm using is likely running an egalaxy firmware.
However webcamd accepts the device and creates a /dev/input/event0.
But I can't get X to use it.
xf86-input-evdev-2.10.5 is installed and it created an X config file
under /usr/local/share/X11/xorg.conf.d/10-evdev.conf.
I also tried some google results in /etc/X11/xorg.conf, but X never
touches the device:
[ 19417.932] 
X.Org X Server 1.18.4
Release Date: 2016-07-19
[ 19417.932] X Protocol Version 11, Revision 0
[ 19417.932] Build Operating System: FreeBSD 12.0-CURRENT arm64 
[ 19417.932] Current Operating System: FreeBSD sa 12.0-CURRENT FreeBSD 
12.0-CURRENT #0: Mon Mar  5 16:28:19 UTC 2018 
ticso@sa:/usr/obj/usr/src-nfs/builder/current-anlage/head/arm64.aarch64/sys/GENERIC
 arm64
[ 19417.933] Build Date: 19 January 2018  09:58:28PM
[ 19417.934]  
[ 19417.934] Current version of pixman: 0.34.0
[ 19417.934]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 19417.934] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 19417.934] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Mar  7 15:59:15 
2018
[ 19417.935] (==) Using config file: "/etc/X11/xorg.conf"
[ 19417.935] (==) Using system config directory 
"/usr/local/share/X11/xorg.conf.d"
[ 19417.936] (==) No Layout section.  Using the first Screen section.
[ 19417.936] (==) No screen section available. Using defaults.
[ 19417.936] (**) |-->Screen "Default Screen Section" (0)
[ 19417.936] (**) |   |-->Monitor ""
[ 19417.937] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[ 19417.938] (==) Automatically adding devices
[ 19417.938] (==) Automatically enabling devices
[ 19417.938] (==) Not automatically adding GPU devices
[ 19417.938] (==) Max clients allowed: 256, resource mask: 0x1f
[ 19417.938] (==) FontPath set to:
/usr/local/share/fonts/misc/,
/usr/local/share/fonts/TTF/,
/usr/local/share/fonts/OTF/,
/usr/local/share/fonts/Type1/,
/usr/local/share/fonts/100dpi/,
/usr/local/share/fonts/75dpi/
[ 19417.938] (==) ModulePath set to "/usr/local/lib/xorg/modules"
[ 19417.938] (II) The server relies on devd to provide the list of input 
devices.
If no devices become available, reconfigure devd or disable 
AutoAddDevices.
[ 19417.938] (II) Loader magic: 0x1e0018
[ 19417.939] (II) Module ABI versions:
[ 19417.939]X.Org ANSI C Emulation: 0.4
[ 19417.939]X.Org Video Driver: 20.0
[ 19417.939]X.Org XInput driver : 22.1
[ 19417.939]X.Org Server Extension : 9.0
[ 19417.939] (II) LoadModule: "glx"
[ 19417.940] (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so
[ 19417.951] (II) Module glx: vendor="X.Org Foundation"
[ 19417.951]compiled for 1.18.4, module version = 1.0.0
[ 19417.951]ABI class: X.Org Server Extension, version 9.0
[ 19417.951] (==) AIGLX enabled
[ 19417.951] (==) Matched modesetting as autoconfigured driver 0
[ 19417.951] (==) Matched scfb as autoconfigured driver 1
[ 19417.951] (==) Assigned the driver to the xf86ConfigLayout
[ 19417.951] (II) LoadModule: "modesetting"
[ 19417.952] (II) Loading /usr/local/lib/xorg/modules/drivers/modesetting_drv.so
[ 19417.952] (II) Module modesetting: vendor="X.Org Foundation"
[ 19417.952]compiled for 1.18.4, module version = 1.18.4
[ 19417.952]Module class: X.Org Video Driver
[ 19417.952]ABI class: X.Org Video Driver, version 20.0
[ 19417.952] (II) LoadModule: "scfb"
[ 19417.953] (II) Loading /usr/local/lib/xorg/modules/drivers/scfb_drv.so
[ 19417.953] (II) Module scfb: vendor="X.Org Foundation"
[ 19417.953]compiled for 1.18.4, module version = 0.0.4
[ 19417.953]ABI class: X.Org Video Driver, version 20.0
[ 19417.954] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 19417.954] (II) scfb: driver for wsdisplay framebuffer: scfb
[ 19417.954] (--) Using syscons driver with X support (version 2.0)
[ 19417.954] (--) using VT number 2

[ 19417.954] (WW) Falling back to old probe method for modesetting
[ 19417.955] (EE) open /dev/dri/card0: No such file or directory
[ 19417.955] (WW) Falling back to old probe method for scfb
[ 19417.955] scfb trace: probe start
[ 19417.955] (II) scfb(0): using default device
[ 19417.955] scfb trace: probe done
[ 19417.955] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 19417.955] scfb: PreInit 0
[ 19417.955] (II) scfb(0): Using: depth (24),   width (1280),height (800)
[ 19417.956] (II) scfb(0): Creating default Display subsection in Screen section
"Default Screen Section" for depth/fbbpp 24/24
[ 19417.956] (==) scfb(0): Depth 24, (==) framebuffer 

Re: best settings for usb2 and attached disks, and sdcards

[Bernd Walter]

On Thu, Mar 08, 2018 at 07:26:11AM -0800, bob prohaska wrote:
> On Thu, Mar 08, 2018 at 10:46:36AM +0100, Bernd Walter wrote:
> > 
> > I'm currently very pleased with the SanDisk Extreme Plus micro SD
> > cards.
> > They are quite expensive, but behave way better with random writes.
> > 
> I don't think I've seen Sandisk Extreme Plus devices, how do they differ
> from "ordinary" Sandisk extreme devices? I think there is a "Pro" version,
> is that the same thing?

I don't know any other SanDisk Extreme SD cards than the Extreme Plus I have.
The Ultra, I usually use, have those typical long delay problems, while the
Extreme Plus never showed up in gstat with more than 100ms absolute worst
case, usually below 25ms under random write load with 4-8MB/s datarate.
Those I have are labeled as SDSQXBG-032G-GN6MA.

> > Event better in random write performance are the SanDisk Extreme
> > USB sticks.
> > Also quite expensive though and quite big.
> > 
> Likewise, my experiece, spread over 4 RPi2's and 2 RPi3's, has been good.
> 
> > I can't tell, however, if they are better in case of power loss
> > related data corruption.
> > 
> 
> Never done a systematic test, but accidental unplugs and power cycles
> after a crash have never caused problems fsck -f won't fix.

I've had those problems with any kind of card I've used.
This even happened for me with fully readonly mounted cards.
Cards have to do ocassional refresh writes for reads, which means
at low level there's no such thing as read-only, but it is amazing
that customers even mange to catch those.
The Extreme Plus however are new for me and I can't tell yet.
At least they are way better during development.
So far I've went to NFS, but NFS has a higher latency and 100MBit
ethernet is slower than local cards could deliver.

-- 
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: best settings for usb2 and attached disks, and sdcards

[Bernd Walter]

On Wed, Mar 07, 2018 at 06:15:25AM +, John wrote:
> Hi,
> [cc'd to arm@ and fs@ where it's also relevant]
> 
> I have a number of rpi3 & rpi3 machines. Usually I want to attach a usb 
> keydrive to them so that the sdcard isn't thrashed. They're all running 
> -current. usr/src and usr/ports at least are mounted on the keydrive.
> 
> When initially updating eg the ports tree, svn will time out/crash because of 
> the poor write performance of these devices in a rpi2/3 context. The fs on 
> the usb keys is always ufs2. I have tried mounting these devices as -o async 
> and also in fstab but this parameter seems not to 'take' in that mount 
> doesn't report the async property set:

I'm currently very pleased with the SanDisk Extreme Plus micro SD
cards.
They are quite expensive, but behave way better with random writes.

Event better in random write performance are the SanDisk Extreme
USB sticks.
Also quite expensive though and quite big.

I can't tell, however, if they are better in case of power loss
related data corruption.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]

[Bernd Walter]

On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote:
> [test_check() between the fork and the wait/sleep prevents the
> failure from occurring. Even a small access to the memory at
> that stage prevents the failure. Details follow.]

Maybe a stupid question, since you might have written it somewhere.
What medium do you swap to?
I've seen broken firmware on microSD cards doing silent data
corruption for some access patterns.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: System-On-Module

[Bernd Walter]

On Thu, Jan 29, 2015 at 11:39:30AM +, Andrew Turner wrote:
 On Thu, 29 Jan 2015 18:27:08 +0900
 Lundberg, Johannes johan...@brilliantservice.co.jp wrote:
 
  What I'm most worried about is the graphics stack.. Some companies
  don't seem so keen on handing out specs.
 
 The only ARM vendor I know that has released documentation on their 3D
 hardware is Broadcom [1]. The only options for this are the Raspberry
 Pi or one of the mobile phones with a Broadcom CPU. I neither option to
 be applicable for your requirements.

On the other hand people still struggle when it comes to CPI on RPi,
because it is handled by the GPU.
I'm still not so sure about this Broadcom SoC.
This is the reason why I like that the RPi Camera header is also used
on the Hummingboard and the BanannaPi.
The Hummingboard is an iMX6.
The BanannaPi unfortunately is an Allwinner and their datasheets are
AFAIK chinese only and IIRC also under NDA.

The Novena crown funding included iMX6 2D/3D driver development for Linux
as a met stretch goal:
https://www.crowdsupply.com/kosagi/novena-open-laptop/stretch-goals
https://www.crowdsupply.com/kosagi/novena-open-laptop
I don't know how much of the results will be useable for us, but at
least some people seem to have access to enough documentation.

 Andrew
 
 [1]
 http://www.broadcom.com/docs/support/videocore/VideoCoreIV-AG100-R.pdf

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: System-On-Module

[Bernd Walter]

On Wed, Jan 28, 2015 at 12:27:31PM -0700, Ian Lepore wrote:
 On Wed, 2015-01-28 at 19:32 +0100, Bernd Walter wrote:
  On Wed, Jan 28, 2015 at 06:52:52PM +0900, Lundberg, Johannes wrote:
   Hi
   
   Of all the low power, high-spec system/computer-on-modules out there which
   have best support for FreeBSD?
   
   MEN
   Variscite
   Technologic system
   Adlink
   etc.
   
   What I am looking for is a system with roughly this specs
   ARM or x86, 64bit if possible.
   2-4 cores
   1.5-2.0 GHz
   2 GB RAM
   ~16 GB Storage
   USB 3.0
   PCB size about one to two credit cards.
  
  In that range I would go for a Wandboard.
  They are 1, 2 or 4 core iMX6 32bit with 512M, 1G or 2G RAM.
  The 4 core has SATA, which to my knowledge we don't support yet.
  They come with 2 useable SD-card slots - one on the module and one
  on a carrier board.
  Clock rate is 1GHz only IIRC and they only have high speed USB, although
  the newest carrier boards have some super speed wiring for future modules.
  
  TechNexion, the originator of that module system also has some
  x86 boards - some may fit your requirements, but those are at
  a higher price and bigger form factor.
  Tech Nexion also has iMX6 boards similar to the wandboard with
  different featuresets, but also at a higher price.
 
 You do get more for that higher price with the Technexion EDM modules,
 namely 1.2ghz chips instead of 1.0, and parts that are industrial and/or
 automotive temperature-rated rather than consumer grade.  On the other
 hand, you generally can't buy Technexion modules one at a time.  Last
 time I checked they were minimum order 10 pieces even from resellers
 like Mouser and Digikey.

Temperature rating - that can easily justify the higher price.

 Another small-board imx6 possibility is the Hummingboard from SolidRun.
 I now have freebsd running on a SolidRun Cubox-i4, so I expect no large
 drama in getting it working on other SolidRun imx6 products.  Gonzo
 ordered a Hummingboard recently, so we should know for sure some time
 soon.

To my knowledge they come in 3 different sizes.
I own the biggest two versions of them.
Completely forgot that the Hummingboard uses modules as well and the
modules are even very small.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: System-On-Module

[Bernd Walter]

On Thu, Jan 29, 2015 at 08:28:58AM +0900, Lundberg, Johannes wrote:
 By the way, this is for an embedded mobile device so we are looking for
 something more like
 
 http://www.kontron.com/products/computeronmodules/smarc/smarc-samx6i.html
 
 instead of Wandboard which has all the connectors that we won't use.

Don't get confused with the wandboard module+carrier board, which is
the normal offer (and in small volumes often cheaper than the 10x
module pack).
The Wandboard module alone is extremly similar to the Kontron modules
in your link.
They don't have eMMC (maybe some of the TechNexion have), but they
do have a micro-SD on the module itself, plus SDIO on the module header.
eMMC can have a higher transport speed because it allows for 8bit instead
of 4bit and as soldered chip it has different issued than a socketed card,
but otherwise they are very similar in design.
The 2 and 4 core Wandboards have BT/WLAN on module, but it is done by SDIO,
for which FreeBSD (to my knowledge) has no support yet.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: System-On-Module

[Bernd Walter]

On Wed, Jan 28, 2015 at 05:36:00PM -0700, Ian Lepore wrote:
 On Thu, 2015-01-29 at 09:12 +0900, Lundberg, Johannes wrote:
  Ah now I see it has EDM connection. I didn't look carefully enough. All the
  images are with the expansion board attached..
  
  Spec-wise and portability-wise it seems like a good option but my hardware
  guy keeps warning me about Freescale that they often have hardware bugs and
  rather than fixing the bugs they pretend they are not there.. In other
  words, Freescale is good for software developers because of open
  documentation but not so for hardware manufactures. Any experiences with
  this?
 
 The imx6 manuals include an errata list, so it would be good to check
 that for anything specific that would matter to your projects.

If you use a prebuild module then you don't get much in touch with
the freescale chip fropm the hardware side.
On the other hand, there are countless iMX6 boards out there with
schematics online.
My recently bought Novena even came with printed schematics and they
open sourced the HW design files as well.
I don't think there are hidden surprises on the hardware side.

 For the devices we use in our products everything is good so far with
 the hardware.  That's emmc, sdcard, ethernet, i2c, uarts, usb, and lots
 of gpio (inputs and outputs).  The ethernet is gigabit but has a known
 limitation of 40MB/s due to the bus it's connected to in the chip.  (But
 hey, it's documented so it's not a problem, right? :)
 
 You mentioned video, and we don't have that working on freebsd imx6 yet,
 but there's not a ton of work to do.  There's a framebuffer driver for
 imx5 and it has pretty much the same framebuffer hardware.  Getting
 video output to a TTL LCD is probably just hours of work.  Getting it to
 an LVDS LCD or HDMI probably needs days of work (entire drivers written,
 potentially, I haven't looked into it).

Sounds interesting for my Novena.
The one I already got are board only (with some FPGA breakout, ...).
They have HDMI though.
But I'm also awaiting for the one with case and LCD panel.
Not to forget that I have a fairy EDM carrier with LCD already.
That said I'v always wondered how much work is it to get the camera
interface running, since the Hummingboards can connect to the RPi
camera modules.

 Some audio support was recently committed, but I don't know much about
 it yet.
 
 -- Ian
 
 

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: System-On-Module

[Bernd Walter]

On Wed, Jan 28, 2015 at 06:52:52PM +0900, Lundberg, Johannes wrote:
 Hi
 
 Of all the low power, high-spec system/computer-on-modules out there which
 have best support for FreeBSD?
 
 MEN
 Variscite
 Technologic system
 Adlink
 etc.
 
 What I am looking for is a system with roughly this specs
 ARM or x86, 64bit if possible.
 2-4 cores
 1.5-2.0 GHz
 2 GB RAM
 ~16 GB Storage
 USB 3.0
 PCB size about one to two credit cards.

In that range I would go for a Wandboard.
They are 1, 2 or 4 core iMX6 32bit with 512M, 1G or 2G RAM.
The 4 core has SATA, which to my knowledge we don't support yet.
They come with 2 useable SD-card slots - one on the module and one
on a carrier board.
Clock rate is 1GHz only IIRC and they only have high speed USB, although
the newest carrier boards have some super speed wiring for future modules.

TechNexion, the originator of that module system also has some
x86 boards - some may fit your requirements, but those are at
a higher price and bigger form factor.
Tech Nexion also has iMX6 boards similar to the wandboard with
different featuresets, but also at a higher price.

 I wish to minimize the amount of porting needed so I am very grateful if
 someone has good insights in this area. And of course, it would help a lot
 if it was a manufacturer who is willing to provide datasheets to make
 porting possible..

Freescale is producting the iMX6 and they supply a hughe PDF for them.
Also the wandboard schematics are public available.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Booting a SuperMicro Superserver

[Bernd Walter]

On Tue, Aug 12, 2014 at 02:25:29PM -0400, Allan Jude wrote:
 On 2014-08-12 14:09, Barney Cordoba wrote:
  The bios only gives you one choice for HDD. You can't select one of the 4 
  drives to boot from. You can specify USB or CD or HDD, but Not HDD2 or HDD3.
  
  BC
  
  
  On Tuesday, August 12, 2014 1:16 PM, John Nielsen li...@jnielsen.net 
  wrote:
   
  
  
  On Aug 12, 2014, at 10:32 AM, Barney Cordoba barney_cord...@yahoo.com 
  wrote:
  
  
  A continuing issue (with 9.1 previously and now 10) is that FreeBSD 
  occasionally (or always) seems to boot from the 2nd installed drive
  rather than the first. I'd be happy to debug this, but I have no idea if 
  it's bootcode or a BIOS issue. Supermicro pleads innocent, but their bios
  guys are hard to work with and fairly arrogant if you don't specifically 
  isolate something.
 
  The scenario occurs when ada0 is upgraded and has an incompatible kernel 
  with other code on drive ada1.  (note that ada1 is a backup of the 
  pre-upgrade ada0, so it's fstab points to ada0 for mount points). The 
  system will boot and then modules will fail to load. It loads the kernel 
  from
ada1 and then mounts partitions from ada0; old kernel and newer modules.
 
  The problem is resolved by popping the 2nd drive. So there is nothing 
  wrong with ada0 to cause it to bounce to ada1.
 
  My question: What would cause the system to boot from ada1 instead of 
  ada0? Bios or Bootcode?
  
  BIOS, most likely. If the disk controller in question is onboard you should 
  be able to specify which disk(s) and what order they will be booted from. 
  If not, you'll need to just say disk controller in the BIOS boot order 
  then go to the controllers BIOS to say which disk(s) to boot from and in 
  what order. I have recent experience with a SuperMicro box and an LSI 
  controller; the latter allows you to specify a (b)oot drive and an 
  (a)lternate. Yes, b comes before a. :)
  
 
 There is usually a second menu after you select 'HDD' in the boot order
 menu, something like 'HDD Boot Priority' that lets you select the
 correct disk to boot from
 
 http://s1121.photobucket.com/user/SleeperPro/media/BIOSBoot.jpg.html
 
 So after you select 'HDD in the 'boot device priority' menu, go to the
 'hard disk drives' menu and set the order of the drives.

I've also seen BIOS to scan complete boot order HDD for GPT and then MBR.
Noticed this when seting up a gmirror server in the old way:
Do lazy install on disk0 and boot.
setup disk1 as gmirror/dedicated disk with it's fake MBR.
Shutdown and physically swap disks, then gmirror the lazy installation
disk.
But after swapping disks the BIOS then bootet from disk1 with GPT, although
the new gmirror/MBR disk0 was first in boot order.
After gmirror sync disk1 the BIOS booted from disk0, so it really was
the GPT why it prefered booting from second disk in bootorder.
Think it was a Intel board, but can't say for sure.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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

Max mmap space (was: expanding past 1 TB on amd64)

[Bernd Walter]

On Tue, Jul 16, 2013 at 02:12:42PM -0700, Alan Cox wrote:
 On Tue, Jul 16, 2013 at 7:08 AM, Kurt Lidl l...@pix.net wrote:
 
  On Wed, Jun 19, 2013 at 1:32 AM, Chris Torek chris.torek at gmail.com
  wrote:
 
   In src/sys/amd64/include/vmparam.**h is this handy map:
 
   * 0x - 0x7fff   user map
   * 0x8000 - 0x7fff   does not exist (hole)
   * 0x8000 - 0x804020100fff   recursive page table (512GB
  slot)
   * 0x804020101000 - 0xfdff   unused
   * 0xfe00 - 0xfeff   1TB direct map
   * 0xff00 - 0xff7f   unused
   * 0xff80 - 0x   512GB kernel map
 
  The actual data that I've seen shows that DIMMs are doubling in size at
  about half that pace, about every three years.  For example, see
  http://users.ece.cmu.edu/~**omutlu/pub/mutlu_memory-**
  scaling_imw13_invited-talk.**pdfslidehttp://users.ece.cmu.edu/~omutlu/pub/mutlu_memory-scaling_imw13_invited-talk.pdfslide
  #8.  So, I think that a factor of 16 is a lot more than we'll need in
  the next five years.  I would suggest configuring the kernel virtual
  address space for 4 TB.  Once you go beyond 512 GB, 4 TB is the net
  plateau in terms of address translation cost.  At 4 TB all of the PML4
  entries for the kernel virtual address space will reside in the same L2
  cache line, so a page table walk on a TLB miss for an instruction fetch
  will effectively prefetch the PML4 entry for the kernel heap and vice
  versa.
 
 
  The largest commodity motherboards that are shipping today support
  24 DIMMs, at a max size of 32GB per DIMM.  That's 768GB, right now.
  (So FreeBSD is already out of bits in terms of supporting current
  shipping hardware.)
 
 
 
 Actually, this scenario with 768 GB of RAM on amd64 as it is today is
 analogous to the typical 32-bit i386 machine, where the amount of RAM has
 long exceeded the default 1 GB size of the kernel virtual address space.
  In theory, we could currently handle up to 1 TB of RAM, but the kernel
 virtual address space would only be 512 GB.

Talking about virtual address space.
I plan to permanently mmap serveral nGB sized files (all together 6-8TB)
into a single process address space.
Actually I see the user map is 128TB, so I shouldn't get into trouble
by doing this and also have lot of additional space left to avoid problems
because of fragmentation.
The system has 192G physical memory, so mapping tables have enough space.
Is there anything else to worry about?

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Light humour

[Bernd Walter]

On Sun, Apr 28, 2013 at 09:07:15PM +0300, Alexander Yerenkow wrote:
 Not criticizing, just commenting.
 I heard such utter nonsense sometimes, in which people do believe despite
 all common sense, that I'm not amused, but scared :)

Well - I don't see a problem with this.
The people who don't understand enough to believe this crap won't use any
BSD and go to Linux instead.
It all contribute to the same quality as Linux already is.
Type netstat -nr and you don't get IPv6 routing table - even windows agrees
to traditional netstat -nr behavour...
Interface isolation for ARP requests - what's that?
Want to know link states use some strange tools.
We all can extend this list forever.
You just need to look at bootmessages to know how inconsistent Linux is.
I didn't read all of the text, but the tiny bit is already failing logic in
itself, which is the main reason why it is funny after all.
I don't want any of those persons who believe this text anywhere else than
on the other side.

 This blog is humor to very small, limited group of people, and at same time
 it's anti-bsd blog to bigger audience, who will not bother read some lines,
 instead peek in title, get few words here, few there, and close it. In they
 memory will be essence - that *BSD is suck, probably not allover, but they
 will remember that there are exist areas in which BSD have big problems.
 Mix this with lacking `nextgen techs` like KMS, decent virtualization
 level, no utf-8 in console and other myths, partial myths, or obsolete
 problems of old releases, and you'll receive bad opinion on BSD.
 But, there's not much to be done actually :)

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Any objections/comments on axing out old ATA stack?

[Bernd Walter]

On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote:
 I have just sent more information to the PR at
 http://www.freebsd.org/cgi/query-pr.cgi?pr=157397
 
 The short summary (more info in the PR) is:
 
 - limiting tags to 31 does not help
 
 - disabling NCQ appears to help in initial testing, but warrants more
 testing
 
 - error happens during WRITE_FPDMA_QUEUED,
 
 - File system in question is SU+J UFS2 mounted on /usr, and I can for
 instance rm -rf /usr/obj or just log into GNOME and try to open a
 gnome-terminal to trigger stalls;
 
 - Linux uses 31 tags (for different reason) and has no drive quirks, but
 a controller quirk;
 
 for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it
 might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag
 - it gets set by Linux on the SB700 that my computer is using, see
 ahci_error_intr() in libahci.h - I am not going to interpret that for
 lack of expertise, but it does affect error handling and appears to
 ignore a certain condition.
 
 Why only my Samsung HDD drive triggers this but not the WD drive, I do
 not know yet.

I have had data corruption with Samsung drive and CAM connected to
an onboard intel AHCI.
The system was known good running with an older FreeBSD version and was
brought back into service for another use case with a fresh installation.
Regulary on major filesystem write activity we got random FS corruptions
and panics.
My assumption was broen NCQ firmware on the drive, but have nothing to
proof this assumtion.
We switched to old ata driver and lived with this until we replaced the
whole machine.
Don't know if the machine still exists somewhere.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: access to hard drives is blocked by writes to a flash drive

[Bernd Walter]

On Tue, Mar 05, 2013 at 09:01:36AM -0700, Ian Lepore wrote:
 On Mon, 2013-03-04 at 21:27 -0800, Don Lewis wrote:
  On  4 Mar, Ian Lepore wrote:
   On Sun, 2013-03-03 at 19:01 -0800, Don Lewis wrote:
   On  3 Mar, Poul-Henning Kamp wrote:
   
For various reasons (see: Lemming-syncer) FreeBSD will block all I/O
traffic to other disks too, when these pileups gets too bad.
   
   The Lemming-syncer problem should have mostly been fixed by 231160 in
   head (231952 in stable/9 and 231967 in stable/8) a little over a year
   ago. The exceptions are atime updates, mmaped files with dirty pages,
   and quotas. Under certain workloads I still notice periodic bursts of
   seek noise. After thinking about it for a bit, I suspect that it could
   be atime updates, but I haven't tried to confirm that.
   
   When using TCQ or NCQ, perhaps we should limit the number of outstanding
   writes per device to leave some slots open for reads.  We should
   probably also prioritize reads over writes unless we are under memory
   pressure.

   
   Then either those changes didn't have the intended effect, or the
   problem we're seeing with lack of system responsiveness when there's a
   large backlog of writes to a slow device is not the lemming-syncer
   problem.  It's also not a lack of TCQ/NCQ slots, given that no such
   thing exists with SD card IO.
   
   When this is going on, the process driving the massive output spends
   almost all its time in a wdrain wait, and if you try to launch an app
   that isn't already in cache, a siginfo generally shows it to be in a
   getblk wait.
  
  If your only drive is a single SD card, then you're pretty much hosed
  when I/O is blocked because the SD card is doing an erase.  It can only
  handle one command at a time, and if a write blocks, there's nothing
  that we can do to get it to execute a read until it is done with the
  write command that it is hung up on.  I'm not familiar with the lower
  layers, but things might be less bad if read ops can jump ahead and get
  sent to the drive before any queued writes.
  
 
 Yes, but an erase-block operation on a nand flash takes on the order of
 500uS, not 8-10 seconds, which is the kind of interactive
 non-responsiveness you experience in these situations.  The very nature
 of SD cards is one operation at a time, so no internal operation
 queueing is in play to explain the long (apparent) hangs.

Values from datasheet I recently read (for an older 1G NAND chip) was
500uS for writing and 3ms for erasing - though erasing happens on larger
granularities than writing.
Of course a write request may include more than one flash write for
bookkeeping.
Nevertheless the long read starvation comes from writing multiple requests
before reading.
I often saw with gstat that a slowly decreasing L(q) was the situation
when I was waiting for a read to complete.
Since r/s never showed any other value than 0 and w/s showed small
numbers during the starvation it is a clear sign that a bunch of write
requests were queued handled before any read attempt.
This usually happens in waves - L(q) pops high and decreases slowly to
zero, while ms/w clims to multiple seconds then directly after another
bunch of writes pop up.

 I've debated playing with the bio work loop in mmcsd to see if moving
 reads ahead of writes was helpful, but that seems like a dangerous path
 to go down without some mitigation strategy to ensure that writes go
 through eventually.  That seems especially important when you consider
 that writes may be necessary to free up memory to un-wedge other things
 that are waiting.  (Yeah, people don't often use sd cards as swap
 storage, but I've done so in a pinch.)  All in all, I've never pursued
 it because it feels like the wrong layer to address the problem at.

Sometimes there is no choice and you have to setup swap on SD, but there
are other reasons to write on your SD card.
But honestly - most of the time you get crazy when you are maintaining
a system - e.g. install a package, which can't get faster anyway, but
very often you want to edit configfiles at the same time.
During production this rarely was an issue for me.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: polling's future [was: Re: Dynamic Ticks/HZ]

[Bernd Walter]

On Tue, Nov 06, 2012 at 10:46:28AM +, Poul-Henning Kamp wrote:
 
 In message 5098e8b4.5040...@freebsd.org, Andre Oppermann writes:
 
  I think it should go away, and if there still is a relevant
  usage segment, be replaced by _real_ device-polling which is
  not tied to the network stack.
 
 Don't we already have the equivalent with a fast interrupt thread
 that simply acknowledges and disables the interrupt [...]
 
 The point is that not all hardware have interrupt-pacing, so
 being able to poll at a lower rate in software would save overhead.
 
 I'm not sure if the hardware where this applies is still relevant,
 it would probably be mostly in the embedded space.

I've used polling on embedded systems to avoid userland starvation and
not to gain bandwidth.
Interrupts have priority over userland processes and with a CPU not capable
to handle say 100MBit/s ethernet interrupt load you can't even login via
console console.
With polling such a machine is way more responsive and allow people to find
out that there is a saturated link before pulling the plug.
There are likely other solutions, but it worked well for that puprose.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: sysctl kern.ipc.somaxconn limit 65535 why?

[Bernd Walter]

On Fri, Oct 05, 2012 at 08:21:53AM +1000, Peter Jeremy wrote:
 On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote:
 In addition we had to migrate all our mysql servers from freebsd to debian
 because they were hitting some arbitary OS limit but I could never figure
 out what, sys% usage went through the roof when this limit was hit, issue
 didnt occur on debian.

It's a well known point that linux isn't serving time correctly
where FreeBSD requires much more load to do it right.
It is also well known that MySQL asks for time horrible often.
Don't know what they expect this to serve, when it's either slow or
wrong, but they do it.
Maybe we have hacked around this issue - there are lots of people
doing workload tests comparing Databases on Linux and FreeBSD and
in the end it always is more or less equal when everything is
configured right.
Our installed defaults for MySQL migh be different than with
Debian and also OS tuning is very different.
Sometimes even hardware selection can make big difference when
comparing OS, if one OS has a slow driver for a given hardware,
or one has a lazy driver ignoring data consistency.

 Did you report this issue on any of the FreeBSD mailing lists?
 Reporting a problem doesn't guarantee that it will be fixed
 (unfortunately) but not reporting a problem makes it extremely
 unlikely that it will be fixed.
 
   I feel recently freebsd is more focused on desktop's
 and as such developer's never develop for a heavy server usage scenario,
 
 This isn't intentionally true but it's true that few developers run
 large servers so they may not run into some issues that only impact
 large systems.  Again, it's up to people who do run such systems to
 provide feedback about bottlenecks  issues they hit so that they can
 be fixed.
 
 I keep coming across hardcoded low limits.  As rightly pointed out default
 
 There are lots of defaults that were set some time (potentially
 decades) ago and may no longer be optimal.  It's unrealistic to expect
 that all the defaults are correct in all circumstances and this is one
 area where end users can help by flagging defaults that they find need
 tuning.
 
 values now days are useless 128 for somaxconn? maybe ok for a desktop.
 
 But, as others have pointed out, this isn't one of them.  Can you
 please provide more details on a use scenario where a listen(2)
 backlog exceeding 128 is reasonable.

It's simple math.
If the accept loop sleeps for 1 second a connection backlog of 128
ist good for 128 connections per second.
However accept loops sleeping for 1 second for high rate servers
mean there is something programmed wrong - more likely accept loops
sleep for 1-5ms, so 128 is good for at least 25600 connetions per
second.
Requiring more than 65536 with well done programming means that
you try to handle more than 13107200 connections per second.
Such a connection rate sounds even unlikely given the number of
IP packets required on the network interface just to establish the
connections.
Furthermore - the typical high transaction service these days are
webservers and there you can benefit from keepalive very much.
If on the other hand your well written accept loop isn't fast
enough because of high CPU load, then the machine is simply overloaded
and queuing more connections won't serve you anything but changing
symptoms.
In any case it ends in bad programming or extremly untypical use case.
Yes - we do not support bad programmed applications or every
imaginable extreme use case out of the box, that's right.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: ipv6 / rtadv problem

[Bernd Walter]

On Tue, Mar 29, 2011 at 08:24:53PM +1030, Daniel O'Connor wrote:
 
 On 29/03/2011, at 19:05, Sergey Kandaurov wrote:
  This is repeatable after a reboot, I haven't experienced with FreeBSD 8.x.
  
  
  I would assume an NDP communication problem or some such,
  it would be interesting to see this sort of traffic, also ifconfig and
  ndp -a output.
 
 Grr.. I had to reinstall today because I forgot to create a swap partition 
 and now I can't reproduce the problem :(

NDP effectively replaces ARP for IPv6.
Like ARP it is also learning by received packets and not only by direct
query and because of this problems might be unnoticed.

Unlike ARP NDP is using multicast - instead of sending the inquiry to
a broadcast address each address has a solicatated multicast address where
the query goes to.
A NIC driver might have broken multicast support, I doub't that's a
problem for your em, but it is more likely that the bug is on the other
host.
It also could be a problem with multicast aware switches - getting
multicast switiching right isn't an easy task and many implementations
are full of bugs.
If an NDP entry expires a host typically reasks using the unicast address
and the last known MAC, so once everything seems to run an underlying
multicast problem can live unnoticed for a much longer time.
Currently my own LAN router has a NIC driver with broken multicast
support and nevertheless everything seems to work fine since months
now, but I know the bug is there and that it can bite me each day.

And unlike ARP NDP is ICMPv6 and not an individual protocol, some
people agressivlely filter ICMPv*, which can easily catch too much.
Especially since many people configuring filter lists are not aware
of those solicitated addresses.

My assumption is that the problem is with the other host or switch
network and you just never noticed this so far because this kind of
problem can easily hide for a very long time.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: ipv6 / rtadv problem

[Bernd Walter]

On Tue, Mar 29, 2011 at 11:43:57PM +1030, Daniel O'Connor wrote:
 
 It is running a fairly old FreeBSD (6.x..), maybe there are bugs there..

I don't think there are general bugs about neighbor discovery in FreeBSD
since the beginning, but NIC drivers might have multicast bugs and
although you are running this host since a long time such bugs might be
unnoticed.
You can show and clear the neighbor cache data by using ndp command,
which has similar handling as arp.
If you use tcpdump to debug NDP packets be aware that by enabling
promiscuous mode you get every multicast packet despite of correct
filter setup, so you won't see a problem if the driver isn't
configuring the filter correctly.
On the other hand you can workaround a such driver bug by enabling
promiscuous mode.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: ipv6 / rtadv problem

[Bernd Walter]

On Tue, Mar 29, 2011 at 10:19:26PM +1030, Daniel O'Connor wrote:
 
 On 29/03/2011, at 22:04, Bernd Walter wrote:
  My assumption is that the problem is with the other host or switch
  network and you just never noticed this so far because this kind of
  problem can easily hide for a very long time.
 
 Hmm, I have pretty stupid hardware, I am fairly sure none of my switches 
 understand multicast.

There are two class of multicast capable switches.
On of them are professional switches of course, but given that IPTV
runs with multicast some cheap manageable switches and quite often
integrated switches in plastic routers support it as well.
IPv4 multicast and IPv6 multicast is very similar, but they use non
colliding MAC ranges, so pure IPv4 multicast switches are not a problem
for IPv6 multicast, but I'm a bit worried that some cheap devices have
alpha quality IPv6 multicast support enabled.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: In-kernel PPPoE

[Bernd Walter]

On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote:
 Just curious about why the in-kernel PPPoE interface was never ported 
 from NetBSD or OpenBSD, to FreeBSD. Does anyone know why?

Maybe because everyone who cares about in-kernel uses the FreeBSD
in-kernel ng_pppoe via mpd?

 From using it for a long time in OpenBSD I always found it quite stable 
 and easy to use.

The same is true with mpd/ng_pppoe.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: In-kernel PPPoE

[Bernd Walter]

On Sun, Dec 05, 2010 at 12:30:16PM -0800, Julian Elischer wrote:
 On 12/5/10 9:30 AM, Bernd Walter wrote:
 On Sun, Dec 05, 2010 at 12:14:21PM -0500, Pierre Lamy wrote:
 Just curious about why the in-kernel PPPoE interface was never ported
 from NetBSD or OpenBSD, to FreeBSD. Does anyone know why?
 Maybe because everyone who cares about in-kernel uses the FreeBSD
 in-kernel ng_pppoe via mpd?
 
  From using it for a long time in OpenBSD I always found it quite stable
 and easy to use.
 The same is true with mpd/ng_pppoe.
 while I like mpd, I should point out that the regular 'in source' ppp 

No surprise that you like it ;-)

 that comes with
 freebsd also uses the in-kernel netgraph pppoe module.   I use it 24 x 
 7 on my gateway
 as I never got around to installing mpd and it did the job.

Same for me if the machine's power is good enough, but my Router is a
tiny FreeBSD/ARM, which has trouble to keep up with load if running
traffic via userland.
I use mpd together with ipfw nat to keep traffic in kernel.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: the world is not built gcc after upgrade svn r214735

[Bernd Walter]

On Thu, Nov 04, 2010 at 05:15:43PM +0200, Ivan Klymenko wrote:
 ?? Thu, 4 Nov 2010 07:57:50 -0700
 David Wolfskill da...@catwhisker.org ??:
 
  On Thu, Nov 04, 2010 at 04:53:16PM +0200, Ivan Klymenko wrote:
   Hello, people!
   After the upgrade to FreeBSD 9.0-CURRENT svn revision 214735 does
   not build world: ...
   
  
  I had no problem going from FreeBSD 9.0-CURRENT #33 r214732 to
  r214777.
  
  Peace,
  david
 
 Do you use when building make option -j?
 
 I'm using -j 3

You likely have stall dependencies in /usr/obj.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: DHCP server in base

[Bernd Walter]

On Fri, Sep 10, 2010 at 10:33:11PM -0700, Kevin Oberman wrote:
  Date: Fri, 10 Sep 2010 17:33:22 -0700
  From: Doug Barton do...@freebsd.org
  Sender: owner-freebsd-curr...@freebsd.org
  
  On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote:
  
   Hi,
  
   another argument about hostapd :) if have access point we must have
   way to assign IP for AP clients.
  
  To start with, your assumption is wrong. DHCPd is not *actually* a 
  requirement, although I admit that practically it is.
 
 It is not. I routinely use hostapd for access for my iPod. I use
 static addressing and don't run dhcpd.

With IPv6 you can additionally use stateles autoconfiguration.
The requirement for autoconfiguration with DHCP is a problem of IPv4,
which won't have a long future for mainstream purspose anymore.
Nevertheless there must be a decision about base and not-base and this
point will always be questionable to some.
I'm also not very strict about bind - it is handy to have dig available,
but at the same time it is handy to have whois available, but the
whois in base isn't good enough anymore for most cases.
A DHCP client however can be required for initial network configuration
to retrieve further packages.
dig and co can be handy to debug initial network problems, but there
are other tools in base for those problems.
But to repeat a point which was already made:
Someone who can configure a DHCP server really shouldn't have problems
to install a package - installing packages or ports is so basic for
an operationg system that this is likely one of the first things to
learn.
Additionally there are ready made systems based on FreeBSD for special
purpose, which probably come with the required tools.

   Since this device is router I must be
   able to serve DHCP. And current implementation of dhcpclient, that we
   have, is same isc-dhcp, and I replace system dhcpclient with ports
   one+dhcpd but with small patch that put basic dhcp utils onto
   libdhcp.so.

DHCP servers don't have to live on routers and there are many reasons
to have them installed somewhere else.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Interpreted language(s) in the base

[Bernd Walter]

On Mon, Aug 16, 2010 at 09:47:40AM +0200, sth...@nethelp.no wrote:
  Personally, I think the whole base and ports thing is an artificial 
  divide that is rapidly losing utility. I think we're past due for 
  stripping the FreeBSD base down to a much more bare minimum, and 
  having a lot more of the bells and whistles live in the ports tree.
 
 Strongly disagree. One of the reasons I've been using FreeBSD for many
 years is precisely the fact that the base system is very good, and
 contains most of what I need without installing a lot of extra ports/
 packages.

I can agree to this argument.
While it is easy to install required tools on your system it is a hassle
if you are doing support for systems installed by someone else.
With FreeBSD you can expect a great set of tools  already available.
I remember the old days when I was doing embedded systems on tiny CF
media and thought I only stripped the tools I really don't need, but in
the end I often missed something.
But I also never missed something with a complete base.
Perl is a fancy tool, but when you really need it you don't have a
problem in installing it.
It is not that long time ago that a friend with his Linux couldn't
even check the negotiated ethernet link without installing an additional
tool - easy if you have network, but isn't this a tool to debug network
problems?

The last thing I've missed was something to script in single-user-mode.
In loader we have FICL and in single-user-mode we have /bin/sh, while
the shell is reasonable to write scripts it also requires external
helpers which sits in non-mounted /usr - e.g.: grep, sed, lock, ...
With todays disk and partition sizes however I don't split /usr -
I split /usr/local (often don't even this), so this isn't a problem
anymore.

Having an embeddable lanmguage is another story - no matter if it is
TCL, FICL, Lua or whatever.
There is a possible benefit for extending our tools, but after reading
PHKs history description I'm not that sure about it anymore.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Why is intr taking up so much cpu?

[Bernd Walter]

On Sat, Jul 17, 2010 at 10:21:28PM +0300, Kostik Belousov wrote:
 On Sat, Jul 17, 2010 at 12:10:26PM -0700, Doug Barton wrote:
  On Sat, 17 Jul 2010, Rui Paulo wrote:
  
  This doesn't indicate any problem. I suggest you try to figure out what 
  interrupt is causing this by adding printfs or disabling drivers one by 
  one.
  
  I've no idea where to even begin on something like that. Given that 
  there are other -current users who are also having problems 
  (particularly with the nvidia drivers) I'm wondering if some sort of 
  systemic debugging isn't in order here?
  
 
 Note that intr time most likely come from the interrupt threads chewing
 the CPU, not from the real interrupt handlers doing something, and definitely
 not due to the high interrupt rate, as your vmstat -i output already shown.

I've noticed a few webpages to trigger lot of X11 related network traffic
just by watching them even without any seeable content change, but CPU
load on browser and especialy X process went high, but of course
symptoms might be different with different drivers - I use mga myself.
I never analysed it properly beacuse I'm using a quite old Xorg version,
but I see the increase of traffic on the domain socket.
I also noticed that recent firefox and seamonkey are doing lots of NFS
traffic, so I was forced to switch ~/.mozilla to a local disk, where
iostat still stays idle.
But my OS is also not very recent, so I also never debugged this problem.

 Run top in the mode where all system threads are shown separately
 (e.g. top -HS seems to do it), then watch what thread eats the processor.



-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sun, Jun 13, 2010 at 12:17:50AM +, Bruce Cran wrote:
 On Sun, Jun 13, 2010 at 12:52:16AM +0200, Bernd Walter wrote:
  I'm at least sure that the compiler can't if it is linked from another
  object file.
 
 Is that still true if LTO is enabled?

Good question - I wasn't aware of LTO.
My precondition was that the function doesn't see what is done with
the result and LTO invalidates this.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sun, Jun 13, 2010 at 12:44:03PM +0200, Matthias Andree wrote:
 Am 13.06.2010, 00:52 Uhr, schrieb Bernd Walter:
 
 In more general terms, the compiler is allowed to make any changes it
 likes to the program as long as the end result behaves exactly like it
 would if it hadn't been changed.  This is called the as if rule.  For
 instance, if you call printf() or fprintf() with a format string that
 does not contain any conversion specifiers, gcc will call gets() or
 fgets() instead.
 
 Amazing - this is one of the things which can get nasty if you try some
 kind of microtuning.
 Recently I had to implement my own atoi on a controller because using the
 library one magically had blown my RAM usage by 1k on a controller with
 just 8k RAM.
 
 There are certain compiler flags to affect that. For GCC, -Os is one  
 (which doesn't necessarily work in FreeBSD though, on some versions the  
 compiler would go into unterminated loop, leak memory and ultimately fail  
 with OOM), flags to tell the compiler that the implementation is  
 freestanding, and attributes to select builtins and the likes.

I know -Os - the problem was more complicated and at linker stage.
It was because atoi sucked more hardly related library parts in, of
which one had 1k static RAM requirement.
Quite surprising outcome from using atoi.
But this isn't related to FreeBSD at all, since it happened with newlibc.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
 Bernd Walter ti...@cicely7.cicely.de writes:
  Amazing - this is one of the things which can get nasty if you try some
  kind of microtuning.
 
 Only if you break the rules.  Bad code is always bad, even if it
 sometimes works by accident.

To expect that function calls are replaced with other functions isn't a
very obvious rule.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sun, Jun 13, 2010 at 06:14:11PM +0200, Dag-Erling Smørgrav wrote:
 Bernd Walter ti...@cicely7.cicely.de writes:
  Dag-Erling Smørgrav d...@des.no writes:
   Bernd Walter ti...@cicely7.cicely.de writes:
Amazing - this is one of the things which can get nasty if you try
some kind of microtuning.
   Only if you break the rules.  Bad code is always bad, even if it
   sometimes works by accident.
  To expect that function calls are replaced with other functions isn't a
  very obvious rule.
 
 You don't need to know that gcc replaces printf() with puts().  That's
 the whole point of the as-if rule: the compiler can only modify the
 program in ways that do not change observable behavior.

Well in ways the compiler _thinks_ it is not observeable.
I'm not saying that it is doing wrong per definition, but if it is really
not observeable and obvious we wouldn't need to talk about it.

 The only way you can tell that gcc did it is if you break the rules,
 such as by defining your own version of printf() or puts().

Our loader stages do this for good reasons.
And in microcontroller programming (surely out of FreeBSD scope) it
is done very regulary.
All I say is that the rules are not obvious in many cases.
Most people using compilers don't have the deep knowledge as you have.
Of course we are talking about corner cases which most people also
never have to face.
In any case - I've learned something new.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Mon, Jun 14, 2010 at 02:20:26AM +1000, Andrew Milton wrote:
 +---[ Bernd Walter ]--
 | On Sun, Jun 13, 2010 at 05:44:29PM +0200, Dag-Erling Smørgrav wrote:
 |  Bernd Walter ti...@cicely7.cicely.de writes:
 |   Amazing - this is one of the things which can get nasty if you try some
 |   kind of microtuning.
 |  
 |  Only if you break the rules.  Bad code is always bad, even if it
 |  sometimes works by accident.
 | 
 | To expect that function calls are replaced with other functions isn't a
 | very obvious rule.
 
 Don't turn on compiler optimisation then. You're explicitly telling
 the compiler to make your code better/faster/smaller. Optimisation
 flags always come with the caveat that your code may not work exactly 
 the same...

This isn't helpfull at all.
Yes - we can disable everything and have nothing after all including
nothing unexpected.
In Germany we say Kind mit dem Bade auschütten.
With other words you throw all the good things away just to catch a
single bad point.
Optimization isn't bad as such, but it is influencing more and more
things, which could be considered save before.
It is important to know which parts can be considered save in future
and how it can be ensured.
And don't tell me in the early/mid 90th anyone has ever expected
compilers to optimize at the same level they do today.
LTO was a very interesting new area because before that compilers never
touched anything outside it's own scope.
printf = puts isn't that amazing if you consider printf to be a puts
consumer which is just shrink to nothing, but I understood Dags point
that this was not the end of function exchange to expect.
Volatile is also a very strong mechanism and often it is enough to
just cast a variable volatile in a specific context as done in the
macro of this thread - instead of just defining it volatile for
every use as was suggested as well.
Compilier optimization is even required in many cases to get decent
performance or in small environments to get it small enough to fit
into memory at all, but this doesn't mean it is what you want in every
case.
The wish to wipe out sensitive data in crypto code is very reasonable,
but this doesn't mean disabling optimzation is the way to go.
So far there isn't a save solution to use memset to wipe out a whole
block of memory.

Go back to the originating mail.
Crypto code wasn't aware of this problem and this is a way more
obviuous optimization than function exchange.
And I do believe that the programmers were clever people.
Alarming, isn't it?
Maybe paranoid users might consider compiling their OS with -O0, but
I don't think this is the right way.
It is amazing how strong the influence of optimization is and how weak
the programmers assumptions are.

The thread is about how to handle optimization in corner cases and not
to disable it.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sun, Jun 13, 2010 at 11:41:03PM +0200, Dag-Erling Smørgrav wrote:
 Bernd Walter ti...@cicely7.cicely.de writes:
  Dag-Erling Smørgrav d...@des.no writes:
   The only way you can tell that gcc did it is if you break the rules,
   such as by defining your own version of printf() or puts().
  Our loader stages do this for good reasons.  And in microcontroller
  programming (surely out of FreeBSD scope) it is done very regulary.
 
 Those are freestanding environments, where printf() and puts() don't
 exist as far as the C standard is concerned.

Most controller environments have some kind of libc.
We even have devel/avr-libc and devel/msp430-libc in ports.
Anyway - printf=puts isn't scarying as such, it is more that this might
happen in other cases as well.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sat, Jun 12, 2010 at 05:35:28PM +0200, Ulrich Spörlein wrote:
 On Fri, 11.06.2010 at 21:37:29 +0200, Dag-Erling Smørgrav wrote:
  Ulrich Spörlein u...@spoerlein.net writes:
   optimizing compilers have a tendency to remove assignments that have
   no side effects. The code in sys/crypto/sha2/sha2.c is doing a lot of
   zeroing variables, which is however optimized away.  [...]  Is there a
   canonical way to zero those variables and should we use them (memset
   perhaps? what are the performance implications?)
  
  If you stick these variables in a struct, you can memset the struct to
  zero them; if there are many of them, it may be faster than zeroing them
  individually.
  
  Alternatively, you can use something like this:
  
  #define FORCE_ASSIGN(type, var, value) \
  *(volatile type *)(var) = (value)
 
 Interesting trick, thanks. I'll try this ...

I'm not sure when removing a memset is allowed.
Maybe passing volatile pointers might be enough.
And I'm happy to be corrected from in deep experts - my knowledge is
more from practical microcontroller programming.
The problem with memset is that is is inlined by at least gcc and
inlined functions are included in the optimizations.

But calling my_abolsutely_not_inlineable_memset should work IMHO.
In other words: declare a local memset function, which is declared
(in compiler specific words) as not being inlineable, which itself calls
memset you should be safe, since the function doesn't know why it does
the memset it can't be removed and the caller doesn't know anything about
the called function.
A portible way would be to have this function in a separate .c file,
which prohibits inlining.

C++ has the concept of volatile member functions, but this is a
slightly different thing.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Cleanup for cryptographic algorithms vs. compiler optimizations

[Bernd Walter]

On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote:
 Bernd Walter ti...@cicely7.cicely.de writes:
  I'm not sure when removing a memset is allowed.
 
 Always, if the compiler can determine that the data will not be used
 later.

I'm at least sure that the compiler can't if it is linked from another
object file.
The problem with memset is that the compiler has an internal implementation.
On the other hand I wonder what the deep sense is to clear memory which
is unused later.
I know that crypto code can be tricky sometimes, but if someone is willing
to explain the specific reason my curiosity would be satified.

 In more general terms, the compiler is allowed to make any changes it
 likes to the program as long as the end result behaves exactly like it
 would if it hadn't been changed.  This is called the as if rule.  For
 instance, if you call printf() or fprintf() with a format string that
 does not contain any conversion specifiers, gcc will call gets() or
 fgets() instead.

Amazing - this is one of the things which can get nasty if you try some
kind of microtuning.
Recently I had to implement my own atoi on a controller because using the
library one magically had blown my RAM usage by 1k on a controller with
just 8k RAM.

  Maybe passing volatile pointers might be enough.
 
 You can't pass a volatile pointer to memset.

Of course not - my fault - it takes non volatile pointers per definition.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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

lock order reversal bufwait/dirhash

[Bernd Walter]

Got this during installworld (source on NFS, destination UFS on CF-card)
Source is current checked out yesterday.

lock order reversal:
 1st 0xc28b85b4 bufwait (bufwait) @ 
/data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575
 2nd 0xc343f000 dirhash (dirhash) @ 
/data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283
KDB: stack backtrace:
db_trace_self_wrapper(c0905b2b,c0d02c56,c2d3d030,c2d40500,ca657890,...) at 
db_trace_self_wrapper+0x26
_witness_debugger(c0d02c56,c343f000,c0d279c2,c2d40500,c0d2762e,...) at 
_witness_debugger+0x25
witness_checkorder(c343f000,9,c0d2762e,11b,0,...) at witness_checkorder+0x73c
_sx_xlock(c343f000,0,c0d2762e,11b,c3a07e80,...) at _sx_xlock+0x51
ufsdirhash_acquire(e,1828,ca6579f0,c3a07e80,cb2bd814,...) at 
ufsdirhash_acquire+0x35
ufsdirhash_add(c3a07e80,ca6579f0,1828,ca657950,ca657954,...) at 
ufsdirhash_add+0x1f
ufs_direnter(c3944dd0,c423e220,ca6579f0,ca657bd0,c292ccb0,...) at 
ufs_direnter+0x894
ufs_mkdir(ca657bf8,ca657c0c,2,0,0,...) at ufs_mkdir+0x51c
VOP_MKDIR_APV(c0e0f4c0,ca657bf8,ca657bd0,ca657b3c,2,...) at VOP_MKDIR_APV+0x8e
kern_mkdirat(c39264e0,ff9c,80513e0,0,1c0,...) at kern_mkdirat+0x240
kern_mkdir(c39264e0,80513e0,0,1c0,ca657c7c,...) at kern_mkdir+0x2f
mkdir(c39264e0,ca657cec,ca657d28,c0d014f7,0,...) at mkdir+0x27
syscallenter(c39264e0,ca657ce4,ca657ce4,0,c0e630c0,...) at syscallenter+0xc6
syscall(ca657d28) at syscall+0x3a
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (136, FreeBSD ELF32, mkdir), eip = 0x281817cf, esp = 0xbfbfe30c, 
ebp = 0xbfbfe398 ---

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Fwd: umodem (4) recognize a CDC-ACM device

[Bernd Walter]

On Wed, Jun 02, 2010 at 06:25:25PM +0200, Hans Petter Selasky wrote:
   Hi,
  
   Can you dump the USB descriptors of your device?
  
  Hi, right now I can do this at FreeBSD 8.0-RELEASE-p2 #8 r206060M,
  but If you prefer tonight I can dump from 'freebsd-current' box.
  
  Thank you
 
 Hi,
 
 The problem is that LOW speed does not support BULK transfers according to 
 the 
 USB specification. I guess we could switch that support on, though I'd rather 
 stick with the spec.

I think the original sense is a bit outdated.
It was when people had a single full speed controller on their systems
and low speed transfers could easily drop overall performance, so
it made sense to prohibid bulk transfers on low speed.
Today however people have multiple channels and high speed chains where
performance is only a matter up to the next transaction translator and
even if they don't use a high speed hub it only harms performance on
a single (of many) usb low/full channels, while bandwidth hungry devices
usually are connected to other controllers.

On the other hand - I never understood why people want to implement
low speed devices.
It has some many restrictions and isn't realy cheaper to build than
full speed devices.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: fsck unable to read disk sectors

[Bernd Walter]

On Mon, May 17, 2010 at 10:54:17PM +0930, Matt Thyer wrote:
 On 12 May 2010 11:16, Bernd Walter ti...@cicely7.cicely.de wrote:
 
  On Tue, May 11, 2010 at 10:15:13PM +0200, Alexander Best wrote:
   i've posted a log here which is pretty self explanatory:
  
   http://pastebin.com/tn3NiDDW
  
 
 [snip]
 
 
  One of the typical problems users have is that they forget that
  adding a label takes one sector, so the labeled device is smaller.
  This is no problem if you create the filesystem on the labeled
  drive, but often enough people add the label after creating the
  filesystem.
 
 FreeBSD's utilities should be able to detect this situation and either
 correct the filesystem size or refuse to apply the label.

How can this work?
glabel doesn't know anything about volume contents - it just writes a
label-sector and offers the remaning storage as a new volume.
Result: Refusing is impossible.
Changing UFS filesystem size isn't an easy task and the last sector is
already lost when filesystem comes into game.
Result: Too late.
I think the only reasonable thing to be done is that fsck can speak
up by checking the volume size with the filesystems size _after_ glabel
has overwritten the last sector.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: fsck unable to read disk sectors

[Bernd Walter]

On Tue, May 11, 2010 at 10:15:13PM +0200, Alexander Best wrote:
 i've posted a log here which is pretty self explanatory:
 
 http://pastebin.com/tn3NiDDW
 
 On Tue, May 11, 2010 at 10:13 PM, Alexander Best
 alexbes...@uni-muenster.de wrote:
  the problem is getting more awkward.
 
  if i do `fsck /dev/label/rootfs` fsck complains that it cannot read a
  specific sector of my hdd as i mentioned before. if i run fsck on the
  device node directly using `fsck /dev/ada0p3` however, fsck succeeds.

So this is not hardware it is bad partitioning.

  what i did was to boot into single user mode with / being mounted read
  only. for some reason however fsck will check /dev/label/rootfs in
  write mode, but if i want fsck to check ada0p3 it will only do so in
  read mode.
 
  this looks like something is really broken. right now the only way to
  get the clean flag set on my hdd is to boot from a livefs cd and then
  run `fsck /dev/ada0p3` (again: `fsck /dev/label/rootfs` will NOT
  succeed).

One of the typical problems users have is that they forget that
adding a label takes one sector, so the labeled device is smaller.
This is no problem if you create the filesystem on the labeled
drive, but often enough people add the label after creating the
filesystem.
Everything seems to work fine until the FS decides to use that special
sector.
I wouldn't add a label for ufs anyway, since UFS has labeling itself,
which is also handled by glabel module and doesn't require extra space.
Just setup the ufs label with tunefs -L and use the resulting /dev/ufs/...
device.
You only need extra label for swap, but this is not problem, since
it has no persistent ondisk structures.

  this is the output of `glabel status` btw:
 
                                      Name  Status  Components
                                label/boot     N/A  ada0p1
  gptid/e52df583-e446-11de-bb92-000fb58207c8     N/A  ada0p1
                                label/swap     N/A  ada0p2
                              label/rootfs     N/A  ada0p3
 
  cheers.
 
  On Tue, Mar 30, 2010 at 2:08 AM, Paul B Mahol one...@gmail.com wrote:
  On 3/29/10, Alexander Best alexbes...@wwu.de wrote:
  hi there,
 
  when doing fsck on my / fs i get this error:
 
  Cannot Read BLK. 471617640 and The Following Disk Sectors could not be
  read: 471617643. after this message the partition gets marked dirty.
 
  i performed the following steps to verify the problem:
 
  1) dd if=/dev/ada0 of=/dev/null bs=1m
  2) fsck / under freebsd 7
  3) mount -u -o snapshot /.snap/snapshot1 /  fsck_ffs /.snap/snapshot1
 
  all three steps showed no problem with that harddrive whatsoever. also
  smartd
  doesn't complain about anything.
 
  i'm running HEAD (r205860) on amd64.
 
  this is the output of `dmesg -a|grep ada0`:
 
  ada0 at ahcich2 bus 0 scbus3 target 0 lun 0
  ada0: SAMSUNG SP2504C VT100-50 ATA-7 SATA 2.x device
  ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
  ada0: Command Queueing enabled
  ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C)
 
  Last time I tried ahci on dead disk it did not complained at all
  (usually I get dead LBA listed on console).

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: Switchover to CAM ATA?

[Bernd Walter]

On Fri, Apr 23, 2010 at 09:50:33AM -0400, John Baldwin wrote:
 On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote:
  If ataraid(4) should be reimplemented in GEOM, then how exactly? One
  more separate RAID infrastructure in GEOM (third?) looks excessive.
  Reuse gmirror, gstripe,... code would be nice, but will make them more
  complicated and could be not easy for RAID0+1 (due to common metadata)
  and RAID5 (due to lack of module in a base system).
 
 Scott's view (which sounds good to me) is that GEOM should include a library 
 of routines for working with common transforms such as RAID1, striping, etc.  
 Each ATA RAID vendor format would then consist of a small GEOM module that 
 used the library routines to manage all the I/O and the bulk of the module 
 would be managing a specific metadata format.

I remember that SCSI standard has support for xor read-modify-write
operations in addition to normal read/write to reduce R5 latency and
bandwith.
I'm not sure if any devices actually support it, but I think this
may be worthwhile for networked devices.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: propose: all arch move into a separate dir

[Bernd Walter]

On Fri, Mar 05, 2010 at 02:27:06PM +0300, Alex Keda wrote:
 On 05.03.2010 14:16, Doug Rabson wrote:
 On Fri, 05 Mar 2010 14:10:43 +0300, Alex Kedaad...@lissyara.su  wrote:

 On 05.03.2010 13:59, Poul-Henning Kamp wrote:
  
 In message4b90e171.2040...@lissyara.su, Alex Keda writes:
 
 

 then can a more correct name of the project or ClosedBSD or
  
 ManagedBSD?

 =)
 or something abstract?
 
  
 You are free to use any other operating system of your choice, if you
 are not happy with FreeBSD.
 
 Don't let the door hit you on the way out.
 

 I'm not going anywhere, not even hope for it =)
 I'm trying to make FreeBSD a better, more logical.
 Maybe that's not very successful, but judging by the number of
 responses, it hurt many, and made to think even more people.
  
 I think you misunderstand. Some of us old-timers have been having this
 discussion repeatedly for well over ten years. It always ends up the same
 way - a re-org might make the source tree marginally prettier but the
 consequences for long-term maintenance and supporting downstream
 contributors outweigh any possible benefit. Having the same conversation
 every two years with the same outcome gets annoying.

 And the fact that this issue was raised with enviable regularity - not 
 make you think that it really needs to be done?

And the fact that weighting the arguments always ends in the same
result - not make you think that this really shouldn't be done?
A calculation always ends in the same result until the variables changes.
So far this hasn't happen, so there is no need to recalculate/rethink
every now and then.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote:
 On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote:
  In message: 20100219033000.gz43...@cicely7.cicely.de
  Bernd Walter ti...@cicely7.cicely.de writes:
  : Warner - it names you in the copyright, so very likely you know this code.
  : I will build a debug version of bind, but as usual it will take some
  : time...
  
  Make sure that the code matches our current atomics code...
 
 There are just 3 functions.
 isc_atomic_xadd and isc_atomic_store just wrap to atomic_fetchadd_int and
 atomic_store_rel_int
 isc_atomic_cmpxchg is inline assembly, but I don't think we have such a
 function in our ARM atomic.h - at least I can't find it.

#0  0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at 
atomic.h:75
75  }
[New Thread 20804500 (LWP 100100)]
[New Thread 208043c0 (LWP 100099)]
[New Thread 20804280 (LWP 100098)]
[New Thread 20804140 (LWP 100043)]
(gdb) bt
#0  0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at 
atomic.h:75
#1  0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write)
at 
/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325
#2  0x000f8144 in dns_db_register (name=0x173fe8 _builtin, create=0x4d46c 
dns_sdb_create, driverarg=0x2092b078, 
mctx=0x2080e0c0, dbimp=0x2092b08c) at 
/data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821
#3  0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 _builtin, 
methods=Variable methods is not available.
)
at 
/data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239
#4  0xc96c in ns_builtin_init () at 
/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296
#5  0x0001a97c in $a () at 
/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
#6  0x0001a97c in $a () at 
/data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
(gdb) print p
$1 = (isc_int32_t *) 0x155214
(gdb) print *p
$2 = -498139128
(gdb) 

Initially it looks like a valid pointer.
But it also looks like a pointer in codespace, which of course would be
non-writeable and can't be updated.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 01:29:03PM +0100, Grzegorz Bernacki wrote:
 Bernd Walter wrote:
 On Fri, Feb 19, 2010 at 05:12:06AM +0100, Bernd Walter wrote:
 On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote:
 In message: 20100219033000.gz43...@cicely7.cicely.de
 Bernd Walter ti...@cicely7.cicely.de writes:
 : Warner - it names you in the copyright, so very likely you know this 
 code.
 : I will build a debug version of bind, but as usual it will take some
 : time...
 
 Make sure that the code matches our current atomics code...
 There are just 3 functions.
 isc_atomic_xadd and isc_atomic_store just wrap to atomic_fetchadd_int and
 atomic_store_rel_int
 isc_atomic_cmpxchg is inline assembly, but I don't think we have such a
 function in our ARM atomic.h - at least I can't find it.
 
 #0  0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at 
 atomic.h:75
 75  }
 [New Thread 20804500 (LWP 100100)]
 [New Thread 208043c0 (LWP 100099)]
 [New Thread 20804280 (LWP 100098)]
 [New Thread 20804140 (LWP 100043)]
 (gdb) bt
 #0  0x0015521c in isc_atomic_cmpxchg (p=0x155214, cmpval=0, val=1) at 
 atomic.h:75
 #1  0x00155a20 in isc_rwlock_lock (rwl=0x1c0fd4, type=isc_rwlocktype_write)
 at 
 
  /data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c:325
 #2  0x000f8144 in dns_db_register (name=0x173fe8 _builtin, 
 create=0x4d46c dns_sdb_create, driverarg=0x2092b078, 
 mctx=0x2080e0c0, dbimp=0x2092b08c) at 
 
  /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/db.c:821
 #3  0x0004d0b4 in dns_sdb_register (drivername=0x173fe8 _builtin, 
 methods=Variable methods is not available.
 )
 at 
 
  /data/builder/arm-current/head/lib/bind/dns/../../../contrib/bind9/lib/dns/sdb.c:239
 #4  0xc96c in ns_builtin_init () at 
 /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/builtin.c:296
 #5  0x0001a97c in $a () at 
 /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
 #6  0x0001a97c in $a () at 
 /data/builder/arm-current/head/usr.sbin/named/../../contrib/bind9/bin/named/main.c:741
 (gdb) print p
 $1 = (isc_int32_t *) 0x155214
 (gdb) print *p
 $2 = -498139128
 (gdb) 
 
 Initially it looks like a valid pointer.
 But it also looks like a pointer in codespace, which of course would be
 non-writeable and can't be updated.
 
 
 Hi,
 
 Some time ago we changed an address of RAS. Probably that's the problem. 
 Please try
 with patch below.

I will try, but if p really points to codespace it should be a problem
in a any of the calling functions.

 grzesiek
 
 diff --git a/contrib/bind9/lib/isc/arm/include/isc/atomic.h 
 b/contrib/bind9/lib/
 index 6a6e984..2f12921 100644
 --- a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
 +++ b/contrib/bind9/lib/isc/arm/include/isc/atomic.h
 @@ -53,9 +53,9 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, 
 isc_int
 
 __asm __volatile(1:\n
 adr%1, 1b\n
 -   mov%0, #0xe004\n
 +   mov%0, #0x1004\n
 str%1, [%0]\n
 -   mov%0, #0xe008\n
 +   mov%0, #0x1008\n
 adr%1, 2f\n
 str%1, [%0]\n
 ldr%1, [%2]\n
 @@ -63,10 +63,10 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, 
 isc_i
 streq  %4, [%2]\n
 2:\n
 mov%3, #0\n
 -   mov%0, #0xe004\n
 +   mov%0, #0x1004\n
 str%3, [%0]\n
 mov%3, #0x\n
 -   mov%0, #0xe008\n
 +   mov%0, #0x1008\n
 str%3, [%0]\n
 : =r (ras_start), =r (done)
 ,+r (p), +r (cmpval), +r (val) : : memory);
 
 

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 08:13:15AM -0600, Mark Tinguely wrote:
 
   Some time ago we changed an address of RAS. Probably that's the problem. 
  Please try
   with patch below.
 
   grzesiek
 
 Good job.
 
 IMO, ARM atomic.h should have cmpxchg and the other standard atomic routines
 so applications don't roll their own and they become stale.

You can see an explanation in svn log:
r174206 | dougb | 2007-12-03 09:26:34 +0100 (Mon, 03 Dec 2007) | 10 lines

Update this file so that BIND on ARM can actually work. I quote:

The problem was, isc_atomic_cmpxchg() is almost like our
atomic_cmpset_32(), except it expects the old value to be
returned, whereas our atomic_cmpset_32 returns 1 on success,
or 0 on failure. So I re-implemented something suitable.

Submitted by:   cognet
Reviewed by:bsdimp


r170349 | dougb | 2007-06-06 00:15:38 +0200 (Wed, 06 Jun 2007) | 5 lines

Add a custom atomic.h file which implements the C versions of the
code we already have assembly versions of.

Written by: imp

 This will help application writers if we move the atomic commands from the
 ARMv4/ARMv5 ARM_RAS_START/ARM_RAS_END atomic method to ARMv6/ARMv7
 ldrex/strex/clrex commands.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 01:29:03PM +0100, Grzegorz Bernacki wrote:
 Hi,
 
 Some time ago we changed an address of RAS. Probably that's the problem. 
 Please try
 with patch below.
 
 grzesiek
 
 diff --git a/contrib/bind9/lib/isc/arm/include/isc/atomic.h 
 b/contrib/bind9/lib/
 index 6a6e984..2f12921 100644
 --- a/contrib/bind9/lib/isc/arm/include/isc/atomic.h
 +++ b/contrib/bind9/lib/isc/arm/include/isc/atomic.h
 @@ -53,9 +53,9 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, 
 isc_int
 
 __asm __volatile(1:\n
 adr%1, 1b\n
 -   mov%0, #0xe004\n
 +   mov%0, #0x1004\n
 str%1, [%0]\n
 -   mov%0, #0xe008\n
 +   mov%0, #0x1008\n
 adr%1, 2f\n
 str%1, [%0]\n
 ldr%1, [%2]\n
 @@ -63,10 +63,10 @@ isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, 
 isc_i
 streq  %4, [%2]\n
 2:\n
 mov%3, #0\n
 -   mov%0, #0xe004\n
 +   mov%0, #0x1004\n
 str%3, [%0]\n
 mov%3, #0x\n
 -   mov%0, #0xe008\n
 +   mov%0, #0x1008\n
 str%3, [%0]\n
 : =r (ras_start), =r (done)
 ,+r (p), +r (cmpval), +r (val) : : memory);

Strange:
cc -O -pipe -mcpu=arm9 -DVERSION='9.6.1-P3' -DHAVE_CONFIG_H -D_REENTRANT 
-D_THREAD_SAFE -DLIBINTERFACE=51 -DLIBREVISION=1 -DLIBAGE=1 -DWANT_IPV6 
-DOPENSSL -DUSE_MD5 -DNS_LOCALSTATEDIR='/var' -DNS_SYSCONFDIR='/etc/namedb' 
-DNAMED_CONFFILE='/etc/namedb/named.conf' 
-DRNDC_CONFFILE='/etc/namedb/rndc.conf' 
-DRNDC_KEYFILE='/etc/namedb/rndc.key' 
-I/data/builder/arm-current/head/lib/bind/isc/.. 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/bind9/include
 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/dns/include/dst
  
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/dns/include
  -I/data/builder/arm-current/head/lib/bind/isc/../dns 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isccc/include
 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isccfg/include
 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/include
  
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/pthreads/include
  
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/include
  -I/data/builder/arm-current/head/lib/bind/isc/../isc 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/lwres/unix/include
  
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/lwres/include
  -I/data/builder/arm-current/head/lib/bind/isc/../lwres 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/include
 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/pthreads/include
 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/include
 -I/data/builder/arm-current/head/lib/bind/isc 
-I/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/arm/include
 -g -std=gnu99  -c 
/data/builder/arm-current/head/lib/bind/isc/../../../contrib/bind9/lib/isc/rwlock.c
{standard input}: Assembler messages:
{standard input}:69: Error: invalid constant -- `mov ip,#0x1004'
{standard input}:71: Error: invalid constant -- `mov ip,#0x1008'
{standard input}:79: Error: invalid constant -- `mov ip,#0x1004'
{standard input}:82: Error: invalid constant -- `mov ip,#0x1008'
*** Error code 1

Stop in /data/builder/arm-current/head/lib/bind/isc.
*** Error code 1

Stop in /data/builder/arm-current/head/lib/bind.
8297.000u 387.000s 2:52:06.37 84.1% -1482+1914k 134+1455io 306pf+0w
Exit 1

I fail to seee why the assembler sees it to be wrong.
It is a valid hex value - what else should the assembler take care
about?

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 05:49:59PM +0100, Olivier Houchard wrote:
  
  Strange:
 
 
 Not so much, the first values for ras_start/end were chosen to be immediate
 values, so you could just mov them, but the new one aren't.
 Try something like the patch attached instead (untested, I have no arm setup
 here, but you'll get the idea).

I just got an idea in wqhich direction to look, just to see a lot of fog
there, but that's my problem.
I'm not very good with ARM assembly and inline assembly, although I did
know a goo amount of alpha, 6502, 68k, ... assembly.

Anyway - your patch works (with minor fix):
[213]Please.tell.me.who.am.I# host -a www.freebsd.org 127.0.0.1
Trying www.freebsd.org
Using domain server:
Name: 10.1.1.9
Address: 10.1.1.9#53
Aliases: 

;; -HEADER- opcode: QUERY, status: NOERROR, id: 26655
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
;www.freebsd.org.   IN  ANY

;; ANSWER SECTION:
www.freebsd.org.3600IN  MX  0 .
www.freebsd.org.3600IN  2001:4f8:fff6::21
www.freebsd.org.3600IN  A   69.147.83.33

;; AUTHORITY SECTION:
freebsd.org.2019IN  NS  ns3.isc-sns.info.
freebsd.org.2019IN  NS  ns2.isc-sns.com.
freebsd.org.2019IN  NS  ns1.isc-sns.net.

;; ADDITIONAL SECTION:
ns3.isc-sns.info.   2019IN  A   63.243.194.1
ns3.isc-sns.info.   2019IN  2001:5a0:10::1
ns2.isc-sns.com.19745   IN  A   38.103.2.1
ns1.isc-sns.net.19745   IN  A   72.52.71.1
ns1.isc-sns.net.19745   IN  2001:470:1a::1

Received 284 bytes from 10.1.1.9#53 in 355 ms
[214]Please.tell.me.who.am.I# 

 
 Regards,
 
 Olivier

 Index: contrib/bind9/lib/isc/arm/include/isc/atomic.h
 ===
 --- contrib/bind9/lib/isc/arm/include/isc/atomic.h(revision 203777)
 +++ contrib/bind9/lib/isc/arm/include/isc/atomic.h(working copy)
 @@ -49,26 +49,22 @@
  static inline isc_int32_t
  isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val)
  {
 - register int done, ras_start;
 + register int done, ras_start = #0x1004;

I had to remove the '#' in this line:
register int done, ras_start = 0x1004;


  
   __asm __volatile(1:\n
   adr%1, 1b\n
 - mov%0, #0xe004\n
   str%1, [%0]\n
 - mov%0, #0xe008\n
   adr%1, 2f\n
 - str%1, [%0]\n
 + str%1, [%0, #4]\n
   ldr%1, [%2]\n
   cmp%1, %3\n
   streq  %4, [%2]\n
   2:\n
   mov%3, #0\n
 - mov%0, #0xe004\n
   str%3, [%0]\n
   mov%3, #0x\n
 - mov%0, #0xe008\n
 - str%3, [%0]\n
 - : =r (ras_start), =r (done)
 + str%3, [%0, #4]\n
 + : +r (ras_start), =r (done)
   ,+r (p), +r (cmpval), +r (val) : : memory);
   return (done);
  


-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: lang/perl5.10 broken

[Bernd Walter]

On Wed, Feb 17, 2010 at 06:49:17PM +0100, Bernd Walter wrote:
 On Wed, Feb 17, 2010 at 10:01:13AM -0700, M. Warner Losh wrote:
  In message: 20100217152557.gw43...@cicely7.cicely.de
  Bernd Walter ti...@cicely7.cicely.de writes:
  : Not sure if this is ARM related or not.
  
  ...
  : *** Signal 11
  
  Silly question: do you have enough swap space enabled?
 
 First try was with 128M on internal SD of which usually just about
 10M is used during compiler runs and the second was with 1G on external
 USB SD reader, but just because of speed with internal.
 I also saw no kernel message that the system was out of space.
 
 I'm currently trying to compile perl5.8, but it takes some time.

perl5.8 seems to work fine.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
 On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
 [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
 GNU gdb 6.1.1 [FreeBSD]
 Copyright 2004 Free Software Foundation, Inc.
 GDB is free software, covered by the GNU General Public License, and you are
 welcome to change it and/or distribute copies of it under certain conditions.
 Type show copying to see the conditions.
 There is absolutely no warranty for GDB.  Type show warranty for details.
 This GDB was configured as arm-marcel-freebsd...(no debugging symbols 
 found)...
 Core was generated by `named'.
 Program terminated with signal 5, Trace/breakpoint trap.
 Reading symbols from /lib/libcrypto.so.6...(no debugging symbols 
 found)...done.
 Loaded symbols for /lib/libcrypto.so.6
 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
 Loaded symbols for /lib/libthr.so.3
 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
 Loaded symbols for /lib/libc.so.7
 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
 found)...done.
 Loaded symbols for /libexec/ld-elf.so.1
 #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
 [New Thread 20804280 (LWP 100062)]
 [New Thread 20804140 (LWP 100052)]
 (gdb) bt
 #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
 #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
 #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
 #3  0x00164cb8 in ?? ()
 (gdb) 
 
 Do we have a general threading problem on ARM?

I see two different type a crashes.
Both have in common that one or more threads are in _umtx_op.
Unfortunately I don't know enough details about those things to isolate
any more.

the one from above:
#0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
[New Thread 20804280 (LWP 100062)]
[New Thread 20804140 (LWP 100052)]
(gdb) bt
#0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
#1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
#2  0x20349da4 in pthread_create () from /lib/libthr.so.3
#3  0x00164cb8 in ?? ()
(gdb) thread 1
[Switching to thread 1 (Thread 20804280 (LWP 100062))]#0  0x203ab6f0 in 
_umtx_op () from /lib/libc.so.7
(gdb) bt
#0  0x203ab6f0 in _umtx_op () from /lib/libc.so.7
#1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
#2  0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3
#3  0x20349540 in pthread_getprio () from /lib/libthr.so.3
#4  0x203499a0 in pthread_create () from /lib/libthr.so.3
#5  0x00164cb8 in ?? ()

And another, which is what I get most of the time:
(gdb) thread 1
[Switching to thread 1 (Thread 20804500 (LWP 100100))]#0  0x20435f28 in kevent 
() from /lib/libc.so.7
(gdb) bt
#0  0x20435f28 in kevent () from /lib/libc.so.7
#1  0x0014f2dc in ?? ()
(gdb) thread 2
[Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0  0x203ab6f4 in 
_umtx_op () from /lib/libc.so.7
(gdb) bt
#0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
#1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
#2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
#3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
#4  0x in ?? ()
(gdb) thread 3
[Switching to thread 3 (Thread 20804280 (LWP 100098))]#0  0x203ab6f4 in 
_umtx_op () from /lib/libc.so.7
(gdb) bt
#0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
#1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
#2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
#3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
#4  0x2092d008 in ?? ()
(gdb) thread 4
[Switching to thread 4 (Thread 20804140 (LWP 100043))]#0  0x0015755c in ?? ()
(gdb) bt
#0  0x0015755c in ?? ()

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
 On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
  On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
   On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
   [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
   GNU gdb 6.1.1 [FreeBSD]
   Copyright 2004 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you 
   are
   welcome to change it and/or distribute copies of it under certain 
   conditions.
   Type show copying to see the conditions.
   There is absolutely no warranty for GDB.  Type show warranty for 
   details.
   This GDB was configured as arm-marcel-freebsd...(no debugging symbols 
   found)...
   Core was generated by `named'.
   Program terminated with signal 5, Trace/breakpoint trap.
   Reading symbols from /lib/libcrypto.so.6...(no debugging symbols 
   found)...done.
   Loaded symbols for /lib/libcrypto.so.6
   Reading symbols from /lib/libthr.so.3...(no debugging symbols 
   found)...done.
   Loaded symbols for /lib/libthr.so.3
   Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
   Loaded symbols for /lib/libc.so.7
   Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
   found)...done.
   Loaded symbols for /libexec/ld-elf.so.1
   #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
   [New Thread 20804280 (LWP 100062)]
   [New Thread 20804140 (LWP 100052)]
   (gdb) bt
   #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
   #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
   #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
   #3  0x00164cb8 in ?? ()
   (gdb) 
   
   Do we have a general threading problem on ARM?
  
  I see two different type a crashes.
  Both have in common that one or more threads are in _umtx_op.
  Unfortunately I don't know enough details about those things to isolate
  any more.
  
  the one from above:
  #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
  [New Thread 20804280 (LWP 100062)]
  [New Thread 20804140 (LWP 100052)]
  (gdb) bt
  #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
  #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
  #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
  #3  0x00164cb8 in ?? ()
  (gdb) thread 1
  [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0  0x203ab6f0 in 
  _umtx_op () from /lib/libc.so.7
  (gdb) bt
  #0  0x203ab6f0 in _umtx_op () from /lib/libc.so.7
  #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
  #2  0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3
  #3  0x20349540 in pthread_getprio () from /lib/libthr.so.3
  #4  0x203499a0 in pthread_create () from /lib/libthr.so.3
  #5  0x00164cb8 in ?? ()
  
  And another, which is what I get most of the time:
  (gdb) thread 1
  [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0  0x20435f28 in 
  kevent () from /lib/libc.so.7
  (gdb) bt
  #0  0x20435f28 in kevent () from /lib/libc.so.7
  #1  0x0014f2dc in ?? ()
  (gdb) thread 2
  [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0  0x203ab6f4 in 
  _umtx_op () from /lib/libc.so.7
  (gdb) bt
  #0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
  #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
  #2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
  #3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
  #4  0x in ?? ()
  (gdb) thread 3
  [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0  0x203ab6f4 in 
  _umtx_op () from /lib/libc.so.7
  (gdb) bt
  #0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
  #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
  #2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
  #3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
  #4  0x2092d008 in ?? ()
  (gdb) thread 4
  [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0  0x0015755c in ?? 
  ()
  (gdb) bt
  #0  0x0015755c in ?? ()
 
 Compile and install ld-elf.so, libc and libthr with debugging symbols:
 (cd libexec/rtld-elf  make all install DEBUG_FLAGS=-g)
 (cd lib/libc  make all install DEBUG_FLAGS=-g)
 (cd lib/libthr  make all install DEBUG_FLAGS=-g)
 
 Then repeat the crash and try to see where in code does it happen.

It is still compiling, but since kdump was fixed recently (thanks guys!)
I already have some other data.
But to be honest I don't see anything usefull in it.
The last entry before the segfault was a successfull syslog submission.
Hope the compiler finishes soon to get more detailed backtraces.

[...]
 59537 namedCALL  kevent(0x8,0xbfffe91c,0x1,0,0,0)
 59537 namedGIO   fd 8 wrote 20 bytes
   0x 0500   0100       
   ||

 59537 namedGIO   fd 8 read 0 bytes
   
 59537 namedRET   kevent 0
 59537

Re: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
 On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
  On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
   On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
   [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
   GNU gdb 6.1.1 [FreeBSD]
   Copyright 2004 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and you 
   are
   welcome to change it and/or distribute copies of it under certain 
   conditions.
   Type show copying to see the conditions.
   There is absolutely no warranty for GDB.  Type show warranty for 
   details.
   This GDB was configured as arm-marcel-freebsd...(no debugging symbols 
   found)...
   Core was generated by `named'.
   Program terminated with signal 5, Trace/breakpoint trap.
   Reading symbols from /lib/libcrypto.so.6...(no debugging symbols 
   found)...done.
   Loaded symbols for /lib/libcrypto.so.6
   Reading symbols from /lib/libthr.so.3...(no debugging symbols 
   found)...done.
   Loaded symbols for /lib/libthr.so.3
   Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
   Loaded symbols for /lib/libc.so.7
   Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
   found)...done.
   Loaded symbols for /libexec/ld-elf.so.1
   #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
   [New Thread 20804280 (LWP 100062)]
   [New Thread 20804140 (LWP 100052)]
   (gdb) bt
   #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
   #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
   #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
   #3  0x00164cb8 in ?? ()
   (gdb) 
   
   Do we have a general threading problem on ARM?
  
  I see two different type a crashes.
  Both have in common that one or more threads are in _umtx_op.
  Unfortunately I don't know enough details about those things to isolate
  any more.
  
  the one from above:
  #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
  [New Thread 20804280 (LWP 100062)]
  [New Thread 20804140 (LWP 100052)]
  (gdb) bt
  #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
  #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
  #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
  #3  0x00164cb8 in ?? ()
  (gdb) thread 1
  [Switching to thread 1 (Thread 20804280 (LWP 100062))]#0  0x203ab6f0 in 
  _umtx_op () from /lib/libc.so.7
  (gdb) bt
  #0  0x203ab6f0 in _umtx_op () from /lib/libc.so.7
  #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
  #2  0x20357cc0 in pthread_cleanup_push () from /lib/libthr.so.3
  #3  0x20349540 in pthread_getprio () from /lib/libthr.so.3
  #4  0x203499a0 in pthread_create () from /lib/libthr.so.3
  #5  0x00164cb8 in ?? ()
  
  And another, which is what I get most of the time:
  (gdb) thread 1
  [Switching to thread 1 (Thread 20804500 (LWP 100100))]#0  0x20435f28 in 
  kevent () from /lib/libc.so.7
  (gdb) bt
  #0  0x20435f28 in kevent () from /lib/libc.so.7
  #1  0x0014f2dc in ?? ()
  (gdb) thread 2
  [Switching to thread 2 (Thread 208043c0 (LWP 100099))]#0  0x203ab6f4 in 
  _umtx_op () from /lib/libc.so.7
  (gdb) bt
  #0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
  #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
  #2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
  #3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
  #4  0x in ?? ()
  (gdb) thread 3
  [Switching to thread 3 (Thread 20804280 (LWP 100098))]#0  0x203ab6f4 in 
  _umtx_op () from /lib/libc.so.7
  (gdb) bt
  #0  0x203ab6f4 in _umtx_op () from /lib/libc.so.7
  #1  0x2035769c in pthread_cleanup_push () from /lib/libthr.so.3
  #2  0x20357a78 in pthread_cleanup_push () from /lib/libthr.so.3
  #3  0x20355580 in pthread_cond_signal () from /lib/libthr.so.3
  #4  0x2092d008 in ?? ()
  (gdb) thread 4
  [Switching to thread 4 (Thread 20804140 (LWP 100043))]#0  0x0015755c in ?? 
  ()
  (gdb) bt
  #0  0x0015755c in ?? ()
 
 Compile and install ld-elf.so, libc and libthr with debugging symbols:
 (cd libexec/rtld-elf  make all install DEBUG_FLAGS=-g)
 (cd lib/libc  make all install DEBUG_FLAGS=-g)
 (cd lib/libthr  make all install DEBUG_FLAGS=-g)
 
 Then repeat the crash and try to see where in code does it happen.

Currently I can only get this type.
I've started the unstripped named to get all the function names.

(gdb) thread 1
[Switching to thread 1 (Thread 20804500 (LWP 100100))]#0  0x20435308 in kevent 
() at kevent.S:3
3   RSYSCALL(kevent)
Current language:  auto; currently asm
(gdb) bt
#0  0x20435308 in kevent () at kevent.S:3
#1  0x0014f2dc in watcher ()
#2  0x203495b0 in thread_start (curthread=0x20804500) at 
/data/builder/arm-current/head/lib/libthr/thread/thr_create.c:288
#3  0x20349a20 in _pthread_create (thread=0x2046caa8, attr=0xbfffe7f8, 
start_routine=0x14f2ac watcher, arg=Variable arg is not available

Re: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote:
 On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
  On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
   On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
 [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0  0x0015755c in 
 isc_atomic_cmpxchg ()
 (gdb) bt
 #0  0x0015755c in isc_atomic_cmpxchg ()
 #1  0x00157dac in isc_rwlock_lock ()
 #2  0x000f9790 in dns_db_register ()
 #3  0x0004d590 in dns_sdb_register ()
 #4  0xc974 in ns_builtin_init ()
 #5  0x0001aa90 in $a ()
 #6  0x0001aa90 in $a ()
 
 isc_atomic_cmpxchg really sounds quite interesting though.
 It is not only the crashing function it is also a type of function which
 sounds error prune.

For me it looks like a bug in bind itself.
It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h.
My assumption is that either the assembly is broken or it gets an
invalid pointer.
I'm not very expirienced with ARM assembly.
Warner - it names you in the copyright, so very likely you know this code.
I will build a debug version of bind, but as usual it will take some
time...

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Fri, Feb 19, 2010 at 04:30:00AM +0100, Bernd Walter wrote:
 On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote:
  On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
   On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
 On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
  [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0  0x0015755c in 
  isc_atomic_cmpxchg ()
  (gdb) bt
  #0  0x0015755c in isc_atomic_cmpxchg ()
  #1  0x00157dac in isc_rwlock_lock ()
  #2  0x000f9790 in dns_db_register ()
  #3  0x0004d590 in dns_sdb_register ()
  #4  0xc974 in ns_builtin_init ()
  #5  0x0001aa90 in $a ()
  #6  0x0001aa90 in $a ()
  
  isc_atomic_cmpxchg really sounds quite interesting though.
  It is not only the crashing function it is also a type of function which
  sounds error prune.
 
 For me it looks like a bug in bind itself.
 It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h.
 My assumption is that either the assembly is broken or it gets an
 invalid pointer.
 I'm not very expirienced with ARM assembly.
 Warner - it names you in the copyright, so very likely you know this code.
 I will build a debug version of bind, but as usual it will take some
 time...

Maybe it helps in the meanwhile:
(gdb) disassemble 0x0015755c
Dump of assembler code for function isc_atomic_cmpxchg:
0x00157550 isc_atomic_cmpxchg+0:  mov r3, r0
0x00157554 isc_atomic_cmpxchg+4:  sub r0, pc, #8  ; 0x8
0x00157558 isc_atomic_cmpxchg+8:  mov r12, #-536870908; 
0xe004
0x0015755c isc_atomic_cmpxchg+12: str r0, [r12]
0x00157560 isc_atomic_cmpxchg+16: mov r12, #-536870904; 
0xe008
0x00157564 isc_atomic_cmpxchg+20: add r0, pc, #12 ; 0xc
0x00157568 isc_atomic_cmpxchg+24: str r0, [r12]
0x0015756c isc_atomic_cmpxchg+28: ldr r0, [r3]
0x00157570 isc_atomic_cmpxchg+32: cmp r0, r1
0x00157574 isc_atomic_cmpxchg+36: streq   r2, [r3]
0x00157578 isc_atomic_cmpxchg+40: mov r1, #0  ; 0x0
0x0015757c isc_atomic_cmpxchg+44: mov r12, #-536870908; 
0xe004
0x00157580 isc_atomic_cmpxchg+48: str r1, [r12]
0x00157584 isc_atomic_cmpxchg+52: mvn r1, #0  ; 0x0
0x00157588 isc_atomic_cmpxchg+56: mov r12, #-536870904; 
0xe008
0x0015758c isc_atomic_cmpxchg+60: str r1, [r12]
0x00157590 isc_atomic_cmpxchg+64: mov pc, lr
End of assembler dump.

Seems to be the str in line 57, which is crashing.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Thu, Feb 18, 2010 at 08:40:12PM -0700, M. Warner Losh wrote:
 In message: 20100219033000.gz43...@cicely7.cicely.de
 Bernd Walter ti...@cicely7.cicely.de writes:
 : On Fri, Feb 19, 2010 at 04:12:00AM +0100, Bernd Walter wrote:
 :  On Thu, Feb 18, 2010 at 03:10:10PM +0200, Kostik Belousov wrote:
 :   On Thu, Feb 18, 2010 at 01:49:07PM +0100, Bernd Walter wrote:
 :On Tue, Feb 16, 2010 at 07:39:51PM +0100, Bernd Walter wrote:
 : On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
 :  [Switching to thread 4 (Thread 20804140 (LWP 100053))]#0  0x0015755c in 
 isc_atomic_cmpxchg ()
 :  (gdb) bt
 :  #0  0x0015755c in isc_atomic_cmpxchg ()
 :  #1  0x00157dac in isc_rwlock_lock ()
 :  #2  0x000f9790 in dns_db_register ()
 :  #3  0x0004d590 in dns_sdb_register ()
 :  #4  0xc974 in ns_builtin_init ()
 :  #5  0x0001aa90 in $a ()
 :  #6  0x0001aa90 in $a ()
 :  
 :  isc_atomic_cmpxchg really sounds quite interesting though.
 :  It is not only the crashing function it is also a type of function which
 :  sounds error prune.
 : 
 : For me it looks like a bug in bind itself.
 : It is in contrib/bind9/lib/isc/arm/include/isc/atomic.h.
 : My assumption is that either the assembly is broken or it gets an
 : invalid pointer.
 : I'm not very expirienced with ARM assembly.
 : Warner - it names you in the copyright, so very likely you know this code.
 : I will build a debug version of bind, but as usual it will take some
 : time...
 
 Damn.  It wasn't me.
 
 Oh, wait, maybe it was...

:-)

 I'll try to look at it tomorrow...

Thank you.
Recompiling libbind and named with debug support also takes some time.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Thu, Feb 18, 2010 at 08:47:39PM -0700, M. Warner Losh wrote:
 In message: 20100219033000.gz43...@cicely7.cicely.de
 Bernd Walter ti...@cicely7.cicely.de writes:
 : Warner - it names you in the copyright, so very likely you know this code.
 : I will build a debug version of bind, but as usual it will take some
 : time...
 
 Make sure that the code matches our current atomics code...

There are just 3 functions.
isc_atomic_xadd and isc_atomic_store just wrap to atomic_fetchadd_int and
atomic_store_rel_int
isc_atomic_cmpxchg is inline assembly, but I don't think we have such a
function in our ARM atomic.h - at least I can't find it.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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

lang/perl5.10 broken

[Bernd Walter]

Not sure if this is ARM related or not.

`sh  cflags optimize='-O -pipe -mcpu=arm9' opmini.o` -DPIC -fPIC 
-DPERL_EXTERNAL_GLOB opmini.c
  CCCMD =  cc -DPERL_CORE -c 
-DAPPLLIB_EXP=/usr/local/lib/perl5/5.10.1/BSDPAN -DHAS_FPSETMASK 
-DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector 
-I/usr/local/include  -O -pipe -mcpu=arm9 -Wall -W -Wextra 
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat 
`sh  cflags optimize='-O -pipe -mcpu=arm9' perlmini.o` -DPIC -fPIC 
-DPERL_IS_MINIPERL perlmini.c
  CCCMD =  cc -DPERL_CORE -c 
-DAPPLLIB_EXP=/usr/local/lib/perl5/5.10.1/BSDPAN -DHAS_FPSETMASK 
-DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -fstack-protector 
-I/usr/local/include  -O -pipe -mcpu=arm9 -Wall -W -Wextra 
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat 
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1 cc -Wl,-E  
-fstack-protector -L/usr/local/lib -o miniperlgv.o toke.o perly.o pad.o 
regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o 
scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o 
universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o 
pp_pack.o pp_sort.o   miniperlmain.o opmini.o perlmini.o -lm -lcrypt -lutil
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1  ./miniperl 
-w -Ilib -MExporter -e '?' || make minitest
cp ext/re/re.pm lib/re.pm
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1  ./miniperl 
-Ilib make_patchnum.pl
*** Signal 11

Stop in /usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1.
*** Error code 1 (ignored)
 
You may see some irrelevant test failures if you have been unable
to build lib/Config.pm, lib/lib.pm or the Unicode data files.
 
cd t  (rm -f perl; /bin/ln -s ../miniperl perl)   
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1  ./perl TEST 
-minitest base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t uni/*.t /dev/tty
*** Signal 11 (ignored)
LD_LIBRARY_PATH=/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1  ./miniperl 
-Ilib autodoc.pl
*** Signal 11

Stop in /usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1.
*** Error code 1

Stop in /usr/ports/lang/perl5.10.
*** Error code 1

Stop in /usr/ports/lang/perl5.10.
11062.000u 1053.000s 4:22:49.31 76.8%   717+-46k 198+25986io 1405pf+0w
Exit 1

[99]Please.tell.me.who.am.I# gdb 
/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1/miniperl 
/usr/obj/usr/ports/lang/perl5.10/work/perl-5.10.1/t/miniperl.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as arm-marcel-freebsd...(no debugging symbols 
found)...
Core was generated by `miniperl'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libutil.so.9...(no debugging symbols found)...done.
Loaded symbols for /lib/libutil.so.9
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000f6eb4 in Perl_new_collate ()
(gdb) bt
#0  0x000f6eb4 in Perl_new_collate ()
#1  0x000f7904 in Perl_init_i18nl10n ()
#2  0x0011e618 in perl_construct ()
#3  0x00103e10 in main ()
(gdb) 

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: lang/perl5.10 broken

[Bernd Walter]

On Wed, Feb 17, 2010 at 10:01:13AM -0700, M. Warner Losh wrote:
 In message: 20100217152557.gw43...@cicely7.cicely.de
 Bernd Walter ti...@cicely7.cicely.de writes:
 : Not sure if this is ARM related or not.
 
 ...
 : *** Signal 11
 
 Silly question: do you have enough swap space enabled?

First try was with 128M on internal SD of which usually just about
10M is used during compiler runs and the second was with 1G on external
USB SD reader, but just because of speed with internal.
I also saw no kernel message that the system was out of space.

I'm currently trying to compile perl5.8, but it takes some time.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Mon, Feb 15, 2010 at 10:39:07PM +0100, Bernd Walter wrote:
 [62]# uname -a
 FreeBSD  9.0-CURRENT FreeBSD 9.0-CURRENT #0 r203927: Mon Feb 15 19:12:36 CET 
 2010 
 ti...@cicely14.cicely.de:/data/builder/arm-current/head/sys/arm/compile/FBOX  
 arm
 [64]# /etc/rc.d/named start
 Starting named.
 /etc/rc.d/named: WARNING: failed to start named
 1.000u 0.000s 0:03.94 54.0% 7446+33509k 0+0io 17pf+0w
 Exit 1
 
 [65]# tail /var/log/messages 
 ...
 Feb 15 21:29:51  named[2567]: starting BIND 9.6.1-P3 -u bind
 Feb 15 21:29:51  named[2567]: built with '--prefix=/usr' 
 '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' 
 '--disable-ipv6' '--enable-getifaddrs' '--disable-linux-caps' 
 '--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' 
 '--without-libxml2'
 Feb 15 21:29:51  kernel: pid 2567 (named), uid 0: exited on signal 11
 Feb 15 21:29:51  ticso: /etc/rc.d/named: WARNING: failed to start named
 
 [66]# cat /etc/rc.conf 
 hostname=Please.tell.me.who.am.I
 tmpmfs=AUTO
 tmpsize=4m
 tmpmfs_flags=-S -M
 varmfs=AUTO
 varsize=5m
 varmfs_flags=-S -M
 sshd_enable=YES
 ntpdate_enable=YES
 ntpdate_program=ntpdate
 ntpd_enable=YES
 thttpd_enable=NO
 fsck_y_enable=YES
 background_fsck=NO
 gateway_enable=YES
 named_enable=YES
 named_chrootdir=
 ifconfig_ate0=up
 mpd_enable=NO
 mpd_flags=-b
 dhcpd_enable=NO
 dhcpd_ifaces=vlan0
 firewall_enable=YES
 firewall_script=/etc/rc.ipfw
 cloned_interfaces=vlan0 vlan1 vlan2 vlan3
 ifconfig_vlan0=192.168.53.1/24 vlan 256 vlandev ate0
 ifconfig_vlan1=vlan 257 vlandev ate0
 ifconfig_vlan2=vlan 258 vlandev ate0
 ifconfig_vlan3=vlan 259 vlandev ate0
 
 /etc/namedb isn't changed from distribution yet

[55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as arm-marcel-freebsd...(no debugging symbols 
found)...
Core was generated by `named'.
Program terminated with signal 5, Trace/breakpoint trap.
Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
[New Thread 20804280 (LWP 100062)]
[New Thread 20804140 (LWP 100052)]
(gdb) bt
#0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
#1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
#2  0x20349da4 in pthread_create () from /lib/libthr.so.3
#3  0x00164cb8 in ?? ()
(gdb) 

Do we have a general threading problem on ARM?

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start

[Bernd Walter]

On Tue, Feb 16, 2010 at 10:40:37AM -0800, Doug Barton wrote:
 On 2/15/2010 1:39 PM, Bernd Walter wrote:
  [62]# uname -a
  FreeBSD  9.0-CURRENT FreeBSD 9.0-CURRENT #0 r203927: Mon Feb 15 19:12:36 
  CET 2010 
  ti...@cicely14.cicely.de:/data/builder/arm-current/head/sys/arm/compile/FBOX
arm
  [64]# /etc/rc.d/named start
  Starting named.
  /etc/rc.d/named: WARNING: failed to start named
  1.000u 0.000s 0:03.94 54.0% 7446+33509k 0+0io 17pf+0w
  Exit 1
 
 Are you getting a core file? If so can you do a backtrace?

I needed to take care about gdb to run.
See my other mail about it.
gdb and ktrace on ARM are still tools which tend to fail quite often :(

  [66]# cat /etc/rc.conf 
  hostname=Please.tell.me.who.am.I
 
 Bonus points here for not ending in .am. :)

That's just a template entry.

  tmpmfs=AUTO
  tmpsize=4m
  tmpmfs_flags=-S -M
 
 FYI, that size of /tmp will probably not allow your periodic/weekly
 process to generate a locate.database. IME you need a /tmp at least 2.5
 times the size of that file in order for it to complete successfully.

Thanks for the pointer - I should disable it.
The system just has 64MB RAM, so large memory filesystems are out of
question.

  ntpdate_enable=YES
  ntpdate_program=ntpdate
 
 IMO you'd be better off with a full path here, although this will
 probably work for /usr/sbin/ntpdate. However you're actually better off
 with the ntpd_sync_on_start option in any case.

This is a bit old - I will compare it with new features.

  cloned_interfaces=vlan0 vlan1 vlan2 vlan3
  ifconfig_vlan0=192.168.53.1/24 vlan 256 vlandev ate0
  ifconfig_vlan1=vlan 257 vlandev ate0
  ifconfig_vlan2=vlan 258 vlandev ate0
  ifconfig_vlan3=vlan 259 vlandev ate0
 
 This is the only area that I have real questions about, since I haven't
 done any work with vlans I'm not sure how named will respond to it. Is
 it possible for you to try starting named with a plain vanilla network
 setup?

I need to recompile the kernel for this, because the  board has an
embedded switch which is setup hardcoded inside the kernel.
But I use this type of setup since a very long time including 7.0 on
the same board type.

  /etc/namedb isn't changed from distribution yet
 
 Ok, since you're not chroot'ing it have you checked to make sure that
 directory is populated? It shouldn't segfault even if it isn't, but nice
 to cover all the bases.

Originally I used the default and just switched for testen.
[61]Please.tell.me.who.am.I# ls -al /etc/namedb/
total 32
drwxr-xr-x  6 root  wheel512 Feb 16 18:47 .
drwxr-xr-x  3 root  wheel512 Feb 15 19:30 ..
drwxr-xr-x  2 bind  wheel512 Feb 15 18:07 dynamic
drwxr-xr-x  2 root  wheel512 Feb 15 18:09 master
-rw-r--r--  1 root  wheel  13969 Feb 15 18:09 named.conf
-rw-r--r--  1 root  wheel   3015 Feb 15 18:09 named.root
-rw---  1 bind  wheel 97 Feb 15 19:30 rndc.key
drwxr-xr-x  2 bind  wheel512 Feb 15 18:07 slave
drwxr-xr-x  2 bind  wheel512 Feb 15 18:07 working
[62]Please.tell.me.who.am.I# ls -al /etc/namedb
lrwxr-xr-x  1 root  wheel  21 Feb 15 20:36 /etc/namedb - /var/named/etc/namedb

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 10:45:14AM -0800, Doug Barton wrote:
 On 2/16/2010 10:39 AM, Bernd Walter wrote:
  [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
  GNU gdb 6.1.1 [FreeBSD]
  Copyright 2004 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you are
  welcome to change it and/or distribute copies of it under certain 
  conditions.
  Type show copying to see the conditions.
  There is absolutely no warranty for GDB.  Type show warranty for details.
  This GDB was configured as arm-marcel-freebsd...(no debugging symbols 
  found)...
  Core was generated by `named'.
  Program terminated with signal 5, Trace/breakpoint trap.
  Reading symbols from /lib/libcrypto.so.6...(no debugging symbols 
  found)...done.
  Loaded symbols for /lib/libcrypto.so.6
  Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
  Loaded symbols for /lib/libthr.so.3
  Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
  Loaded symbols for /lib/libc.so.7
  Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
  found)...done.
  Loaded symbols for /libexec/ld-elf.so.1
  #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
  [New Thread 20804280 (LWP 100062)]
  [New Thread 20804140 (LWP 100052)]
  (gdb) bt
  #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
  #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
  #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
  #3  0x00164cb8 in ?? ()
  (gdb) 
  
  Do we have a general threading problem on ARM?
 
 Wow, that was fast. :)  It sure looks like that's the problem. Can you
 try compiling ports/dns/bind96 without threads and see if that works for
 you? If it does then it would be good to follow up on
 freebsd-...@freebsd.org and see if the problem can be addressed.

I'd send it before I saw your mail.
Compiling however will take some time.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 01:54:30PM -0700, M. Warner Losh wrote:
 In message: 20100216123646.fc741643.s...@freebsd.org
 Stanislav Sedov s...@freebsd.org writes:
 : On Tue, 16 Feb 2010 19:39:51 +0100
 : Bernd Walter ti...@cicely7.cicely.de mentioned:
 : 
 :  
 :  Do we have a general threading problem on ARM?
 :  
 : 
 : I don't think so.  I used a lot of threaded applications on arm, and they
 : worked fine.  However, this might be some obscure bug.
 
 I know that 6.x ARM worked with threads no problem.  We had dozens of
 threads in our control programs.

No doubt - I'm running 7.0-current:
[82]arm9# uname -a
FreeBSD arm9.cicely.de 7.0-CURRENT FreeBSD 7.0-CURRENT #12: Thu Dec  6 02:39:25 
CET 2007 
ti...@arm9.cicely.de:/data/builder/arm-p4-running-2/src/sys/arm/compile/FBOX  
arm
[83]arm9# uptime
10:02PM  up 690 days, 19:43, 1 user, load averages: 0.29, 0.22, 0.15

Including named, although not on exactly this machine.
This one is even compiled O2 - with a few hand selected exceptions.

Compiling perl fails with sig11 as well, but I hadn't verified this
problem any further.

 The one caveat is that I've found bugs in the atomic routines in the
 past, and have had people submit fixes as well.  All of those should
 be in the tree, but since some arrived when I was crazy busy for
 Cisco, they might have fallen on the floor.

I'm running on RM9200, so it is a UP system.
Of course this won't rule out all possible atomic cases.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 11:02:24AM -0800, Doug Barton wrote:
 On 2/16/2010 10:56 AM, Bernd Walter wrote:
  Wow, that was fast. :)  It sure looks like that's the problem. Can you
  try compiling ports/dns/bind96 without threads and see if that works for
  you? If it does then it would be good to follow up on
  freebsd-...@freebsd.org and see if the problem can be addressed.
  
  I'd send it before I saw your mail.
 
 Yeah, I figured that when I got your other reply just now. :)  I
 received the trace message to the list in the same mail download as my
 message to the list, which I thought was quite impressive on your part. :)
 
  Compiling however will take some time.
 
 No problem, let us know how it works out.

A first try failed because a dependend lib won't compile :(
I will retry without XML.
But iconv isn't that unimportant, so this needs investigation as well.

[...]
install  -o root -g wheel -m 444 include/libcharset.h 
/usr/obj/usr/ports/converters/libiconv/work/libiconv-1.13.1/lib/libcharset.h
install  -o root -g wheel -m 444 include/localcharset.h.inst 
/usr/obj/usr/ports/converters/libiconv/work/libiconv-1.13.1/lib/localcharset.h
cd lib  make all
/bin/sh /usr/local/bin/libtool --mode=compile --tag=CC cc -I. -I. -I../include 
-I./../include -I.. -I./..  -O -pipe -mcpu=arm9 -std=gnu89 
-DLIBDIR=\/usr/local/lib\ -DBUILDING_LIBICONV -DBUILDING_DLL  
-DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\/usr/local/lib\ 
-DNO_XMALLOC  -Dset_relocation_prefix=libiconv_set_relocation_prefix  
-Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c
libtool: compile:  cc -I. -I. -I../include -I./../include -I.. -I./.. -O -pipe 
-mcpu=arm9 -std=gnu89 -DLIBDIR=\/usr/local/lib\ -DBUILDING_LIBICONV 
-DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY 
-DINSTALLDIR=\/usr/local/lib\ -DNO_XMALLOC 
-Dset_relocation_prefix=libiconv_set_relocation_prefix 
-Drelocate=libiconv_relocate -DHAVE_CONFIG_H -c ./iconv.c  -fPIC -DPIC -o 
.libs/iconv.o
{standard input}: Assembler messages:
{standard input}:569470: Error: symbol definition loop encountered at `.L4822'
*** Error code 1

Stop in /usr/obj/usr/ports/converters/libiconv/work/libiconv-1.13.1/lib.
*** Error code 1

Stop in /usr/obj/usr/ports/converters/libiconv/work/libiconv-1.13.1.
*** Error code 1

Stop in /usr/ports/converters/libiconv.
*** Error code 1

Stop in /usr/ports/converters/libiconv.
*** Error code 1

Stop in /usr/ports/devel/gettext.
*** Error code 1

Stop in /usr/ports/devel/gmake.
*** Error code 1

Stop in /usr/ports/textproc/libxml2.
*** Error code 1

Stop in /usr/ports/dns/bind96.
*** Error code 1

Stop in /usr/ports/dns/bind96.
3214.000u 1468.000s 2:12:18.00 58.9%3300+1299k 845+23834io 5433pf+0w
Exit 1

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 12:36:46PM -0800, Stanislav Sedov wrote:
 On Tue, 16 Feb 2010 19:39:51 +0100
 Bernd Walter ti...@cicely7.cicely.de mentioned:
 
  
  Do we have a general threading problem on ARM?
  
 
 I don't think so.  I used a lot of threaded applications on arm, and they
 worked fine.  However, this might be some obscure bug.

The question is if it works on current.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 01:54:30PM -0700, M. Warner Losh wrote:
 In message: 20100216123646.fc741643.s...@freebsd.org
 Stanislav Sedov s...@freebsd.org writes:
 : On Tue, 16 Feb 2010 19:39:51 +0100
 : Bernd Walter ti...@cicely7.cicely.de mentioned:
 : 
 :  
 :  Do we have a general threading problem on ARM?
 :  
 : 
 : I don't think so.  I used a lot of threaded applications on arm, and they
 : worked fine.  However, this might be some obscure bug.
 
 I know that 6.x ARM worked with threads no problem.  We had dozens of
 threads in our control programs.
 
 The one caveat is that I've found bugs in the atomic routines in the
 past, and have had people submit fixes as well.  All of those should
 be in the tree, but since some arrived when I was crazy busy for
 Cisco, they might have fallen on the floor.

At least in my short test threads seem to work:
[70]Please.tell.me.who.am.I# gcc -Wall -pthread -o thread thread.c
5.000u 0.000s 0:15.80 42.7% 39273+42143k 7+0io 0pf+0w
[71]Please.tell.me.who.am.I# ./thread
hello world
hello world from thread
[72]Please.tell.me.who.am.I# cat thread.c 
#include pthread.h
#include stdint.h
#include stdio.h
#include unistd.h

void *
mythread(void *arg)
{
printf(hello world from thread\n);
return NULL;
}

int
main(int argc, char *argv[])
{
printf(hello world\n);
pthread_t id = 0;
pthread_create(id, NULL, mythread, NULL);
sleep(10);
return 0;
}

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: bind fails with sig11 on start / pthread failure on ARM?

[Bernd Walter]

On Tue, Feb 16, 2010 at 10:13:27PM +0100, Bernd Walter wrote:
 On Tue, Feb 16, 2010 at 11:02:24AM -0800, Doug Barton wrote:
  On 2/16/2010 10:56 AM, Bernd Walter wrote:
   Wow, that was fast. :)  It sure looks like that's the problem. Can you
   try compiling ports/dns/bind96 without threads and see if that works for
   you? If it does then it would be good to follow up on
   freebsd-...@freebsd.org and see if the problem can be addressed.
   
   I'd send it before I saw your mail.
  
  Yeah, I figured that when I got your other reply just now. :)  I
  received the trace message to the list in the same mail download as my
  message to the list, which I thought was quite impressive on your part. :)
  
   Compiling however will take some time.
  
  No problem, let us know how it works out.

Mmm - the port (without thread and without XML) works fine:
[78]Please.tell.me.who.am.I# host -a www.freebsd.org 127.0.0.1
Trying www.freebsd.org
Using domain server:
Name: 10.1.1.9
Address: 10.1.1.9#53
Aliases: 

;; -HEADER- opcode: QUERY, status: NOERROR, id: 2501
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
;www.freebsd.org.   IN  ANY

;; ANSWER SECTION:
www.freebsd.org.3600IN  MX  0 .
www.freebsd.org.3600IN  2001:4f8:fff6::21
www.freebsd.org.3600IN  A   69.147.83.33

;; AUTHORITY SECTION:
freebsd.org.3544IN  NS  ns3.isc-sns.info.
freebsd.org.3544IN  NS  ns2.isc-sns.com.
freebsd.org.3544IN  NS  ns1.isc-sns.net.

;; ADDITIONAL SECTION:
ns2.isc-sns.com.87978   IN  A   38.103.2.1
ns1.isc-sns.net.87978   IN  A   72.52.71.1
ns1.isc-sns.net.87978   IN  2001:470:1a::1
ns3.isc-sns.info.   3546IN  A   63.243.194.1
ns3.isc-sns.info.   3546IN  2001:5a0:10::1

Received 284 bytes from 10.1.1.9#53 in 135 ms

Feb 17 02:21:48 Please named[28754]: starting BIND 9.6.1-P3
Feb 17 02:21:48 Please named[28754]: built with '--localstatedir=/var' 
'--disable-linux-caps' '--with-randomdev=/dev/random' '--with-openssl=/usr' 
'--without-libxml2' '--without-idn' '--disable-threads' '--prefix=/usr/local' 
'--mandir=/usr/local/man' '--infodir=/usr/local/info/' 
'--build=arm-portbld-freebsd9.0' 'build_alias=arm-portbld-freebsd9.0' 'CC=cc' 
'CFLAGS=-O -pipe -mcpu=arm9' 'LDFLAGS= -rpath=/usr/lib:/usr/local/lib' 
'CXX=c++' 'CXXFLAGS=-O -pipe -mcpu=arm9'
Feb 17 02:21:54 Please named[28754]: max open files (957) is smaller than max 
sockets (4096)
Feb 17 02:21:57 Please named[28754]: command channel listening on 127.0.0.1#953
Feb 17 02:21:57 Please named[28754]: command channel listening on ::1#953
Feb 17 02:22:05 Please named[28754]: running

[75]Please.tell.me.who.am.I# sockstat | grep named
root named  28754 3  dgram  - /var/run/logpriv
root named  28754 20 tcp4   127.0.0.1:53  *:*
root named  28754 21 tcp4   127.0.0.1:953 *:*
root named  28754 22 tcp6   ::1:953   *:*
root named  28754 512 udp4  127.0.0.1:53  *:*

On the other hand a short pthread test worked fine as well.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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

bind fails with sig11 on start

[Bernd Walter]

[62]# uname -a
FreeBSD  9.0-CURRENT FreeBSD 9.0-CURRENT #0 r203927: Mon Feb 15 19:12:36 CET 
2010 
ti...@cicely14.cicely.de:/data/builder/arm-current/head/sys/arm/compile/FBOX  
arm
[64]# /etc/rc.d/named start
Starting named.
/etc/rc.d/named: WARNING: failed to start named
1.000u 0.000s 0:03.94 54.0% 7446+33509k 0+0io 17pf+0w
Exit 1

[65]# tail /var/log/messages 
...
Feb 15 21:29:51  named[2567]: starting BIND 9.6.1-P3 -u bind
Feb 15 21:29:51  named[2567]: built with '--prefix=/usr' 
'--infodir=/usr/share/info' '--mandir=/usr/share/man' '--enable-threads' 
'--disable-ipv6' '--enable-getifaddrs' '--disable-linux-caps' 
'--with-openssl=/usr' '--with-randomdev=/dev/random' '--without-idn' 
'--without-libxml2'
Feb 15 21:29:51  kernel: pid 2567 (named), uid 0: exited on signal 11
Feb 15 21:29:51  ticso: /etc/rc.d/named: WARNING: failed to start named

[66]# cat /etc/rc.conf 
hostname=Please.tell.me.who.am.I
tmpmfs=AUTO
tmpsize=4m
tmpmfs_flags=-S -M
varmfs=AUTO
varsize=5m
varmfs_flags=-S -M
sshd_enable=YES
ntpdate_enable=YES
ntpdate_program=ntpdate
ntpd_enable=YES
thttpd_enable=NO
fsck_y_enable=YES
background_fsck=NO
gateway_enable=YES
named_enable=YES
named_chrootdir=
ifconfig_ate0=up
mpd_enable=NO
mpd_flags=-b
dhcpd_enable=NO
dhcpd_ifaces=vlan0
firewall_enable=YES
firewall_script=/etc/rc.ipfw
cloned_interfaces=vlan0 vlan1 vlan2 vlan3
ifconfig_vlan0=192.168.53.1/24 vlan 256 vlandev ate0
ifconfig_vlan1=vlan 257 vlandev ate0
ifconfig_vlan2=vlan 258 vlandev ate0
ifconfig_vlan3=vlan 259 vlandev ate0

/etc/namedb isn't changed from distribution yet

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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

ports/net/mpd[45] broken with utmpx.h change

[Bernd Walter]

===  Building for mpd-4.4.1_1
=== src (all)
Warning: Object directory not changed from original 
/usr/obj/usr/ports/net/mpd4/work/mpd-4.4.1/src
cc -O -pipe -mcpu=arm9 -DNO_IDEA -mcpu=arm9 
-DPATH_CONF_DIR=\/usr/local/etc/mpd4\ -DSYSLOG_FACILITY=LOG_DAEMON 
-DMPD_VERSION='4.4.1 (r...@please.tell.me.who.am.i 01:46 16-Feb-2010)' -g 
-Wall  -Wcast-align  -Wchar-subscripts  -Wformat  -Winline  
-Wmissing-declarations  -Wmissing-prototypes  -Wnested-externs  -Wpointer-arith 
 -Wwrite-strings  -pthread  -I/usr/local/include -DPHYSTYPE_MODEM 
-DPHYSTYPE_UDP -DPHYSTYPE_TCP -DPHYSTYPE_NG_SOCKET -DPHYSTYPE_PPTP 
-DPHYSTYPE_PPPOE -DPHYSTYPE_L2TP -DENCRYPTION_DES -std=gnu99  -c modem.c
In file included from auth.h:22,
 from bund.h:22,
 from ppp.h:117,
 from modem.c:10:
/usr/include/utmp.h:2:2: error: #error utmp.h has been replaced by utmpx.h
*** Error code 1

I don't know how difficult it is to fix, but for many of us mpd is
important to have network connection.

-- 
B.Walter be...@bwct.de http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
___
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: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Bernd Walter]

On Sat, Nov 22, 2003 at 08:08:29AM -0500, Brian F. Feldman wrote:
 Found it!!!  Definitely a problem created then...
 
 --- ohci.c  12 Nov 2003 01:40:11 -  1.138
 +++ ohci.c  22 Nov 2003 03:28:42 -
 @@ -569,7 +569,7 @@
 cur-td.td_cbp = htole32(dataphys);
 cur-nexttd = next;
 cur-td.td_nexttd = htole32(next-physaddr);
 -   cur-td.td_be = htole32(DMAADDR(dma, curlen - 1));
 +   cur-td.td_be = htole32(DMAADDR(dma, offset + curlen - 1));
 cur-len = curlen;
 cur-flags = OHCI_ADD_LEN;
 cur-xfer = xfer;
 
 I'm a lot happier now :-)  Let's start trying to get this stuff merged in!

Great news!

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

[Bernd Walter]

On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote:
 Doug White [EMAIL PROTECTED] wrote:
  The OHCI driver is largely synced with NetBSD so you might see if they
  have the same bug.
 
 I'll look around for a bootable NetBSD CD.

NetBSD is different in that point.

  This might be the underlying wierdness we were seeing in gtetlow's
  microdrive with transfers over 8k.  The one-page-crossing ohci limitation
  is really annoying.
 
 Is there a way to add a quirk for max 8k transfers or anything?  Even though 
 that would be patently lame, I'd like to get some sort of workaround here.  
 I don't even know what is supposed to be the problem here -- the fact that 
 it's an ohci controller, an ohci+ehci controller, or that it's some specific 
 controller issue...

We never did any page crossing on ohci/ehci bevor the newbus change
took place.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Multifunction USB devices

[Bernd Walter]

On Tue, Nov 18, 2003 at 08:12:49PM -0500, Jeff Walters wrote:
 
 I have an Epson printer/scanner combo device (CX5200) which works just 
 fine either as a printer or as a scanner (when I add the vendor and 
 product codes to usbdevs and uscanner.c) but not both simultaneously.  
 Currently I compile ulpt and my customized uscanner as modules, and 
 to switch functions I power the device off, unload/load the 
 appropriate kernel module, and power the device back on.
 
 I'm assuming a patch to add the CX5200 vendor/device codes to usbdevs 
 and uscanner.c in the way I'm doing wouldn't be accepted into CURRENT 
 since the resulting usage of it is a bit of a hack.  Is that right?

The right fix would be to convert uscanner into a function level driver
for scanner combinations - currently it's a device level driver.
ulpt does the right thing.
Compare USB_MATCH and USB_ATTACH functions to get an idea about the
difference.
Adding device identification to uscanner is required anyway, because
there is no class definition for scanners.

 I wouldn't mind doing work over the next few months to create proper 
 simultaneous support for both devices if it can be done with a 
 reasonable level of effort and I can find some sources of 
 information, and I can get some guidance from an experienced 
 committer or architect to help do it right the first time.  Where 
 should I go for discussion?  I'd like to learn ie. should I work to 
 combine ulpt and uscanner into some kind of single umulti type of 
 device driver, or should a virtual hub device of some kind be created 
 to support both ulpt and uscanner simultaneously as-is (one USB 
 endpoint, multiple interfaces), or should the system simply continue 
 searching after matching a USB device, or will this be OBE with some 
 other USB work going on, etc.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Who needs these silly statfs changes...

[Bernd Walter]

On Thu, Nov 13, 2003 at 12:54:18AM -0800, Kris Kennaway wrote:
 On Thu, Nov 13, 2003 at 06:44:25PM +1100, Peter Jeremy wrote:
  On Wed, Nov 12, 2003 at 06:04:00PM -0800, Kris Kennaway wrote:
  ...my sparc machine reports that my i386 nfs server has 15 exabytes of
  free space!
  
  enigma# df -k
  Filesystem  1K-blocks Used Avail Capacity  Mounted on
  rot13:/mnt2  56595176 54032286 18014398507517260 0%/rot13/mnt2
  
  18014398507517260 = 2^54 - 1964724.  and 2^54KB == 2^64 bytes.  Is it
  possible that rot13:/mnt2 has negative free space?  (ie it's into the
  8-10% reserved area).
 
 Yes, that's precisely what it is..the bug is either in df or the
 kernel (I suspect the latter, i.e. something in the nfs code).

And it's nothing new - I'm seeing this since several years now.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: New EHCI device ID

[Bernd Walter]

On Mon, Nov 10, 2003 at 10:03:20AM +0100, Alexander Leidinger wrote:
 On Mon, 10 Nov 2003 00:11:37 +0100
 Bernd Walter [EMAIL PROTECTED] wrote:
 
  On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote:
   It's that easy? Just adding device ID? I was under impression that you
   need to write/modify a driver for a new chip.
  
  Adding the ID is just beautifying the boot messages.
  EHCI controllers are all compatible (modulo bugs) from the software
  point of view.
 
 We have a problem then. Normally this is a headless system, but I had a
 mouse attached once and it caused a hard hang. Something with int 10
 or too much interrupts or something like this (the mouse works on my
 desktop system and it works on the machine in question in Windows). When
 I test the new apic code on this system, I will attache a mouse again
 and report back.

I really doubt that you have a high speed mouse.
EHCI only supports high speed devices itself.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: New EHCI device ID

[Bernd Walter]

On Mon, Nov 10, 2003 at 01:50:02PM +0100, Alexander Leidinger wrote:
 On Mon, 10 Nov 2003 13:19:12 +0100
 Bernd Walter [EMAIL PROTECTED] wrote:
 
  I really doubt that you have a high speed mouse.
  EHCI only supports high speed devices itself.
 
 But it shouldn't stop the entire system if I attach an USB 1.1 mouse to
 an ehci controlled port.

But ehci doesn't control low/full speed ports.
The physical ports are multiplexed between ehci and ohci/uhci ports.
The switching is done without driver interaction.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: New EHCI device ID

[Bernd Walter]

On Mon, Nov 10, 2003 at 03:54:23PM +0100, Alexander Leidinger wrote:
 On Mon, 10 Nov 2003 13:55:39 +0100
 Bernd Walter [EMAIL PROTECTED] wrote:
 
  But ehci doesn't control low/full speed ports.
  The physical ports are multiplexed between ehci and ohci/uhci ports.
  The switching is done without driver interaction.
 
 Attached to the port is a
 
 uhub1: NEC Corporation USB2.0 Hub Controller, class 9/0, rev 2.00/1.00, addr 2
 uhub1: 4 ports with 4 removable, self powered

USB2 hubs are currently not supported with high speed uplinks.
That's the reason why there is no EHCI support in GENERIC.
EHCI needs interrupt transfers first to support usb2.0 hubs at high
speed uplinks with high speed devices.
For low and full speed downlink we additionaly need speed conversion
support in uhub code.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: New EHCI device ID

[Bernd Walter]

On Mon, Nov 10, 2003 at 04:35:31PM +0100, Alexander Leidinger wrote:
 On Mon, 10 Nov 2003 16:19:27 +0100
 Bernd Walter [EMAIL PROTECTED] wrote:
 
  USB2 hubs are currently not supported with high speed uplinks.
  That's the reason why there is no EHCI support in GENERIC.
  EHCI needs interrupt transfers first to support usb2.0 hubs at high
  speed uplinks with high speed devices.
  For low and full speed downlink we additionaly need speed conversion
  support in uhub code.
 
 Is there an easy way of printing something like this instead of halting
 the system?

Don't know, but if I ever put time in that issue then by implementing
the missing points and not by changing symptoms.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: New EHCI device ID

[Bernd Walter]

On Sun, Nov 09, 2003 at 08:24:25PM +0100, Alexander Leidinger wrote:
 
 Hi,
 
 I get this in the dmesg:
 ---snip---
 ehci0: EHCI (generic) USB 2.0 controller mem 0xfc00-0xfc0003ff irq 12 at d
 evice 29.7 on pci0
 ehci0: (New EHCI DeviceId=0x24dd8086)
 ---snip---
 
 pciconv tells me:
 ---snip---
 [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x24dd17f2 chip=0x24dd8086 
 rev=0x02 hdr=0x00
 vendor   = 'Intel Corporation'
 device   = '82801EB/ER (ICH4/ICH5R) USB EHCI Controller'
 class= serial bus
 subclass = USB
 ---snip---
 
 It's an Intel 865PE chipset.

Will take this - there is already a ticket open with a new ID - maybe the
same.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: New EHCI device ID

[Bernd Walter]

On Sun, Nov 09, 2003 at 11:56:19PM +0100, Pav Lucistnik wrote:
 It's that easy? Just adding device ID? I was under impression that you
 need to write/modify a driver for a new chip.

Adding the ID is just beautifying the boot messages.
EHCI controllers are all compatible (modulo bugs) from the software
point of view.

 In that case I'm here with my own motherboard:
 
 ehci0: EHCI (generic) USB 2.0 controller mem 0xdffeff00-0xdffe irq 21 at 
 device 16.3 on pci0
 ehci0: (New EHCI DeviceId=0x31041106)
 
 [EMAIL PROTECTED]:16:3:class=0x0c0320 card=0x71201462 chip=0x31041106 
 rev=0x82 hdr=0x00
 vendor   = 'VIA Technologies Inc'
 device   = 'VT6202 USB 2.0 Enhanced Host Controller'
 class= serial bus
 subclass = USB
 
 But not that it does not work correctly ATM. USB2 devices have problems attaching.

That must be for a different reason.

 I'm willing to test any patches you can come up with.

Well - I need to see the errors first :)

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Forward: HEADS UP! Default value of ip6_v6only changed

[Bernd Walter]

On Tue, Oct 28, 2003 at 11:51:59PM +, Christian Weisgerber wrote:
 Hajimu UMEMOTO [EMAIL PROTECTED] wrote:
 
  Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to
  on on 5.X to follow NetBSD's practice.  This behavior on 5.X breaks
  RFC2553/3493, and the change was intentional from security
  consideration.  But, NetBSD changed it off by default.
 
 OpenBSD's behavior is equivalent to v6only on, and OpenBSD doesn't
 even provide a knob.
 
 Note that the default choice has a major impact on 3rd party software
 (ports).  If we ship with a default of v6only off, then people will
 not fix software to open two sockets.  This in turn means that
 turning v6only on will break this software.  I predict that a good
 many people will then consider the v6only option to be useless.

I can second this.
The first time I noticed this mistake in self written software was when
I tested it on NetBSD, where the default was already to v6only while
FreeBSD still had it off.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: SCSI cd errors

[Bernd Walter]

On Wed, Oct 22, 2003 at 07:47:14PM +0200, Sven Esbjerg wrote:
 I upgraded my PC yesterday and have experienced hangs in boot. It seems
 like something has changed in the SCSI or GEOM code. I have an Advansys SCSI
 controller with two plextor CD drivers attached as well as a HP scanner.
 When the CD drives are detected the system hangs. Booting with verbose output
 shows errors and timeouts.

 adv0: AdvanSys ASC3030/50 SCSI controller port 0x9000-0x90ff mem 
 0xfa221000-0xfa2210ff irq 2 at device 7.0 on pci0

irq2 is bogus - there is no such thing since 80286 systems.
Disabling irq2/9 in BIOS setup may help to work around.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Problems with NFS (client) under 5.1.

[Bernd Walter]

On Tue, Oct 21, 2003 at 01:09:18PM +0100, Josef Karthauser wrote:
 I'm trying to set a FreeBSD 5.1 machine up as an NFS client.  The
 server is on an SGI box.  Things are strange:
 
 phoenix# uname -a
 FreeBSD phoenix.mydomain 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Sep 18 15:20:19 
 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC  i386
 
 phoenix# ls -ld /mnt
 drwxr-xr-x  2 root  wheel  512 Jun  5 01:53 /mnt
 
 phoenix# mount rebus:/rebus/home /mnt
 phoenix# ls -ld /mnt
 ls: /mnt: Permission denied
 phoenix# ls -ld /* | grep mnt
 
 phoenix# umount /mnt
 phoenix# ls -ld /* | grep mnt
 drwxr-xr-x   2 root  wheel   512 Jun  5 01:53 /mnt

You are root - and root is often mapped to nobody on the server.
Are you shure that nobody is allowed to see?
The ls -ld /mnt case is strange, but /mnt is already on the server
namespace.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: new -current panic

[Bernd Walter]

On Mon, Oct 20, 2003 at 09:09:47AM +0200, Soren Schmidt wrote:
 Just got this one (using bsd scheduler):
 
 Fatal trap 12: page fault while in kernel mode
 fault virtual address   = 0x24
 fault code  = supervisor read, page not present
 instruction pointer = 0x8:0xc04b8f3b
 stack pointer   = 0x10:0xcd619bc4
 frame pointer   = 0x10:0xcd619bd8
 code segment= base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def32 1, gran 1
 processor eflags= interrupt enabled, resume, IOPL = 0
 current process = 3 (g_up)
 kernel: type 12 trap, code=0
 Stopped at  propagate_priority+0x8b:cmpl0x24(%ebx),%ecx
 db trace
 propagate_priority(c0ebfe40,c25983c0,c2512400,cd619c14,c04cc9d1) at propagate_pr
 iority+0x8b
 _mtx_lock_sleep(c069c340,0,0,0,c0698700) at _mtx_lock_sleep+0x249
 bufdonebio(c7675b68,cd619c44,c048d612,c084c540,c259f990) at bufdonebio+0x47
 biodone(c7675b68,c06411ba,c259f990,c7675b68,0) at biodone+0xbc
 g_dev_done(c259f990,c0ebfe40,1,0,4) at g_dev_done+0x8a
 biodone(c259f990,0,24c,c0640b45,a) at biodone+0xbc
 g_io_schedule_up(c0ebfe40,c0ebe1e4,cd619d34,c04acae1,0) at g_io_schedule_up+0xb8
 g_up_procbody(0,cd619d48,0,0,0) at g_up_procbody+0x28
 fork_exit(c048df60,0,cd619d48) at fork_exit+0xb1
 fork_trampoline() at fork_trampoline+0x8
 --- trap 0x1, eip = 0, esp = 0xcd619d7c, ebp = 0 ---
 db 

I can remember having seen a similar panic several month ago - maybe
even in jan or feb.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: USB problem: /dev/ugen* dynamically auto-reconfigures to root:operator 644, so non-root user unable to access USB devices even if wanted

[Bernd Walter]

On Mon, Oct 20, 2003 at 01:44:50PM +0200, Poul-Henning Kamp wrote:
 In message [EMAIL PROTECTED], Andreas Klemm writ
 es:
 [EMAIL PROTECTED] ~ ls -l /dev/ugen*
 crw-r--r--  1 root  operator  114,   0 Oct 20 13:14 /dev/ugen0
 crw-r--r--  1 root  operator  114,   2 Oct 20 13:14 /dev/ugen0.2
 crw-rw-rw-  1 root  operator  114,  16 Oct 20 13:14 /dev/ugen1
 crw-r--r--  1 root  operator  114,  17 Oct 20 13:14 /dev/ugen1.1
 crw-r--r--  1 root  operator  114,  18 Oct 20 13:14 /dev/ugen1.2
 crw-r--r--  1 root  operator  114,  19 Oct 20 13:14 /dev/ugen1.3
 
 And voila, ther permission are wrong again.
 
 I have no idea what goes on here.

An USB device can be switched between several alternative
configurations.
If such a change is requested (USB_SET_CONFIG) the devicenode for
everything but the control channel is recreated.

-- 
B.Walter   BWCThttp://www.bwct.de
[EMAIL PROTECTED]  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]