Patch fixes issue with Halt Endnpoint Test observed during using g_zero
driver as DUT. Bug occurred only on some testing board.
Endpoint can defer transition to Halted state if endpoint has pending
requests.
Patch add additional condition that allows to return correct endpoint
status during Get Endpoint Status request even if the halting endpoint
is in progress.
Reported-by: Rahul Kumar <[email protected]>
Signed-off-by: Rahul Kumar <[email protected]>
Signed-off-by: Pawel Laszczak <[email protected]>
Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
---
drivers/usb/cdns3/ep0.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c
index 44f652e8b5a2..10ae03430f34 100644
--- a/drivers/usb/cdns3/ep0.c
+++ b/drivers/usb/cdns3/ep0.c
@@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct cdns3_device *priv_dev,
static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
struct usb_ctrlrequest *ctrl)
{
+ struct cdns3_endpoint *priv_ep;
__le16 *response_pkt;
u16 usb_status = 0;
u32 recip;
+ u8 index;
recip = ctrl->bRequestType & USB_RECIP_MASK;
@@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
case USB_RECIP_INTERFACE:
return cdns3_ep0_delegate_req(priv_dev, ctrl);
case USB_RECIP_ENDPOINT:
- /* check if endpoint is stalled */
+ index = cdns3_ep_addr_to_index(ctrl->wIndex);
+ priv_ep = priv_dev->eps[index];
+
+ /* check if endpoint is stalled or stall is pending */
cdns3_select_ep(priv_dev, ctrl->wIndex);
- if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
+ if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
+ (priv_ep->flags & EP_STALL_PENDING))
usb_status = BIT(USB_ENDPOINT_HALT);
break;
default:
--
2.17.1
On 07/10/2019 09:39, Pawel Laszczak wrote:
> Patch fixes issue with Halt Endnpoint Test observed during using g_zero
> driver as DUT. Bug occurred only on some testing board.
>
> Endpoint can defer transition to Halted state if endpoint has pending
> requests.
> Patch add additional condition that allows to return correct endpoint
> status during Get Endpoint Status request even if the halting endpoint
> is in progress.
>
> Reported-by: Rahul Kumar <[email protected]>
> Signed-off-by: Rahul Kumar <[email protected]>
> Signed-off-by: Pawel Laszczak <[email protected]>
> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
Tested-by: Roger Quadros <[email protected]>
cheers,
-roger
> ---
> drivers/usb/cdns3/ep0.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c
> index 44f652e8b5a2..10ae03430f34 100644
> --- a/drivers/usb/cdns3/ep0.c
> +++ b/drivers/usb/cdns3/ep0.c
> @@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct cdns3_device *priv_dev,
> static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
> struct usb_ctrlrequest *ctrl)
> {
> + struct cdns3_endpoint *priv_ep;
> __le16 *response_pkt;
> u16 usb_status = 0;
> u32 recip;
> + u8 index;
>
> recip = ctrl->bRequestType & USB_RECIP_MASK;
>
> @@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
> case USB_RECIP_INTERFACE:
> return cdns3_ep0_delegate_req(priv_dev, ctrl);
> case USB_RECIP_ENDPOINT:
> - /* check if endpoint is stalled */
> + index = cdns3_ep_addr_to_index(ctrl->wIndex);
> + priv_ep = priv_dev->eps[index];
> +
> + /* check if endpoint is stalled or stall is pending */
> cdns3_select_ep(priv_dev, ctrl->wIndex);
> - if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
> + if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
> + (priv_ep->flags & EP_STALL_PENDING))
> usb_status = BIT(USB_ENDPOINT_HALT);
> break;
> default:
>
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
On 19-10-07 07:39:11, Pawel Laszczak wrote:
> Patch fixes issue with Halt Endnpoint Test observed
%s/Endnpoint/Endpoint
>
> during using g_zero
> driver as DUT. Bug occurred only on some testing board.
g_zero is legacy, please use configfs function source_sink or loopback
instead.
>
> Endpoint can defer transition to Halted state if endpoint has pending
> requests.
The implementation of halt handling is a little complicated, you may
consider return -EAGAIN for functional stall through usb_ep_set_halt
from function driver if the requests are pending, it doesn't need to
defer such kinds of functional stall.
Peter
> Patch add additional condition that allows to return correct endpoint
> status during Get Endpoint Status request even if the halting endpoint
> is in progress.
>
> Reported-by: Rahul Kumar <[email protected]>
> Signed-off-by: Rahul Kumar <[email protected]>
> Signed-off-by: Pawel Laszczak <[email protected]>
> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
> ---
> drivers/usb/cdns3/ep0.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c
> index 44f652e8b5a2..10ae03430f34 100644
> --- a/drivers/usb/cdns3/ep0.c
> +++ b/drivers/usb/cdns3/ep0.c
> @@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct cdns3_device *priv_dev,
> static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
> struct usb_ctrlrequest *ctrl)
> {
> + struct cdns3_endpoint *priv_ep;
> __le16 *response_pkt;
> u16 usb_status = 0;
> u32 recip;
> + u8 index;
>
> recip = ctrl->bRequestType & USB_RECIP_MASK;
>
> @@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
> case USB_RECIP_INTERFACE:
> return cdns3_ep0_delegate_req(priv_dev, ctrl);
> case USB_RECIP_ENDPOINT:
> - /* check if endpoint is stalled */
> + index = cdns3_ep_addr_to_index(ctrl->wIndex);
> + priv_ep = priv_dev->eps[index];
> +
> + /* check if endpoint is stalled or stall is pending */
> cdns3_select_ep(priv_dev, ctrl->wIndex);
> - if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
> + if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
> + (priv_ep->flags & EP_STALL_PENDING))
> usb_status = BIT(USB_ENDPOINT_HALT);
> break;
> default:
> --
> 2.17.1
>
--
Thanks,
Peter Chen
Hi Peter,
>
>EXTERNAL MAIL
>
>
>On 19-10-07 07:39:11, Pawel Laszczak wrote:
>> Patch fixes issue with Halt Endnpoint Test observed
>
>%s/Endnpoint/Endpoint
>
>>
>> during using g_zero
>> driver as DUT. Bug occurred only on some testing board.
>
>g_zero is legacy, please use configfs function source_sink or loopback
>instead.
Yes, you are right, we are using both.
>
>>
>> Endpoint can defer transition to Halted state if endpoint has pending
>> requests.
>
>The implementation of halt handling is a little complicated, you may
>consider return -EAGAIN for functional stall through usb_ep_set_halt
>from function driver if the requests are pending, it doesn't need to
>defer such kinds of functional stall.
Yes, I remember your suggestion regarding using EAGAIN, but f_mass_storage
Driver simple check the status and try to stall endpoint again after 100 ms.
What if Command Verifier ask for endpoint status before this time, or if
the transfer will not be finished on time ? Then the CV test may fail.
So solution from this patch should be more certain.
>
>Peter
>> Patch add additional condition that allows to return correct endpoint
>> status during Get Endpoint Status request even if the halting endpoint
>> is in progress.
>>
>> Reported-by: Rahul Kumar <[email protected]>
>> Signed-off-by: Rahul Kumar <[email protected]>
>> Signed-off-by: Pawel Laszczak <[email protected]>
>> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
>> ---
>> drivers/usb/cdns3/ep0.c | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c
>> index 44f652e8b5a2..10ae03430f34 100644
>> --- a/drivers/usb/cdns3/ep0.c
>> +++ b/drivers/usb/cdns3/ep0.c
>> @@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct cdns3_device *priv_dev,
>> static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
>> struct usb_ctrlrequest *ctrl)
>> {
>> + struct cdns3_endpoint *priv_ep;
>> __le16 *response_pkt;
>> u16 usb_status = 0;
>> u32 recip;
>> + u8 index;
>>
>> recip = ctrl->bRequestType & USB_RECIP_MASK;
>>
>> @@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct cdns3_device *priv_dev,
>> case USB_RECIP_INTERFACE:
>> return cdns3_ep0_delegate_req(priv_dev, ctrl);
>> case USB_RECIP_ENDPOINT:
>> - /* check if endpoint is stalled */
>> + index = cdns3_ep_addr_to_index(ctrl->wIndex);
>> + priv_ep = priv_dev->eps[index];
>> +
>> + /* check if endpoint is stalled or stall is pending */
>> cdns3_select_ep(priv_dev, ctrl->wIndex);
>> - if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
>> + if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
>> + (priv_ep->flags & EP_STALL_PENDING))
>> usb_status = BIT(USB_ENDPOINT_HALT);
>> break;
>> default:
>> --
>> 2.17.1
>>
>
>--
>
>Thanks,
>Peter Chen
Regards,
Pawel
> >> Endpoint can defer transition to Halted state if endpoint has pending
> >> requests.
> >
> >The implementation of halt handling is a little complicated, you may
> >consider return -EAGAIN for functional stall through usb_ep_set_halt
> >from function driver if the requests are pending, it doesn't need to
> >defer such kinds of functional stall.
>
> Yes, I remember your suggestion regarding using EAGAIN, but f_mass_storage
> Driver simple check the status and try to stall endpoint again after 100 ms.
>
> What if Command Verifier ask for endpoint status before this time, or if the transfer
> will not be finished on time ? Then the CV test may fail.
>
> So solution from this patch should be more certain.
>
Your description is reasonable, since I have not met this issue, I would like
to know more about it:
It occurs at CV9 or MSC test? For CV9 test, it may not try to stall non-ep0.
Which test case was failed?
Peter
> >
> >Peter
> >> Patch add additional condition that allows to return correct endpoint
> >> status during Get Endpoint Status request even if the halting
> >> endpoint is in progress.
> >>
> >> Reported-by: Rahul Kumar <[email protected]>
> >> Signed-off-by: Rahul Kumar <[email protected]>
> >> Signed-off-by: Pawel Laszczak <[email protected]>
> >> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
> >> ---
> >> drivers/usb/cdns3/ep0.c | 10 ++++++++--
> >> 1 file changed, 8 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c index
> >> 44f652e8b5a2..10ae03430f34 100644
> >> --- a/drivers/usb/cdns3/ep0.c
> >> +++ b/drivers/usb/cdns3/ep0.c
> >> @@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct
> >> cdns3_device *priv_dev, static int cdns3_req_ep0_get_status(struct
> cdns3_device *priv_dev,
> >> struct usb_ctrlrequest *ctrl) {
> >> + struct cdns3_endpoint *priv_ep;
> >> __le16 *response_pkt;
> >> u16 usb_status = 0;
> >> u32 recip;
> >> + u8 index;
> >>
> >> recip = ctrl->bRequestType & USB_RECIP_MASK;
> >>
> >> @@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct
> cdns3_device *priv_dev,
> >> case USB_RECIP_INTERFACE:
> >> return cdns3_ep0_delegate_req(priv_dev, ctrl);
> >> case USB_RECIP_ENDPOINT:
> >> - /* check if endpoint is stalled */
> >> + index = cdns3_ep_addr_to_index(ctrl->wIndex);
> >> + priv_ep = priv_dev->eps[index];
> >> +
> >> + /* check if endpoint is stalled or stall is pending */
> >> cdns3_select_ep(priv_dev, ctrl->wIndex);
> >> - if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
> >> + if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
> >> + (priv_ep->flags & EP_STALL_PENDING))
> >> usb_status = BIT(USB_ENDPOINT_HALT);
> >> break;
> >> default:
> >> --
> >> 2.17.1
> >>
> >
> >--
> >
> >Thanks,
> >Peter Chen
>
> Regards,
> Pawel
Peter,
On 08/10/2019 11:44, Peter Chen wrote:
>
>>>> Endpoint can defer transition to Halted state if endpoint has pending
>>>> requests.
>>>
>>> The implementation of halt handling is a little complicated, you may
>>> consider return -EAGAIN for functional stall through usb_ep_set_halt
>> >from function driver if the requests are pending, it doesn't need to
>>> defer such kinds of functional stall.
>>
>> Yes, I remember your suggestion regarding using EAGAIN, but f_mass_storage
>> Driver simple check the status and try to stall endpoint again after 100 ms.
>>
>> What if Command Verifier ask for endpoint status before this time, or if the transfer
>> will not be finished on time ? Then the CV test may fail.
>>
>> So solution from this patch should be more certain.
>>
>
> Your description is reasonable, since I have not met this issue, I would like
> to know more about it:
> It occurs at CV9 or MSC test? For CV9 test, it may not try to stall non-ep0.
> Which test case was failed?
Since g_zero was used it would be CV9.
cheers,
-roger
>
> Peter
>
>>>
>>> Peter
>>>> Patch add additional condition that allows to return correct endpoint
>>>> status during Get Endpoint Status request even if the halting
>>>> endpoint is in progress.
>>>>
>>>> Reported-by: Rahul Kumar <[email protected]>
>>>> Signed-off-by: Rahul Kumar <[email protected]>
>>>> Signed-off-by: Pawel Laszczak <[email protected]>
>>>> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
>>>> ---
>>>> drivers/usb/cdns3/ep0.c | 10 ++++++++--
>>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/cdns3/ep0.c b/drivers/usb/cdns3/ep0.c index
>>>> 44f652e8b5a2..10ae03430f34 100644
>>>> --- a/drivers/usb/cdns3/ep0.c
>>>> +++ b/drivers/usb/cdns3/ep0.c
>>>> @@ -234,9 +234,11 @@ static int cdns3_req_ep0_set_address(struct
>>>> cdns3_device *priv_dev, static int cdns3_req_ep0_get_status(struct
>> cdns3_device *priv_dev,
>>>> struct usb_ctrlrequest *ctrl) {
>>>> + struct cdns3_endpoint *priv_ep;
>>>> __le16 *response_pkt;
>>>> u16 usb_status = 0;
>>>> u32 recip;
>>>> + u8 index;
>>>>
>>>> recip = ctrl->bRequestType & USB_RECIP_MASK;
>>>>
>>>> @@ -262,9 +264,13 @@ static int cdns3_req_ep0_get_status(struct
>> cdns3_device *priv_dev,
>>>> case USB_RECIP_INTERFACE:
>>>> return cdns3_ep0_delegate_req(priv_dev, ctrl);
>>>> case USB_RECIP_ENDPOINT:
>>>> - /* check if endpoint is stalled */
>>>> + index = cdns3_ep_addr_to_index(ctrl->wIndex);
>>>> + priv_ep = priv_dev->eps[index];
>>>> +
>>>> + /* check if endpoint is stalled or stall is pending */
>>>> cdns3_select_ep(priv_dev, ctrl->wIndex);
>>>> - if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)))
>>>> + if (EP_STS_STALL(readl(&priv_dev->regs->ep_sts)) ||
>>>> + (priv_ep->flags & EP_STALL_PENDING))
>>>> usb_status = BIT(USB_ENDPOINT_HALT);
>>>> break;
>>>> default:
>>>> --
>>>> 2.17.1
>>>>
>>>
>>> --
>>>
>>> Thanks,
>>> Peter Chen
>>
>> Regards,
>> Pawel
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Hi,
Peter Chen <[email protected]> writes:
> On 19-10-07 07:39:11, Pawel Laszczak wrote:
>> Patch fixes issue with Halt Endnpoint Test observed
>
> %s/Endnpoint/Endpoint
>
>>
>> during using g_zero
>> driver as DUT. Bug occurred only on some testing board.
>
> g_zero is legacy, please use configfs function source_sink or loopback
> instead.
We still want fixes for those ;-)
>> Endpoint can defer transition to Halted state if endpoint has pending
>> requests.
>
> The implementation of halt handling is a little complicated, you may
> consider return -EAGAIN for functional stall through usb_ep_set_halt
> from function driver if the requests are pending, it doesn't need to
> defer such kinds of functional stall.
-EAGAIN, IIRC is only supposed to be used for IN endpoint stalls.
--
balbi
On 19-10-08 15:58:57, Felipe Balbi wrote:
>
> Hi,
>
> Peter Chen <[email protected]> writes:
> > On 19-10-07 07:39:11, Pawel Laszczak wrote:
> >> Patch fixes issue with Halt Endnpoint Test observed
> >
> > %s/Endnpoint/Endpoint
> >
> >>
> >> during using g_zero
> >> driver as DUT. Bug occurred only on some testing board.
> >
> > g_zero is legacy, please use configfs function source_sink or loopback
> > instead.
>
> We still want fixes for those ;-)
Yes, g_zero also uses source_sink and loopback, we just suggest the user
configfs instead of legacy modules.
>
> >> Endpoint can defer transition to Halted state if endpoint has pending
> >> requests.
> >
> > The implementation of halt handling is a little complicated, you may
> > consider return -EAGAIN for functional stall through usb_ep_set_halt
> > from function driver if the requests are pending, it doesn't need to
> > defer such kinds of functional stall.
>
> -EAGAIN, IIRC is only supposed to be used for IN endpoint stalls.
>
Yes, you are right.
--
Thanks,
Peter Chen
Hi,
>
>Hi,
>
>Peter Chen <[email protected]> writes:
>> On 19-10-07 07:39:11, Pawel Laszczak wrote:
>>> Patch fixes issue with Halt Endnpoint Test observed
>>
>> %s/Endnpoint/Endpoint
>>
>>>
>>> during using g_zero
>>> driver as DUT. Bug occurred only on some testing board.
>>
>> g_zero is legacy, please use configfs function source_sink or loopback
>> instead.
>
>We still want fixes for those ;-)
So, if my understanding is correct in new production systems
using legacy gadget drivers is not recommended and we are not going to fix
any more bugs there.
The legacy gadget drivers remains in the kernel only to support the old
products.
So because we introduce new driver we should not worry about legacy
gadget drivers.
Is my understanding correct ?
pawell
>
>>> Endpoint can defer transition to Halted state if endpoint has pending
>>> requests.
>>
>> The implementation of halt handling is a little complicated, you may
>> consider return -EAGAIN for functional stall through usb_ep_set_halt
>> from function driver if the requests are pending, it doesn't need to
>> defer such kinds of functional stall.
>
>-EAGAIN, IIRC is only supposed to be used for IN endpoint stalls.
>
>--
>balbi
Pawel,
On 09/10/2019 06:58, Pawel Laszczak wrote:
> Hi,
>
>>
>> Hi,
>>
>> Peter Chen <[email protected]> writes:
>>> On 19-10-07 07:39:11, Pawel Laszczak wrote:
>>>> Patch fixes issue with Halt Endnpoint Test observed
>>>
>>> %s/Endnpoint/Endpoint
>>>
>>>>
>>>> during using g_zero
>>>> driver as DUT. Bug occurred only on some testing board.
>>>
>>> g_zero is legacy, please use configfs function source_sink or loopback
>>> instead.
>>
>> We still want fixes for those ;-)
>
> So, if my understanding is correct in new production systems
> using legacy gadget drivers is not recommended and we are not going to fix
> any more bugs there.
We can't really control who uses what. So we need to support legacy
drivers as well.
The issue detected by using g_zero is a controller driver issue and not an
issue with g_zero itself.
cheers,
-roger
>
> The legacy gadget drivers remains in the kernel only to support the old
> products.
>
> So because we introduce new driver we should not worry about legacy
> gadget drivers.
>
> Is my understanding correct ?
>
> pawell
>
>>
>>>> Endpoint can defer transition to Halted state if endpoint has pending
>>>> requests.
>>>
>>> The implementation of halt handling is a little complicated, you may
>>> consider return -EAGAIN for functional stall through usb_ep_set_halt
>>> from function driver if the requests are pending, it doesn't need to
>>> defer such kinds of functional stall.
>>
>> -EAGAIN, IIRC is only supposed to be used for IN endpoint stalls.
>>
>> --
>> balbi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
hi,
Roger Quadros <[email protected]> writes:
>>> Peter Chen <[email protected]> writes:
>>>> On 19-10-07 07:39:11, Pawel Laszczak wrote:
>>>>> Patch fixes issue with Halt Endnpoint Test observed
>>>>
>>>> %s/Endnpoint/Endpoint
>>>>
>>>>>
>>>>> during using g_zero
>>>>> driver as DUT. Bug occurred only on some testing board.
>>>>
>>>> g_zero is legacy, please use configfs function source_sink or loopback
>>>> instead.
>>>
>>> We still want fixes for those ;-)
>>
>> So, if my understanding is correct in new production systems
>> using legacy gadget drivers is not recommended and we are not going to fix
>> any more bugs there.
>
> We can't really control who uses what. So we need to support legacy
> drivers as well.
>
> The issue detected by using g_zero is a controller driver issue and not an
> issue with g_zero itself.
thanks for clarifying, Roger.
Pawel, Roger is correct here. But in any case, if *real* bugs are found
on the legacy gadget drivers, let's see if they happen with
configfs-based interface as well. They should behave exactly the same
nowadays since legacy driver were converted to simply programmatically
spawn the configfs interface.
If there are bugs in legacy gadget drivers, we *WANT* to fix those.
--
balbi