How to debug ethernet driver ?
Hello, I am writing ethernet network driver. I would like to ask if there are any steps which can help when debugging ethernet driver, or is it that the first test should already involve transmit/recieve packets to/from ip stack ? Any tips for debugging and testing a new ethernet driver will be appreciated, Thank you, Ran ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: doubt on schedule_work() - work task getting scheduled lately
Did you tried ftrace? https://www.kernel.org/doc/Documentation/trace/ftrace.txt
I've been using this to measure some latencies. The problem here is
visualizing the output. If you need someting more elaborated than
simple prints with timestamps and delta calculations, then you should
try something more complex. If not you can enable FTRACE and generate
trace output with delta timestamps on it, event for interrupts :)
Best regards,
2016-08-01 7:32 GMT-03:00 Muni Sekhar :
> On Fri, Jul 29, 2016 at 9:05 PM, Daniel. wrote:
>> Nice tool @Ricardo!
>>
>> 2016-07-29 10:48 GMT-03:00 Ricardo Ribalda Delgado
>> :
>>> you can use http://lttng.org/ for analyzing this
> Thanks Ricardo, I will use this.
>
>>>
>>> Regards!
>>>
>>> On Fri, Jul 29, 2016 at 12:44 PM, Pranay Srivastava
>>> wrote:
On Fri, Jul 29, 2016 at 4:02 PM, Muni Sekhar
wrote:
> Hi All,
>
> I have a doubt regarding the workqueue scheduling.
>
> I am using the workqueue for processing the Rx Interrupt data. I am
> calling schedule_work() on receiving the Rx interrupt from hardware.
>
> I calculated the time between calling the schedule_work() and
> workqueue task actually getting executed, Here I see many cases of
> less than 100 us(It is fairly good).
>
> But sometimes I see 10’s of ms and a lot in the 100’s of ms. I have
> seen over 0.5 secs too. I would like to know why does sometimes kernel
> takes longer time(in milli seconds) to schedule it? Is there any way
> to reduce this time gap?
>
>
> My code:
>
> static void my_workqueuetask(struct work_struct *work)
> {
> printk("In %s() \n",__func__);
>
You probably don't need this if it's just for your work_fn, yeah but
if there's race between this and something else...
> mutex_lock(&bh_mutex);
>
> //Do something here
>
> mutex_unlock(&bh_mutex);
> }
>
>
> static irqreturn_t my_irq_handler(int irq, void *dev)
> {
> ……;
>
> if(Rx Interrupt)
> schedule_work(&rx_work);
Maybe system_wq has too much already on it's plate?
Have you tried the same with completion and a kthread? or
with your own workqueue, overkill but you can give it a shot.
> I have not tried this. First I will analyze with lttng and then
> attempts this. Does using our own workqueue reduces the latency?
>
>
> return IRQ_HANDLED;
> }
>
> --
> Thanks,
> Sekhar
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
---P.K.S
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>>
>>> --
>>> Ricardo Ribalda
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> --
>> "Do or do not. There is no try"
>> Yoda Master
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> Thanks,
> Sekhar
--
"Do or do not. There is no try"
Yoda Master
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: doubt on schedule_work() - work task getting scheduled lately
On Fri, Jul 29, 2016 at 9:05 PM, Daniel. wrote:
> Nice tool @Ricardo!
>
> 2016-07-29 10:48 GMT-03:00 Ricardo Ribalda Delgado
> :
>> you can use http://lttng.org/ for analyzing this
Thanks Ricardo, I will use this.
>>
>> Regards!
>>
>> On Fri, Jul 29, 2016 at 12:44 PM, Pranay Srivastava
>> wrote:
>>> On Fri, Jul 29, 2016 at 4:02 PM, Muni Sekhar
>>> wrote:
Hi All,
I have a doubt regarding the workqueue scheduling.
I am using the workqueue for processing the Rx Interrupt data. I am
calling schedule_work() on receiving the Rx interrupt from hardware.
I calculated the time between calling the schedule_work() and
workqueue task actually getting executed, Here I see many cases of
less than 100 us(It is fairly good).
But sometimes I see 10’s of ms and a lot in the 100’s of ms. I have
seen over 0.5 secs too. I would like to know why does sometimes kernel
takes longer time(in milli seconds) to schedule it? Is there any way
to reduce this time gap?
My code:
static void my_workqueuetask(struct work_struct *work)
{
printk("In %s() \n",__func__);
>>> You probably don't need this if it's just for your work_fn, yeah but
>>> if there's race between this and something else...
mutex_lock(&bh_mutex);
//Do something here
mutex_unlock(&bh_mutex);
}
static irqreturn_t my_irq_handler(int irq, void *dev)
{
……;
if(Rx Interrupt)
schedule_work(&rx_work);
>>>
>>> Maybe system_wq has too much already on it's plate?
>>> Have you tried the same with completion and a kthread? or
>>> with your own workqueue, overkill but you can give it a shot.
I have not tried this. First I will analyze with lttng and then
attempts this. Does using our own workqueue reduces the latency?
return IRQ_HANDLED;
}
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>>
>>>
>>> --
>>> ---P.K.S
>>>
>>> ___
>>> Kernelnewbies mailing list
>>> Kernelnewbies@kernelnewbies.org
>>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
>>
>> --
>> Ricardo Ribalda
>>
>> ___
>> Kernelnewbies mailing list
>> Kernelnewbies@kernelnewbies.org
>> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
>
> --
> "Do or do not. There is no try"
> Yoda Master
>
> ___
> Kernelnewbies mailing list
> Kernelnewbies@kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
--
Thanks,
Sekhar
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Stupid question regarding bogomips and udelay()
Hello, that's an interesting question! I'm currently reading the same book, but you've read more than me so far :) On Mon, Aug 01, 2016 at 08:36:07AM +0300, Aleksander Alekseev wrote: > * bogomips value (see `cat /proc/cpuinfo`) is determined only once > during system boot As far as I know, I is (was?) the case. > It's my understanding that it shouldn't work. CPU frequency actually > changes manually (see cpufrequtils) and/or automatically depending for > instance on laptop's current battery charge. There is also such a nasty > thing as Intel Turbo Boost. In other words actual MIPS could be higher > or lower than measured MIPS. So udealy() can't guarantee anything. Makes sense. Do you have such machine? Did you try to get bogomips and then reduce your CPU count / speed and get that number again? Maybe this value is now dynamic. Also, did you actually try udealay() in high/low frequency to see wether you see an actual difference between runs? Sorry I don't have final answers! -- François ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
