Bug#394753: workaround: add clocksource=tsc as a boot param
Package: linux-image-2.6.18-3-486 Version: 2.6.18-7 bug report as created by reportbug package follows below: Subject: workaround: add clocksource=tsc as a boot param Followup-For: Bug #394753 Package: linux-image-2.6.18-3-486 Version: 2.6.18-7 *** Please type your report below this line *** I encountered the same problem, yesterday. On irc://irc.freenode.net/#debian, user xingu provided me with kind of a fix: In /boot/grub/menu.lst, to the line # defoptions=, I added clocksource=tsc, then called upgrade-grub. Since that, the clock behaves normal. PS: This box is also a AMD K6-2/400; on the other box (K7), there are no clock issues. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i586) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-486 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.18-3-486 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85e tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo linux-image-2.6.18-3-486 recommends no packages. -- debconf information: linux-image-2.6.18-3-486/preinst/initrd-2.6.18-3-486: linux-image-2.6.18-3-486/postinst/old-dir-initrd-link-2.6.18-3-486: true linux-image-2.6.18-3-486/postinst/create-kimage-link-2.6.18-3-486: true linux-image-2.6.18-3-486/preinst/abort-install-2.6.18-3-486: linux-image-2.6.18-3-486/preinst/lilo-initrd-2.6.18-3-486: true linux-image-2.6.18-3-486/postinst/depmod-error-initrd-2.6.18-3-486: false linux-image-2.6.18-3-486/preinst/elilo-initrd-2.6.18-3-486: true linux-image-2.6.18-3-486/postinst/old-system-map-link-2.6.18-3-486: true linux-image-2.6.18-3-486/postinst/old-initrd-link-2.6.18-3-486: true linux-image-2.6.18-3-486/postinst/bootloader-test-error-2.6.18-3-486: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-3-486/preinst/overwriting-modules-2.6.18-3-486: true linux-image-2.6.18-3-486/preinst/already-running-this-2.6.18-3-486: linux-image-2.6.18-3-486/prerm/removing-running-kernel-2.6.18-3-486: true linux-image-2.6.18-3-486/prerm/would-invalidate-boot-loader-2.6.18-3-486: true linux-image-2.6.18-3-486/postinst/bootloader-error-2.6.18-3-486: linux-image-2.6.18-3-486/preinst/abort-overwrite-2.6.18-3-486: linux-image-2.6.18-3-486/postinst/kimage-is-a-directory: linux-image-2.6.18-3-486/preinst/bootloader-initrd-2.6.18-3-486: true linux-image-2.6.18-3-486/preinst/failed-to-move-modules-2.6.18-3-486: linux-image-2.6.18-3-486/preinst/lilo-has-ramdisk: linux-image-2.6.18-3-486/postinst/depmod-error-2.6.18-3-486: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411098: AMD K6-2/400 + Package: kernel-image-2.6.18-3-486 = crashes
Package: kernel-image-2.6.18-3-486 Version: everything else: see attachted plain text file, as created by the reportbug tool Subject: kernel-image-2.6.18-3-486: frequent invalid opcode calls cause crashes Package: kernel-image-2.6.18-3-486 Severity: important *** Please type your report below this line *** On a AMD K6-2 400, using this kernel I continuously encounter kind of core dumps, /var/log/messages snippet included below. First, I thought this could be a side effect of the system clock running twice as fast as usual (i.e. every one second, the clock ticks two seconds). Assuming, that could be related to the RTC, I installed ntpd, ntpdate, chrony to get rid of that. Then I noticed the invalid opcode dumps first; I presumed, they sprung into action the moment, ntpd*/chrony attempted to set the clock back. Hence, I removed ntpd/ntpdate/chrony, but the dumps continued to appear. On irc://irc.freenode.net/#debian, user xingu provided me with a kernel parameter for grub's menu list (deboptions=clocksource=tsc), which made the clock run at normal speed again. But still, the dumps didn't go away. As a last resort, I replaced hardware, but the problem's still there. -- At least on Sarge's 2.6.8 kernel, I didn't encounter any issue like this one. Despite I'd like Etch to be released soon, I consider this problem important enough to be reported. Sorry for providing this as another possible delay for Etch. :-( NB: As an absolutely last resort, just before filing this bug report, I uninstalled acpid and hal packages. During writing this bug report, I encountered no such issue at all; but that could be a random even, and the box would crash later... From /var/log/messages, I cut a complete cycle from restart to crash. Hopefully, that might tell you anything: Feb 13 10:18:59 localhost exiting on signal 15 Feb 14 01:37:19 localhost syslogd 1.4.1#18: restart. Feb 14 01:37:19 localhost kernel: klogd 1.4.1#18, log source = /proc/kmsg started. Feb 14 01:37:19 localhost kernel: Linux version 2.6.18-3-486 (Debian 2.6.18-7) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 Mon Dec 4 15:59:52 UTC 2006 Feb 14 01:37:19 localhost kernel: BIOS-provided physical RAM map: Feb 14 01:37:19 localhost kernel: BIOS-e820: - 0009fc00 (usable) Feb 14 01:37:19 localhost kernel: BIOS-e820: 0009fc00 - 000a (reserved) Feb 14 01:37:19 localhost kernel: BIOS-e820: 000e - 0010 (reserved) Feb 14 01:37:19 localhost kernel: BIOS-e820: 0010 - 13ff (usable) Feb 14 01:37:19 localhost kernel: BIOS-e820: 13ff - 13ff8000 (ACPI data) Feb 14 01:37:19 localhost kernel: BIOS-e820: 13ff8000 - 1400 (ACPI NVS) Feb 14 01:37:19 localhost kernel: BIOS-e820: fec0 - fec01000 (reserved) Feb 14 01:37:19 localhost kernel: BIOS-e820: fee0 - fee01000 (reserved) Feb 14 01:37:19 localhost kernel: BIOS-e820: fffe - 0001 (reserved) Feb 14 01:37:19 localhost kernel: 319MB LOWMEM available. Feb 14 01:37:19 localhost kernel: DMI 2.0 present. Feb 14 01:37:19 localhost kernel: ACPI: PM-Timer IO Port: 0x4008 Feb 14 01:37:19 localhost kernel: Allocating PCI resources starting at 2000 (gap: 1400:eac0) Feb 14 01:37:19 localhost kernel: Detected 400.941 MHz processor. Feb 14 01:37:19 localhost kernel: Built 1 zonelists. Total pages: 81904 Feb 14 01:37:19 localhost kernel: Kernel command line: root=/dev/hda5 ro bootkbd=de Feb 14 01:37:19 localhost kernel: No local APIC present or hardware disabled Feb 14 01:37:19 localhost kernel: Initializing CPU#0 Feb 14 01:37:19 localhost kernel: PID hash table entries: 2048 (order: 11, 8192 bytes) Feb 14 01:37:19 localhost kernel: Console: colour VGA+ 80x25 Feb 14 01:37:19 localhost kernel: Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Feb 14 01:37:19 localhost kernel: Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Feb 14 01:37:19 localhost kernel: Memory: 317136k/327616k available (1500k kernel code, 9816k reserved, 602k data, 256k init, 0k highmem) Feb 14 01:37:19 localhost kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok. Feb 14 01:37:19 localhost kernel: Calibrating delay using timer specific routine.. 802.42 BogoMIPS (lpj=1604843) Feb 14 01:37:19 localhost kernel: Security Framework v1.0.0 initialized Feb 14 01:37:19 localhost kernel: SELinux: Disabled at boot. Feb 14 01:37:19 localhost kernel: Capability LSM initialized Feb 14 01:37:19 localhost kernel: Mount-cache hash table entries: 512 Feb 14 01:37:19 localhost kernel: CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) Feb 14 01:37:19 localhost kernel: Compat vDSO mapped to e000. Feb 14 01:37:19 localhost kernel: CPU: AMD-K6(tm) 3D processor stepping 0c Feb 14 01:37:19 localhost kernel: Checking 'hlt' instruction... OK. Feb 14 01:37:19
Processed: Re: Bug#411098: AMD K6-2/400 + Package: kernel-image-2.6.18-3-486 = crashes
Processing commands for [EMAIL PROTECTED]: reassign 411098 linux-2.6 Bug#411098: AMD K6-2/400 + Package: kernel-image-2.6.18-3-486 = crashes Warning: Unknown package 'kernel-image-2.6.18-3-486' Bug reassigned from package `kernel-image-2.6.18-3-486' to `linux-2.6'. -- 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: Kernel 2.6.19
Goswin von Brederlow [EMAIL PROTECTED] writes: Otavio Salvador [EMAIL PROTECTED] writes: maximilian attems [EMAIL PROTECTED] writes: On Thu, Feb 01, 2007 at 10:14:10AM +0100, Matthias Popp wrote: Hallo, Why is kernel 2.6.19 removed from here ? http://kernel-archive.buildserver.net/debian-kernel/pool/main/l/linux-2.6/ just use the 2.6.20-rc6 I noticed that some flavours aren't being build yet. Does anyone has any idea when XEN could be add on 2.6.20-rc6 packages? When redhat gets their xen 2.6.20 mercurial repository to actualy compile so a xen patch can be extracted I guess. Ah great. They do have a working 2.6.19.2 branch though. Nice! -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411115: sky2 module
Package: Kernel
Version: 2.6.18-4
Stephen Hemminger post some patchs to sky2 module in:
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/11.html
[PATCH 0/6]
This set of patches fixes all the problems observed so far on
my machines. The biggest one was not doing transmit flow control
correctly.
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/12.html
[PATCH 1/6]
An embedded and charset-unspecified text was scrubbed...
Name: sky2-pause-flush.patch
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/14.html
[PATCH 2/6]
An embedded and charset-unspecified text was scrubbed...
Name: sky2-no-asym-down.patch
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/13.html
[PATCH 3/6]
An embedded and charset-unspecified text was scrubbed...
Name: sky2-fe-fc.patch
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/17.html
[PATCH 4/6]
An embedded and charset-unspecified text was scrubbed...
Name: sky2-timeout3.patch
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/16.html
[PATCH 5/6]
An embedded and charset-unspecified text was scrubbed...
Name: sky2-rx-error-handle.patch
https://lists.osdl.org/mailman/private/sk-drivers/2007-February/15.html
[PATCH 6/6]
An embedded and charset-unspecified text was scrubbed...
Name: sky2-v1.13.patch
Patchs is attached, please use it.
--
Renato S. Yamane
Fingerprint: 68AE A381 938A F4B9 8A23 D11A E351 5030 D420 515A
PGP Server: http://pgp.mit.edu/ -- KeyID: 0xD420515A
http://www.renatoyamane.com
The Yukon-FE chip doesn't do gigabit and has a differen PHY internally.
On this chip, phy status register doesn't properly reflect the result
of flow control negotiation. To workaround the problem and avoid having
to have so much chip dependent code; compute the result of flow control
by looking at the local and remote advertised bits.
Signed-off-by: Stephen Hemmminger [EMAIL PROTECTED]
--- sky2-dev.orig/drivers/net/sky2.c 2007-02-14 10:01:41.0 -0800
+++ sky2-dev/drivers/net/sky2.c 2007-02-14 13:32:00.0 -0800
@@ -1766,10 +1766,10 @@
{
struct sky2_hw *hw = sky2-hw;
unsigned port = sky2-port;
- u16 lpa;
+ u16 advert, lpa;
+ advert = gm_phy_read(hw, port, PHY_MARV_AUNE_ADV);
lpa = gm_phy_read(hw, port, PHY_MARV_AUNE_LP);
-
if (lpa PHY_M_AN_RF) {
printk(KERN_ERR PFX %s: remote fault, sky2-netdev-name);
return -1;
@@ -1784,20 +1784,40 @@
sky2-speed = sky2_phy_speed(hw, aux);
sky2-duplex = (aux PHY_M_PS_FULL_DUP) ? DUPLEX_FULL : DUPLEX_HALF;
- /* Pause bits are offset (9..8) */
- if (hw-chip_id == CHIP_ID_YUKON_XL
- || hw-chip_id == CHIP_ID_YUKON_EC_U
- || hw-chip_id == CHIP_ID_YUKON_EX)
- aux = 6;
-
- sky2-flow_status = sky2_flow(aux PHY_M_PS_RX_P_EN,
- aux PHY_M_PS_TX_P_EN);
+ /* Since the pause result bits seem to in different positions on
+ * different chips. look at registers.
+ */
+ if (!sky2_is_copper(hw)) {
+ /* Shift for bits in fiber PHY */
+ advert = ~(ADVERTISE_PAUSE_CAP|ADVERTISE_PAUSE_ASYM);
+ lpa = ~(LPA_PAUSE_CAP|LPA_PAUSE_ASYM);
+
+ if (advert ADVERTISE_1000XPAUSE)
+ advert |= ADVERTISE_PAUSE_CAP;
+ if (advert ADVERTISE_1000XPSE_ASYM)
+ advert |= ADVERTISE_PAUSE_ASYM;
+ if (lpa LPA_1000XPAUSE)
+ lpa |= LPA_PAUSE_CAP;
+ if (lpa LPA_1000XPAUSE_ASYM)
+ lpa |= LPA_PAUSE_ASYM;
+ }
+
+ sky2-flow_status = FC_NONE;
+ if (advert ADVERTISE_PAUSE_CAP) {
+ if (lpa LPA_PAUSE_CAP)
+ sky2-flow_status = FC_BOTH;
+ else if (advert ADVERTISE_PAUSE_ASYM)
+ sky2-flow_status = FC_RX;
+ } else if (advert ADVERTISE_PAUSE_ASYM) {
+ if ((lpa LPA_PAUSE_CAP) (lpa LPA_PAUSE_ASYM))
+ sky2-flow_status = FC_TX;
+ }
if (sky2-duplex == DUPLEX_HALF sky2-speed SPEED_1000
!(hw-chip_id == CHIP_ID_YUKON_EC_U || hw-chip_id == CHIP_ID_YUKON_EX))
sky2-flow_status = FC_NONE;
- if (aux PHY_M_PS_RX_P_EN)
+ if (sky2-flow_status FC_TX)
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_PAUSE_ON);
else
sky2_write8(hw, SK_REG(port, GMAC_CTRL), GMC_PAUSE_OFF);
--
Stephen Hemminger [EMAIL PROTECTED]
___
Sk-drivers mailing list
[EMAIL PROTECTED]
https://lists.osdl.org/mailman/listinfo/sk-drivers
Resetting the pause bits on shutdown is not necessary.
The code was inherited from the vendor driver, and it is currently #ifdef'd
out there as well.
Signed-off-by: Stephen Hemminger [EMAIL PROTECTED]
--- sky2-dev.orig/drivers/net/sky2.c 2007-02-13 15:08:31.0 -0800
+++ sky2-dev/drivers/net/sky2.c 2007-02-13 15:13:03.0 -0800
@@ -1742,13 +1742,6 @@
reg = ~(GM_GPCR_RX_ENA | GM_GPCR_TX_ENA);
gma_write16(hw, port, GM_GP_CTRL, reg);
- if (sky2-flow_status == FC_RX) {
- /* restore Asymmetric Pause bit */
- gm_phy_write(hw, port, PHY_MARV_AUNE_ADV,
- gm_phy_read(hw, port, PHY_MARV_AUNE_ADV)
- | PHY_M_AN_ASP);
- }
-
netif_carrier_off(sky2-netdev);
netif_stop_queue(sky2-netdev);
--
Stephen Hemminger [EMAIL PROTECTED]
have the permissions changes on the kernel source
Is it my imagination or have the group permissions on the linux kernel source as installed by apt-get source changed? The end result used to be that group src was assigned to the directory in /usr/src that received the source, but now it seems to be group root. This change seems to have happened somewhere between 2.6.17 and 2.6.18. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#411115: sky2 module
Processing commands for [EMAIL PROTECTED]: reassign 45 linux-2.6 Bug#45: sky2 module Bug reassigned from package `kernel' to `linux-2.6'. severity 45 important Bug#45: sky2 module Severity set to `important' from `normal' tags 45 patch Bug#45: sky2 module There were no tags set. Tags added: patch stop 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]
Bug#411115: sky2 module
reassign 45 linux-2.6 severity 45 important tags 45 patch stop On Fri, Feb 16, 2007 at 08:37:27AM -0200, Renato S. Yamane wrote: Package: Kernel Version: 2.6.18-4 Stephen Hemminger post some patchs to sky2 module in: https://lists.osdl.org/mailman/private/sk-drivers/2007-February/11.html we are currently under freeze, i had no sky2 test box until now. some of the patches qualify for a stable release update, i'll check with dannf which we'll add. thanks a lot for your mail -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405270: systems hangs during boot with radio kill switch on
Hi, I'd like to report that I have the same issue : I have a Dell Latitude D420 featuring an Intel 3945ABG card, and a radio kill switch. When booting with the switch on (i.e. radio off) the system hangs during the boot sequence, somewhat between /etc/init.d/ipw3945d (most likely there) and /etc/init.d/networking. With radio on it starts OK. This has been observed with various versions of ipw3945 packages in testing/unstable. Currently I have : ii firmware-ipw3945 0.3 ii ipw3945-modules-2.6.18-3-686 2.6.18+1.1.3-3 (compiled with m-a) ii ipw3945-modules-2.6.18-4-686 2.6.18+1.1.3-4 (from contrib) ii ipw3945-source1.1.3-3 ii ipw3945d 1.7.22-4 and I tried with the official kernels : ii linux-image-2.6.18-3-686 2.6.18-7 ii linux-image-2.6.18-4-686 2.6.18.dfsg.1-10 (I had the same bug with older 2.6.17, I have a self-compiled 2.6.20 at hand but module-assistant fails to build ipw3945 for it...) Best regards, Jeremie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of the kernel wrt etch
On Thu, 15 Feb 2007, dann frazier wrote: What else needs to happen before we upload -11? hmm forgot that one: Revert [Bluetooth] Fix compat ioctl for BNEP, CMTP and HIDP Does not work in 2.6.16. needs check for our 2.6.18 if same story applies. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of the kernel wrt etch
On Thu, 15 Feb 2007, dann frazier wrote: What else needs to happen before we upload -11? sky2 had some considerable fixes since 2.6.18, i'd appreciate if you cherry-pick some of them. can give you an remote account on a box with sky2 or test them myself. won't have any real time before next week to do the work myself. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411135: linux-image-2.6.18-4-sparc64-smp: Unknown symbol execve in module bbc
Package: linux-image-2.6.18-4-sparc64-smp Version: 2.6.18.dfsg.1-10 Severity: important Fans are very noisy on this blade100, so I'd like to control them: modprobe bbc FATAL: Error inserting bbc (/lib/modules/2.6.18-4-sparc64-smp/ kernel/drivers/sbus/char/bbc.ko): Unknown symbol in module, or unknown parameter (see dmesg) dmesg says bbc: Unknown symbol execve I tried with linux-image-2.6.18-4-sparc64, same problem. Cheers, Jim -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-sparc64-smp Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-4-sparc64-smp depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85e tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo linux-image-2.6.18-4-sparc64-smp recommends no packages. -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-4-sparc64-smp/prerm/removing-running-kernel-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/preinst/overwriting-modules-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/postinst/old-dir-initrd-link-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/preinst/failed-to-move-modules-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/postinst/depmod-error-2.6.18-4-sparc64-smp: false linux-image-2.6.18-4-sparc64-smp/preinst/bootloader-initrd-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/preinst/abort-overwrite-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/preinst/abort-install-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/postinst/kimage-is-a-directory: linux-image-2.6.18-4-sparc64-smp/preinst/elilo-initrd-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/preinst/already-running-this-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/postinst/create-kimage-link-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/postinst/old-initrd-link-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/preinst/initrd-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/preinst/lilo-has-ramdisk: linux-image-2.6.18-4-sparc64-smp/postinst/depmod-error-initrd-2.6.18-4-sparc64-smp: false linux-image-2.6.18-4-sparc64-smp/prerm/would-invalidate-boot-loader-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/postinst/old-system-map-link-2.6.18-4-sparc64-smp: true linux-image-2.6.18-4-sparc64-smp/postinst/bootloader-test-error-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/postinst/bootloader-error-2.6.18-4-sparc64-smp: linux-image-2.6.18-4-sparc64-smp/preinst/lilo-initrd-2.6.18-4-sparc64-smp: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398011: No longer reproductible under new kernel
I installed new kernel (linux-image-2.6.18-4-xen-686 2.6.18.dfsg.1-10) over a week ago, and up till now I haven't seen any internal xen networking problems. Look like new xen snapshot fixes those bugs. Regards -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410039: No /usr/lib/xen folder so it's confusing other packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow wrote: The problem is that multiple xen versions (3.0-unstable, 3.0.3, 3.0.4) can be installed and they are incompatible with each other. If each one contained /usr/lib/python/xen then the packages would have to conflict. I understood that, for sure! What you need is a common package that contains wrapper scripts in /usr/lib/python/xen that will pick the right /usr/lib/xen-VERSION/lib/python subdir applicable to the running xen version. Maybe xen-utils-common is what you should be using? Maybe a script run at startup could check for the xen version that is running and make the appropriate symlink? Sure that could be in a xen-common package, for example... Is that what xen-utils-common does? Thomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF1buQl4M9yZjvmkkRAtTDAJ9TOYMKkyfvTSs1xjEpcFniyCbz7QCg4P0a eydB76cWR1OcL8U/zeRbSF0= =4SYo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401916: Bug 401916: analysis and suggested solution
I've spent more time researching this by reading kernel code, checking the boot process of other distros and trolling through mailing list archives and I think I have a pretty good picture of the problem now. Description: Basically udevsettle will return once all modules have been loaded and no more uevents are pending. all modules include e.g. scsi host drivers and usb host drivers. The problem is that even if a module has been loaded for a usb host which has a storage device attached, the usb host driver will not emit uevents for the device immediately. Instead the scanning is done asynchronously and might take an arbitrary amount of time (based on things like the reset-time of the storage device, which can be several seconds, the number of hubs between the host and the device, etc). The same goes for several other buses (e.g. SCSI, Firewire, fibre-channel, etc), and we won't be able to solve it completely by watching kernel threads (the approach that I tried in earlier mails to the same BR). Short-term solution: Therefore, I think the best short-term solution (considering the ever-impending Etch release) would be to add the root_wait= boot parameter so that affected users can set the timeout value manually. If that parameter was added, and documented in the release docs, the severity of these bugs could be downgraded (imho). Alternatively, or additionally, the scripts could check whether one of several problematic modules have been loaded when udevsettle returns and if so, sleep a couple of extra seconds (most other distros that take this approach seem to wait around 6 - 10 seconds). The problem is that the list of problematic modules is potentially huge (see list of buses above) Long-term solution: In the long term (post-Etch), I think something like the following might be a good solution: Take all scripts under /usr/share/initramfs-tools/scripts/local-top/ that setup block devices (i.e. cryptsetup, lvm, evms, etc), and split them in two, a udev rule snippet and a script. The udev rule snippet would list the devices that this particular script is interested in, and tell udev to call the script whenever such a device node is created. The script is basically the old script with minor changes so that it takes a device node as argument, and also so that it doesn't preserve any state between invocations. Then the main init script is changed to sleep until $ROOT (not /dev/root but whatever is set as the $ROOT variable) appears Advantages of the long-term approach: there will be no more sleeping than necessary everything will be asynchronous there will be no need to specify dependencies between the /usr/share/initramfs-tools/scripts/local-top/ scripts The last one might seem minor, but it actually makes the system much simpler. Right now it is not possible to support both crypto-on-lvm and lvm-on-crypto without duplicating the lvm functionality in the cryptsetup initramfs script (as you can tell initramfs to run lvm before or after cryptsetup, but not both). Example: Let's say we have the scripts lvm, cryptsetup and md in /usr/share/initramfs-tools/scripts/blockdev-scripts/ Each script has a udev rule snippet in /usr/share/initramfs-tools/scripts/blockdev-rules/ Most probably these rule snippets would be something like (this is probably not a valid udev rule, I can't check the syntax right now): KERNEL=[sh]d[a-z], PROGRAM=/usr/share/initramfs-tools/scripts/blockdev-rules/md Let's say that /dev/sda1 is detected. udev will then use its rules to execute /usr/share/initramfs-tools/scripts/blockdev-scripts/lvm which will check the device, realize it's no lvm pv and exit the same thing then happens for the cryptsetup script the md script recognizes /dev/sda1 as a raid partition, but it is missing an additional device, so no action is taken Later, /dev/sdb1 is detected. udev calls the lvm script again, which exits again the same thing then happends for the cryptsetup script the md script recognizes /dev/sdb1 as a raid partition, and /dev/sda1 is the other part of the raid device, so the device is setup and a new uevent is triggered in response, udev creates /dev/md1 and starts going through the scripts again udev calls the lvm script again, which exits again udev calls the cryptsetup script which recognizes /dev/md1 as a crypto device, prompts for the password and sets it up, this generates another uevent in response, udev creates /dev/mapper/cryptroot and starts going through the scripts again udev calls the lvm script again, which recognizes /dev/mapper/cryptroot as a lvm pv and sets up the vg and its lv's the lv's generate new uevents in response, udev creates (among others) /dev/mapper/mainvg-mainlv init notices this and boot continues Phew, this mail became much longer than expectedso whaddaya think Maks? -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411150: linux-image-2.6.18-4-686: hangs in ACPI during boot on Sony Vaio PCG-Z600LEK
Package: linux-image-2.6.18-4-686 Version: 2.6.18.dfsg.1-10 Severity: important All the versions of linux-image-2.6.18-*-686 that I have tried normally hang when booting on my Sony Vaio PCG-Z600LEK. Last time I had to boot 4 times before the machine booted correctly. I have to poweroff between each boot attempt. linux-image-2.6.16-2-686 boots everytime. The first time the boot hung after these lines: PIIX4 devres I PIO at 0398-0399 PIIX4 devres J PIO at 0398-0399 ACPI: Embedded Controller [EC0] (gpe 9) interrupt mode The second time it hung after: ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 The third time it hung after: Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init When the machine booted correctly (on the 4th attempt) dmesg said BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000e8400 - 0010 (reserved) BIOS-e820: 0010 - 03ff (usable) BIOS-e820: 03ff - 03fff800 (ACPI data) BIOS-e820: 03fff800 - 0400 (ACPI NVS) BIOS-e820: fff8 - 0001 (reserved) 0MB HIGHMEM available. 63MB LOWMEM available. On node 0 totalpages: 16368 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 12272 pages, LIFO batch:1 DMI 2.1 present. ACPI: RSDP (v000 SONY ) @ 0x000f6bb0 ACPI: RSDT (v001 SONY Z3 0x20001225 PTL 0x) @ 0x03ffc1ca ACPI: FADT (v001 SONY Z3 0x20001225 PTL 0x000f4240) @ 0x03fff764 ACPI: BOOT (v001 SONY Z3 0x20001225 PTL 0x0001) @ 0x03fff7d8 ACPI: DSDT (v001 SONY Z3 0x20001225 MSFT 0x0107) @ 0x ACPI: PM-Timer IO Port: 0x8008 Allocating PCI resources starting at 1000 (gap: 0400:fbf8) Detected 694.900 MHz processor. Built 1 zonelists. Total pages: 16368 Kernel command line: root=/dev/hda2 ro Local APIC disabled by BIOS -- you can enable it with lapic mapped APIC to d000 (01089000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 57068k/65472k available (1544k kernel code, 7996k reserved, 577k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 1390.86 BogoMIPS (lpj=2781723) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0383f9ff CPU: After vendor identify, caps: 0383f9ff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 256K CPU: After all inits, caps: 0383f9ff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 16k freed ACPI: Core revision 20060707 CPU0: Intel Pentium III (Coppermine) stepping 06 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs migration_cost=0 checking if image is initramfs... it is Freeing initrd memory: 4746k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: PCI BIOS revision 2.10 entry at 0xfd9ae, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 PCI quirk: region 8000-803f claimed by PIIX4 ACPI PCI quirk: region 1040-104f claimed by PIIX4 SMB PIIX4 devres I PIO at 0398-0399 PIIX4 devres J PIO at 0398-0399 PCI: Firmware left :00:0b.0 e100 interrupts enabled, disabling Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: Embedded Controller [EC0] (gpe 9) interrupt mode. ACPI: PCI Interrupt Link [LNKA] (IRQs *9) ACPI: PCI Interrupt Link [LNKB] (IRQs 9) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 9) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 9) *0, disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 11 devices PnPBIOS: Disabled by ACPI PNP PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report pnp: 00:01: ioport range 0x398-0x399 has been
Bug#411150: linux-image-2.6.18-4-686: hangs in ACPI during boot on Sony Vaio PCG-Z600LEK
On Fri, Feb 16, 2007 at 04:57:21PM +0100, Stuart Pook wrote: Package: linux-image-2.6.18-4-686 Version: 2.6.18.dfsg.1-10 Severity: important All the versions of linux-image-2.6.18-*-686 that I have tried normally hang when booting on my Sony Vaio PCG-Z600LEK. Last time I had to boot 4 times before the machine booted correctly. I have to poweroff between each boot attempt. linux-image-2.6.16-2-686 boots everytime. hey Stuart, Can you try the latest trunk snapshot (2.6.20-based) and see if the problem has gone away? http://wiki.debian.org/DebianKernel -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
Package: kernel
Severity: critical
Multiple attempts to install Etch fail. The syslog file is filled with
failure messages along these lines:
Feb 16 01:09:27 debootstrap: Unpacking replacement base-files ...
Feb 16 01:09:57 kernel: ata1: command 0xca timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sda: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:09:57 kernel: Info fld=0x0
Feb 16 01:09:57 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sdb: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata1: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sda: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sdb: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
I have saved as much of syslog as was flushed right before giving up (at
the rate it was going it would have taken days to finish -- if ever --
what completed successfully in under a half hour using the i386 version)
on the last attempt (I also have the complete partman log), and will be
happy to post them (or make them available via HTTP) if you believe they
will be of any use.
I have run hardware diagnostic tests on the drives and on the memory,
and everything is reported as healthy. I did the same installation
successfully using the i386 version of Etch. For the successful
installation only two changes were made:
1. I left the results of partitioning the hardware disks from the
last pass with the amd64 installer, and picked up with doing
the RAID configuration as before; and
2. i selected a different ethernet device.
Debian versions:
Debian GNU/Linux testing Etch - Official Snapshot amd64 Binary-1
(20061110) [failed]
Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-1
20070215-23:10 [succeeded]
Hardware:
ASUS A8N-VN motherboard
AMD Athlon(tm) 64 Processor 3800+ (single processor)
2GB dual-channel PC3200 DDR 400
2 x ATA WDC WD2500JS-60N Rev: 10.0 disks
[configured using Linux software RAID level 1; the RAID support on the
motherboard is disabled]
I'll be glad to supply any other information that will help track down
the cause for the failure.
--
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398011: No longer reproductible under new kernel
On Fri, Feb 16, 2007 at 03:04:55PM +0100, Michal Pokrywka wrote: I installed new kernel (linux-image-2.6.18-4-xen-686 2.6.18.dfsg.1-10) over a week ago, and up till now I haven't seen any internal xen networking problems. Look like new xen snapshot fixes those bugs. Thanks, closing then. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398011: marked as done (linux-image-2.6.18-2-xen-k7: DomU network dies during nmap scan)
Your message dated Fri, 16 Feb 2007 11:56:57 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#398011: No longer reproductible under new kernel 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) ---BeginMessage--- Package: linux-image-2.6.18-2-xen-k7 Version: 2.6.18-4 Severity: important The network of a 2.6.18-2 domU image stops working during an nmap SYN scan (nmap -sS). Using tcpdump on dom0 I can see the packet going to the vif, however it never arrives in domU. When I do the same thing using a 2.6.18-1 domU there are no problems (it keeps working). Both domU images were running on a 2.6.18-2 dom0. Nothing suspicious in dmesg. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (101, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-xen-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-2-xen-k7 depends on: ii initramfs-tools 0.85a tools for generating an initramfs ii linux-modules-2.6.18-2-xen-k7 2.6.18-4 Linux 2.6.18 modules on AMD K7 Versions of packages linux-image-2.6.18-2-xen-k7 recommends: ii libc6-xen2.3.6.ds1-7 GNU C Library: Shared libraries [X -- no debconf information ---End Message--- ---BeginMessage--- On Fri, Feb 16, 2007 at 03:04:55PM +0100, Michal Pokrywka wrote: I installed new kernel (linux-image-2.6.18-4-xen-686 2.6.18.dfsg.1-10) over a week ago, and up till now I haven't seen any internal xen networking problems. Look like new xen snapshot fixes those bugs. Thanks, closing then. -- dann frazier ---End Message---
Processed: reassign 411170 to linux-2.6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.27 reassign 411170 linux-2.6 Bug#411170: SATA failures with amd64 version of Etch Bug reassigned from package `kernel' to `linux-2.6'. End of message, 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]
Bug#411170: SATA failures with amd64 version of Etch
On Fri, Feb 16, 2007 at 02:29:36PM -0500, Bob Kline wrote: I have saved as much of syslog as was flushed right before giving up (at the rate it was going it would have taken days to finish -- if ever -- what completed successfully in under a half hour using the i386 version) on the last attempt (I also have the complete partman log), and will be happy to post them (or make them available via HTTP) if you believe they will be of any use. I have run hardware diagnostic tests on the drives and on the memory, and everything is reported as healthy. I did the same installation successfully using the i386 version of Etch. For the successful installation only two changes were made: 1. I left the results of partitioning the hardware disks from the last pass with the amd64 installer, and picked up with doing the RAID configuration as before; and 2. i selected a different ethernet device. Debian versions: Debian GNU/Linux testing Etch - Official Snapshot amd64 Binary-1 (20061110) [failed] Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-1 20070215-23:10 [succeeded] hey Bob, Its very likely that the success of the i386 install wasn't due to the architecture, but rather to a newer kernel used (kernel has changed significantly between 20061110 and 20070215). Please try the 20070215 amd64 installer. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328079: need help verifying #328079
Can someone running an r4k-ip22 Debian kernel check out #328079 and see if it still exists? Specifically, I'd like to know if: 1) Still happens in the latest 2.4 in sarge 2) Still happens with the latest 2.6.18 in etch (or sid) -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
dann frazier wrote: hey Bob, Its very likely that the success of the i386 install wasn't due to the architecture, but rather to a newer kernel used (kernel has changed significantly between 20061110 and 20070215). Please try the 20070215 amd64 installer. Thanks, Dann. I'll give it a try. I was trying (but I guess didn't succeed very well) to pull down the frozen release candidate of Etch when I downloaded the 20061110 images. (I've been planning a switch from RedHat to Debian for my main server, and was trying to time it with the release of Debian 4.0. I figured I'd do my part by testing it before the release to see if I could catch any bugs before it went out the door. Can you tell me which version is the release candidate for 4.0?) I'll report back the results with the newer kernel. -- Bob Kline http://www.rksystems.com mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
On Fri, Feb 16, 2007 at 03:33:58PM -0500, Bob Kline wrote: dann frazier wrote: hey Bob, Its very likely that the success of the i386 install wasn't due to the architecture, but rather to a newer kernel used (kernel has changed significantly between 20061110 and 20070215). Please try the 20070215 amd64 installer. Thanks, Dann. I'll give it a try. I was trying (but I guess didn't succeed very well) to pull down the frozen release candidate of Etch when I downloaded the 20061110 images. (I've been planning a switch from RedHat to Debian for my main server, and was trying to time it with the release of Debian 4.0. I figured I'd do my part by testing it before the release to see if I could catch any bugs before it went out the door. Can you tell me which version is the release candidate for 4.0?) I'll report back the results with the newer kernel. Your best bet is one of these images: http://www.debian.org/devel/debian-installer/ RC1 is no longer usable (see the News section) - RC2 should be available Real Soon Now. I'm going to go ahead and close this bug as I'm fairly certain it has been fixed, but don't hestitate to reopen if you run into it again w/ the latest build. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: marked as done (SATA failures with amd64 version of Etch)
Your message dated Fri, 16 Feb 2007 13:43:43 -0700
with message-id [EMAIL PROTECTED]
and subject line Bug#411170: SATA failures with amd64 version of Etch
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)
---BeginMessage---
Package: kernel
Severity: critical
Multiple attempts to install Etch fail. The syslog file is filled with
failure messages along these lines:
Feb 16 01:09:27 debootstrap: Unpacking replacement base-files ...
Feb 16 01:09:57 kernel: ata1: command 0xca timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sda: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:09:57 kernel: Info fld=0x0
Feb 16 01:09:57 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:09:57 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:09:57 kernel: sdb: Current: sense key: No Sense
Feb 16 01:09:57 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata1: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata1: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sda: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
Feb 16 01:10:27 kernel: ata2: command 0x35 timeout, stat 0x50 host_stat 0x24
Feb 16 01:10:27 kernel: ata2: status=0x50 { DriveReady SeekComplete }
Feb 16 01:10:27 kernel: sdb: Current: sense key: No Sense
Feb 16 01:10:27 kernel: Additional sense: No additional sense
information
I have saved as much of syslog as was flushed right before giving up (at
the rate it was going it would have taken days to finish -- if ever --
what completed successfully in under a half hour using the i386 version)
on the last attempt (I also have the complete partman log), and will be
happy to post them (or make them available via HTTP) if you believe they
will be of any use.
I have run hardware diagnostic tests on the drives and on the memory,
and everything is reported as healthy. I did the same installation
successfully using the i386 version of Etch. For the successful
installation only two changes were made:
1. I left the results of partitioning the hardware disks from the
last pass with the amd64 installer, and picked up with doing
the RAID configuration as before; and
2. i selected a different ethernet device.
Debian versions:
Debian GNU/Linux testing Etch - Official Snapshot amd64 Binary-1
(20061110) [failed]
Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-1
20070215-23:10 [succeeded]
Hardware:
ASUS A8N-VN motherboard
AMD Athlon(tm) 64 Processor 3800+ (single processor)
2GB dual-channel PC3200 DDR 400
2 x ATA WDC WD2500JS-60N Rev: 10.0 disks
[configured using Linux software RAID level 1; the RAID support on the
motherboard is disabled]
I'll be glad to supply any other information that will help track down
the cause for the failure.
--
Bob Kline
http://www.rksystems.com
mailto:[EMAIL PROTECTED]
---End Message---
---BeginMessage---
On Fri, Feb 16, 2007 at 03:33:58PM -0500, Bob Kline wrote:
dann frazier wrote:
hey Bob,
Its very likely that the success of the i386 install wasn't due to
the architecture, but rather to a newer kernel used (kernel has changed
significantly between 20061110 and 20070215). Please try the 20070215
amd64 installer.
Thanks, Dann. I'll give it a try. I was trying (but I guess didn't succeed
very well) to pull
down the frozen release candidate of Etch when I downloaded the 20061110
images. (I've been
planning a switch from RedHat to Debian for my main server, and was trying to
time it with the
release of Debian 4.0. I figured I'd do my part by testing it before the
release to see if I
could catch any bugs before it went out the door. Can you tell me which
version is the release
candidate for 4.0?)
I'll report back the results with the newer kernel.
Your best bet is one of these images:
http://www.debian.org/devel/debian-installer/
RC1 is no longer usable (see the News section) - RC2 should be
available Real Soon Now.
I'm going to go ahead and close this bug as I'm fairly certain it has
been fixed, but don't hestitate to reopen if you run into it again w/
the latest build.
--
dann frazier
---End Message---
Re: Generic IDE support in Debian kernel-image packages
I thought an easy way to set a value to ide_generic_all would be to add module_param(ide_generic_all, int, 0) to the end of ide/pci/generic.c as ata/ata_generic.c does. Looking around for some documentation on module_param (I can only keep so many levels of macro expansion in my head) I found a changelog entry for the ubuntu 2.6.17.1-10.34 linux kernel that claimed to be doing the same thing. In that version they use module_param_named. Either way, the changelog entry makes sense to me: * ide/pci/generic: Add all_generic_ide module option. This is a no-op patch. Only affects people who know to use this option. Option existed already, but didn't work because we compiled this as a module instead of into the kernel. This code seems to drive the whole marvell backend as pata/ide. I am able to read from the CD-ROM drive. In the long term switching from ide to ata, where there is a generic module option and possibly better support and handling, would be best. In the shorter term if Etch will not have 2.6.20 I think that having an install time option of the kernel supporting new hardware in generic mode would be quite useful. -- Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372483: marked as done (linux-image-2.6.16-2-xen-686: Please build a PAE version of the Xen kernel)
Your message dated Fri, 16 Feb 2007 17:03:11 -0800 with message-id [EMAIL PROTECTED] and subject line Please build a PAE version of the Xen kernel 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) ---BeginMessage--- Package: linux-image-2.6.16-2-xen-686 Severity: wishlist Please build a version of the Xen kernel that includes PAE support. This is required to allow Xen to use more than 4gb of memory, and is only required for x86-32, not x86-64. To include this option, you simply need to set the CONFIG_HIGHMEM64G=y. This should be a separate kernel, as the non-PAE kernels will not boot under the PAE hypervisor, and vice-versa. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-rc4-knight-1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) ---End Message--- ---BeginMessage--- Source: linux-2.6 Version: 2.6.18.dfsg.1-10 In the latest version of the linux-2.6 package, the Xen packages are built exclusively with PAE enabled. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ ---End Message---
Bug#411202: linux-image-2.6.18-4-xen-amd64: sata_sil doesn't find disks with Xen kernel
Package: linux-image-2.6.18-4-xen-amd64 Version: 2.6.18.dfsg.1-10 Severity: important I have an AMD64 system with an ATI SATA controller that works fine with the regular kernel, but is unusable with Xen. lspci info: 00:11.0 IDE interface: ATI Technologies Inc ATI 437A Serial ATA Controller (rev 80) 00:12.0 IDE interface: ATI Technologies Inc ATI 4379 Serial ATA Controller (rev 80) boot options: kernel /xen-3.0.3-1-amd64.gz module /vmlinuz-2.6.18-4-xen-amd64 root=/dev/mapper/borges-root ro acpi=off noapic nolapic nosmp console=tty0 module /initrd.img-2.6.18-4-xen-amd64 dmesg output from a successful boot with linux-image-2.6.18-4-amd64: sata_sil :00:11.0: version 2.0 ata1: SATA max UDMA/100 cmd 0xC2010C80 ctl 0xC2010C8A bmdma 0xC2010C00 irq 11 ata2: SATA max UDMA/100 cmd 0xC2010CC0 ctl 0xC2010CCA bmdma 0xC2010C08 irq 11 scsi0 : sata_sil ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: ATA-7, max UDMA/133, 234441648 sectors: LBA48 ata1.00: ata1: dev 0 multi count 16 ata1.00: configured for UDMA/100 scsi1 : sata_sil ata2: SATA link down (SStatus 0 SControl 310) Vendor: ATA Model: WDC WD1200JS-00M Rev: 02.0 Type: Direct-Access ANSI SCSI revision: 05 ata3: SATA max UDMA/100 cmd 0xC2012880 ctl 0xC201288A bmdma 0xC2012800 irq 5 ata4: SATA max UDMA/100 cmd 0xC20128C0 ctl 0xC20128CA bmdma 0xC2012808 irq 5 scsi2 : sata_sil ata3: SATA link down (SStatus 0 SControl 310) scsi3 : sata_sil dmesg output from a failed boot attempt with linux-image-2.6.18-4-xen-amd64: ata1: SATA max UDMA/100 cmd 0xC2012C80 ctl 0xC2012C8A bmdma 0xC2012C00 irq 11 ata2: SATA max UDMA/100 cmd 0xC2012CC0 ctl 0xC2012CCA bmdma 0xC2012C08 irq 11 scsi0 : sata_sil ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) scsi1 : sata_sil ata2: SATA link down (SStatus 0 SControl 310) ata3: SATA max UDMA/100 cmd 0xc2014880 ctl 0xC201488A bmdma 0xC2014800 irq 5 ata4: SATA max UDMA/100 cmd 0xC20148C0 ctl 0xC20148CA bmdma 0xC2014808 irq 5 scsi2 : sata_sil ata3: SATA link down (SStatus 0 SControl 310) scsi3 : sata_sil ata4: SATA link down (SStatus 0 SControl 310) -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.18-4-xen-amd64 depends on: ii e2fsprog 1.39+1.40-WIP-2006.11.14+dfsg-1 ext2 file system utilities and lib ii initramf 0.85e tools for generating an initramfs ii linux-mo 2.6.18.dfsg.1-10Linux 2.6.18 modules on AMD64 linux-image-2.6.18-4-xen-amd64 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410204: linux-image-2.6.18-4-amd64: Data corruption on dm-crypt+XFS
Hi Sami, I'm told that dmcrypt+XFS has never worked in the upstream kernel or in Debian, so this is essentially an unsupported configuration. But you've filed this bug as critical with the justification that it causes serious data loss. Did you lose data as a result of this bug? Could you explain the process by which that happened? It's my impression that this combination is so unreliable that it will oops before you really have a chance to try to use it for storing data, so you can't really lose any data if you can't put it there in the first place. Based on the status as a known-buggy and unsupported config I think this bug should be downgraded to non-RC status for etch, but I'd like to be sure first that I understand the impact of any real-world risk of data loss. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411170: SATA failures with amd64 version of Etch
Bob Kline wrote: Thanks, Dann. I'll give it a try. I'll report back the results with the newer kernel. Works perfectly. Sorry for the confusion about the kernel versions. Guess I was confused about what frozen meant. (Good thing it didn't mean what I thought it meant, or I'd have been stuck with broken support for amd64 in Etch.) Thanks again! -- Bob Kline http://www.rksystems.com mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
