Why is the ipwireless driver disabled in intrepid?

fgrep IPWI /boot/config-2.6.27-4-generic gives
# CONFIG_IPWIRELESS is not set

I created a bug report
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/274748

but there is no response so far.

Thanks
Martin Capitanio

Re: Why is the ipwireless driver disabled in intrepid?

ubuntu <at> capitanio.org wrote:
> fgrep IPWI /boot/config-2.6.27-4-generic gives
> # CONFIG_IPWIRELESS is not set
> 
> I created a bug report
> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/274748
> 
> but there is no response so far.
> 
> Thanks
> Martin Capitanio
> 

Just an oversight. Its enabled now.

--

-- 
Tim Gardner tim.gardner <at> canonical.com

Re: include ext4

On Tue, Sep 30, 2008 at 02:06:47PM +0100, Scott James Remnant wrote:
> When do you expect ext4 to be stable enough to be a default?  I
> understood F10 to be shipping alongside 8.10, which implies 2.6.27 and
> it's still "in development" there?

Well, it helps that Eric Sandeen from Red Hat is fairly actively
working on ext4.  As far as I know, Fedora 10 isn't going to ship at
as the default, but they will be supporting it in their installer, and
I believe without needing some kind of magic boot option to the
installer. 

> Intrepid has 2.6.27 (rc6? but aiming for release), but only e2fsprogs
> 1.41.0.
> 
> How much would you recommend a version update of e2fsprogs, even if we
> don't do anything with ext4 -- I suspect the latter is unlikely, but
> something we could look into for 9.04

I just released e2fsprogs 1.41.2 this morning.  Most of the bug fixes
between v1.41.0 and v1.41.2 are ext4 specific, although there are a
lot of man page clarifications, updated translations that aren't in
1.41.0, etc.  There is also fixes to Launchpad bugs 246892, and
275272, as well as a host of minor bugs via Debian and Red Hat.

The really big bug fix which is in e2fsprogs 1.41.2 which I think
makes 1.41.2 worth fixes a regression since 1.40.7 which causes
"e2fsck -b 32768 /dev/XXX" to fail, which affects ext2, ext3, and ext4
filesystems that are corrupted badly enough that e2fsck may suggest to
the user to use the backup superblock via "e2fsck -b 32768" or "e2fsck
-b 8193".  In many cases e2fsck will just automatically fall back do

Re: include ext4

Thanks Ted,

After checking with the Release Manager, I think we'll pick up the new
e2fsprogs after beta.

Scott
-- 
Scott James Remnant
scott <at> canonical.com

Thanks Ted,

After checking with the Release Manager, I think we'll pick up the new
e2fsprogs after beta.

Scott
--

-- 
Scott James Remnant
scott <at> canonical.com

Uploaded Intrepid kernel linux_2.6.27-5.8

Note the ABI bump.

This kernel is based on 2.6.27-rc8 plus the e1000e patch from Intel that
protects EEPROM (also referred to as NV RAM) from getting trashed. I've
also switched the config options to use the upstream e1000e driver as
opposed to the SourceForge version in ubuntu/e1000e.

rtg
--

-- 
Tim Gardner tim.gardner <at> canonical.com

Re: Uploaded Intrepid kernel linux_2.6.27-5.8

Tim Gardner schrieb:
> Note the ABI bump.
>
> This kernel is based on 2.6.27-rc8 plus the e1000e patch from Intel that
> protects EEPROM (also referred to as NV RAM) from getting trashed. I've
> also switched the config options to use the upstream e1000e driver as
> opposed to the SourceForge version in ubuntu/e1000e.
>
> rtg
>   

Any chance you could include the complete changelog in future mails?

Re: Uploaded Intrepid kernel linux_2.6.27-5.8

does this mean that it's not only blacklisted, but now not blacklisted
and working?!

sorry, is the new e1000e patch a "fix" or workaround?  does it allow
baisc functionality of the device?  is it "safe"

Thank You

Michael Haas wrote:
> Tim Gardner schrieb:
>> Note the ABI bump.
>>
>> This kernel is based on 2.6.27-rc8 plus the e1000e patch from Intel that
>> protects EEPROM (also referred to as NV RAM) from getting trashed. I've
>> also switched the config options to use the upstream e1000e driver as
>> opposed to the SourceForge version in ubuntu/e1000e.
>>
>> rtg
>>   
> 
> Any chance you could include the complete changelog in future mails?
> 

Re: Uploaded Intrepid kernel linux_2.6.27-5.8

On Thu, 2008-10-02 at 18:04 +0200, Michael Haas wrote:

> Tim Gardner schrieb:
> > Note the ABI bump.
> >
> > This kernel is based on 2.6.27-rc8 plus the e1000e patch from Intel that
> > protects EEPROM (also referred to as NV RAM) from getting trashed. I've
> > also switched the config options to use the upstream e1000e driver as
> > opposed to the SourceForge version in ubuntu/e1000e.
> >
> > rtg
> >   
> 
> Any chance you could include the complete changelog in future mails?
> 
You can retrieve this from the intrepid-changes list once the package
has been approved.

Scott
--

-- 
Scott James Remnant
scott <at> canonical.com

On Thu, 2008-10-02 at 18:04 +0200, Michael Haas wrote:

> Tim Gardner schrieb:
> > Note the ABI bump.
> >
> > This kernel is based on 2.6.27-rc8 plus the e1000e patch from Intel that

SCSI patch

I posted earlier about a patch that allows me to connect to my Motorola phone (see
https://lists.ubuntu.com/archives/kernel-team/2008-September/thread.html) over usb. This
patch has now been included in the mainline kernel, with git commit ID
44ea91c597ae4641d9ac21b8bbba0795d2f4261e. Is there any chance this could be included?

(fwd) BUG: mmapfile/writev spurious zero bytes still in the wild

I should have just added you as CC.  I've tried reporting this via
launchpad, but it just keeps timing out on me again :(

I'm also CCing the user who reported the problem to me.  He's running
2.6.14-19-xen, but the problem exists in all 64 bit kernels in Ubuntu
if it exists in one.  This causes massive data corruption to Cyrus
running on kernels between 2.6.23 and 2.6.25.8.

You can read the full backthread here:

http://lkml.org/lkml/2008/6/17/9

Linus posted the patch here:

http://lkml.org/lkml/2008/6/17/234

And the fix was rolled into 2.6.25.8:

commit 864f24395c72b6a6c48d13f409f986dc71a5cf4a
Author: Linus Torvalds <torvalds <at> linux-foundation.org>
Date:   Tue Jun 17 17:47:50 2008 -0700

    x86-64: Fix "bytes left to copy" return value for copy_from_user()

    commit 42a886af728c089df8da1b0017b0e7e6c81b5335 upstream

    Most users by far do not care about the exact return value (they only
    really care about whether the copy succeeded in its entirety or not),
    but a few special core routines actually care deeply about exactly how
    many bytes were copied from user space.