Re: USB device debugging
On Wed, May 25, 2016 at 3:41 PM, Bjørn Mork wrote: > Narasimha M writes: > >> Thanks for explanation. Here data is getting corrupted before it comes >> to the usbnet itself, so after it reaches to usbnet and go through >> network stack, it is failing in tcp checksum and packet is getting >> dropped. Same driver is working with linux-3.10.20 but not working >> with linux-2.6.32.Not able to find the exact function in driver which >> sends receive packet to usbnet, not able to proceed further. Please >> suggest some pointers to proceed further. > > This is no surprise. There is no "send receive packet to usbnet". > > usbnet allocates a receive buffer and hands it to the USB host > controller. This happens in rx_submit(). Understood this. >The host controller calls the > rx_complete() callback when it gets data from the device. Here i want the help that where will be this host controller ? and how to it calls the rx_complete () callback ? Whet is the function in host controller does this. ? Ehat is the exact meaning of when device gets the data ? These things i am not able to understand. BTW iam using some 4g dongle as usb and usb driver is gobinet to support this and i am checking this on one router which has 2.6.32 kernel. I tried to use usbmon also, i got the raw data. I am trying to process it. Meanwhile i am not clear about the above explanation. Please try to explain me if you are not irritated. >This callback > will trigger further handling in the usbnet_bh() tasklet, calling > rx_process(). This again calls the minidriver specific rx_fixup() > callback if there is any, which is GobiNet's only chance of inspecting > and possibly modifying the buffer. But normally it will not touch the > buffer, since there is no fixup necessary for Gobi devices in 802.3 mode > (they transmit plain ethernet packets). rx_process() ends up calling > usbnet_skb_return() which hands the buffer over the the networking stack > using netif_rx(). > Understood > So, if we ignore the possible firmware bug workarounds in rx_fixup(), > then nothing ever touches the receive buffer in usbnet. It's just a > handle being passed around. > Understood. > Note that I don't remember, or care, what 2.6.32 might have done. It's too > outdated to be relevant. But the usbnet design is much older and > haven't changed drastically, so I assume most of the above is valid > there too. > > > Bjørn -- Narasimha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
On Thu, May 26, 2016 at 11:01:31AM +0530, Narasimha M wrote: > Hi, Thank you so much for your help. One last query in this. From you > explanation USB host controller will receive the packet from device. So could > you please tell me, what is the first function being called when device gets > the data Which device? The host controller? Or the driver for the USB device itself? > and if I am not working this first function will be in USB host > controller code. The host controller gets the data first and then passes it to the specific USB device driver. Again, usbmon is going to be the best thing to use here, good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Hi, Thank you so much for your help. One last query in this. From you explanation USB host controller will receive the packet from device. So could you please tell me, what is the first function being called when device gets the data and if I am not working this first function will be in USB host controller code. On Wed, May 25, 2016 at 09:11:59PM +0530, Narasimha M wrote: > I am attaching the raw data in two cases (working - 2.mon.out) and not > working (1.mon.out) files. > > working one is with the device having linux 3.10.20 and not working > one is with linux 2.6.32. Here i have run same traffic in both the > cases. You really are on your own with 2.6.32, sorry. If you have issues with that kernel, please contact the vendor that is forcing you to stick with it, as you are paying them to do this work. If that vendor is yourself, well, sorry, it's all your fault, nothing the community can do with such an obsolete and broken kernel release. good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Identify tasks which mmap'ed file
Within the kernel and given a struct file *, is it possible to enumerate the tasks which have mmap/MAP_SHARED'ed the file? I have tried to use find_get_pages/rmap_walk on the file's f_mapping field, but this does not seem to work. I find the mapping's first page with find_get_pages, but rmap_walk does not seem to find any vma's as rmap_walk never calls the callback function I pass in. Thank you, -- Mike :wq ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: free(), the size to free?
2016-05-25 14:17 GMT-04:00 Greg KH : > On Wed, May 25, 2016 at 02:00:41PM -0400, Wenda Ni wrote: >> The prototype is void kfree(const void *). >> >> As the input pointer is void *, how does the kernel know the size of memory >> to >> be freed? There should be some metadata recorded under the hood, right? > > Yes there is. See the memory allocation code for the details. > > Same goes for the C language implementation of free(), look at any libc > implementation for more details about that if you are curious, the > basics are the same for within the kernel. Take heap allocation in glibc for example, 1. An allocated chunk is represented as follows: chunk -> | Size of previous chunk, if allocated | | Size of chunk, in bytes |A|M|P| mem -> | User data starts here | | | 2. An chunk that was at one time allocated but has been free()d, chunk -> | Size of previous chunk, if allocated | | Size of chunk, in bytes |A| |P| mem -> | Forward pointer to next chunk in list | | Back pointer to next chunk in list | | Unused space| The pointer (argument in free or kfree) is a pointer to a complicated data structure. The information you seek is all in that data structure. All you need to do is to find documents that explains this data structure. My best regards to you. No System Is Safe! mudongliang > > thanks, > > greg k-h > > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
On Wed, May 25, 2016 at 09:11:59PM +0530, Narasimha M wrote: > I am attaching the raw data in two cases (working - 2.mon.out) and not > working (1.mon.out) files. > > working one is with the device having linux 3.10.20 and not working > one is with linux 2.6.32. Here i have run same traffic in both the > cases. You really are on your own with 2.6.32, sorry. If you have issues with that kernel, please contact the vendor that is forcing you to stick with it, as you are paying them to do this work. If that vendor is yourself, well, sorry, it's all your fault, nothing the community can do with such an obsolete and broken kernel release. good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: free(), the size to free?
On Wed, May 25, 2016 at 02:00:41PM -0400, Wenda Ni wrote: > The prototype is void kfree(const void *). > > As the input pointer is void *, how does the kernel know the size of memory to > be freed? There should be some metadata recorded under the hood, right? Yes there is. See the memory allocation code for the details. Same goes for the C language implementation of free(), look at any libc implementation for more details about that if you are curious, the basics are the same for within the kernel. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
free(), the size to free?
The prototype is void kfree(const void *). As the input pointer is void *, how does the kernel know the size of memory to be freed? There should be some metadata recorded under the hood, right? Thank you for sharing your thoughts. Cheers, Wenda Ni, Ph.D. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
If possible yes, i need a help. I am working on it for the first time on usb subsystem. I just tried using usbmon also, i got some raw data in text file. Could you please let me know how it will help to debug further?. One more observation is that if i decrease the mtu size to around 480, then i am able to run the traffic. Which means the data is getting corrupted after 480 bytes length or so. Is there any possible chance for this case? On Wed, May 25, 2016 at 6:26 PM, Bjørn Mork wrote: > Narasimha M writes: > >> Thanks for clear explanation. Could you please let me know where does >> host_controller will be present is it in USB device or USB core part >> of kernel. >> >> Actually my issue is that we ported Gobinet driver from open source to >> support one dongle. After porting, it is working fine on little endian >> host (linux-2.6.31 kernel). We have added some changes in driver code >> o support it for big endian hosts. After adding the changes with the >> help of le16_to_cpu () function dongle is working in one of our big >> endian hosts (which has linux-3.10.20), but facing corrupted packet >> issue in other bigendian supported host (linux-2.6.32). Could you >> please help in providing some pointers here > > Sounds like you have a bug in your code. Did you expect me to make a > more precise guess? > > > Bjørn -- Narasimha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Changing the default scheduler
Changing the policy of the init process at include/linux/init_task.h worked! Although a lot of tasks asked to change the scheduler policy to SCHED_NORMAL (and thus the scheduler class to CFS) through sched_setscheduler(), so I had to add some code there to force the SCHED_RR policy. I made the priority of the tasks to be the same of the init process, so the RT scheduler turned (I think) into a simple Round-Robin scheduler, as the priority of almost all processes is the same. The only processes that had higher priority were the ones that already runned using the RT scheduler even when the CFS was being used. The linux booted up okay, although I am not using a desktop environment, so I don't know if it would boot up if it had XOrg. What would I have to do if I instead wanted to change the scheduler class that is used when a process specifies the SCHED_NORMAL policy? Is there a way to do that without replacing the CFS source at fair.c? Thanks. Em ter, 24 de mai de 2016 às 12:22, Frederic Weisbecker escreveu: > (Sorry I forgot to Cc kernelnewbies, I fixed the Cc line). > > On Tue, May 24, 2016 at 11:47:37AM +, Renato Utsch wrote: > > Hi Frederic, > > > > Thanks, this was exactly what I was looking for! I was suspecting that > all > > the processes would inherit the policy of the init process, but I didn't > > know where to look at. I'll take a look at this and see what happens. > > > > By the way, how are the scheduler policies and the schedulers related? > > Because the RT scheduler can be used with either SCHED_FIFO or SCHED_RR. > > Are some policies linked to particular schedulers? If so, can I introduce > > new SCHED_* constants? How should I do that if I want to call > > sched_setscheduler() to change the policy to, say, SCHED_MY in an > userspace > > program? > > What you refer as "scheduler" is in fact a scheduler class. > So we have two different notions here: scheduler policy and scheduler > class. > > _ The scheduler policy is set by the user or the system to tell how to > schedule a task. > That's in the user interface level. > > _ The scheduler classes handle the tasks scheduling differently on top of > their scheduler policy (driven > by the user) or on top of kernel internal needs (idle_sched_class and > stop_sched_class). > > We have 4 of them, from lowest prio to highest: > > _ idle_sched_class = implement idle tasks. The idle tasks (one per > CPU) > are set with SCHED_NORMAL but the policy of idle > tasks are > not even checked. > > _ fair_sched_class = implement SCHED_NORMAL/SCHED_FAIR and SCHED_IDLE > (not to be confused > with idle tasks. In fact SCHED_IDLE tasks are > normal tasks that execute > when there is no SCHED_NORMAL tasks to run) > > _ rt_sched_class = implement SCHED_RR and SCHED_FIFO > > _ dl_sched_class = deadline realtime tasks (SCHED_DEADLINE) > > _ stop_sched_class = stop machine tasks. They don't refer to any > policy, the stop machine > tasks call sched_set_stop_task() to switch to > this class. Their policy > are SCHED_NORMAL but it's ignored. > >That's in the implementation level. > > When the scheduler needs to choose the next task to run on the CPU, it > iterates each class > from highest prio to lower: (stop, dl, rt, fair, idle) and calls the > ->pick_next_task() > callback for each of these classes. The first one that has a task to run > will have it on > the CPU. This is how class priorities are implemented. > > So if you want to implement a new policy, the easiest is to create a new > scheduler class > but you'll need to decide where it fits between the classes prio. > > Now when people talk about re-implementing the scheduler, they usually > mean the way to schedule > the SCHED_NORMAL tasks. If that's what you're interested in, I think you > rather want to rewrite > kernel/sched/fair.c and do your own fair_sched_class implementation. > > Now kernel/sched/fair.c does a lot more than just implement > fair_sched_class so rewriting it the > way you like to experiment will be painful due to the links it has all > around in the core kernel. > Perhaps it's easier to create your own policy, define its prio between > idle_sched_class and > fair_sched_class then run your task under that policy on a CPU that > doesn't have any SCHED_NORMAL > tasks. > > You can also set the init/0 task to your policy but there is no guarantee > it will propagate all > along recursively to the whole process tree as anything can override a > parent back to SCHED_NORMAL > at some point. > > Thanks. > > > > > Em ter, 24 de mai de 2016 às 08:39, Frederic Weisbecker < > fweis...@gmail.com> > > escreveu: > > > > > Hi Renato, > > > > > > What you're talking about is not exactly the scheduler but the > scheduler > > > policy. Basically the scheduler policy is inherited on fork(). The very > > > firs
Re: USB device debugging
Narasimha M writes: > Thanks for clear explanation. Could you please let me know where does > host_controller will be present is it in USB device or USB core part > of kernel. > > Actually my issue is that we ported Gobinet driver from open source to > support one dongle. After porting, it is working fine on little endian > host (linux-2.6.31 kernel). We have added some changes in driver code > o support it for big endian hosts. After adding the changes with the > help of le16_to_cpu () function dongle is working in one of our big > endian hosts (which has linux-3.10.20), but facing corrupted packet > issue in other bigendian supported host (linux-2.6.32). Could you > please help in providing some pointers here Sounds like you have a bug in your code. Did you expect me to make a more precise guess? Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Thanks for clear explanation. Could you please let me know where does host_controller will be present is it in USB device or USB core part of kernel. Actually my issue is that we ported Gobinet driver from open source to support one dongle. After porting, it is working fine on little endian host (linux-2.6.31 kernel). We have added some changes in driver code o support it for big endian hosts. After adding the changes with the help of le16_to_cpu () function dongle is working in one of our big endian hosts (which has linux-3.10.20), but facing corrupted packet issue in other bigendian supported host (linux-2.6.32). Could you please help in providing some pointers here On Wed, May 25, 2016 at 5:31 PM, Bjørn Mork wrote: > Narasimha M writes: > >> Thanks for the info. Sorry to ask you again, where does the usb driver >> (GobiNet in my case) comes into picture in receive packet flow. I >> suspect that the driver has to send some data (may be with some >> interrupts) to rx_complete and then it will go to rx_submit. Is my >> understanding is correct ? or if rx_submit is the first function to >> generate the data, then where does Gobinet driver comes into place. >> Could you please explain. I don't know how some usb driver works. This >> is the first time i am working on it. > > GobiNet isn't part of the receive packet flow at all, if we assume a > non-buggy Gobi device operating in 802.3 mode. The rx_fixup callback is > called, but it does nothing. There isn't anything to do. The buffer is > filled with an ethernet packet by the device + host controller. > > The usbnet_bh() tasklet is responsible for calling rx_submit (indirectly > in newer kernels). This is triggered by setting the EVENT_DEV_OPEN > flag, which is done by usbnet_open(). GobiNet obfuscates this quite a > bit, but it doen't do anything extra-ordinary here - it simply calls > usbnet_open() when you open the netdev. > > > > Bjørn -- Narasimha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > Thanks for the info. Sorry to ask you again, where does the usb driver > (GobiNet in my case) comes into picture in receive packet flow. I > suspect that the driver has to send some data (may be with some > interrupts) to rx_complete and then it will go to rx_submit. Is my > understanding is correct ? or if rx_submit is the first function to > generate the data, then where does Gobinet driver comes into place. > Could you please explain. I don't know how some usb driver works. This > is the first time i am working on it. GobiNet isn't part of the receive packet flow at all, if we assume a non-buggy Gobi device operating in 802.3 mode. The rx_fixup callback is called, but it does nothing. There isn't anything to do. The buffer is filled with an ethernet packet by the device + host controller. The usbnet_bh() tasklet is responsible for calling rx_submit (indirectly in newer kernels). This is triggered by setting the EVENT_DEV_OPEN flag, which is done by usbnet_open(). GobiNet obfuscates this quite a bit, but it doen't do anything extra-ordinary here - it simply calls usbnet_open() when you open the netdev. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Thanks for the info. Sorry to ask you again, where does the usb driver (GobiNet in my case) comes into picture in receive packet flow. I suspect that the driver has to send some data (may be with some interrupts) to rx_complete and then it will go to rx_submit. Is my understanding is correct ? or if rx_submit is the first function to generate the data, then where does Gobinet driver comes into place. Could you please explain. I don't know how some usb driver works. This is the first time i am working on it. On Wed, May 25, 2016 at 4:36 PM, Bjørn Mork wrote: > Narasimha M writes: > >> I am able to see the corrupted data in rx_complete itself. > > Then the only likely source is the device. In theory it could be the > host controller, but that is very unliekely unless you use some > out-of-tree driver there too. > > You can easily verify that usbnet can be ruled out by follwing the > earlier usbmon advice. > >> What are >> the possibilities for the data corruption in rx_complete. Any fixes to >> resolve this. And from where the data in rx_submit generates > > rx_submit allocates new buffers using __netdev_alloc_skb_ip_align() like > many other network drivers. > > > > Bjørn -- Narasimha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > I am able to see the corrupted data in rx_complete itself. Then the only likely source is the device. In theory it could be the host controller, but that is very unliekely unless you use some out-of-tree driver there too. You can easily verify that usbnet can be ruled out by follwing the earlier usbmon advice. > What are > the possibilities for the data corruption in rx_complete. Any fixes to > resolve this. And from where the data in rx_submit generates rx_submit allocates new buffers using __netdev_alloc_skb_ip_align() like many other network drivers. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: make oldconfig forces HWMON to be inbuilt
On Fri, May 20, 2016 at 7:35 AM, Ani Sinha wrote: > Hi guys : > > I am seeing this weird issue where even though my original kernel > configuration tries to build HWMON as a module, when I do 'make > oldconfig', it forces HWMON to be built into the kernel. Is there > anyway I can find what configuration is forcing this change? > CONFIG_HWMEM is a tristate symbol. Did you mean CONFIG_HWMON? Run make menuconfig and use / CONFIG_HWMON to find its place in config hierarchy. It should be under "Device Drivers" -> Hardware Monitoring Support. Then press "?" to find more info about CONFIG_HWMON symbol. Look for "Selected by". thanks, Daniel. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
I am able to see the corrupted data in rx_complete itself. What are the possibilities for the data corruption in rx_complete. Any fixes to resolve this. And from where the data in rx_submit generates On Wed, May 25, 2016 at 3:41 PM, Bjørn Mork wrote: > Narasimha M writes: > >> Thanks for explanation. Here data is getting corrupted before it comes >> to the usbnet itself, so after it reaches to usbnet and go through >> network stack, it is failing in tcp checksum and packet is getting >> dropped. Same driver is working with linux-3.10.20 but not working >> with linux-2.6.32.Not able to find the exact function in driver which >> sends receive packet to usbnet, not able to proceed further. Please >> suggest some pointers to proceed further. > > This is no surprise. There is no "send receive packet to usbnet". > > usbnet allocates a receive buffer and hands it to the USB host > controller. This happens in rx_submit(). The host controller calls the > rx_complete() callback when it gets data from the device. This callback > will trigger further handling in the usbnet_bh() tasklet, calling > rx_process(). This again calls the minidriver specific rx_fixup() > callback if there is any, which is GobiNet's only chance of inspecting > and possibly modifying the buffer. But normally it will not touch the > buffer, since there is no fixup necessary for Gobi devices in 802.3 mode > (they transmit plain ethernet packets). rx_process() ends up calling > usbnet_skb_return() which hands the buffer over the the networking stack > using netif_rx(). > > So, if we ignore the possible firmware bug workarounds in rx_fixup(), > then nothing ever touches the receive buffer in usbnet. It's just a > handle being passed around. > > Note that I don't remember, or care, what 2.6.32 might have done. It's too > outdated to be relevant. But the usbnet design is much older and > haven't changed drastically, so I assume most of the above is valid > there too. > > > Bjørn -- Narasimha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Narasimha M writes: > Thanks for explanation. Here data is getting corrupted before it comes > to the usbnet itself, so after it reaches to usbnet and go through > network stack, it is failing in tcp checksum and packet is getting > dropped. Same driver is working with linux-3.10.20 but not working > with linux-2.6.32.Not able to find the exact function in driver which > sends receive packet to usbnet, not able to proceed further. Please > suggest some pointers to proceed further. This is no surprise. There is no "send receive packet to usbnet". usbnet allocates a receive buffer and hands it to the USB host controller. This happens in rx_submit(). The host controller calls the rx_complete() callback when it gets data from the device. This callback will trigger further handling in the usbnet_bh() tasklet, calling rx_process(). This again calls the minidriver specific rx_fixup() callback if there is any, which is GobiNet's only chance of inspecting and possibly modifying the buffer. But normally it will not touch the buffer, since there is no fixup necessary for Gobi devices in 802.3 mode (they transmit plain ethernet packets). rx_process() ends up calling usbnet_skb_return() which hands the buffer over the the networking stack using netif_rx(). So, if we ignore the possible firmware bug workarounds in rx_fixup(), then nothing ever touches the receive buffer in usbnet. It's just a handle being passed around. Note that I don't remember, or care, what 2.6.32 might have done. It's too outdated to be relevant. But the usbnet design is much older and haven't changed drastically, so I assume most of the above is valid there too. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: USB device debugging
Thanks for explanation. Here data is getting corrupted before it comes to the usbnet itself, so after it reaches to usbnet and go through network stack, it is failing in tcp checksum and packet is getting dropped. Same driver is working with linux-3.10.20 but not working with linux-2.6.32.Not able to find the exact function in driver which sends receive packet to usbnet, not able to proceed further. Please suggest some pointers to proceed further. On Tue, May 24, 2016 at 10:30 PM, Bjørn Mork wrote: > Greg KH writes: >> On Tue, May 24, 2016 at 01:48:16PM +0530, Narasimha M wrote: >>> Thanks for the information. But i want to know the flow of receive >>> packet from usb driver to linux stack. I am facing an issue that >>> corrupted data is coming to usbnet_bh function. So i want to know >>> about the place where we generate the data in usb driver and sent it >>> to usbnet. Could you please help in finding out this. I am using >>> Gobinet driver as usb driver. >> >> Look in the usbnet driver itself, it is the one that receives the data >> from the USB core. >> >> If you suspect the USB core isn't getting the data properly, use usbmon >> to look at the "raw" USB data for the device, instructions for how to >> use that is in the kernel documentation directory. > > I would have started with usbmon in this case. Some Gobi firmwares are > known to corrupt ethernet headers in various ways, if that is the > problem. There are numerous workarounds for these issues in the > qmi_wwan driver, and AFAIK also in the GobiNet driver. But the worst > mess is unfixable, where the header is overwritten by arbitrary data and > you don't even know if there is a header there or not. The only > possible workaround for those devices is using "raw-ip" mode, where you > can be certain that there is no ethernet header (and therefore no mess) > > Nothing can be ruled out of course, but I say that there is little > chance of any data corruption in the usbnet code. It doesn't really > touch the packet buffers between USB controller and network stack. The > corruption is most likely to happen in firmware, or possibly in GobiNet > although I haven't yet seen any proof of that. > > > Bjørn -- Narasimha ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
