Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
You ([EMAIL PROTECTED]) wrote: H If you know more, please add your knowledge below. [skip] 2.6.14-2 still enables the outdated ieee80211 :( Fixing this is simply a matter of disabling CONFIG_IEEE80211. This will allow to use ipw2200 (ipw2100 also) drivers built using module-assistant as before. -- Mikhail Gusarov ICQ UIN: 111575219 JID: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321419: closed (Was: Re: Bug#321419: linux-image-2.6.12-1-686: irq11 makes eth0 problems)
hi all,
I had the following problem:
description: CardBus bridge
product: PCI1250
vendor: Texas Instruments
On Wed, Aug 31, 2005 at 10:12:59PM +0200, Philippe Bourcier wrote:
On Wed, Aug 17, 2005 at 02:26:17AM +0200, Daniel Ritz wrote:
On Tuesday 16 August 2005 22.47, Philippe Bourcier wrote:
I tried latest debian 2.6.12 kernel; see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321419
irq 11: nobody cared!
[c01388fa] __report_bad_irq+0x2a/0xa0
[c013836d] handle_IRQ_event+0x3d/0x70
[c0138a12] note_interrupt+0x82/0xa0
[c0138490] __do_IRQ+0xf0/0x100
[c0105729] do_IRQ+0x19/0x30
[c0103ada] common_interrupt+0x1a/0x20
[c011f2ae] __do_softirq+0x2e/0xa0
[c011f346] do_softirq+0x26/0x30
[c010572e] do_IRQ+0x1e/0x30
[c0103ada] common_interrupt+0x1a/0x20
handlers:
[c8cddea0] (usb_hcd_irq+0x0/0x80 [usbcore])
[c8d00990] (yenta_interrupt+0x0/0x40 [yenta_socket])
[c8d00990] (yenta_interrupt+0x0/0x40 [yenta_socket])
Disabling IRQ #11
eth0: interrupt(s) dropped!
ask more if you need,
simple question: is that card a multifunction card with ethernet and a
modem?
exactly!
description: Megahertz 3CXEM556
product: LAN + 56k Modem
vendor: 3Com
i see from the dmesg that a ttyS2 pops up the same time when the
3c589 shows up. the problem compared to 2.4 is that the serial interface
is assigned irq 11 when the network card is on irq 9. but on 2.4 both
functions use irq 9 (which is correct). could you try the attached patch?
well, the I see this bug is resolved with the last (debian)
kernel \o/
Thanks very much for resolving! Congratulations!!
$ dmesg
Linux version 2.6.14-2-686 (Debian 2.6.14-3) ([EMAIL PROTECTED])
(gcc version 4.0.3 20051023 (prerelease) (Debian 4.0.2-3)) #1 Mon
Nov 14 14:19:05 UTC 2005
BIOS-provided physical RAM map:
BIOS-e801: - 0009f000 (usable)
BIOS-e801: 0010 - 0800 (usable)
0MB HIGHMEM available.
128MB LOWMEM available.
On node 0 totalpages: 32768
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 28672 pages, LIFO batch:15
HighMem zone: 0 pages, LIFO batch:1
DMI not present.
Allocating PCI resources starting at 1000 (gap:
0800:f800)
Built 1 zonelists
Kernel command line: root=/dev/hda2 video=vesafb:ywrap,mtrr
vga=791 noapic acpi=off ro
Local APIC disabled by BIOS -- you can enable it with lapic
mapped APIC to d000 (01101000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 300.794 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 122060k/131072k available (1851k kernel code, 8424k
reserved, 532k data, 180k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor
mode... Ok.
Calibrating delay using timer specific routine.. 602.10 BogoMIPS
(lpj=301052)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff
CPU: After vendor identify, caps: 0183f9ff
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 512K
CPU: After all inits, caps: 0183f9ff 0040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
mtrr: v2.0 (20020519)
CPU: Intel Pentium II (Deschutes) stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
checking if image is initramfs... it is
softlockup thread 0 started up.
Freeing initrd memory: 4331k freed
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xeb080, last bus=0
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00ff020
PnPBIOS: PnP BIOS version 1.0, entry 0xec000:0x3d18, dseg 0xec000
PnPBIOS: 19 nodes reported by PnP BIOS; 19 recorded by driver
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
Boot video device is :00:02.0
PCI quirk: region 1000-103f claimed by PIIX4 ACPI
PCI quirk: region 1400-141f claimed by PIIX4 SMB
PIIX4 devres C PIO at 0398-0399
PIIX4 devres E PIO at 0800-0807
PIIX4 devres I PIO at 0200-0201
PIIX4 devres J PIO at 0388-038b
PCI: Using IRQ router PIIX/ICH [8086/7110] at :00:07.0
pnp: 00:01: ioport range 0xcf8-0xcff could not be reserved
pnp: 00:01: ioport range 0x4d0-0x4d1 has been reserved
pnp: 00:01: ioport range 0x3f0-0x3f1 has been reserved
pnp: 00:01: ioport range
Bug#340486: linux-headers-2.6.14-2-k7: Unable to compile modules, fixdep.c required
Jurij, I am re-sending this email because I just checked the bug report and I do not see it listed -- so I assume it went astray. That's probably my fault, even though I would think that if Makefile would be written correctly, and fixdep binary already present (and it is present), then it would not try to rebuild it. Can you please confirm that it builds fine if you remove scripts/basic/Makefile? I should have included this in the original report -- that's the first thing I tested. When I remove Makefile from the script/basic directory, the make-kpgk fails with a complaint that there's no fule to make target scripts/basic/Makefile. I just tried this again with the latest linux-headers release, 2.6.14-4, and I have the same problem: complilation fails with or without the script/basic/Makefile. Please let me know if you need any further information. -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332381: This problem has broader implications
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Although the original report says, After 250 days, the jiffies overflow and ipt_recent do not work anymore and is for 2.4, I've actually found that the code included in 2.6.8 (and probably any kernel version that includes ipt_recent) causes unexpected issues related to the jiffies as well, other than the 250 days issue. If you have rules that block based on ipt_recent you will find that they will block much too early at odd times. For example, I have a rule that will DROP ssh connections if there have been more than 6 seen in the last 60 seconds, but (seemingly) randomly I will get DROPped on the first connection. Micah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDigIG9n4qXRzy1ioRAgDaAJ9g3uzHBKkSewx2CL0YkRs0ksFFoACgqR5D rRv5+cm8MbV9KH95NsY6Y2I= =3jfv -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341014: broken with udev 0.76
Package: initramfs-tools Version: 0.40 Severity: grave udev 0.76 failed to queue events correctly and didn't populate /dev at all using initramfs-tools. I only got a /dev/.udev/failed. No devices in /dev lead to failure to find root and no boot. To get up and running again I had to build a new initrd on a remote system and copy it over using a live-cd. yaird seems to have no problems with the same kernel (2.6.14-2-k7) and udev (0.76-2) cheers -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (401, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-k7 Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.01-3 Tiny utilities for small and embed ii cpio 2.6-9 GNU cpio -- a program to manage ar ii klibc-utils 1.1.1-4small statically-linked utilities ii udev 0.076-2/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337293: Problem is with udev and with 2.6.14
I've been working with this problem over the weekend, and I have the following facts to add to the mix. (1) As far as I can tell, this is a problem with udev, not with 2.6.14 only. I tried to boot my machine using udev on 2.6.12, and ran into what seems to be the same problem: /sbin/init: 432 cannot create /dev/null /sbin/init: 433 cannot open dev/null Kernel-panic etc. I view this as a migration problem from devfs to udev. If there's clear instructions on how to accomplish a migration, I don't know what they are. (2) I was able to install 2.6.14 *without* having udev installed! Since 2.6.14 seems to rely on udev and yaird, I believe udev should be a depedency of 2.6.14. (3) I thought that perhaps the problem was DELAY=10 in my mkinitrd.conf; but I tried building 2.6.12 using DELAY=0, and I still bomb out. I frankly am perplexed by this problem. My /dev is completely cluttered with everything that devfs created, I have a /dev/.static directory with console, null, and zero present, yet I can't seem to boot under udev. I wonder if the problem is that devfs is attempting to come up before udev? -- Moshe Yudkowsky Disaggregate 2952 W Fargo Chicago, IL 60645 USA www.Disaggregate.com www.PebbleAndAvalanche.com [EMAIL PROTECTED] +1 773 764 8727 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#317258: Status of this bug?
I have a NetRAID-1M and have been trying to use it in a 2.6.11 or greater kernel. Google has not helped, and neither has the linux-scsi ml. Is this patch ready or is more modification still needed? Thanks for any pointers! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341049: linux-image-2.6.14-2-686: Doesn't boot (/dev/hda1 does not exist)
Package: linux-image-2.6.14-2-686 Version: 2.6.14-3 Severity: normal The linux kernel now does not boot for me. This is with udev 0.076-1 installed, and with hotplug purged. The IDE subsystem seems to be initialized correctly, but /dev/hda1 does not exist. I get (copied by hand): hda: FUJITSU MHT2040AT, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 128KiB hda: 78140160 sectors (40007 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100) hda: cache flushes supported hda: hda1 Done. ... and then soon after: Begin: Mounting root file system ... Begin: Running /scripts/local-top ... Done. ALERT! /dev/hda1 does not exist. Dropping to a shell! Investigation within the shell reveals that /dev contains only /dev/console and /dev/null. The static /dev directory on my /dev/hda1 partition _does_ apparently contain a /dev/hda1 entry. All of the testing above was with root=/dev/hda1 appended to the kernel command line. Without that argument, I get a failure to boot at a different point in the process (immediately after starting udevd, and it asks for the root password for maintenance). Both failures to boot seem to be because of a lack of a /dev/hda1 device node. I can write and copy the transcript for that failure case as well if you like. The debian image linux-image-2.6.12-1-686 version 2.6.12-6 boots correctly for me. Let me know if you need any more information. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.14-2-686 depends on: ii initramfs-tools [linux-initra 0.40 tools for generating an initramfs ii module-init-tools 3.2-pre9-4 tools for managing Linux kernel mo linux-image-2.6.14-2-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 28 Nov 2005 00:13:50 +0100 Sven Luther [EMAIL PROTECTED] wrote: Jonas, maybe you would feel like adding a wiki page with the arch status or something ? Sorry - I don't understand - what do you want different from the arch status notes on http://wiki.debian.org/InitrdReplacementOptions ? - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDilwUn7DbMsAkQLgRApmXAKCVnwQYN5VlVXXQXthPx8Fm13Ej0ACeMhRP 7aJetXTU1VctA5eNaMAWEcw= =iWl+ -END PGP SIGNATURE-
Processed: This is not really RC ...
Processing commands for [EMAIL PROTECTED]: severity 286756 important Bug#286756: udev gets tmpfs kernel support test wrong Severity set to `important'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, Nov 28, 2005 at 02:23:32AM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 28 Nov 2005 00:13:50 +0100 Sven Luther [EMAIL PROTECTED] wrote: Jonas, maybe you would feel like adding a wiki page with the arch status or something ? Sorry - I don't understand - what do you want different from the arch status notes on http://wiki.debian.org/InitrdReplacementOptions ? What i really like is a summary of any remaining showstoppers for not moving 2.6.14-4 kernels to testing, from a yaird perspective. Well, from a yaird+initramfs-tools perspective probably. The point is to ensure that no users are left out in the cold with no upgrade path and a broken kernel if we do so. What about 328534 for example, altough i suppose this one is mergeable with the other dpt_io bug. I was tempted to reassign a clone thereof to yaird + initramfs-tools. BTW, also, about ia64 situation, is it possible to use yaird in initrd case still ? I know Eric was disabling this for 0.12, but we are still using 0.11 ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.14 status summary, and upcoming 2.6.15 ...
On Mon, Nov 28, 2005 at 12:13:50AM +0100, Sven Luther wrote: Hi all, ... Well, fs uploaded 2.6.14-4, and i think now is a good time to examine the current situation and make a status summary, and plan for the future. Ok, i did a bit of cleanup of the RC bugs, and there seems to be the following issues i am aware of : 1) the linux-header mess. We need to fix it or confirm it is fixed in 2.6.14-4. 2) dpt_io driver seem to have some trouble. I sense that this may be due to the wrong driver taking care of the card, and doing a bad job of it. There are two separate bugs about this. Someone needs to investigate this, but i get a feeling that it maybe udev initramfs-tools/yaird related. 3) the initramfs/ia64 situation. either we need yaird with initrd support, use plain initrd-tools on ia64, or fix this. No news about a fix in that bug report though. 4) #335656 is probably an acpi/irq/whatever breakage, and only needs the right kernel command line option to work. This seems to be a mess, and someone with more knowledge or interest in x86 hardware need to have a look. The reporter needs to provide more real info though. Well, that is all i could say about the linux-2.6 RC bugs, there may be some issues related to the latest udev though, and more ramdisk-tool issues we didn't catch yet though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: some severity reorg.
Processing commands for [EMAIL PROTECTED]: severity 328534 grave Bug#328534: Kernel panic on Adaptec 2100S on boot Severity set to `grave'. severity 335656 grave Bug#335656: linux-image-2.6.13-1-386: PCI error Severity set to `grave'. severity 337974 grave Bug#337974: linux-image-2.6.12-1-k7: i2o controller probe failed err -110 Severity set to `grave'. severity 337493 critical Bug#337493: linux-2.6 2.6.14 should not move to testing unexpectedly. Severity set to `critical'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.27-12 for Sid
Horms wrote: Holger kindly reminded me on IRC yesterday that its been a long time since a new 2.4.27 was uploaded into Sarge. He pointed out that there are a number of valuable fixes in SVN. Is there any reason why you're sticking with 2.4.27+patches rather than following the 2.4 series upstream? Seems to this uninformed observer like it might be less work to follow upstream since it's limited to security fixes, serious bug fixes, and driver backports, assuming merging with it isn't too much work. -- see shy jo signature.asc Description: Digital signature
