[opensuse-factory] Kernel for 11.4?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion. Factory is currently using 2.6.36 which was released 3 weeks ago. Upstream versions tend to take about 10-11 weeks, on average, to release. The scheduled release for the first openSUSE RC is Jan 20. The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12. That sounds like kind of a tight window, but the reality is that the differences in the later kernel RCs tend to be small and fix bugs. The "real" development happens in -rc1, which was released about two weeks ago. Later -rcs serve to stabilize the development that went into -rc1. So, the the feature freeze aspect of it will be a one-shot, when I update to -rc1. (Actually, I hardly ever update to -rc1 and instead use - -rc2 which tends to be more stable). I've already done the merge work for 2.6.37-rc1 since the master kernel always tracks the latest upstream. Xen is the lone exception, as it usually is, but Jan Beulich has been great about getting that completed shortly after I do the update. This time might be a little more difficult because much of the Xen code has been merged into the mainline kernel so there's some sorting out to be done. As far as testing goes, we're still early enough that we won't lose a lot of effort. I'd update Factory to 2.6.37-rc2 as soon as it is released upstream, which should be this week. Our usual corps of dedicated testers can dig in quickly. In my experience, though, the number of testers drastically increases around the RC1 release. I wish it weren't so, but it is. So revving the kernel now isn't likely to toss out a lot of testing. The biggest "feature" I'm going for is not having to backport fixes from 2.6.37. The BKL removal patches and the VFS scalability patches are going to improve performance on multicore systems. The removal of I/O barriers should also be pretty noticeable but I haven't had time to verify that yet. So, opinions? - -Jeff Features that are going into 2.6.37: - - The inode portion of the VFS scalability patches - - More BKL removal, including parts of the core kernel - - Block I/O can be throttled via cgroups - - Simple pNFS support - - In-kernel PPTP (tunneling) acceleration - - "Lazy" inode table creation for ext4 to allow faster fs creation - - Batched discard support, which allows the file system to advise the block layer to use the TRIM command. This allows online TRIMs, but is only implemented in ext4 so far. - - Xen dom0 support (mostly) - - The usual round of bug fixes. - - fanotify - - Block barriers have been removed[1] Drivers: - - Systems and processors: - Flexibility Connect boards - Telechips TCC ARM926-based systems - Telechips TCC8000-SDK development kits - Vista Silicon Visstrim_m10 i.MX27-based boards - LaCie d2 Network v2 NAS boards - Qualcomm MSM8x60 RUMI3 emulators - Qualcomm MSM8x60 SURF eval boards - Eukrea CPUIMX51SD modules - Freescale MPC8308 P1M boards - APM APM821xx evaluation boards - Ito SH-2007 reference boards - IBM "SMI-free" realtime BIOS's - MityDSP-L138 and MityDSP-1808 systems - OMAP3 Logic 3530 LV SOM boards - OMAP3 IGEP modules - taskit Stamp9G20 CPU modules - aESOP Samsung S5PV210-based Torbreck boards - - Block: - Chelsio T4 iSCSI offload engines - Cypress Astoria USB SD host controllers - Marvell PXA168/PXA910/MMP2 SD host controllers - ST Microelectronics Flexible Static Memory Controllers - - Input: - Roccat Pyra gaming mice - UC-Logic WP4030U, WP5540U and WP8060U tablets - several varieties of Waltop tablets - OMAP4 keyboard controllers - NXP Semiconductor LPC32XX touchscreen controllers - Hanwang Art Master III tablets - ST-Ericsson Nomadik SKE keyboards - ROHM BU21013 touch panel controllers - TI TNETV107X touchscreens - - Miscellaneous: - Freescale eSPI controllers - Topcliff platform controllher hub devices - OMAP AES crypto accelerators - NXP PCA9541 I2C master selectors - Intel Clarksboro memory controller hubs - OMAP 2-4 onboard serial ports - GPIO-controlled fans - Linear Technology LTC4261 Negative Voltage Hot Swap Controller I2C interfaces - TI BQ20Z75 gas gauge ICs - OMAP TWL4030 BCI chargers - ROHM ROHM BH1770GLC and OSRAM SFH7770 combined ALS and proximity sensors - Avago APDS990X combined ALS and proximity sensors - Intersil ISL29020 ambient light sensors - Medfield Avago APDS9802 ALS sensor modules - Basic, memory-mapped GPIO controllers - Intel Topcliff GPIO controllers - Intel Moorestown/Medfield i2c controllers - IDT CPS Gen.2 SRIO RapidIO switches - Freescale i.MX DMA engines - ARM PrimeCell PL080 or PL081 DMA engines - Cypress West Bridge Astoria controllers - USB ENE card readers - Asahi Kasei AK8975 3-axis magnetometers - OLPC XO display controller devices - Analog Devices AD799x analog/digital converters - Winbond/Nuvoton W83795G/ADG hardware monitoring chips - Flarion OFDM usb and pcmcia modems - Maxim MAX8952 and MAX8998 Power Management ICs - National Semiconductors LP3972 PMIC regulators - Broadcom BCM63xx hardware watchdogs - - Network: - Brocade 1010/1020 10Gb Ethernet cards - Conexant CX82310 USB ethernet ports - Atheros AR9170 "otus" 802.11n USB devices - Topcliff PCH Gigabit Ethernet controllers - Intel Topcliff platform controller hub CAN interfaces - Technologic Systems TS-CAN1 PC104 peripheral boards - SBE wanPMC-2T3E3 interfaces - RealTek RTL8712U (RTL8192SU) Wireless LAN NICs (replaces older rtl8712 driver) - Atheros AR6003 wireless interface controllers - Beeceem USB Wimax adapters - Broadcom bcm43xx wireless chipsets - - Sound: - Marvell 88pm860x codecs - TI WL1273 FM radio codecs - HP iPAQ RX1950 audio devices - Native Instruments Traktor Kontrol S4 audio devices - Aztech Sound Galaxy AZT1605 and AZT2316 ISA sound cards - Wolfson Micro WM8985 and WM8962 codecs - Wolfson Micro WM8804 S/PDIF transceivers - Samsung S/PDIF controllers - Cirrus Logic EP93xx AC97 controllers - Intel MID SST DSP devices - - USB: Intel Langwell USB OTG transceivers - YUREX "leg shake" sensors - USB-attached SCSI devices - - Video4Linux2: remotes using the RC-5 (streamzap) protocol - Konica chipset-based cameras - Sharp IX2505V silicon tuners - LME2510 DM04/QQBOX USB DVB-S boxes - Samsung s5h1432 demodulators - Several new Conexant cx23417-based boards - Nuvoton w836x7hg consumer infrared transceivers - OmniVision OV6650 sensors - OMAP1 camera interfaces - Siliconfile SR030PC30 VGA cameras - Sony imx074 sensors - VIA integrated chipset camera controllers - -Jeff [1] This is because they were a very big hammer that had a reputation for killing performance. They're necessary for safely using journals on devices with write caching enabled, but were implemented by flushing the entire I/O queue to physical media -- not just "to disk" which includes the disk's write cache. The new implementation will still use the flush-to-media feature but will not stall the i/o queue. - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzhW0YACgkQLPWxlyuTD7JgBACbBfR+uJwfKKnEcBZIg/KeIj/S hikAnRiL9nG50QoKZkrn1AsmGljnGvYn =T/Hp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
I've often wondered if feature freeze so early as it is made much sense WRT the rapid pace of kernel development. It seems to me a later freeze for kernels than generally would be reasonable. Shouldn't kernel RC2 release 6 or more weeks prior to scheduled GA be enough? Maybe distro releasing should be scheduled the other way around, picking a GA date that would pick up the latest kernel before the next reaches RC1? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Nov 15, 2010 at 11:09:43AM -0500, Jeff Mahoney wrote:
Hi all -
Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion.
Factory is currently using 2.6.36 which was released 3 weeks ago. Upstream versions tend to take about 10-11 weeks, on average, to release. The scheduled release for the first openSUSE RC is Jan 20.
The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12.
I'd like to see this happen, so you have agreement from me to help accomplish this. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
I too vote for using 2.6.37 in 11.4. I have a biased view, but I consider the new drivers for wireless devices to be very important. In particular, brcm80211 supplies an open-source driver where none existed before for some new devices. It also marks the first time that Broadcom has provided open-source code. Another new driver, r8712u, is extremely stable, whereas the previous vendor driver for those devices was not. These drivers are available through Packman, but that entails all the disadvantages of out-of-kernel drivers. I have been running 2.6.37 since the post-2.6.36 merge started. I have found and reported a couple of small bugs, but nothing very serious. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 11/15/10, Larry Finger <Larry.Finger@lwfinger.net> wrote:
I too vote for using 2.6.37 in 11.4.
I have a biased view, but I consider the new drivers for wireless devices to be very important. In particular, brcm80211 supplies an open-source driver where none existed before for some new devices. It also marks the first time that Broadcom has provided open-source code. Another new driver, r8712u, is extremely stable, whereas the previous vendor driver for those devices was not. These drivers are available through Packman, but that entails all the disadvantages of out-of-kernel drivers.
I have been running 2.6.37 since the post-2.6.36 merge started. I have found and reported a couple of small bugs, but nothing very serious.
Larry
There's actually an openFATE entry for this. https://features.opensuse.org/310646 In the end, AJ says: == The Kernel:HEAD project will be updated with 2.6.37 once it stabilizes as usual and we will then decide whether to go for 2.6.37 or not. Let's not discuss this further here, it will be done after discussion on the opensuse-kernel mailing list - and I bet it's 2.6.37. == So it looks like at least from AJ's perspective its up to the kernel team to decide. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/15/2010 01:18 PM, Greg Freemyer wrote:
On 11/15/10, Larry Finger <Larry.Finger@lwfinger.net> wrote:
I too vote for using 2.6.37 in 11.4.
I have a biased view, but I consider the new drivers for wireless devices to be very important. In particular, brcm80211 supplies an open-source driver where none existed before for some new devices. It also marks the first time that Broadcom has provided open-source code. Another new driver, r8712u, is extremely stable, whereas the previous vendor driver for those devices was not. These drivers are available through Packman, but that entails all the disadvantages of out-of-kernel drivers.
I have been running 2.6.37 since the post-2.6.36 merge started. I have found and reported a couple of small bugs, but nothing very serious.
Larry
There's actually an openFATE entry for this.
https://features.opensuse.org/310646
In the end, AJ says:
== The Kernel:HEAD project will be updated with 2.6.37 once it stabilizes as usual and we will then decide whether to go for 2.6.37 or not. Let's not discuss this further here, it will be done after discussion on the opensuse-kernel mailing list - and I bet it's 2.6.37. ==
So it looks like at least from AJ's perspective its up to the kernel team to decide.
Agreed. Coolo also recommended posting to the list, so I did since it's technically it's a policy exception. BTW, I've posted my -rc1 merge build to my home:jeff_mahoney:nextkernel project. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzherIACgkQLPWxlyuTD7JieACbBll7cJxVs/aPBn5wMuYHAJID btsAn1jyT/MIOJVZaTuA6IpqQ8PQ+qdQ =M4g6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, 15 Nov 2010 11:09:43 -0500 Jeff Mahoney <jeffm@suse.com> wrote:
So, opinions?
I like it (but I'm running Kernel:HEAD all the time anyway, so for me it makes no difference ;)
Features that are going into 2.6.37:
- - Block I/O can be throttled via cgroups
YES! I Like it :)
Drivers: - Telechips TCC ARM926-based systems
Cool. Do we get the rest of the distro for ARM, too? (just kidding) -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Drivers: - Telechips TCC ARM926-based systems
Cool. Do we get the rest of the distro for ARM, too? (just kidding)
It seems to be getting some background effort at least. https://features.opensuse.org/310070 Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On 11/15/2010 10:29 PM, Stefan Seyfried wrote:
Drivers:
- Telechips TCC ARM926-based systems
Cool. Do we get the rest of the distro for ARM, too? (just kidding)
Well, ARM support would be nice. I use now an ARM smartbook: http://www.genesi-usa.com/products/smartbook but with Ubuntu at the moment. I'd be more happy with my usual openS.u.S.E. environment... Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 15/11/10 18:37, Peter Czanik escribió:
Well, ARM support would be nice. I use now an ARM smartbook: http://www.genesi-usa.com/products/smartbook but with Ubuntu at the moment. I'd be more happy with my usual openS.u.S.E. environment...
Have you found some box with more than 512 MB RAM ? because building a bunch of packages with it gotta be painful... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On 11/15/2010 11:45 PM, Cristian Rodríguez wrote:
El 15/11/10 18:37, Peter Czanik escribió:
Well, ARM support would be nice. I use now an ARM smartbook: http://www.genesi-usa.com/products/smartbook but with Ubuntu at the moment. I'd be more happy with my usual openS.u.S.E. environment...
Have you found some box with more than 512 MB RAM ? because building a bunch of packages with it gotta be painful...
First of all: you don't need to compile native on an ARM machine, the BS can easily cross compile it for you. For example MeeGo code first sees real ARM hardware only during installation, for compilation only x86 is used. Second: there is a new Debian ARM port ( http://wiki.debian.org/ArmHardFloatPort ) which was entirely built on a small cluster of similar ARM machines ( http://www.genesi-usa.com/products/efika ). Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 16/11/10 04:57, Peter Czanik escribió:
First of all: you don't need to compile native on an ARM machine, the BS can easily cross compile it for you.
The day we have _native_ hardware available to do this, I may commit time into this ARM port (reasons are explained in fate)
Second: there is a new Debian ARM port ( http://wiki.debian.org/ArmHardFloatPort ) which was entirely built on a small cluster of similar ARM machines ( http://www.genesi-usa.com/products/efika ).
We need a similar cluster then. ;) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 16/11/10 13:48, Cristian Rodríguez wrote:
El 16/11/10 04:57, Peter Czanik escribió:
First of all: you don't need to compile native on an ARM machine, the BS can easily cross compile it for you.
I've cross-built many kernels for the Angstrom port under openSUSE using the tools from http://www.codesourcery.com/sgpp/lite/arm/portal/release1294
The day we have _native_ hardware available to do this, I may commit time into this ARM port (reasons are explained in fate)
Only $179.00 US. http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=296%2D25798%2DND&Site=US&Lang=EN
Second: there is a new Debian ARM port ( http://wiki.debian.org/ArmHardFloatPort ) which was entirely built on a small cluster of similar ARM machines ( http://www.genesi-usa.com/products/efika ).
We need a similar cluster then. ;)
There is also a Ubuntu port. I'm running Ubuntu 10.10 on a Beagleboard C3. The plus is that I can build software much easier on it than I can using the Angstrom distribution. There is a Fedora port with an active mailing list but I've never seen reference to it on the beagleboard list, so it must be quite a niche port. It would be a big bonus if there was an openSUSE port. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 16/11/10 11:34, Sid Boyce escribió:
Only $179.00 US. http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=296%2D25798%2DND&Site=US&Lang=EN
Very Nice :-D though it still has 512 MB ram ! Im not going to spent time building/debugging whatever on a system with such little resources. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 16/11/10 15:00, Cristian Rodríguez wrote:
El 16/11/10 11:34, Sid Boyce escribió:
Only $179.00 US. http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=296%2D25798%2DND&Site=US&Lang=EN
Very Nice :-D though it still has 512 MB ram ! Im not going to spent time building/debugging whatever on a system with such little resources.
ARM is an important and significant embedded platform that now extends to netbooks which are becoming increasingly popular. Sure, it will require time but Fedora and Ubuntu have done it and done it well, especially well in the case of Ubuntu which I use. Even Ubuntu 10.10 runs well. I suspect that once the tools are there, the rest should be reasonably easy though I've not spent any time exploring how the other distros have done it. http://elinux.org/Toolchains may give some insight. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 16/11/10 17:03, Sid Boyce wrote:
On 16/11/10 15:00, Cristian Rodríguez wrote:
El 16/11/10 11:34, Sid Boyce escribió:
Only $179.00 US. http://search.digikey.com/scripts/DkSearch/dksus.dll?PName?Name=296%2D25798%2DND&Site=US&Lang=EN
Very Nice :-D though it still has 512 MB ram ! Im not going to spent time building/debugging whatever on a system with such little resources.
ARM is an important and significant embedded platform that now extends to netbooks which are becoming increasingly popular. Sure, it will require time but Fedora and Ubuntu have done it and done it well, especially well in the case of Ubuntu which I use. Even Ubuntu 10.10 runs well. I suspect that once the tools are there, the rest should be reasonably easy though I've not spent any time exploring how the other distros have done it. http://elinux.org/Toolchains may give some insight. Regards Sid.
http://infoworld.com/d/hardware/arm-readies-processing-cores-64-bit-computin... This will up the stakes. Will openSUSE be left behind and ruing the day? Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Nov 20, 2010 at 12:23:46AM +0000, Sid Boyce wrote:
http://infoworld.com/d/hardware/arm-readies-processing-cores-64-bit-computin...
This will up the stakes. Will openSUSE be left behind and ruing the day?
No. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 19/11/10 21:23, Sid Boyce escribió:
This will up the stakes. Will openSUSE be left behind and ruing the day? Regards Sid.
If some powerful system happends to be sold in the consumer market (hint, this announcements are vaporware), I will buy one and build the distribution myself :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hello, On 11/22/2010 08:55 PM, Cristian Rodríguez wrote:
El 19/11/10 21:23, Sid Boyce escribió:
This will up the stakes. Will openSUSE be left behind and ruing the day? Regards Sid.
If some powerful system happends to be sold in the consumer market (hint, this announcements are vaporware), I will buy one and build the distribution myself :-)
Here you go: http://www.linuxfordevices.com/c/a/News/PandaBoard/?kc=rss It's not the usual 512MB and single core machine, it's a 1GB dual core. Thank you for building the distribution for ARM! :) Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Nov 22, 2010 at 09:11:33PM +0100, Peter Czanik wrote:
Hello,
On 11/22/2010 08:55 PM, Cristian Rodríguez wrote:
El 19/11/10 21:23, Sid Boyce escribió:
This will up the stakes. Will openSUSE be left behind and ruing the day? Regards Sid.
If some powerful system happends to be sold in the consumer market (hint, this announcements are vaporware), I will buy one and build the distribution myself :-)
Here you go: http://www.linuxfordevices.com/c/a/News/PandaBoard/?kc=rss It's not the usual 512MB and single core machine, it's a 1GB dual core. Thank you for building the distribution for ARM! :)
I have one of these, and it's still a pretty underpowered machine compared to my many-year-old desktop. Nothing to fear just yet... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 22/11/10 21:26, Greg KH wrote:
On Mon, Nov 22, 2010 at 09:11:33PM +0100, Peter Czanik wrote:
Hello,
On 11/22/2010 08:55 PM, Cristian Rodríguez wrote:
El 19/11/10 21:23, Sid Boyce escribió:
This will up the stakes. Will openSUSE be left behind and ruing the day? Regards Sid.
If some powerful system happends to be sold in the consumer market (hint, this announcements are vaporware), I will buy one and build the distribution myself :-)
Here you go: http://www.linuxfordevices.com/c/a/News/PandaBoard/?kc=rss It's not the usual 512MB and single core machine, it's a 1GB dual core. Thank you for building the distribution for ARM! :)
I have one of these, and it's still a pretty underpowered machine compared to my many-year-old desktop. Nothing to fear just yet...
For mobile applications the small footprint of these boards is ideal, my Beagleboard C3 runs Ubuntu very well, KDE brings it to its knees starting up. No way would it be suitable for full desktop use, but for important one-off applications, it fits the bill, e.g for Software Defined Radio (SDR) it makes possible a very compact transceiver like the SDR-Cube and the BeagleBrick. Other complex single task operations can be supported, telemetry, firewalls, audiovisual streaming, etc. Another plus, with a small LCD screen, it beats lugging a desktop around hands down. One problem I saw with Ubuntu was a USB sound card was reporting lack of bandwidth when I tried using it with my SDR rig and I've yet to try the Beaglebrick Angstrom distribution. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
The email appended below was from back then. I have a couple of Beagleboards, a XM and a C3. I started off with the Angstrom distro but found it limited as far as supplied applications and building some applications proved to be a recursive build nightmare. I switched to Ubuntu and enjoy the full gamut of applications available for Intel/AMD. My preference as always would be for openSUSE on ARM. I am very pleased it's fuelled up and ready for engine start. Regards Sid. On 22/11/10 21:26, Greg KH wrote:
On Mon, Nov 22, 2010 at 09:11:33PM +0100, Peter Czanik wrote:
Hello,
On 11/22/2010 08:55 PM, Cristian Rodríguez wrote:
El 19/11/10 21:23, Sid Boyce escribió:
This will up the stakes. Will openSUSE be left behind and ruing the day? Regards Sid.
If some powerful system happends to be sold in the consumer market (hint, this announcements are vaporware), I will buy one and build the distribution myself :-)
Here you go: http://www.linuxfordevices.com/c/a/News/PandaBoard/?kc=rss It's not the usual 512MB and single core machine, it's a 1GB dual core. Thank you for building the distribution for ARM! :) I have one of these, and it's still a pretty underpowered machine compared to my many-year-old desktop. Nothing to fear just yet...
-- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 22/11/10 17:11, Peter Czanik escribió:
Here you go: http://www.linuxfordevices.com/c/a/News/PandaBoard/?kc=rss It's not the usual 512MB and single core machine, it's a 1GB dual core. Thank you for building the distribution for ARM! :)
Cool :) that's is certainly getting near to what I would buy for hacking .. 1GB RAM is still very little to build stuff.. let's say hrmmm.. 3 or 4Gb.. is fine for me .. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 15/11/10 13:09, Jeff Mahoney escribió:
- Batched discard support, which allows the file system to advise the block layer to use the TRIM command. This allows online TRIMs, but is only implemented in ext4 so far.
Yeah, because in current kernel:head not even "discard" works see bnc#646863 btw.. any hope of getting bnc#647554 fixed ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Nov 15, 2010 at 2:43 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 15/11/10 13:09, Jeff Mahoney escribió:
- Batched discard support, which allows the file system to advise the block layer to use the TRIM command. This allows online TRIMs, but is only implemented in ext4 so far.
Yeah, because in current kernel:head not even "discard" works see bnc#646863
btw.. any hope of getting bnc#647554 fixed ?
Even in 2.6.37, it's a barely useful feature. The ATA spec. allows for the TRIM command to have a payload of numerous trim ranges. The 2.6.37 ext4 kernel implementation only sends one range at a time (except for very large ranges which are broken into multiple contiguous ranges and sent in one TRIM payload). Because TRIM causes the SSD to flush its cache, having one command per range is still very ineffective, and the benchmarks show it is not a major performance win. OTOH, the userspace hdparm / wiper.sh pair do a great job and fully leverage the multiple ranges per TRIM command. Unfortunately, the hdparm / wiper.sh scripts don't support software raid or LVM setups while the kernel implementation does. So I would only advise using the kernel TRIM feature in those 2 limited environments. See: http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 15/11/10 19:56, Greg Freemyer escribió:
Unfortunately, the hdparm / wiper.sh scripts don't support software raid or LVM setups while the kernel implementation does.
There is a version that supports LVM, and used it with success, until I apparently mispatched it and got my information nicely destroyed :-D -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Nov 15, 2010 at 3:00 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 15/11/10 19:56, Greg Freemyer escribió:
Unfortunately, the hdparm / wiper.sh scripts don't support software raid or LVM setups while the kernel implementation does.
There is a version that supports LVM, and used it with success, until I apparently mispatched it and got my information nicely destroyed :-D
Cristian, LVM support is good news. I googled and found this from May: http://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684 It says: "This currently only supports linear logical volumes on top of a single device (i.e. no striped, mirrored, or concatenated volumes)" If that is still the current state, I hesitate to call that LVM support. Most if not all the LVM setups I've ever made had more than a single device. Do you have reason to think it now supports more than that? Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 15/11/10 20:14, Greg Freemyer escribió:
It says: "This currently only supports linear logical volumes on top of a single device (i.e. no striped, mirrored, or concatenated volumes)"
If that is still the current state, I hesitate to call that LVM support.
It fits my needs, though I must assure not to hack into it again without a large dose of coffee ;)
Do you have reason to think it now supports more than that?
No. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Nov 15, 2010 at 09:09, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi all -
Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion.
Factory is currently using 2.6.36 which was released 3 weeks ago. Upstream versions tend to take about 10-11 weeks, on average, to release. The scheduled release for the first openSUSE RC is Jan 20.
The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12.
That sounds like kind of a tight window, but the reality is that the differences in the later kernel RCs tend to be small and fix bugs. The "real" development happens in -rc1, which was released about two weeks ago. Later -rcs serve to stabilize the development that went into -rc1. So, the the feature freeze aspect of it will be a one-shot, when I update to -rc1. (Actually, I hardly ever update to -rc1 and instead use - -rc2 which tends to be more stable).
I've already done the merge work for 2.6.37-rc1 since the master kernel always tracks the latest upstream. Xen is the lone exception, as it usually is, but Jan Beulich has been great about getting that completed shortly after I do the update. This time might be a little more difficult because much of the Xen code has been merged into the mainline kernel so there's some sorting out to be done.
As far as testing goes, we're still early enough that we won't lose a lot of effort. I'd update Factory to 2.6.37-rc2 as soon as it is released upstream, which should be this week. Our usual corps of dedicated testers can dig in quickly. In my experience, though, the number of testers drastically increases around the RC1 release. I wish it weren't so, but it is. So revving the kernel now isn't likely to toss out a lot of testing.
The biggest "feature" I'm going for is not having to backport fixes from 2.6.37. The BKL removal patches and the VFS scalability patches are going to improve performance on multicore systems. The removal of I/O barriers should also be pretty noticeable but I haven't had time to verify that yet.
So, opinions?
- -Jeff
Another thing to take into consideration is what the other distributions are going to include. My guess is that they will be using 2.6.37 which if that's the case will see more testing than 2.6.36. Stephen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff, thanks for asking for an exception. I agree with others and suggest to grant the exception since the kernel will stabilize now, Andreas -- Andreas Jaeger, Program Manager openSUSE, aj@{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 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 15 November 2010 11:09:43 Jeff Mahoney wrote:
Hi all -
Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion.
The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12.
Hi Jeff, I tried yesterday based on your message the 2.6.37-rc1 vanilla kernel from Kernel:vanilla. I am not sure how this particular kernel compares to the standard kernel-desktop, but I noticed that again the Intel driver has issues. I am running Factory on my Lenovo Notebook (T410 with Intel HD graphics 5700MHD) with KDE desktop and desktop effects enabled. This system is very fast with its graphics and effects. Switching to the 2.6.37-rc1 kernel delivered me a desktop with very slow effects. Dragging a window from one corner to the next delivered the effect that the Mouse was at the other corner and the window that was dragged followed a couple of seconds later. It could be of course that this will still improve with the upcoming RC's, but IMHO we should be very carefull with this as this could damage the openSUSE image for intel graphics users. Bear in mind that the initial 11.3 distribution was unusable for intel graphics users due to the combination of the new KMS and Xorg drivers. Let's get this kernel build according to openSUSE standards and having it tested by as many users as possible before the decision is taken to make this the standard kernel for the upcoming 11.4 just my five cents :-) Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Mandag den 15. november 2010 17:09:43 skrev Jeff Mahoney:
Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion.
Factory is currently using 2.6.36 which was released 3 weeks ago. Upstream versions tend to take about 10-11 weeks, on average, to release. The scheduled release for the first openSUSE RC is Jan 20.
The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12.
I really don't follow kernel development anywhere near enough to have an informed opinion on 2.6.36 vs. 2.6.37. But I can say this, the 2.6.34 in 11.3 caused a lot of problems for many people with basic things like shutting down or rebooting on many machines - often machines which worked fine with older kernels. So we definitely don't want something like that to happen again. Beforehand I had thought 11.3 was poised for success having a newer kernel than Ubuntu, Mandriva and Fedora at the time - but it turned out not to be an advantage at all - au contraire. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Tue, Nov 16, 2010 at 10:55:32AM +0100, Martin Schlander wrote:
Mandag den 15. november 2010 17:09:43 skrev Jeff Mahoney:
Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion.
Factory is currently using 2.6.36 which was released 3 weeks ago. Upstream versions tend to take about 10-11 weeks, on average, to release. The scheduled release for the first openSUSE RC is Jan 20.
The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12.
I really don't follow kernel development anywhere near enough to have an informed opinion on 2.6.36 vs. 2.6.37.
But I can say this, the 2.6.34 in 11.3 caused a lot of problems for many people with basic things like shutting down or rebooting on many machines - often machines which worked fine with older kernels. So we definitely don't want something like that to happen again.
Beforehand I had thought 11.3 was poised for success having a newer kernel than Ubuntu, Mandriva and Fedora at the time - but it turned out not to be an advantage at all - au contraire.
It is always hit or miss :/ Ciao, Marcus -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Monday 15 November 2010 17:09:43 schrieb Jeff Mahoney:
Hi all -
Since technically we're in feature freeze for 11.4, I thought I'd put this out for discussion.
Factory is currently using 2.6.36 which was released 3 weeks ago. Upstream versions tend to take about 10-11 weeks, on average, to release. The scheduled release for the first openSUSE RC is Jan 20.
The scheduled release for the first RC is Jan 20. The typical development time for a kernel release, on average, is about 10-11 weeks. That puts the release of 2.6.37 around Dec 29 to Jan 12.
That sounds like kind of a tight window, but the reality is that the differences in the later kernel RCs tend to be small and fix bugs. The "real" development happens in -rc1, which was released about two weeks ago. Later -rcs serve to stabilize the development that went into -rc1. So, the the feature freeze aspect of it will be a one-shot, when I update to -rc1. (Actually, I hardly ever update to -rc1 and instead use -rc2 which tends to be more stable).
I've already done the merge work for 2.6.37-rc1 since the master kernel always tracks the latest upstream. Xen is the lone exception, as it usually is, but Jan Beulich has been great about getting that completed shortly after I do the update. This time might be a little more difficult because much of the Xen code has been merged into the mainline kernel so there's some sorting out to be done.
As far as testing goes, we're still early enough that we won't lose a lot of effort. I'd update Factory to 2.6.37-rc2 as soon as it is released upstream, which should be this week. Our usual corps of dedicated testers can dig in quickly. In my experience, though, the number of testers drastically increases around the RC1 release. I wish it weren't so, but it is. So revving the kernel now isn't likely to toss out a lot of testing.
Thank you for providing new 2.6.37-rc2. I need this kernel for my TV-usb-Card. I have installed it from kernel:head on my OS11.3 laptop. But the system does not start with the 2.6.37 series. I have also testet 2.6.37-rc1 vanilla. On my desktop machine ( with 11.2) it works perfekt. Shall I open a bug-report? But I have no idea what to report. After Grub there comes nothing. What can I try further? Daniel
participants (15)
-
Andreas Jaeger -
Cristian Rodríguez -
Daniel Fuhrmann -
Felix Miata -
Greg Freemyer -
Greg KH -
Jeff Mahoney -
Larry Finger -
Marcus Meissner -
Martin Schlander -
Peter Czanik -
Raymond Wooninck -
Sid Boyce -
Stefan Seyfried -
Stephen Shaw