From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account

From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct  9 10:21:53 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 09 Oct 2015 10:21:53 -0700
Subject: [DragonFlyBSD - Bug #2685] configuring ath0 freezes the system
References: <redmine.issue-2685.20140615171936@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12709.20151009172152.9181d747c5c902ab@leaf.dragonflybsd.org>

Issue #2685 has been updated by xbit.


Seems to be fixed with 4.2.x. The device can be configured and used as before.

I don't know if 4.0.x is still affected and if this matters.

So I think the issues resolved.

----------------------------------------
Bug #2685: configuring ath0 freezes the system
http://bugs.dragonflybsd.org/issues/2685#change-12709

* Author: xbit
* Status: New
* Priority: Normal
* Assignee: 
* Category: Driver
* Target version: 4.0.x
----------------------------------------
Loading if_ath works, but when configuring the device the system locks up/freezes.

System has been upgraded from 3.6-RELEASE via buildworld, installworld. Kernel is GENERIC_X64_86 and HEAD is 358af07.

Running "ifconfig ath0 up" works.

Then calling "ifconfig wlan0 create wlandev ath0" freezes the system.

I discovered the follwoing kernel message when trying to configure the device using /etc/rc.d/netif.

ath0: _ath_power_restore_power_state.refcount=0?

I also applied the change from http://lists.dragonflybsd.org/pipermail/commits/2014-June/270210.html via cherry-picking, but no changes.

The 3.6-RELEASE have been used successfully with the same hardware.

Here are the ath related snippets from the dmesg output:

wlan: <802.11 Link Layer>                                                                                                      
ath_dfs: WTF module                                                                                                            
ath_rate: <SampleRate bit-rate selection algorithm>                                                                            
                                                                                                                                                                                                                                                              
ath0.pci3.pcib3.pci0.pcib0.acpi0.nexus0.root0                                                                                  
ath0: <Atheros 2413> [tentative] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfebf0000                                                                 
                                                                                                                               
                                                                                                                               
ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps                                                                                    
ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps                                                          
24Mbps 36Mbps 48Mbps 54Mbps                                                                                                    
ath0: AR2413 mac 7.8 RF2413 phy 4.5                                                                                            
ath0: 2GHz radio: 0x0000; 5GHz radio: 0x0056                                                                                   
ath0: Use hw queue 1 for WME_AC_BE traffic                                                                                     
ath0: Use hw queue 0 for WME_AC_BK traffic                                                                                     ath0: Use hw queue 2 for WME_AC_VI traffic                                                                                     
ath0: Use hw queue 3 for WME_AC_VO traffic                                                                                     
ath0: Use hw queue 8 for CAB traffic                                                                                           
ath0: Use hw queue 9 for beacons                                                                                               
ath0: using multicast key search                                                                                               
ath0: <Atheros 2413> [attached!] mem 0xfebf0000-0xfebfffff irq 20 at                                                           
device 5.0 on pci3                                                                                                             
pci3: <ACPI PCI bus> [attached!] on pcib3                                                                                      
pcib3: <ACPI PCI-PCI bridge> [attached!] at device 20.4 on pci0




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 13 06:48:43 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 13 Oct 2015 06:48:43 -0700
Subject: [DragonFlyBSD - Bug #2843] Fails to create dm device via dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12711.20151013134843.b487ae15d860c558@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.


dev->uuid is zero-filled whenever dm ioctl is called via dmsetup(8) and that's the reason dm_dev_lookup_uuid() returns non null after the first time.

dm targets with a dedicated high-level command (e.g. cryptsetup(8)) sets an unique non-zero value, so there isn't any issue with lookup, and this is what's expected to happen.

Setting uuid is userspace logic that really has nothing to do with kernel dm code other than it's been used for device lookup, however zero-filled uuid is apparently not a valid one. The patch simply ignores uuid lookup if ioctl received zero-filled uuid.
https://www.dragonflybsd.org/~tkusumi/diff/0001-sys-dev-disk-dm-Ignore-zero-filled-uuid-on-inserting.patch


===== with the existing code
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10' 
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create zero1 --table '0 100 zero'
  ioctl create call failed: File exists
  
  Command failed
  # dmsetup create error1 --table '0 100 error'
  ioctl create call failed: File exists
  
  Command failed
  # ls /dev/mapper
  control linear1

===== with this commit
  # kldload dm
  # dmsetup create linear1 --table '0 1000 linear /dev/da3 0'
  # dmsetup create delay1 --table '0 1000 delay /dev/da3 0 10 /dev/da3 0 10'
  # dmsetup create zero1 --table '0 100 zero'
  # dmsetup create error1 --table '0 100 error'
  # ls /dev/mapper
  control delay1  error1  linear1 zero1


----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12711

* Author: tkusumi
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 14 12:44:37 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 14 Oct 2015 12:44:37 -0700
Subject: [DragonFlyBSD - Bug #2843] (Closed) Fails to create dm device via
 dmsetup
References: <redmine.issue-2843.20150928151559@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12712.20151014194437.bde0c714c5b9034e@leaf.dragonflybsd.org>

Issue #2843 has been updated by tkusumi.

Status changed from New to Closed

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/03821153fc23b82d42316ad8dd63ac8852a65105

----------------------------------------
Bug #2843: Fails to create dm device via dmsetup
http://bugs.dragonflybsd.org/issues/2843#change-12712

* Author: tkusumi
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
There seems to be an issue with device mapper on dfly.
This happens with dm-error target as well.
I'll try to investigate and fix when possible (since I want dm-flakey on dfly).


----------
# uname
Linux
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
# dmsetup create zero2 --table '0 100 zero'
# ls -l /dev/mapper/zero*
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero1 -> ../dm-3
lrwxrwxrwx 1 root root 7 Sep 29 00:14 /dev/mapper/zero2 -> ../dm-4

----------
# uname
DragonFly
# kldload dm
# dmsetup create zero1 --table '0 100 zero'
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1
# dmsetup create zero2 --table '0 100 zero'
ioctl create call failed: File exists

Command failed
# ls -l /dev/mapper/zero*
crw-r-----  1 root  operator   66, 0x1e110007 Sep 29 00:01 /dev/mapper/zero1




-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 15 20:03:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 15 Oct 2015 20:03:40 -0700
Subject: [DragonFlyBSD - Bug #2845] (New) Hangs using dsched policys other
 than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2845.20151016030340.bcee2e1fc13c9c20@leaf.dragonflybsd.org>

Issue #2845 has been reported by jkolodzi.

----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Fri Oct 16 14:14:05 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Fri, 16 Oct 2015 14:14:05 -0700
Subject: [DragonFlyBSD - Bug #2845] Hangs using dsched policys other than noop
References: <redmine.issue-2845.20151016030340@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12713.20151016211405.72534880bbe555bb@leaf.dragonflybsd.org>

Issue #2845 has been updated by ddb.


Similar experience here... When using bfq while making parallel buildworld, the kernel produced several hundreds of these messages:

kernel: dsched_thread_io: destroy race tdio=0xffffffe0f4c6ce00

After about an hour I've found the system unresponsive.

When trying fq during dports compiling, the kernel produced just one such message and currently running pkg(8) process got stuck. On reboot the system "gave up on 232 buffers" which resulted in corrupted pkg(8) database (ouch ;-)).

When using noop scheduler, the system doesn't report any races and runs with no problems.


----------------------------------------
Bug #2845: Hangs using dsched policys other than noop
http://bugs.dragonflybsd.org/issues/2845#change-12713

* Author: jkolodzi
* Status: New
* Priority: Low
* Assignee: 
* Category: VFS subsystem
* Target version: Unverifiable
----------------------------------------
When using fq or bfq with heavy disk IO on one SATA HDD (where "heavy" means running make -j10 buildworld and building chromium and firefox all at the same time -- heavy for a single-user el-cheapo Satellite D55 laptop, really light for a server) occasionally all disk IO will stop and no new IO can be started, including a panic dump from the debugger(!) If top, ps, etc. happen to be in the cache it looks like the processes are all stuck in vnode wait status, and there seems to be no way to kick them out of that status.

The as policy, on the other hand, takes about 3 IOs to hang. I'm not sure yet if processes are also in vnode wait status there.

Putting it as low priority as the default (noop) seems to work perfectly. Target should read 4.3.CURRENT but that isn't a choice.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Mon Oct 19 16:10:30 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Mon, 19 Oct 2015 16:10:30 -0700
Subject: [DragonFlyBSD - Bug #2847] (New) rtadvd: improper padding of DNSSL
 option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2847.20151019231030.29b8e887e1da4e95@leaf.dragonflybsd.org>

Issue #2847 has been reported by cmusser.

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Tue Oct 20 02:45:40 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Tue, 20 Oct 2015 02:45:40 -0700
Subject: [DragonFlyBSD - Bug #2848] (New) i915: *ERROR* pipe is still busy
 with an old pageflip
References: <redmine.issue-2848.20151020094539@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2848.20151020094539.570daf9ac2eabe40@leaf.dragonflybsd.org>

Issue #2848 has been reported by ddb.

----------------------------------------
Bug #2848: i915: *ERROR* pipe is still busy with an old pageflip
http://bugs.dragonflybsd.org/issues/2848

* Author: ddb
* Status: New
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Process Xorg stuck in state "lwe" with kernel saying:

WARNING ({ int start_jiffies, elapsed_jiffies, remaining_jiffies, ret; _Bool timeout_expired = 0; _Bool interrupted = 0; long retval; start_jiffies = ticks; lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000002); while (1) { if (!intel_crtc_has_pending_flip(crtc)) break; ret = lksleep(&dev_priv->pending_flip_queue, &dev_priv->pending_flip_queue.lock, 0, "lwe", 60*hz); if (ret == 4 || ret == (-1)) { interrupted = 1; break; } if (ret == 35) { timeout_expired = 1; break; } } lockmgr(&dev_priv->pending_flip_queue.lock, 0x00000006); elapsed_jiffies = ticks - start_jiffies; remaining_jiffies = 60*hz - elapsed_jiffies; if (remaining_jiffies <= 0) remaining_jiffies = 1; if (timeout_expired) retval = 0; else if (interrupted) retval = -512; else if (60*hz > 0) retval = remaining_jiffies; else retval = 1; retval; }) == 0 failed at /usr/src/sys/dev/drm/i915/intel_display.c:3348

error: [drm:pid1018:intel_pipe_set_base] *ERROR* pipe is still busy with an old pageflip

These two messages then repeat in 1 minute interval. Switching to console works (but is delayed up to that 1 minute), so the system can be rebooted cleanly.

The machine runs on Intel Celeron J1900 (ie. "<ValleyView/Baytrail> on vgapci0") with software from current dports (xorg-server-1.17.2,1 + xf86-video-intel-2.99.2015.09.09,1).

PS: I suspect this to be some race condition as I've been running "DragonFly desktop" on this machine for several days with no problem so far.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Wed Oct 21 02:09:24 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Wed, 21 Oct 2015 02:09:24 -0700
Subject: [DragonFlyBSD - Bug #2847] rtadvd: improper padding of DNSSL option
References: <redmine.issue-2847.20151019231030@leaf.dragonflybsd.org>
Message-ID: <redmine.journal-12717.20151021090924.e86e738352a7bb63@leaf.dragonflybsd.org>

Issue #2847 has been updated by sepherosa.


Patch pushed.

On Tue, Oct 20, 2015 at 7:10 AM,
<bugtracker-admin at leaf.dragonflybsd.org> wrote:
> Issue #2847 has been reported by cmusser.
>
> ----------------------------------------
> Bug #2847: rtadvd: improper padding of DNSSL option
> http://bugs.dragonflybsd.org/issues/2847
>
> * Author: cmusser
> * Status: New
> * Priority: Normal
> * Assignee:
> * Category: Networking
> * Target version: 4.2.x
> ----------------------------------------
> The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
> options, which need to be padded to an eight byte boundary. The code
> correctly calculates the padding length, then fails to increment the
> pointer used to write the packet data by this amount. As a result, all
> subsequent option data gets written into the wrong place, making the
> rest of the packet junk.
>
> The attached patch (for the master branch) fixes this.
>
> ---Files--------------------------------
> rtadvd_config.c.diff (795 Bytes)
>
>
> --
> You have received this notification because you have either subscribed to it, or are involved in it.
> To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account



-- 
Tomorrow Will Never Die

----------------------------------------
Bug #2847: rtadvd: improper padding of DNSSL option
http://bugs.dragonflybsd.org/issues/2847#change-12717

* Author: cmusser
* Status: New
* Priority: Normal
* Assignee: 
* Category: Networking
* Target version: 4.2.x
----------------------------------------
The rtadvd program, recently refreshed from FreeBSD, mishandles DNSSL
options, which need to be padded to an eight byte boundary. The code
correctly calculates the padding length, then fails to increment the
pointer used to write the packet data by this amount. As a result, all
subsequent option data gets written into the wrong place, making the
rest of the packet junk.

The attached patch (for the master branch) fixes this.

---Files--------------------------------
rtadvd_config.c.diff (795 Bytes)


-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account


From bugtracker-admin at leaf.dragonflybsd.org  Thu Oct 29 20:59:44 2015
From: bugtracker-admin at leaf.dragonflybsd.org (bugtracker-admin at leaf.dragonflybsd.org)
Date: Thu, 29 Oct 2015 20:59:44 -0700
Subject: [DragonFlyBSD - Bug #2849] (New) Allow bpf to work with wireless
 interfaces.
References: <redmine.issue-2849.20151030035944@leaf.dragonflybsd.org>
Message-ID: <redmine.issue-2849.20151030035944.026d9a5cc8ee4b40@leaf.dragonflybsd.org>

Issue #2849 has been reported by shamaz.

----------------------------------------
Bug #2849: Allow bpf to work with wireless interfaces.
http://bugs.dragonflybsd.org/issues/2849

* Author: shamaz
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
This patch to bpf_movein makes it check if data link layer type is
DLT_IEEE802_11 or DLT_IEEE802_11_RADIO, allowing bpf to work with wireless
connections.



-- 
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account