Re: likely kernel/driver problem with 3G USB stick
On Tue, Mar 1, 2011 at 11:10 AM, Simon Leung wrote:
> Hi all,
>
> I'm having a problem with my 3G USB stick (Huawei E220) .
>
> The kernel I'm using is version 2.6.21 customized for an ARM board. When
> I insert the USB stick into the system, normally 3 device show up:
> /dev/ttyUSB{0,1,2}. The problem I' having is that some time, only the
> first one shows up and I cannot connect to it. When this happens,
> normally a reboot will fix it.
>
> As I said, this sounds like a kernel/driver issue to me. Could somebody
> give me some pointers as how to prove/fix it?
>
>
>
You may need to eject the scsi cdrom with USB_ModeSwitch. In distros with
normally is automatically done via a udev rule.
--
John
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: some questions about kernel source
On Fri, Feb 18, 2011 at 12:16 PM, John Mahoney wrote:
> On Fri, Feb 18, 2011 at 9:28 AM, loody wrote:
>> hi :
>>
>>
>> 2011/2/18 John Mahoney :
>>> On Thu, Feb 17, 2011 at 9:17 AM, loody wrote:
>>>> hi :-)
>>>>
>>>> 2011/2/16 Mulyadi Santosa :
>>>>> Hi :)
>>>>>
>>>>> On Wed, Feb 16, 2011 at 12:59, Rajat Jain wrote:
>>>>>> Hello loody,
>>>>>>
>>>>>>> 1. in kernel/trace, I always see "__read_mostly" at the end of
>>>>>>> parameter is that a compiler optimization parameter?
>>>>>>
>>>>>> Yes, it is a hint to the compiler that the parameter is mostly read,
>>>>>> thus if the compiler has to make a decision between optimizing one of
>>>>>> the read / write paths, it will optimize the read path even at the
>>>>>> expense of write path.
>>>>>
>>>>>
>>>>> To be precise, they will be grouped into same cache line as much as
>>>>> possible. By doing so, those cache line won't be invalidated so often
>>>>> (keeping them "hot" :) hehehhe )
>>>>
>>>> I cannot find it on the gcc manual.
>>>> is it a option in kernel for kernel usage?
>>>> if so, where I can found them.
>>>> If not, can I use it on normal user level program?
>>>>
>>>
>>> It is a macro defined for x86 as:
>>>
>>> #define __read_mostly __attribute__((__section__(".data..read_mostly")))
>>>
>>> http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h
>> I found where you pointed out but I try to find out where is it in the
>> mips arch.
>
> It looks pretty new for mips and you may have older code.
>
> $ git log -p cache.h
> commit 1befdd5536e1500371f7f884d0f0ae528a519333
> Author: David Daney
> Date: Thu Oct 14 12:36:49 2010 -0700
>
> MIPS: Implement __read_mostly
> commit 1befdd5536e1500371f7f884d0f0ae528a519333
> Author: David Daney
> Date: Thu Oct 14 12:36:49 2010 -0700
>
> MIPS: Implement __read_mostly
>
> Just do what everyone else is doing by placing __read_mostly things in
> the .data.read_mostly section.
>
> mips_io_port_base can not be read-only (const) and writable
> (__read_mostly) at the same time. One of them has to go, so I chose
> to eliminate the __read_mostly. It will still get stuck in a portion
> of memory that is not adjacent to things that are written, and thus
> not be on a dirty cache line, for whatever that is worth.
>
> Signed-off-by: David Daney
> To: linux-m...@linux-mips.org
> Patchwork: http://patchwork.linux-mips.org/patch/1702/
> Signed-off-by: Ralf Baechle
I left off some the end see below.
diff --git a/arch/mips/include/asm/cache.h b/arch/mips/include/asm/cache.h
index 37f175c..650ac9b 100644
--- a/arch/mips/include/asm/cache.h
+++ b/arch/mips/include/asm/cache.h
@@ -17,4 +17,6 @@
#define SMP_CACHE_SHIFTL1_CACHE_SHIFT
#define SMP_CACHE_BYTESL1_CACHE_BYTES
+#define __read_mostly __attribute__((__section__(".data.read_mostly")))
+
#endif /* _ASM_CACHE_H */
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: some questions about kernel source
On Fri, Feb 18, 2011 at 9:28 AM, loody wrote:
> hi :
>
>
> 2011/2/18 John Mahoney :
>> On Thu, Feb 17, 2011 at 9:17 AM, loody wrote:
>>> hi :-)
>>>
>>> 2011/2/16 Mulyadi Santosa :
>>>> Hi :)
>>>>
>>>> On Wed, Feb 16, 2011 at 12:59, Rajat Jain wrote:
>>>>> Hello loody,
>>>>>
>>>>>> 1. in kernel/trace, I always see "__read_mostly" at the end of
>>>>>> parameter is that a compiler optimization parameter?
>>>>>
>>>>> Yes, it is a hint to the compiler that the parameter is mostly read, thus
>>>>> if the compiler has to make a decision between optimizing one of the read
>>>>> / write paths, it will optimize the read path even at the expense of
>>>>> write path.
>>>>
>>>>
>>>> To be precise, they will be grouped into same cache line as much as
>>>> possible. By doing so, those cache line won't be invalidated so often
>>>> (keeping them "hot" :) hehehhe )
>>>
>>> I cannot find it on the gcc manual.
>>> is it a option in kernel for kernel usage?
>>> if so, where I can found them.
>>> If not, can I use it on normal user level program?
>>>
>>
>> It is a macro defined for x86 as:
>>
>> #define __read_mostly __attribute__((__section__(".data..read_mostly")))
>>
>> http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h
> I found where you pointed out but I try to find out where is it in the
> mips arch.
It looks pretty new for mips and you may have older code.
$ git log -p cache.h
commit 1befdd5536e1500371f7f884d0f0ae528a519333
Author: David Daney
Date: Thu Oct 14 12:36:49 2010 -0700
MIPS: Implement __read_mostly
commit 1befdd5536e1500371f7f884d0f0ae528a519333
Author: David Daney
Date: Thu Oct 14 12:36:49 2010 -0700
MIPS: Implement __read_mostly
Just do what everyone else is doing by placing __read_mostly things in
the .data.read_mostly section.
mips_io_port_base can not be read-only (const) and writable
(__read_mostly) at the same time. One of them has to go, so I chose
to eliminate the __read_mostly. It will still get stuck in a portion
of memory that is not adjacent to things that are written, and thus
not be on a dirty cache line, for whatever that is worth.
Signed-off-by: David Daney
To: linux-m...@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1702/
Signed-off-by: Ralf Baechle
As a side note I would not use this just because you think your
variable is read more than written. Premature optimization is a waste
of time, so make sure your on a hot path before even considering
something like this.
--
John
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: some questions about kernel source
On Thu, Feb 17, 2011 at 9:17 AM, loody wrote:
> hi :-)
>
> 2011/2/16 Mulyadi Santosa :
>> Hi :)
>>
>> On Wed, Feb 16, 2011 at 12:59, Rajat Jain wrote:
>>> Hello loody,
>>>
1. in kernel/trace, I always see "__read_mostly" at the end of
parameter is that a compiler optimization parameter?
>>>
>>> Yes, it is a hint to the compiler that the parameter is mostly read, thus
>>> if the compiler has to make a decision between optimizing one of the read /
>>> write paths, it will optimize the read path even at the expense of write
>>> path.
>>
>>
>> To be precise, they will be grouped into same cache line as much as
>> possible. By doing so, those cache line won't be invalidated so often
>> (keeping them "hot" :) hehehhe )
>
> I cannot find it on the gcc manual.
> is it a option in kernel for kernel usage?
> if so, where I can found them.
> If not, can I use it on normal user level program?
>
It is a macro defined for x86 as:
#define __read_mostly __attribute__((__section__(".data..read_mostly")))
http://lxr.linux.no/linux+v2.6.37/arch/x86/include/asm/cache.h
---snip---
Start a new thread for a new topic.
--
John
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: avoid ip forward replaces the source MAC address
On Tue, Feb 1, 2011 at 2:39 PM, John Mahoney wrote: > On Tue, Feb 1, 2011 at 2:27 PM, Elvis Yoan Tamayo Mollares > wrote: >> hi list, during ip forwarding process, the kernel replace the source MAC >> address of the package it received with my own MAC address.. My question >> is: Is there any way to avoid this behavior? > > That is what routing does at the ip layer. You may be able to > accomplish this by bridging the two ports together so that the traffic > is handled at layer 2. As a side note, looking at the iptables target: -m mac --mac-source XX:XX:XX:XX:XX:XX [1] and the kernel code for that module (net/netfilter/xt_mac.c) it appears that the src MAC address is saved in the sk_buff and is still accessible in the PREROUTING, INPUT, and FORWARD chains via eth_hdr(skb)->h_source. I do not know if that helps. I guess my point is my first answer was the logical one, but it may be possible if you think outside the box. -- John [1]http://www.faqs.org/docs/iptables/matches.html#TABLE.MACMATCH ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: avoid ip forward replaces the source MAC address
On Tue, Feb 1, 2011 at 2:27 PM, Elvis Yoan Tamayo Mollares wrote: > hi list, during ip forwarding process, the kernel replace the source MAC > address of the package it received with my own MAC address.. My question > is: Is there any way to avoid this behavior? That is what routing does at the ip layer. You may be able to accomplish this by bridging the two ports together so that the traffic is handled at layer 2. -- John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Implement custom network protocol for local processes
On Mon, Jan 17, 2011 at 4:24 PM, Kfir Lavi wrote: > Hi, > How can one implement custom header network protocol. > I mean header that wraps regular network packets like ethernet, udp, tcp, > etc... > The sending of this custom packets is done between processes running > locally. > ie. I get a Ethernet packet, inspect it, then add my custom header and > forward > it to another process that listens to a socket, and expect to get data > wrapped with > this custom header. > > What is a good way to go about and implement this thing? Have you looked at the tun/tap drivers? Also, try asking this question on a network specific list. -- John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: ML archive
On Wed, Jan 5, 2011 at 6:46 PM, wrote: > Hi there, > > The actual archive contains only December and January. > Were are the older archives? It disappeared, but here is an "unofficial" archive(see bottom left) back to Jan 2003: http://blog.gmane.org/gmane.linux.kernel.kernelnewbies > ___ > 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: addition of guidelines page on kernelnewbies.org
On Wed, Jan 5, 2011 at 4:20 PM, Anuz Pratap Singh Tomar wrote: > With great power comes great responsibility, :p > > So, I have created the guideline page finally( it took me a while to figure > out how to edit wikipages.) > > I have modified ML page to include link to guidelines page: > http://kernelnewbies.org/ML > > the guideline page is available here: > http://kernelnewbies.org/mailinglistguidelines > > Please let me know if you find any errors/corrections or want to suggest any > improvements. Thanks for taking your time to write this up. The following link http://mail.nl.Linux.org/kernelnewbies/ to the old archive appears to be dead. Also, on this note does anyone plan to consolidate the old and new archive. I feel this is very useful information to preserve and would hate to lose years of knowledge. Thanks again, John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: fixed memory bytes
Please reply all..I added back list. On Tue, Jan 4, 2011 at 1:58 PM, mohit verma wrote: > thnx john,. > but i know that this indicates to compiler to align the structure to its > nearest boundries. is that so? I am not sure of your definition of boundary, but I would say it does the opposite. It tells the compiler not to align the struct to boundaries. -- John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: fixed memory bytes
On Tue, Jan 4, 2011 at 1:07 PM, Rajesh S R wrote: > > > On Tue, Jan 4, 2011 at 11:28 PM, Mulyadi Santosa > wrote: >> >> On Wed, Jan 5, 2011 at 00:40, mohit verma wrote: >> > >> > hi all, >> > i have seen many places in kernel where the variables specially the >> > structures should be of fixed size independent of the architecture. i >> > went >> > through the definitions of them but dint get clearly (or frankly >> > say >> > ...dint get them even a bit) . >> >> Your question isn't specific enough, so I'll just guess. Let's say >> "int". In 32 bit, AFAIK it's 4 byte, but in 64 bit (like IA 64, not >> sure if it's x64) it's 8 byte. So, if you just say "int", you will >> likely getting screwed up. >> >> By using types like u_int or something like that, you pretty much say >> "I mean 4 byte kind of integer" etc > > > Still there can be padding issues due to byte alignment, which may vary > across architecture. Am not sure if that is controllable (probably some > pragma to gcc?). Probably, OP is asking about it? I believe you are referring to __attribute__( ( packed ) ) ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Problem with booting newly compiled kernel
>> b. Also, who generates these UUID - is it a disk property (like, ROM >> signature or stuff?), or this is some udev magic? >> > > IMHO, this is fixed for every device during manufacturing. > I believe the UUID is created per partition/file system and are created when creating the file system for a partition. If anyone even had their drive changed from /dev/hda to /dev/sda due to linux changing how they labeled ide drives they will know why people use UUID instead of the device name . Also, it is not guaranteed that they drives will always come up in the same order between kernel releases(This is my personal opinion). -- John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: KVM - virtualization support
On Tue, Dec 21, 2010 at 1:49 AM, Sengottuvelan S wrote: > Hi All, > > I am trying to see whether my kernel has KVM support or not. When i execute > #egrep -c '(vmx|svm)' /proc/cpuinfo , output shows '0'' which means my > custom kernel does not have capability of KVM. > I think you are misunderstanding the flags in /proc/cpuinfo. I believe they represent which features the processor supports, not what features the kernel supports. Like Rajat said you may need to enable the feature in your BIOS, but otherwise you may want to check the datasheet for the processor. feel free to paste the output of: cat /proc/cpuinfo If you do not have this feature you will have to use something such as VirtualBox, of course there will be a performance penalty. -- John ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
