Bug#311221: Zaurus no longer connects

[Adam Majer]

Package: kernel-source-2.6.11
Version: 2.6.11-5
Severity: normal

After upgrading the kernel to 2.6.11-5 version, Zaurus (OpenZaurus) 
can no longer connect via USB,

usb 3-2: new full speed USB device using uhci_hcd and address 3
usb 3-2: device descriptor read/64, error -32
usb 3-2: device descriptor read/64, error -32
usb 3-2: new full speed USB device using uhci_hcd and address 4
usb 3-2: device descriptor read/64, error -32
usb 3-2: device descriptor read/64, error -32

It works with 2.6.10 kernel as well as earlier versions of the 2.6.11.

- Adam


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11-1-k7
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)

Versions of packages kernel-source-2.6.11 depends on:
ii  binutils  2.15-6 The GNU assembler, linker and bina
ii  bzip2 1.0.2-7high-quality block-sorting file co
ii  coreutils [fileutils] 5.2.1-2The GNU core utilities


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#309909: kernel-image-2.6-686-smp: acpi + rtc causes hang on debian boot

[Horms]

On Fri, May 20, 2005 at 01:55:07PM +0200, juan wrote:
> Package: kernel-image-2.6-686-smp
> Severity: important
> 
> 
> open /dev/rtc hangs for ever, a simple fix is to boot without acpi.
> since the init process uses hwclock, the system is hung forever on boot

Smells like a dell box with a broken rtc. 
Please try adding the --directisa option to your
invocation of hwclock and see if that helps.
Or prehaps replace hwclock with a script that
calls the original binary with --directisa

e.g.

mv /sbin/hwclock /sbin/hwclock.i.love.dell
echo 'exec /sbin/hwclock --directisa $@' > /sbin/hwclock
chmod 755 /sbin/hwclock

I believe that newer versions of hwclock implent a timeout 
mechanism to get around this problem, wherby it tries to
access the rtc, if after a short time there is no response 
it tries the --directisa codepath.

Can you let me know if this resolves your problem?
If it does then unfortunately what you have is a hardware
bug and the rtc maintaner has advised me that he is
quite comfortable with the current userspace workarounds
available and has no intention to play games in the kernel
to get around this. In short he doesn't believe its a
kernel bug, and I tend to agree.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Sarge 2.6.8 kernel suitable for NFS?

[Horms]

On Fri, May 20, 2005 at 07:29:43AM +0200, Arne Nordmark wrote:
> From the discussion regarding whether to stick with 2.6.8 in sarge 
> , one gets 
> the impression that there are NFS problems in the sarge 2.6.8 kernel. 
> Are these severe enough to not recommend this kernel for NFS server 
> and/or client use?

I believe so.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#309865: fails to restart from init.d/hotplug restart, and unable to deal with memory card reader

[Horms]

On Fri, May 20, 2005 at 11:33:08AM +0200, Marco d'Itri wrote:
> reassign 309865 kernel-image-2.6.8-i386
> thanks
> 
> On May 20, John Shin <[EMAIL PROTECTED]> wrote:
> 
> > 1 gig). When I
> > boot the pc with the card inserted, it is correctly
> > recognized and
> > correct device name is created under /dev/sdd1. Also,
> > when the computer
> > is already started, if I plug in the card, it usually
> > detects and
> > correct device name is created about 80% of the time.
> This looks like a kernel issue to me.

Could you provide the output of dmsg and relevant portions of
/var/log/syslog (or wherever udev logs its stuff) for a time
when it works and a time when it doesn't?



-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: [SUMMARY] RFC: New uniform packaging scheme

[Horms]

On Wed, May 25, 2005 at 08:10:01AM +0200, Sven Luther wrote:
> On Tue, May 24, 2005 at 09:55:31PM -0400, Jurij Smakov wrote:
> > Any thoughts and ideas on this are welcome. As soon as the discussion is 
> > settled, I'll try to write up the results in some more or less permanent 
> > location.
> 
> Also, it would be nice if we could aim at 2.6.12 for this, not sure if the
> release will be too early or something though ? 

Yes, that would be nice indeed.

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Kernel Modules for PE2850 in default i386 2.6 kernel builds.

[Horms]

On Fri, May 27, 2005 at 09:13:00PM -0400, Satadru Pramanik wrote:
> I'm more than willing to test some images out.
> 
> Thanks.
> 
> satadru

I have put the images and source up at http://debian.vergenet.net/testing/
The debian version is 5.hls.2005052700

> -Original Message-
> From: Horms <[EMAIL PROTECTED]>
> Date: Friday, May 27, 2005 8:02 pm
> Subject: Re: Kernel Modules for PE2850 in default i386 2.6 kernel builds.
> 
> On Thu, May 19, 2005 at 05:13:08PM +0200, Achim Bohnet wrote:
> > On Thursday 19 May 2005 16:37, Satadru Pramanik wrote:
> > > I am setting up a Dell PowerEdge 2850 with Debian/Sarge and noticed  
> > > that I can install with a sarge installation cd
> > > using kernel 2.4.x, but I can not install with the debian 2.6.x  
> > > kernels, nor update to a debian 2.6.x kernel that will support
> > > the built in scsi hardware.
> > > 
> > > The problem lies in the LSI SCSI cards masquerading as PERC cards  
> > > inside the machine using the megaraid2 driver
> > > on 2.4.x, and on 2.6 using the megaraid_newgen and megaraid_mailbox  
> > > drivers.
> > > 
> > > Is there any chance the following drivers could be compiled in as  
> > > modules for 2.6.11-x-686-smp?
> > > 
> > > CONFIG_MEGARAID_NEWGEN
> > > CONFIG_MEGARAID_MM
> > > CONFIG_MEGARAID_MAILBOX
> > 
> > I would like to see this addition too.
> > 
> > > These are already in the default config for 2.6.11-x-em64t-p4-smp.
> > 
> > An additional note:  the -em64t-p4-smp kernel can also be used
> > on Dells PE2850, BUT there are some user 32/kernel 64 bit IPMI
> > problems in the 2.6.11 em64t that make it no good default choice.
> > [Hopefully the fixes get merged before 2.6.12.]
> > 
> > > Compiling a kernel for myself hasn't been a problem, but for the  
> > > corporate minded, it is easier to sell a
> > > debian install (as opposed to RedHat) to a client by showing them  
> > > that a stock debian 32 bit 2.6 kernel
> > > that has gone through the debian vetting process supports their system.
> > 
> > I can confirm this, we have this discussion here.
> 
> That sounds fine to me. I have put it into SVN and will do some test builds. 
> I'll make them available when they are done (likely over the weekend), 
> testing would be appreciated.
> 
> -- 
> Horms
> 

-- 
Horms


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#310982: smbmount does not honor uid and gid options with 2.4 kernel

[Andrew Bartlett]

On Sun, 2005-05-29 at 01:44 -0700, Steve Langasek wrote:
> On Sat, May 28, 2005 at 11:45:23PM +0200, Bill Allombert wrote:
> > On Sat, May 28, 2005 at 02:07:04PM -0700, Steve Langasek wrote:
> > > On Sat, May 28, 2005 at 06:39:28PM +0200, Bill Allombert wrote:
> > > > On Fri, May 27, 2005 at 12:20:49PM -0700, Steve Langasek wrote:
> > > > > On Sat, May 28, 2005 at 05:17:39AM +1000, Andrew Bartlett wrote:
> > > > > Yeah, on second look I see that it can be done in smbmount, and this 
> > > > > would
> > > > > be a far more expedient fix.
> 
> > > > You mean something like the patch below ?
> > > > (Not tested yet, want to be sure this is the idea)
> 
> > > I would've uploaded such a fix already, but upstream objects to this 
> > > because
> > > doing this in userspace instead of in the kernel means losing the other
> > > features of CAP_UNIX -- which are, uh, symlinks and pipes, basically.  I'm
> > > not really convinced that symlinks and pipes are important enough for 
> > > people
> > > who are using existing mounts with uid or gid smashing to warrant shipping
> 
> > I am obviously biased since I spend a whole night trying to track down this
> > problem, but I think that people interested in CAP_UNIX will have moved
> > to kernel 2.6 and cifs. At that point it seems unlikely that kernel 2.4
> > will be ever fixed, in Debian or in mainline.
> 
> > It is a very nasty security problem: The server can change the security
> > model of the client by enabling unix capability ! This can be used to
> > compromise the client if the server is compromised.  
> 
> Yes, I certainly agree that it's bad, and I'm really leaning towards the
> position that the security implications for users upgrading from woody
> outweigh upstream's desire for the other features to Just Work.  Even
> *those* are a behavior change, and arguably not an automatic win for all
> users.
> 
> > One option would be to check if the host run a 2.4 kernel or a 2.6 kernel
> > and only apply the correction for 2.4 kernel. (It is my understanding
> > that 2.6 kernels do not have this problem, though I did not try);
> 
> Well, most people using 2.6 kernels are likely to be using cifs instead of
> smbfs anyway (due to smbfs's general bitrot in 2.6 last I looked at it), so
> I'm not sure that addresses upstream's objections.

I suggest you raise this on the samba-technical list, to get a broader
viewpoint of what 'upstream' might think.  

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org
Student Network Administrator, Hawker College  http://hawkerc.net


signature.asc
Description: This is a digitally signed message part

Bug#277942: marked as done (issues with IPv6)

[Debian Bug Tracking System]

Your message dated Sun, 29 May 2005 23:18:20 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Appears to be fixed in the mean time
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 23 Oct 2004 15:39:42 +
>From [EMAIL PROTECTED] Sat Oct 23 08:39:42 2004
Return-path: <[EMAIL PROTECTED]>
Received: from gateway.nixsys.be [195.144.77.33] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1CLNza-000205-00; Sat, 23 Oct 2004 08:39:42 -0700
Received: from folk.grep.be (cl-grep.tunnel.nixsys.be 
[IPv6:2001:838:37f:abcd::4])
by gateway.nixsys.be (Postfix) with ESMTP id DDEC079
for <[EMAIL PROTECTED]>; Sat, 23 Oct 2004 17:39:38 +0200 (CEST)
Received: from western.grep.be ([192.168.119.16])
by folk.grep.be with esmtp (Exim 4.34 1 (Debian))
id 1CLNvM-00011C-Nw
for <[EMAIL PROTECTED]>; Sat, 23 Oct 2004 17:35:45 +0200
Received: from wouter by western.grep.be with local (Exim 4.34)
id 1CLNeF-Yu-Kh; Sat, 23 Oct 2004 17:17:39 +0200
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Wouter Verhelst <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: issues with IPv6
X-Mailer: reportbug 2.63
Date: Sat, 23 Oct 2004 17:17:39 +0200
Message-Id: <[EMAIL PROTECTED]>
Sender: "Wouter Verhelst,,+32 15 27 69 50,+32 3 542 35 14," <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2004_03_25
X-Spam-Level: 

Package: kernel-image-2.4.27-1-sparc64
Version: 2.4.27-1
Severity: important

Hi,

The above kernel image seems to be broken with regard to IPv6 support.

If I load the ipv6 module from /etc/modules, the kernel will end up in
a looped Oops once slapd starts (so badly that Stop-A doesn't even work
anymore). If I load it later, either manually or from a script which is
ran from init, then the system works, but it has now panic()ed on at
least two occasions when it was running for a few days.

The kernel regularly spawns the following messages:

Oct 23 14:14:47 localhost kernel: hw tcp v6 csum failed
Oct 23 14:14:48 localhost kernel: hw tcp v6 csum failed
Oct 23 14:17:07 localhost kernel: hw tcp v4 csum failed
Oct 23 14:22:25 localhost kernel: hw tcp v4 csum failed
Oct 23 14:22:56 localhost kernel: hw tcp v4 csum failed
Oct 23 14:23:53 localhost kernel: hw tcp v4 csum failed
Oct 23 14:26:25 localhost kernel: hw tcp v4 csum failed
Oct 23 14:32:09 localhost kernel: hw tcp v4 csum failed

this seems especially true during moments of high network traffic.

It should be noted that my system is an Ultra10 with a Happy Meal
network card; that my network is mainly a 10Mbit BNC one, but the
Ultra10 is connected to an el cheapo hub with a BNC connector.

If any further information is required, please ask.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: sparc (sparc64)
Kernel: Linux 2.4.27-1-sparc64
Locale: LANG=nl_BE, LC_CTYPE=nl_BE

Versions of packages kernel-image-2.4.27-1-sparc64 depends on:
ii  initrd-tools  0.1.74 tools to create initrd image for p

-- no debconf information

---
Received: (at 277942-done) by bugs.debian.org; 29 May 2005 21:18:33 +
>From [EMAIL PROTECTED] Sun May 29 14:18:33 2005
Return-path: <[EMAIL PROTECTED]>
Received: from asia.telenet-ops.be [195.130.132.59] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DcVB3-0005bp-00; Sun, 29 May 2005 14:18:33 -0700
Received: from localhost (localhost.localdomain [127.0.0.1])
by asia.telenet-ops.be (Postfix) with SMTP id 06E742240DA
for <[EMAIL PROTECTED]>; Sun, 29 May 2005 23:18:31 +0200 (MEST)
Received: from western.grep.be (dD5E0678D.access.telenet.be [213.224.103.141])
by asia.telenet-ops.be (Postfix) with ESMTP id EA7D9224098
for <[EMAIL PROTECTED]>; Sun, 29 May 2005 23:18:30 +0200 (MEST)
Received: from [2001:838:37f:20:20d:93ff:fec0:b54a] (helo=grep.be)
by western.grep.be with esmtp (Exim 4.50)
id 1DcVB0-0004HD-Ei
for [EMAIL PROTECTED]
message size 1005; Sun, 29 May 2005 23:18:30 +0200
Received: from wouter by grep.be with local (Exim 4.

Bug#311210: kernel-image-2.6.11-i386: Please add RF Monitor mode for orinoco_cs drivers

[Simon Law]

Package: kernel-image-2.6.11-i386
Version: N/A; reported 2005-05-29
Severity: wishlist

Please add the RF Monitor patches for the Orinoco wireless drivers.  It
would make life more pleasant if you did, because then I'd be able to
find local access points without having to rebuild the kernel.

This functionality is there for most other drivers, but it won't land in
2.6 for a very long time.  *sigh*

You can find a patch for 2.6.11 at
http://www.kismetwireless.net/download.shtml#orinoco2611
Previous versions are also available on that page.

Thanks,
Simon

-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux alps 2.4.18-1-686 #1 Wed Apr 14 18:20:10 UTC 2004 i686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#311187: kernel-image-2.6.8-2-k7: kernel panic when removing external usb storage (LG GSA-4040B in Sarotech MyBox 5.25 in.)

[Martin]

Package: kernel-image-2.6.8-2-k7
Version: 2.6.8-13
Severity: normal


Here comes the kernel panic as an extract of /var/log/kern.log:

May 29 15:35:03 speedy kernel: usb 6-5.4: USB disconnect, address 5
May 29 15:35:08 speedy kernel: scsi: Device offlined - not ready after
error recovery: host 1 channel 0 id 0 lun 0
May 29 15:35:08 speedy kernel: sr 1:0:0:0: Illegal state transition
cancel->offline
May 29 15:35:08 speedy kernel: Badness in scsi_device_set_state at
drivers/scsi/scsi_lib.c:1643
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+740807/5541136]
scsi_device_set_state+0xc6/0x120 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+730901/5541136]
scsi_eh_offline_sdevs+0x64/0x80 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732477/5541136]
scsi_unjam_host+0xcc/0x200 [scsi_mod]
May 29 15:35:08 speedy kernel:  [default_wake_function+0/32]
default_wake_function+0x0/0x20
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+733044/5541136]
scsi_error_handler+0x103/0x1c0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732785/5541136]
scsi_error_handler+0x0/0x1c0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [kernel_thread_helper+5/20]
kernel_thread_helper+0x5/0x14
May 29 15:35:08 speedy kernel: Badness in kobject_get at
lib/kobject.c:433
May 29 15:35:08 speedy kernel:  [kobject_get+76/80]
kobject_get+0x4c/0x50
May 29 15:35:08 speedy kernel:  [get_device+24/48] get_device+0x18/0x30
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+738582/5541136]
scsi_request_fn+0x25/0x400 [scsi_mod]
May 29 15:35:08 speedy kernel:  [blk_insert_request+186/224]
blk_insert_request+0xba/0xe0
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+734026/5541136]
scsi_queue_insert+0x89/0xd0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732146/5541136]
scsi_eh_flush_done_q+0x71/0xf0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732425/5541136]
scsi_unjam_host+0x98/0x200 [scsi_mod]
May 29 15:35:08 speedy kernel:  [default_wake_function+0/32]
default_wake_function+0x0/0x20
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+733044/5541136]
scsi_error_handler+0x103/0x1c0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732785/5541136]
scsi_error_handler+0x0/0x1c0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [kernel_thread_helper+5/20]
kernel_thread_helper+0x5/0x14
May 29 15:35:08 speedy kernel: Unable to handle kernel paging request at
virtual address 00100104
May 29 15:35:08 speedy kernel:  printing eip:
May 29 15:35:08 speedy kernel: f89c6a70
May 29 15:35:08 speedy kernel: *pde = 
May 29 15:35:08 speedy kernel: Oops: 0002 [#1]
May 29 15:35:08 speedy kernel: PREEMPT 
May 29 15:35:08 speedy kernel: Modules linked in: isofs st sg sr_mod
snd_mixer_oss lp ipv6 ide_cd cdrom pcspkr tsdev mousedev evdev psmouse
floppy parport_pc parport via_ircc irda crc_ccitt tulip auerswald sd_mod
ohci_hcd ehci_hcd usblp uhci_hcd snd_cmipci snd_pcm snd_page_alloc
snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi
snd_seq_device snd pci_hotplug via_agp agpgart capability commoncap
reiserfs dm_mod hci_usb bluetooth usb_storage scsi_mod cmpci soundcore
gameport nvidia dmfe usbkbd usbcore asus_acpi ac genrtc ext3 jbd mbcache
ide_generic via82cxxx ide_disk ide_core unix font vesafb cfbcopyarea
cfbimgblt cfbfillrect
May 29 15:35:08 speedy kernel: CPU:0
May 29 15:35:08 speedy kernel: EIP:
0060:[__crc_pm_idle+748529/5541136]Tainted: P  
May 29 15:35:08 speedy kernel: EFLAGS: 00010002   (2.6.8-2-k7) 
May 29 15:35:08 speedy kernel: EIP is at
scsi_device_dev_release+0x30/0x110 [scsi_mod]
May 29 15:35:08 speedy kernel: eax: 00100100   ebx: f25e3008   ecx:
00200200   edx: f25e3184
May 29 15:35:08 speedy kernel: esi: f25e3000   edi: 0282   ebp:
f7fa92b4   esp: e01a7ea8
May 29 15:35:08 speedy kernel: ds: 007b   es: 007b   ss: 0068
May 29 15:35:08 speedy kernel: Process scsi_eh_1 (pid: 4652,
threadinfo=e01a6000 task=cfaae640)
May 29 15:35:08 speedy kernel: Stack:  f25e31a8 c02fb448
c02fb460 f7fa92d8 c01f4458 f25e3184 f25e31a8 
May 29 15:35:08 speedy kernel:c02fb448 c02fb460 c01a3d68
f25e31a8 e01a6000 f25e3000 e01a6000 e01a6000 
May 29 15:35:08 speedy kernel:f89c4592 f25e31a8 f7a3c4b0
f25e3000 f7a3c4b0 f25e3184 f7a3c4b0 f25e3000 
May 29 15:35:08 speedy kernel: Call Trace:
May 29 15:35:08 speedy kernel:  [device_release+88/96]
device_release+0x58/0x60
May 29 15:35:08 speedy kernel:  [kobject_cleanup+152/160]
kobject_cleanup+0x98/0xa0
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+739091/5541136]
scsi_request_fn+0x222/0x400 [scsi_mod]
May 29 15:35:08 speedy kernel:  [blk_insert_request+186/224]
blk_insert_request+0xba/0xe0
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+734026/5541136]
scsi_queue_insert+0x89/0xd0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732146/5541136]
scsi_eh_flush_done_q+0x71/0xf0 [scsi_mod]
May 29 15:35:08 speedy kernel:  [__crc_pm_idle+732425/5541136]
scsi_unjam_host+0x98/0x200 [scsi_mod]
May 29 15:35:08 speedy kernel:  [default_wake_function+0/32]

Re: kernel updates accepted for sarge

[Steve Langasek]

On Sun, May 29, 2005 at 04:07:00PM +0200, Holger Levsen wrote:
> please respect reply-to: - thanks.

> On Sunday 29 May 2005 06:57, Steve Langasek wrote:
> > Thanks to some fancy last-minute archive work by James Troup, we now have a
> > solution that lets us get security-fixed kernels into sarge r0 (instead of
> > just into security.d.o) without running into GPL problems with
> > debian-installer.

> Great, thanks! 

> (But) AFAIUI, fai-kernels also has to be rebuild now. (It's i386 only at the 
> moment.)

> This means it needs a new upload, as the build depends in the control file 
> has 
> to be changed from kernel-tree-2.6.8-15 and kernel-tree-2.4.27-8 to -16 and 
> -10.

> Or do I misunderstand something ?

If you are build-depending on kernel-tree-2.6.8-15 and kernel-tree-2.4.27-8,
this means that you are ensuring in your debian/rules that you get those
exact patch levels of the tree, right?  In that case, there is no license
requirement that you rebuild against the latest trees; it would be
appreciated if you did so in order to remove one more TODO item from the
security team's list.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#311164: CAN-2005-0757: DoS possibility in xattrs handling on 64 bits archs

[Moritz Muehlenhoff]

Package: kernel-source-2.4.27
Severity: important
Tags: security

Quoting from http://rhn.redhat.com/errata/RHSA-2005-294.html:
A flaw in offset handling in the xattr file system code backported to
Red Hat Enterprise Linux 3 was fixed. On 64-bit systems, a user who
can access an ext3 extended-attribute-enabled file system could cause
a denial of service (system crash). This issue is rated as having a
moderate security impact (CAN-2005-0757).

I couldn't find further information on whether this is already fixed
in 2.4.27, do you have further information?

Cheers,
Moritz

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc5
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: kernel updates accepted for sarge

[Holger Levsen]

Hi,

please respect reply-to: - thanks.

On Sunday 29 May 2005 06:57, Steve Langasek wrote:
> Thanks to some fancy last-minute archive work by James Troup, we now have a
> solution that lets us get security-fixed kernels into sarge r0 (instead of
> just into security.d.o) without running into GPL problems with
> debian-installer.

Great, thanks! 

(But) AFAIUI, fai-kernels also has to be rebuild now. (It's i386 only at the 
moment.)

This means it needs a new upload, as the build depends in the control file has 
to be changed from kernel-tree-2.6.8-15 and kernel-tree-2.4.27-8 to -16 and 
-10.

Or do I misunderstand something ?


regards,
Holger

P.S.: btw, in case you dont allready know: improvements for this situation are 
planned for etch.

> The following updates from unstable have just been approved:
> kernel-source-2.4.27 2.4.27-10
> kernel-image-2.4.27-i386 2.4.27-10
> kernel-source-2.6.8 2.6.8-16
> kernel-image-2.6.8-i386 2.6.8-16
> If there are updates to unstable pending for any other architectures,
> please let debian-release know.


pgpZGlItIi2nl.pgp
Description: PGP signature

Re: kernel updates accepted for sarge

[Norbert Tretkowski]

* Steve Langasek wrote:
> If there are updates to unstable pending for any other
> architectures, please let debian-release know.

I'm currently compiling updates for alpha 2.4 and 2.6 kernels, upload
tomorrow.

Norbert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broadcom proposed firmware licence, please comment ...

[Colin Watson]

On Sun, May 29, 2005 at 05:48:55AM -0400, Nathanael Nerode wrote:
> Before you move the whole driver to non-free, you should know that I have 
> made 
> a version of the driver which loads the firmware from files if it is 
> available (many tg3 users don't *need* the firmware), and I believe that is 
> the one currently in Debian's kernel tree.  I have also designed a package 
> containing appropriate firmware files for this version of the driver.  The 
> only reason I have not published the package yet is that it was under this 
> legal cloud.
> 
> The package generates the firmware files as arch-independent binary files 
> (with a specified endianness) by writing out the hex in a really 
> simple-minded way.  (Each lump of hex has a length and a lump in the C file, 
> and I just write the the length and the lump out binary, in a defined order.)
> 
> If this binary form counts as "equivalent", then I have a package for you 
> :-), 
> and I just have to fix it up to generate a udeb (and get a sponsor).

I think it would probably be better for you not to generate a udeb, and
let the linux-modules-nonfree-di-* source packages in d-i build-depend
on your firmware package instead; that means we don't have to cope with
lots of different firmware udebs in the d-i build system, and can
instead just have one or a few packages called
"nic-firmware-2.6.11-386", etc.

That said, I don't know exactly what we're doing about firmware yet. I
have a kernel-wedge patch in Ubuntu which supports generating
*-firmware-*-di udebs, although it's a bit clone-and-hack from
copy-modules and I haven't ported it to kernel-wedge 2 yet.

Cheers,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

kernel-image-2.6.8-ia64_2.6.8-14_ia64.changes ACCEPTED

[Debian Installer]

Accepted:
kernel-headers-2.6-itanium-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium-smp_2.6.8-14_ia64.deb
kernel-headers-2.6-itanium_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-itanium_2.6.8-14_ia64.deb
kernel-headers-2.6-mckinley-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley-smp_2.6.8-14_ia64.deb
kernel-headers-2.6-mckinley_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6-mckinley_2.6.8-14_ia64.deb
kernel-headers-2.6.8-2-itanium-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-itanium-smp_2.6.8-14_ia64.deb
kernel-headers-2.6.8-2-itanium_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-itanium_2.6.8-14_ia64.deb
kernel-headers-2.6.8-2-mckinley-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-mckinley-smp_2.6.8-14_ia64.deb
kernel-headers-2.6.8-2-mckinley_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2-mckinley_2.6.8-14_ia64.deb
kernel-headers-2.6.8-2_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-headers-2.6.8-2_2.6.8-14_ia64.deb
kernel-image-2.6-itanium-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium-smp_2.6.8-14_ia64.deb
kernel-image-2.6-itanium_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-itanium_2.6.8-14_ia64.deb
kernel-image-2.6-mckinley-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley-smp_2.6.8-14_ia64.deb
kernel-image-2.6-mckinley_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6-mckinley_2.6.8-14_ia64.deb
kernel-image-2.6.8-2-itanium-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-itanium-smp_2.6.8-14_ia64.deb
kernel-image-2.6.8-2-itanium_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-itanium_2.6.8-14_ia64.deb
kernel-image-2.6.8-2-mckinley-smp_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-mckinley-smp_2.6.8-14_ia64.deb
kernel-image-2.6.8-2-mckinley_2.6.8-14_ia64.deb
  to 
pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-2-mckinley_2.6.8-14_ia64.deb
kernel-image-2.6.8-ia64_2.6.8-14.dsc
  to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-14.dsc
kernel-image-2.6.8-ia64_2.6.8-14.tar.gz
  to pool/main/k/kernel-image-2.6.8-ia64/kernel-image-2.6.8-ia64_2.6.8-14.tar.gz
Announcing to debian-devel-changes@lists.debian.org


Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: broadcom proposed firmware licence, please comment ...

[Nathanael Nerode]

Sven Luther wrote:
> The text of the new licence proposal is as follows :
> 
> > +/* xxx.h: Broadcom tg3 network driver.
> > + *
> > + * Copyright (c) 2004, 2005 Broadcom Corporation
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation, except as noted below.
> > + *
> > + * This file contains firmware data derived from proprietary unpublished
> > + * source code, Copyright (c) 2004, 2005 Broadcom Corporation.
> > + *
> > + * Permission is hereby granted for the distribution of this firmware 
data
> > + * in hexadecimal or equivalent format, provided this copyright notice is
> > + * accompanying it.
> > + */
> 
> I would have liked a clear identification of the firmware blob, but i guess
> that to anyone familiar with C, it is immediately evident what is the 
firmware
> blob and what is normal code.
> 
> So, before i reply to them, i would like to have feedback from debian-legal,
> and we can then move ahead and upload this driver to the non-free part of 
our
> archive, including a working .udeb.

Great!  This license is totally distributable.  I'm not sure, unfortunately, 
what counts as "equivalent" to hexadecimal.  I think that's the only problem.  
If it was just "permission to distribute, unmodified, in any form", it would 
be clear.

Before you move the whole driver to non-free, you should know that I have made 
a version of the driver which loads the firmware from files if it is 
available (many tg3 users don't *need* the firmware), and I believe that is 
the one currently in Debian's kernel tree.  I have also designed a package 
containing appropriate firmware files for this version of the driver.  The 
only reason I have not published the package yet is that it was under this 
legal cloud.

The package generates the firmware files as arch-independent binary files 
(with a specified endianness) by writing out the hex in a really 
simple-minded way.  (Each lump of hex has a length and a lump in the C file, 
and I just write the the length and the lump out binary, in a defined order.)

If this binary form counts as "equivalent", then I have a package for you :-), 
and I just have to fix it up to generate a udeb (and get a sponsor).  If the 
binary form doesn't, we can rewrite the kernel driver to actually parse hex, 
but that seems a bit silly to me.  They seem equivalent to me.  I suspect 
they're meant to be equivalent, because the compiled version of the stock 
kernel contains binary rather than hex, and they want it to be possible to 
distribute that.  Do we need clarification here?

In any case, I believe we do not need to move the whole driver to non-free in 
this case, just the firmware.  Remember that this one works for many cards 
without the firmware, so people will certainly appreciate that.

--Nathanael Nerode


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#310982: smbmount does not honor uid and gid options with 2.4 kernel

[Steve Langasek]

On Sat, May 28, 2005 at 11:45:23PM +0200, Bill Allombert wrote:
> On Sat, May 28, 2005 at 02:07:04PM -0700, Steve Langasek wrote:
> > On Sat, May 28, 2005 at 06:39:28PM +0200, Bill Allombert wrote:
> > > On Fri, May 27, 2005 at 12:20:49PM -0700, Steve Langasek wrote:
> > > > On Sat, May 28, 2005 at 05:17:39AM +1000, Andrew Bartlett wrote:
> > > > Yeah, on second look I see that it can be done in smbmount, and this 
> > > > would
> > > > be a far more expedient fix.

> > > You mean something like the patch below ?
> > > (Not tested yet, want to be sure this is the idea)

> > I would've uploaded such a fix already, but upstream objects to this because
> > doing this in userspace instead of in the kernel means losing the other
> > features of CAP_UNIX -- which are, uh, symlinks and pipes, basically.  I'm
> > not really convinced that symlinks and pipes are important enough for people
> > who are using existing mounts with uid or gid smashing to warrant shipping

> I am obviously biased since I spend a whole night trying to track down this
> problem, but I think that people interested in CAP_UNIX will have moved
> to kernel 2.6 and cifs. At that point it seems unlikely that kernel 2.4
> will be ever fixed, in Debian or in mainline.

> It is a very nasty security problem: The server can change the security
> model of the client by enabling unix capability ! This can be used to
> compromise the client if the server is compromised.  

Yes, I certainly agree that it's bad, and I'm really leaning towards the
position that the security implications for users upgrading from woody
outweigh upstream's desire for the other features to Just Work.  Even
*those* are a behavior change, and arguably not an automatic win for all
users.

> One option would be to check if the host run a 2.4 kernel or a 2.6 kernel
> and only apply the correction for 2.4 kernel. (It is my understanding
> that 2.6 kernels do not have this problem, though I did not try);

Well, most people using 2.6 kernels are likely to be using cifs instead of
smbfs anyway (due to smbfs's general bitrot in 2.6 last I looked at it), so
I'm not sure that addresses upstream's objections.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature