February 2010 - openSUSE Kernel - openSUSE Mailing Lists

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Jan Beulich 23 Feb '10

23 Feb '10

>>> Richard Guenther <rguenther(a)suse.de> 23.02.10 15:35 >>> >So that's a more convincing example to at least get consistency >here. I'll open a bug, but please fix the kernel to use offsetof. Yeah, I meanwhile got confirmation that this is going to be accepted upstream. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Jan Beulich 23 Feb '10

23 Feb '10

>>> Richard Guenther <rguenther(a)suse.de> 23.02.10 15:27 >>> >That'll be not very well recieved as the example I gave was already >rejcted by GCC 2.95. See my other reply - likely caused by an issue with your test case. >Note that GCC itself provides the stddef.h header, see >/usr/lib*/gcc/*-unknown-linux-gnu/*/include Nothing in the standard says that it has to be the compiler (project) that provides that header - commonly it comes with the C library I believe. Furthermore, nothing says that in a specialized environment like the kernel including that header wouldn't result in collisions with definitions provided elsewhere. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Jan Beulich 23 Feb '10

23 Feb '10

>>> Richard Guenther <rguenther(a)suse.de> 23.02.10 14:41 >>> >> >> #define __RING_SIZE(_s, _sz) \ >> (__RD32(((_sz) - offsetof(struct netif_rx_sring, ring)) / sizeof((_s)->ring[0]))) > >And this was already reported as >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39773 and closed as invalid. > >Btw we for a long time rejected the similar > >const long x = (long)((struct X *)0)->j - (long)(struct X *)0; This one certainly doesn't compile, but considering that the member in question is an array, this struct s { int i; long l; }; #define SIZE ((long)&((struct s*)0)->l - (long)((struct s*)0)) const unsigned sz = SIZE; int arr[SIZE]; compiles fine for me with gcc 4.4.2 (and I'm pretty certain this difference is also what caused the problem with icc). >and even > >struct X { int i; int j; }; >char a[(long)((struct X *)0)->j - (long)(struct X *)0]; > >is rejected since at least GCC 2.95. It looks like you just managed >to obfuscate the non-constant enough that GCC folding machinery >invalidly triggered in full glory for constant expression evaluation. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Jan Beulich 23 Feb '10

23 Feb '10

>>> Richard Guenther <rguenther(a)suse.de> 23.02.10 15:06 >>> >> ~matz/bin/opt/bin/intel64/icc -S t.i >t.i(3): error: expression must have a constant value > const long x = (long)((struct X *)0)->j - (long)(struct X *)0; > ^ > >t.i(4): error: expression must have a constant value > char a[(long)((struct X *)0)->j - (long)(struct X *)0]; >... >so your assertion is not true. Interesting - I tried icl 10.1 and 11.0 (Windows), and both accept that construct, even when turning off MSVC compatibility. >stddef.h is required for a C89 environment. Even the Linux kernel doesn't provide one, nor does it generally (there may be a few exceptions) use other than linux/stddef.h. So this only is a theoretical requirement, and I think the compiler ought to honor this by at least providing a compatibility switch for changes like the one above. Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Andreas Jaeger 23 Feb '10

23 Feb '10

On Tuesday 23 February 2010 14:54:57 Jan Beulich wrote: > >>> Michael Matz <matz(a)suse.de> 23.02.10 14:17 >>> > > > >On Tue, 23 Feb 2010, Jan Beulich wrote: > >> >>> Richard Guenther <rguenther(a)suse.de> 23.02.10 12:05 >>> > >> > > >> >The above contains an obfustcated offsetof. Using offsetof > >> >(or __builtin_offsetof if the kernel doesn't have a suitable > >> >definition of offsetof somewhere) should work fine. > >> > >> The header where this gets defined represents an interface between > >> Xen host and guests. It is intentionally written in a way that does not > >> make any assumptions on the environment within which it would be > >> compiled - hence no offsetof() and no gcc extensions. > > > >Relying on "(long)s->ring - (long)s" being a constant expression _is_ a > >GCC extension. You have to use offsetof: > > While this may be an extension, it's one that all compilers I have > access to support, and thus is usable in common code. If 's' were > a variable, I would tend to agree that it's not portable. But with > 's' being (and equivalent of) NULL, I certainly don't, and would > expect the compiler to need fixing (I would bet Xen is not the only > piece of software in the world using code like this). Nevertheless > I'll also check with the Xen community on whether some sort of > sufficiently portable fix can be implemented there. > > >#define __RING_SIZE(_s, _sz) \ > > (__RD32(((_sz) - offsetof(struct netif_rx_sring, ring)) / > > sizeof((_s)->ring[0]))) > > Again - this is not an option. This header, for example, also needs to > be usable on Windows, and as far as I recall Windows (the more its > DDK) doesn't use or provide standard types and macros (i.e. they > may have an OFFSETOF() macro instead). You can make code conditional on compilation with GCC, e.g. #ifdef __GCC__ ... #else ... #endif That might be your only choice if your statement above is valid. Could we add for *now* at least a patch locally that does use offsetof so that kernel-xen builds again? Andreas -- Andreas Jaeger, Program Manager openSUSE, aj(a){novell.com,opensuse.org} Twitter: jaegerandi | Identica: jaegerandi SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

1 0

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Michael Matz 23 Feb '10

23 Feb '10

Hi, On Tue, 23 Feb 2010, Jan Beulich wrote: > >>> Richard Guenther <rguenther(a)suse.de> 23.02.10 12:05 >>> > >The above contains an obfustcated offsetof. Using offsetof > >(or __builtin_offsetof if the kernel doesn't have a suitable > >definition of offsetof somewhere) should work fine. > > The header where this gets defined represents an interface between > Xen host and guests. It is intentionally written in a way that does not > make any assumptions on the environment within which it would be > compiled - hence no offsetof() and no gcc extensions. Relying on "(long)s->ring - (long)s" being a constant expression _is_ a GCC extension. You have to use offsetof: #define __RING_SIZE(_s, _sz) \ (__RD32(((_sz) - offsetof(struct netif_rx_sring, ring)) / sizeof((_s)->ring[0]))) Ciao, Michael. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1

Re: [opensuse-kernel] Current kernel in Factory does not boot - master works
by Jan Beulich 23 Feb '10

23 Feb '10

>>> Richard Guenther <rguenther(a)suse.de> 23.02.10 11:14 >>> >Care to paste one of the declarations? I hope these are all relevant bits which cannot be easily inferred: #define __RD2(_x) (((_x) & 0x00000002) ? 0x2 : ((_x) & 0x1)) #define __RD4(_x) (((_x) & 0x0000000c) ? __RD2((_x)>>2)<<2 : __RD2(_x)) #define __RD8(_x) (((_x) & 0x000000f0) ? __RD4((_x)>>4)<<4 : __RD4(_x)) #define __RD16(_x) (((_x) & 0x0000ff00) ? __RD8((_x)>>8)<<8 : __RD8(_x)) #define __RD32(_x) (((_x) & 0xffff0000) ? __RD16((_x)>>16)<<16 : __RD16(_x)) #define __RING_SIZE(_s, _sz) \ (__RD32(((_sz) - (long)(_s)->ring + (long)(_s)) / sizeof((_s)->ring[0]))) ... #define NET_TX_RING_SIZE __RING_SIZE((struct netif_tx_sring *)0, PAGE_SIZE) #define NET_RX_RING_SIZE __RING_SIZE((struct netif_rx_sring *)0, PAGE_SIZE) ... struct netfront_info { ... struct sk_buff *tx_skbs[NET_TX_RING_SIZE+1]; struct sk_buff *rx_skbs[NET_RX_RING_SIZE]; ... }; Jan -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

[opensuse-kernel] Disabling CONFIG_IDE for openSUSE 11.3
by Tejun Heo 19 Feb '10

19 Feb '10

Hello, I'm currently maintaining the ATA part of the kernel. We've switched to libata for both PATA and SATA for some time but the IDE drivers were left enabled for debugging and occassional fallback. However, there was almost no case where it actually was useful while there still are problems and confusions with duplicate drivers for the same controller. So, I'm thinking about disabling it for openSUSE 11.3 and on and will turn it off in FACTORY soonish. If there's any issue or you're aware of cases where the IDE drivers are indispensible, please speak up. Thanks. -- tejun -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

1 0

[opensuse-kernel] Re: openSUSE Build Service
by Michal Marek 18 Feb '10

18 Feb '10

On 16.2.2010 21:44, Brian K. White wrote: > Hi, Hi Brian, please use the opensuse-kernel mailing list (an pick a better subject next time...). I also added Jiri, who maintains the lxc package in Factory. > cgroup support is missing from the desktop kernel. Is this intentional > or accidental? Intentional, see https://features.opensuse.org/305694 and http://gitorious.org/opensuse/kernel-source/commit/c065c52q1 . > It breaks LXC which requires it. All other LXC options are enabled in > the desktop kernel but the one can't work without the other so you might > as well turn the other lxc options off also, or turn cgroup on. BTW, which are these options? > I'm checking now to see if the previous desktop kernel had cgroup or > not. I don't remember seeing this problem before, but I have only > started using lxc since 11.2 and I normally override the default and > install the now mis-named "default" kernel anyways so I don't know maybe > this has always been the case and maybe I only just now noticed. > > That said, regardless if the desktop kernel is intended or not, or > continues or not, to to include cgroup support, since there are packages > that depend on the feature, and there is no file I know of that can be > checked for in a spec file Requires: field, I think there should be a > flag in the spec/rpm files for the kernels that says they provide the > feature or not, so that other packages can say "Requires: cgroup" and > they don't care which specific kernel you install, merely that you are > running a kernel that includes the facility. There are ways to check the > running kernel of course like "grep cgroup /proc/filesystems" but I > don't think a spec file can be told to run a test like that as part of > the "requires:" field. Maybe %pre or %prein are the place for a test > like that? But putting a dependency in Requires: ensures that even when > the user goes to install some other kernel later after lxc is already > installed, if the new kernel is not also "kernel-default" rpm will > notice and try to either prevent the install or remove lxc along with > the old kernel to maintain a consistent system. The problem with userspace packages depending on certain kernel features or versions is that it doesn't really do what you want. You can express a dependency on an installed package, but what really matters is the running kernel, which rpm can't test for. Also if you depend on a certain kernel flavor (or some virtual capability provided by some flavors), the effect would be that the installer would install the desired kernel flavor _alongside_ with the "wrong" flavor, because different kernel flavors don't conflict with each other. Just something to keep in mind. > Currently for my own updated lxc package in build service home:aljex, > I am specifying "Requires: kernel-default" which is wrong but ensures > that lxc will work. And then I am also performing the /proc/filesystems > check at run-time in my lxc init script just to be sure. > > Thanks > Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

3 4

[opensuse-kernel] Pentium M (Dothan) not PAE?
by Stefan Seyfried 18 Feb '10

18 Feb '10

Hi, I wanted to try the kernel-desktop, but my machine failed to boot, telling me that I need a PAE-capable processor. It's a compaq nc6000 with a Pentium M 1.7GHz: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 13 model name : Intel(R) Pentium(R) M processor 1.70GHz stepping : 6 cpu MHz : 600.000 cache size : 2048 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov clflush dts acpi mmx fxsr sse sse2 ss tm pbe up bts est tm2 bogomips : 1196.27 clflush size : 64 cache_alignment : 64 address sizes : 32 bits physical, 32 bits virtual power management: I first thought "well, that's what you get for running old hardware" but then I noticed that the much older DELL C610 at home with an older Pentium III Mobile CPU is happily running a kernel-pae. So I'm wondering what's wrong with my Pentium M :) Thanks for any insight -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-kernel+help(a)opensuse.org

2 1