Problem with VLANs and via-velocity driver

Problem with VLANs and via-velocity driver

[Kevin Shanahan]

Hi,

I've had some problems with getting a fairly simple (I thought) VLAN
configuration working with the on board Via NICs on my Via M700
board. Looks like as soon as a tagged VLAN interface is added, the
underlying "raw" (untagged) interface stops responding.

E.g. this is my desired setup on eth1:

Untagged VLAN: 10.193.38.0/24
  cubert (Linux 2.6.30.5) - 10.193.38.254
  switch (HP ProCurve)    - 10.193.38.1

Tagged VLAN (101): 10.193.39.192/26
  cubert (Linux)       - 10.193.39.254
  switch (HP ProCurve) - 10.193.39.193

Starting with just eth1 configured, VLAN interfaces are down:

cubert:~# ifconfig eth1
eth1      Link encap:Ethernet  HWaddr 00:40:63:fa:bb:80  
          inet addr:10.193.38.254  Bcast:10.193.38.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4504 errors:0 dropped:0 overruns:0 frame:0
          TX packets:453 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:49136 (47.9 KiB)  TX bytes:21066 (20.5 KiB)
          Interrupt:36 Base address:0xdc00 

cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
64 bytes from 10.193.38.1: icmp_seq=1 ttl=64 time=0.885 ms
64 bytes from 10.193.38.1: icmp_seq=2 ttl=64 time=0.889 ms
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.885/0.887/0.889/0.002 ms
cubert:~# 

So far so good...

cubert:~# ifup vlan101
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 101 to IF -:eth1:-
cubert:~# ifconfig vlan101
vlan101   Link encap:Ethernet  HWaddr 00:40:63:fa:bb:80  
          inet addr:10.193.39.254  Bcast:10.193.39.255  Mask:255.255.255.192
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

cubert:~# ping 10.193.39.193
PING 10.193.39.193 (10.193.39.193) 56(84) bytes of data.
64 bytes from 10.193.39.193: icmp_seq=1 ttl=64 time=4.24 ms
64 bytes from 10.193.39.193: icmp_seq=2 ttl=64 time=1.11 ms
^C
--- 10.193.39.193 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.116/2.681/4.247/1.566 ms
cubert:~# 

Also looking good, however:

cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1010ms

And eth1 won't respond again until I take down vlan101 and eth1 and
bring eth1 back up again.

cubert:~# ifdown vlan101
Removed VLAN -:vlan101:-
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1011ms

cubert:~# ifdown eth1
cubert:~# ifup eth1
cubert:~# ping 10.193.38.1
PING 10.193.38.1 (10.193.38.1) 56(84) bytes of data.
64 bytes from 10.193.38.1: icmp_seq=1 ttl=64 time=0.869 ms
64 bytes from 10.193.38.1: icmp_seq=2 ttl=64 time=0.947 ms
^C
--- 10.193.38.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.869/0.908/0.947/0.039 ms

Here is my configuration in /etc/network/interfaces (Debian/Lenny):

iface eth1 inet static
	address 10.193.38.254
	netmask 255.255.255.0
	broadcast 10.193.38.255
	network 10.193.38.0

iface vlan101 inet static
	address 10.193.39.254
	netmask 255.255.255.192
	broadcast 10.193.39.255
	network 10.193.39.192
	vlan_raw_device eth1

A bit of searching found a few references to similar problems going
back a few years (2005, 2007). Sounded like there were some driver
issues, but it wasn't clear from the messages I found whether they
were believed to be fixed or not. I tried the same test using a
differnt NIC with the tg3 driver and there were no problems, so it
looks to me like it's still a via-velocity issue. Unfortunately I
don't have room to add NICs to this machine and need to use the on
board Via hardware.

This is the network hardware on the non-working Via board:

cubert:~# lspci -k
...
02:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
	Kernel driver in use: via-velocity
03:00.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 82)
	Kernel driver in use: via-velocity

And on my laptop where this same config does work:

kulgan:~# lspci -k
...
09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02)
	Subsystem: Dell Device 01d6
	Kernel driver in use: tg3

I understand that it's not best practice to combine tagged and
untagged frames on the same link (something to do with VLAN hopping
attacks), so perhaps this is not a priority to fix. However, I'm happy
to test patches if there are any.

Regards,
Kevin Shanahan.

Re: Problem with VLANs and via-velocity driver

[Patrick McHardy]

Kevin Shanahan wrote:
> Hi,
> 
> I've had some problems with getting a fairly simple (I thought) VLAN
> configuration working with the on board Via NICs on my Via M700
> board. Looks like as soon as a tagged VLAN interface is added, the
> underlying "raw" (untagged) interface stops responding.
> 
> ...
> 
> A bit of searching found a few references to similar problems going
> back a few years (2005, 2007). Sounded like there were some driver
> issues, but it wasn't clear from the messages I found whether they
> were believed to be fixed or not. I tried the same test using a
> differnt NIC with the tg3 driver and there were no problems, so it
> looks to me like it's still a via-velocity issue. Unfortunately I
> don't have room to add NICs to this machine and need to use the on
> board Via hardware.

There's some special-casing for VID 0 in velocity_init_cam_filter().
Does "ip link add link eth0 type vlan id 0" make any difference?
If not, does "ip link set eth0 promisc on"?

Re: Problem with VLANs and via-velocity driver

[Séguier Régis]

Patrick McHardy a écrit :
> Kevin Shanahan wrote:
>   
>> Hi,
>>
>> I've had some problems with getting a fairly simple (I thought) VLAN
>> configuration working with the on board Via NICs on my Via M700
>> board. Looks like as soon as a tagged VLAN interface is added, the
>> underlying "raw" (untagged) interface stops responding.
>>
>> ...
>>
>> A bit of searching found a few references to similar problems going
>> back a few years (2005, 2007). Sounded like there were some driver
>> issues, but it wasn't clear from the messages I found whether they
>> were believed to be fixed or not. I tried the same test using a
>> differnt NIC with the tg3 driver and there were no problems, so it
>> looks to me like it's still a via-velocity issue. Unfortunately I
>> don't have room to add NICs to this machine and need to use the on
>> board Via hardware.
>>     
>
> There's some special-casing for VID 0 in velocity_init_cam_filter().
> Does "ip link add link eth0 type vlan id 0" make any difference?
> If not, does "ip link set eth0 promisc on"?
>   
When we patch the driver to support multiple vlan, we decide to use the 
vlan 0 to desactivate the vlan filtering.

via-velocity: fix vlan receipt

- vlans were using a single CAM register (see mac_set_vlan_cam)
- setting the address filtering registers for vlans is not
  needed when there is no vlan

The non-tagged interface is filtered out as soon as a tagged
(!= 0) interface is created. Its traffic appears again when an
zero-tagged interface is created.

Tested on Via Epia SN (VT6130 chipset) with several vlans whose
tag was above or beyond 255.

Signed-off-by: Séguier Régis <rseguier@e-teleport.net>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
-- 
Régis Séguier

Re: Problem with VLANs and via-velocity driver

[Patrick McHardy]

Séguier Régis wrote:
> Patrick McHardy a écrit :
>> Kevin Shanahan wrote:
>>  
>>> I've had some problems with getting a fairly simple (I thought) VLAN
>>> configuration working with the on board Via NICs on my Via M700
>>> board. Looks like as soon as a tagged VLAN interface is added, the
>>> underlying "raw" (untagged) interface stops responding.
>>>
>>>
>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>> Does "ip link add link eth0 type vlan id 0" make any difference?
>> If not, does "ip link set eth0 promisc on"?
>>   
> When we patch the driver to support multiple vlan, we decide to use the
> vlan 0 to desactivate the vlan filtering.

Why? The usual behaviour is to receive both tagged and untagged
frames.

> via-velocity: fix vlan receipt
> 
> - vlans were using a single CAM register (see mac_set_vlan_cam)
> - setting the address filtering registers for vlans is not
>  needed when there is no vlan
> 
> The non-tagged interface is filtered out as soon as a tagged
> (!= 0) interface is created. Its traffic appears again when an
> zero-tagged interface is created.

VID 0 doesn't mean untagged, it means the tag contains only a priority
value.

Re: Problem with VLANs and via-velocity driver

[Séguier Régis]

Patrick McHardy a écrit :
>
>>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>>> Does "ip link add link eth0 type vlan id 0" make any difference?
>>> If not, does "ip link set eth0 promisc on"?
>>>   
>>>       
>> When we patch the driver to support multiple vlan, we decide to use the
>> vlan 0 to desactivate the vlan filtering.
>>     
>
> Why? The usual behaviour is to receive both tagged and untagged
> frames.
>   
We decide this with françois as an alternative to desactivate the NIC 
vlan filtering instead of creating a modul parameter.
The vlan id 0 need to be created but not necessary activate.

In september 2008, we had a discution about exactly the same problem.
You speak about the possibility of an ALLVLAN device flag.

I think i proposed a patch to desactivate NIC vlan filtering when we are 
in promisc mode but not used.
-- 
Régis Séguier

Re: Problem with VLANs and via-velocity driver

[Patrick McHardy]

Séguier Régis wrote:
> Patrick McHardy a écrit :
>>
>>>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>>>> Does "ip link add link eth0 type vlan id 0" make any difference?
>>>> If not, does "ip link set eth0 promisc on"?
>>>>         
>>> When we patch the driver to support multiple vlan, we decide to use the
>>> vlan 0 to desactivate the vlan filtering.
>>>     
>>
>> Why? The usual behaviour is to receive both tagged and untagged
>> frames.
>>   
> We decide this with françois as an alternative to desactivate the NIC
> vlan filtering instead of creating a modul parameter.
> The vlan id 0 need to be created but not necessary activate.

That doesn't seem like a good idea since it behaves differently than
any other driver supporting VLAN.

> In september 2008, we had a discution about exactly the same problem.
> You speak about the possibility of an ALLVLAN device flag.

That was meant for the case where hardware filtering for specific VLANs
is active and you want to see traffic of VLANs not configured locally
without switching to promiscous mode.

> I think i proposed a patch to desactivate NIC vlan filtering when we are
> in promisc mode but not used.

Yes, in promiscous mode VLAN filtering should be disabled.

Re: Problem with VLANs and via-velocity driver

[Kevin Shanahan]

On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
> Kevin Shanahan wrote:
> > Hi,
> > 
> > I've had some problems with getting a fairly simple (I thought) VLAN
> > configuration working with the on board Via NICs on my Via M700
> > board. Looks like as soon as a tagged VLAN interface is added, the
> > underlying "raw" (untagged) interface stops responding.
> > 
> > ...
> > 
> > A bit of searching found a few references to similar problems going
> > back a few years (2005, 2007). Sounded like there were some driver
> > issues, but it wasn't clear from the messages I found whether they
> > were believed to be fixed or not. I tried the same test using a
> > differnt NIC with the tg3 driver and there were no problems, so it
> > looks to me like it's still a via-velocity issue. Unfortunately I
> > don't have room to add NICs to this machine and need to use the on
> > board Via hardware.
> 
> There's some special-casing for VID 0 in velocity_init_cam_filter().
> Does "ip link add link eth0 type vlan id 0" make any difference?

Thanks Patrick, this command got the untagged interface working again
(eth1 in my case). I can use this as a work around.

I didn't really understand if there was a good reason for the
special-casing in this driver, but from at least from my user
perspective I think it would be better if the drivers were consistent
in how they handle this.

Regards,
Kevin Shanahan.

Re: Problem with VLANs and via-velocity driver

[Patrick McHardy]

Kevin Shanahan wrote:
> On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
>> Kevin Shanahan wrote:
>>> Hi,
>>>
>>> I've had some problems with getting a fairly simple (I thought) VLAN
>>> configuration working with the on board Via NICs on my Via M700
>>> board. Looks like as soon as a tagged VLAN interface is added, the
>>> underlying "raw" (untagged) interface stops responding.
>>>
>>> ...
>>>
>>> A bit of searching found a few references to similar problems going
>>> back a few years (2005, 2007). Sounded like there were some driver
>>> issues, but it wasn't clear from the messages I found whether they
>>> were believed to be fixed or not. I tried the same test using a
>>> differnt NIC with the tg3 driver and there were no problems, so it
>>> looks to me like it's still a via-velocity issue. Unfortunately I
>>> don't have room to add NICs to this machine and need to use the on
>>> board Via hardware.
>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>> Does "ip link add link eth0 type vlan id 0" make any difference?
> 
> Thanks Patrick, this command got the untagged interface working again
> (eth1 in my case). I can use this as a work around.
> 
> I didn't really understand if there was a good reason for the
> special-casing in this driver, but from at least from my user
> perspective I think it would be better if the drivers were consistent
> in how they handle this.

I agree.

Re: Problem with VLANs and via-velocity driver

[Tiago Pierezan Camargo]

> Kevin Shanahan <kmshanah <at> disenchant.net> writes:

Hi
Sorry for resurrecting an old thread, but I'm having the same problem here.

> On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
> > Kevin Shanahan wrote:
> > > Hi,
> > > 
> > > I've had some problems with getting a fairly simple (I thought) VLAN
> > > configuration working with the on board Via NICs on my Via M700
> > > board. Looks like as soon as a tagged VLAN interface is added, the
> > > underlying "raw" (untagged) interface stops responding.

My setup is a bit different: I want to sniff all network activity, including
possible tagged traffic. No tagged interfaces are created.

> > > A bit of searching found a few references to similar problems going
> > > back a few years (2005, 2007). Sounded like there were some driver
> > > issues, but it wasn't clear from the messages I found whether they
> > > were believed to be fixed or not. I tried the same test using a
> > > differnt NIC with the tg3 driver and there were no problems, so it
> > > looks to me like it's still a via-velocity issue. Unfortunately I
> > > don't have room to add NICs to this machine and need to use the on
> > > board Via hardware.
> > 
> > There's some special-casing for VID 0 in velocity_init_cam_filter().
> > Does "ip link add link eth0 type vlan id 0" make any difference?
> 
> Thanks Patrick, this command got the untagged interface working again
> (eth1 in my case). I can use this as a work around.

Unfortunately, Patrick's workaround doesn't work for me. To see any tagged
packet I need to create a vlan that matches the packet vlan (same id).

Régis' promiscous mode patch (http://lists.openwall.net/netdev/2008/10/08/106)
does not work either. I tried to completely disable hw vlan filtering without
success. It seems my board uses a different register/offset to disable filtering.

06:0a.0 0200: 1106:3119 (rev 11)
        Subsystem: 1106:0110
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 16
        Region 0: I/O ports at e000 [size=256]
        Region 1: Memory at fbfff400 (32-bit, non-prefetchable) [size=256]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: via-velocity
        Kernel modules: via-velocity

Any suggestions?

Thanks!

- Tiago

Re: Problem with VLANs and via-velocity driver

[Patrick McHardy]

Tiago Pierezan Camargo wrote:
>> Kevin Shanahan <kmshanah <at> disenchant.net> writes:
> 
> Hi
> Sorry for resurrecting an old thread, but I'm having the same problem here.
> 
>> On Fri, Nov 13, 2009 at 07:40:39AM +0100, Patrick McHardy wrote:
>>> Kevin Shanahan wrote:
>>>> Hi,
>>>>
>>>> I've had some problems with getting a fairly simple (I thought) VLAN
>>>> configuration working with the on board Via NICs on my Via M700
>>>> board. Looks like as soon as a tagged VLAN interface is added, the
>>>> underlying "raw" (untagged) interface stops responding.
> 
> My setup is a bit different: I want to sniff all network activity, including
> possible tagged traffic. No tagged interfaces are created.
> 
>>>> A bit of searching found a few references to similar problems going
>>>> back a few years (2005, 2007). Sounded like there were some driver
>>>> issues, but it wasn't clear from the messages I found whether they
>>>> were believed to be fixed or not. I tried the same test using a
>>>> differnt NIC with the tg3 driver and there were no problems, so it
>>>> looks to me like it's still a via-velocity issue. Unfortunately I
>>>> don't have room to add NICs to this machine and need to use the on
>>>> board Via hardware.
>>> There's some special-casing for VID 0 in velocity_init_cam_filter().
>>> Does "ip link add link eth0 type vlan id 0" make any difference?
>> Thanks Patrick, this command got the untagged interface working again
>> (eth1 in my case). I can use this as a work around.
> 
> Unfortunately, Patrick's workaround doesn't work for me. To see any tagged
> packet I need to create a vlan that matches the packet vlan (same id).
> 
> Régis' promiscous mode patch (http://lists.openwall.net/netdev/2008/10/08/106)
> does not work either. I tried to completely disable hw vlan filtering without
> success. It seems my board uses a different register/offset to disable filtering.
> 
> ...
> 
> Any suggestions?

This should be fixed in the driver as discussed previously.

Re: Problem with VLANs and via-velocity driver

[Tiago Pierezan Camargo]

Patrick McHardy <kaber <at> trash.net> writes:
> > ...
> >
> > Any suggestions?
>
> This should be fixed in the driver as discussed previously.

Well, the following patch completely disables hw vlan filtering
(against 2.6.31).

--- ../via_kernel_org/via-velocity.c	2010-02-10 11:45:14.000000000 -0200
+++ via-velocity.c	2010-02-11 11:24:37.000000000 -0200
@@ -607,9 +607,10 @@
 {
 	struct mac_regs __iomem * regs = vptr->mac_regs;

-	/* Turn on MCFG_PQEN, turn off MCFG_RTGOPT */
-	WORD_REG_BITS_SET(MCFG_PQEN, MCFG_RTGOPT, &regs->MCFG);
-	WORD_REG_BITS_ON(MCFG_VIDFR, &regs->MCFG);
+	/* Completely disable vlan filtering */
+	WORD_REG_BITS_OFF(MCFG_PQEN, &regs->MCFG);
+	WORD_REG_BITS_OFF(MCFG_VIDFR, &regs->MCFG);
+	WORD_REG_BITS_OFF(MCFG_RTGOPT, &regs->MCFG);

 	/* Disable all CAMs */
 	memset(vptr->vCAMmask, 0, sizeof(u8) * 8);
@@ -1406,7 +1407,7 @@
 		/*
 		 *	Don't drop CE or RL error frame although RXOK is off
 		 */
-		if (rd->rdesc0.RSR & (RSR_RXOK | RSR_CE | RSR_RL)) {
+		if (rd->rdesc0.RSR & (RSR_RXOK | RSR_CE | RSR_RL | RSR_VIDM)) {
 			if (velocity_receive_frame(vptr, rd_curr) < 0)
 				stats->rx_dropped++;

I know it's not the best solution. I can come up with a better patch
but I'm a bit confused about the expected behavior.

- Should we only disable vlan filtering when promiscuous mode is
enabled? (should we care about hw tag stripping?)
- Should we disable vlan filtering entirely and let the software deal
with it? (this seems to be the semantics implemented in the freebsd
driver)

Suggestions?

Regards,

-- 
Tiago Pierezan Camargo
tcamargo at gmail dot com

Re: Problem with VLANs and via-velocity driver

[Patrick McHardy]

Tiago Pierezan Camargo wrote:
> Patrick McHardy <kaber <at> trash.net> writes:
>>> ...
>>>
>>> Any suggestions?
>> This should be fixed in the driver as discussed previously.
> 
> Well, the following patch completely disables hw vlan filtering
> (against 2.6.31).

You should CC the maintainer(s).

> --- ../via_kernel_org/via-velocity.c	2010-02-10 11:45:14.000000000 -0200
> +++ via-velocity.c	2010-02-11 11:24:37.000000000 -0200
> @@ -607,9 +607,10 @@
>  {
>  	struct mac_regs __iomem * regs = vptr->mac_regs;
> 
> -	/* Turn on MCFG_PQEN, turn off MCFG_RTGOPT */
> -	WORD_REG_BITS_SET(MCFG_PQEN, MCFG_RTGOPT, &regs->MCFG);
> -	WORD_REG_BITS_ON(MCFG_VIDFR, &regs->MCFG);
> +	/* Completely disable vlan filtering */
> +	WORD_REG_BITS_OFF(MCFG_PQEN, &regs->MCFG);
> +	WORD_REG_BITS_OFF(MCFG_VIDFR, &regs->MCFG);
> +	WORD_REG_BITS_OFF(MCFG_RTGOPT, &regs->MCFG);
> 
>  	/* Disable all CAMs */
>  	memset(vptr->vCAMmask, 0, sizeof(u8) * 8);
> @@ -1406,7 +1407,7 @@
>  		/*
>  		 *	Don't drop CE or RL error frame although RXOK is off
>  		 */
> -		if (rd->rdesc0.RSR & (RSR_RXOK | RSR_CE | RSR_RL)) {
> +		if (rd->rdesc0.RSR & (RSR_RXOK | RSR_CE | RSR_RL | RSR_VIDM)) {
>  			if (velocity_receive_frame(vptr, rd_curr) < 0)
>  				stats->rx_dropped++;
> 
> I know it's not the best solution. I can come up with a better patch
> but I'm a bit confused about the expected behavior.
> 
> - Should we only disable vlan filtering when promiscuous mode is
> enabled? (should we care about hw tag stripping?)

Filtering should be disabled in promiscous mode, stripping can
stay enabled.

> - Should we disable vlan filtering entirely and let the software deal
> with it? (this seems to be the semantics implemented in the freebsd
> driver)

That doesn't seem like a good idea. Basically what it should do
is:

- when no VLANs are configured locally and promiscous mode is
  disabled, all VLANs can be filtered

- when local VLANs are configured, these specific VLANs should be
  accepted

- in promiscous mode, all filters should be disabled