Bug#412194: linux-image-2.6.18-3-k7: total system freeze after max. 10 minutes uptime
On Sun, Feb 25, 2007 at 09:26:10AM +0100, Alexander Schories wrote: OOI, does booting with 'nosmp' affect this hang problem for either of you? Will try this right now and give you response within 1h. In the meantime, do you think the clocksource - as described above - could be the reason? I will try to compile the kernel with either rtc or acpi_pm to see if it solves this bug. However, every successful local recompile does not inevitably mean a true solution for the problem as far as my operating experience reminds me. Sure, it could be, but I don't know anything about the architecture of the kernel's clocksource stuff. Good luck, -- 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#412194: linux-image-2.6.18-3-k7: total system freeze after max. 10 minutes uptime
Hello Steve, uptime with nosmp so far: 57 min. Everything runs fine and smoothly. Of course overall system load is about 5 percent (average) to 20 percent (peak) higher than usual - man, i do love and miss smp.. :D Just kidding, i can easily live happily either with nosmp or particularly with 2.6.17 for now. Maybe other affected users might agree to lower the initial severity to important? But guess who appears on stage now again (dmesg log): #Time: pit clocksource has been installed. #... #Real Time Clock Driver v1.12ac #Generic RTC Driver v1.07 RTC is back for good! This makes me so curios about the mysticals of linux time again: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/ linux-2.6.git;a=commit;h=734efb467b31e56c2f9430590a9aa867ecf3eea1 After reading, re-reading and hopefully understanding i will try to find a solution, why 2.6.18-k7 decides to use Programmable Interval Timer of 1981(!) instead of our even younger and trusted friend rtc or even the fancy acpi_pm .. Once i find helpful information or even a solution, i will post it here. Thank you very much again! Alexander Schories Tuebingen, Germany Sure, it could be, but I don't know anything about the architecture of the kernel's clocksource stuff. Good luck, -- 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#410853: linux-2.6: please add support for armel architecture
* Joey Hess [EMAIL PROTECTED] [2007-02-24 13:30]: It doesn't matter, really, armel is not targeted at etch, so as long as the patch is there we'll be set for lenny. OK, I'll add it to SVN trunk soon. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 412194 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.27 # workaround available (run in UP mode) severity 412194 important Bug#412194: linux-image-2.6.18-3-k7: total system freeze after max. 10 minutes uptime Severity set to `important' from `grave' 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#352765: Successfull Etch install on a Multia
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve Ok, thanks. FWIW, this same chip works fine for me in an LX164 Steve system; but you're the second to report problems with it on Steve other alphas -- unfortunately, though, the first to confirm Steve that it's a problem with current 2.6 kernels. Another example of de2104x misbehaviour on Alpha (this time with an AlphaStation 500/333): 00:06.0 0200: 1011:0002 (rev 24) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 Interrupt: pin A routed to IRQ 29 Region 0: I/O ports at 9800 [size=128] Region 1: Memory at 0225b000 (32-bit, non-prefetchable) [size=128] With de2104x: de2104x PCI Ethernet driver v0.7 (Mar 17, 2004) eth0: 21040 at 0xfc860225b000, 00:f8:22:fb:cd:ec, IRQ 29 With de4x5: :00:06.0: DE434/5 at 0x9800, h/w address 00:00:f8:22:fb:cd, and requires IRQ29 (provided by PCI BIOS). Notice how the ethernet address is shifted by 8 bits to the left. Of course, the real ether address is the one reported by de4x5 (checked from SRM). This is not as bad as with the Multia, since the driver actually works, and I managed to install etch over the network. This is extremly confusing though. Regards, M. -- And if you don't know where you're going, any road will take you there... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412194:
Hello again, i hope, i may take the liberty of presenting you a working solution. So the late grave bug (sorry for this again!) hopefully will be closed quite soon. a) testing info Running 2.6.18-4-k7 without nosmp i looked what clocksources are actually available and which one is used: www:~# cat /sys/devices/system/clocksource/clocksource0/* jiffies tsc pit pit Well, although jiffies and tsc were present and even of higher position and value, 2.6.18-4-k7 still chose pit as clocksource. Interestingly acpi_pm was neither shown nor detected (dmesg log): #ACPI: Unable to locate RSDP #... #ACPI: Interpreter disabled. #Linux Plug and Play Support v0.97 (c) Adam Belay #pnp: PnP ACPI: disabled As i do not use acpi=off or any similar it is hard to guess, why exactly 2.6.18-4-k7 fails to detect the ACPI Root System Description Pointer. Useless to say, why my previous clocksource=acpi_pm was pretty braindead. :D b) possible solution (at least over here :P) No problem, life is great without ACPI, as far as i currently believe :P, so let's slap 2.6.18-4-k7 for serving us pit and not using the Time Step Clock (tsc) we can enjoy since the very first pentium cpu and that 2.6.18-4-k7 has already detected above: www:~# echo tsc /sys/devices/system/clocksource/clocksource0/ current_clocksource www:~# cat /sys/devices/system/clocksource/clocksource0/* jiffies tsc pit tsc www:~# Now, once tsc is on command everything runs smooth again. No freezes. Just smp heaven as it used to be. :) I decided to put clocksource=tsc as a boot option for 2.6.18-4-k7. Rebooted. And my 2.6.18-4-k7 system is up for hours without freezes again. @ Figaro ynegorp_at_charter_dot_net: Please test this, as it is important to know, whether this solution is usefull for your system also. Please let us know asap, so Steve can close this grave thingy, disable or downgrade pit-support in favour of tsc and heat up the autobuilders. Thank you! 8) @ Steve: As i don't exactly know, whether some user might truly need pit on k7-platform as clocksource, i leave the above described decision up to you..:P (shame on me!) Thank you all very much! Alexander Schories Tuebingen, Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352765: Successfull Etch install on a Multia
As a last check for today, I gave the installer a go on an AlphaStation 255/233 (Avanti). 00:0e.0 0200: 1011:0002 (rev 26) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 255 Interrupt: pin A routed to IRQ 15 Region 0: I/O ports at 8400 [size=128] Region 1: Memory at 01209000 (32-bit, non-prefetchable) [size=128] On this machine, de2104x runs perfectly, and get the right ethernet address. So in the de4x5 vs de2104x match, de4x5 wins by 2 to 1 on my sample of 3 old Alpha systems. My vote is clearly for the inclusion of de4x5 in the installer, even if it is disabled by default. M. -- And if you don't know where you're going, any road will take you there... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412139: linux-image-2.6.18-4-686: Not booting. Hangs with message waiting for root
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Made an important discovery today. If I create an initrd image with yaird my system boots. My best guess is that this bug is not related to the linux-image but to mkinitramfs, so this bug should be forwarded to initramfs-tools: $ dpkg -s initramfs-tools Package: initramfs-tools Status: install ok installed Priority: optional Section: utils Installed-Size: 372 Maintainer: Debian kernel team debian-kernel@lists.debian.org Architecture: all Version: 0.85e $ dpkg -s yaird Package: yaird Status: install ok installed Priority: optional Section: utils Installed-Size: 636 Maintainer: Yaird Team [EMAIL PROTECTED] Architecture: i386 Version: 0.0.12-18 From what I have been able to find out it seems like mounting the disks fails and therefore the command to shift root from the initrd image to the root on my disks hangs forever. If my observations holds I would mean this should cause the level raised from important to severe? - -- Hilsen/Regards Michael Rasmussen Get my public GnuPG keys: michael at rasmussen dot cc http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xD3C9A00E mir at datanom dot net http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE501F51C mir at miras dot org http://keyserver.veridis.com:11371/pks/lookup?op=getsearch=0xE3E80917 - -- No matter how good she looks, some other guy is sick and tired of putting up with her crap. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF4bmGQQOPluUB9RwRAhgRAKC84a2TSBAuD/MslIYd4YlfwOMrWgCgqSCF SJdt8AAVsAywFX1A0jO87GA= =w2Ig -END PGP SIGNATURE-
Bug#412194: linux-image-2.6.18-3-k7: total system freeze after max. 10 minutes uptime
I can live single processor for a while. So yes reduction of severity is okay for me. But, I'm thinking that there are a number of k7-smp servers that are the truck horses of various clusters (esp. universities and small research groups) who mayn't tolerate the loss of utility. matthew Alexander Schories wrote: Hello Steve, uptime with nosmp so far: 57 min. Everything runs fine and smoothly. Of course overall system load is about 5 percent (average) to 20 percent (peak) higher than usual - man, i do love and miss smp.. :D Just kidding, i can easily live happily either with nosmp or particularly with 2.6.17 for now. Maybe other affected users might agree to lower the initial severity to important? But guess who appears on stage now again (dmesg log): #Time: pit clocksource has been installed. #... #Real Time Clock Driver v1.12ac #Generic RTC Driver v1.07 RTC is back for good! This makes me so curios about the mysticals of linux time again: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=734efb467b31e56c2f9430590a9aa867ecf3eea1 After reading, re-reading and hopefully understanding i will try to find a solution, why 2.6.18-k7 decides to use Programmable Interval Timer of 1981(!) instead of our even younger and trusted friend rtc or even the fancy acpi_pm .. Once i find helpful information or even a solution, i will post it here. Thank you very much again! Alexander Schories Tuebingen, Germany Sure, it could be, but I don't know anything about the architecture of the kernel's clocksource stuff. Good luck, --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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401979: marked as done (/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq not working properly on Centrino Banias)
Your message dated Sun, 25 Feb 2007 21:41:38 +0200 with message-id [EMAIL PROTECTED] and subject line This bug is solved. 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-3-686 Version: 2.6.18-7 Hello! I'm not able to set /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq to more than 1000 MHz ( the max frequency of my CPU is 1500 MHz ). I am using Debian Etch with the 2.6.18-3-686 precompiled kernel from unstable in an IBM X31 laptop ( Centrino Banias 1500 MHz ). At the end comes the result of cat /proc/cpuinfo, lspci and dmesg in my machine. I'm able to solve the problem compiling a new kernel without the option X86_SPEEDSTEP_CENTRINO_ACPI. The needed option is X86_SPEEDSTEP_CENTRINO_TABLE. I'm also experimenting the problem when I compile the kernel with both options. I would gladly help you in anything I can. Thank you very much for your time. Best regards. - processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 9 model name : Intel(R) Pentium(R) M processor 1500MHz stepping: 5 cpu MHz : 600.000 cache size : 1024 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr mce cx8 sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 tm pbe up est tm2 bogomips: 1199.96 - 0:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03) 00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY 02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) 02:00.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa) 02:00.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02) 02:02.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04) 02:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (MOB) Ethernet Controller (rev 81) - Linux version 2.6.18-3-686 (Debian 2.6.18-7) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Mon Dec 4 16:41:14 UTC 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000d2000 - 000d4000 (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 3ff6 (usable) BIOS-e820: 3ff6 - 3ff77000 (ACPI data) BIOS-e820: 3ff77000 - 3ff79000 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 261984 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 32608 pages, LIFO batch:7 DMI present. ACPI: RSDP (v002 IBM ) @ 0x000f6d70 ACPI: XSDT (v001 IBMTP-1Q0x3020 LTP 0x) @ 0x3ff69e78 ACPI: FADT (v003 IBMTP-1Q0x3020 IBM 0x0001) @ 0x3ff69f00 ACPI:
Bug#412194: linux-image-2.6.18-3-k7: total system freeze after max. 10 minutes uptime
Hello all, I've done as Alexander has suggested: added a boot option in /boot/grub/menu.lst snip title Debian GNU/Linux, kernel 2.6.18-4-k7 root(hd0,0) kernel /vmlinuz-2.6.18-4-k7 root=/dev/sda2 ro clocksource=tsc initrd /initrd.img-2.6.18-4-k7 savedefault rebooted and: # echo tsc /sys/devices/system/clocksource/clocksource0/current_clocksource # cat /sys/devices/system/clocksource/clocksource0/* jiffies tsc pit tsc We are up and running now (45min.). Alex. has been up for some hours (9+) using this method. So maybe others can use this and help us understand later the why of it. Anyway, fingers crossed let us see matthew Alexander Schories wrote: Hello Steve, uptime with nosmp so far: 57 min. Everything runs fine and smoothly. Of course overall system load is about 5 percent (average) to 20 percent (peak) higher than usual - man, i do love and miss smp.. :D Just kidding, i can easily live happily either with nosmp or particularly with 2.6.17 for now. Maybe other affected users might agree to lower the initial severity to important? But guess who appears on stage now again (dmesg log): #Time: pit clocksource has been installed. #... #Real Time Clock Driver v1.12ac #Generic RTC Driver v1.07 RTC is back for good! This makes me so curios about the mysticals of linux time again: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=734efb467b31e56c2f9430590a9aa867ecf3eea1 After reading, re-reading and hopefully understanding i will try to find a solution, why 2.6.18-k7 decides to use Programmable Interval Timer of 1981(!) instead of our even younger and trusted friend rtc or even the fancy acpi_pm .. Once i find helpful information or even a solution, i will post it here. Thank you very much again! Alexander Schories Tuebingen, Germany Sure, it could be, but I don't know anything about the architecture of the kernel's clocksource stuff. Good luck, --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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412194: Cool!
So maybe others can use this and help us understand later the why of it. Well, timing (clock and event) is possibly even more critical for smp architecture than for single cpu systems. Trying to run k7-smp- systems with originally 1981 based timers (pit) as clocksource seems to be strange right from the beginning.. Only a debug build coupled with knowledge and time could lead to the exact faulty code. As far as i understand from the current kernel discussions, http://marc.theaimsgroup.com/?t=11720995555r=1w=2 http://marc.theaimsgroup.com/?l=linux-kernelm=117215082521287w=2 at least 2.6.21rc has already additional patches regarding this issue. It will only use pit as possible eventsource, but possibly not as clocksource at all anymore. So in the end i personally feel that there is no need to annoy kernel.org gurus about that - this decision is up to SteveCo. anyway. And: This bug can be closed right now, means after pit is disabled as clocksource for k7-kernels. Again, this is just my personal view. Thank you all once again! Alexander Schories Tuebingen, Germany -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: bug 409313 is forwarded to http://marc.theaimsgroup.com/?l=linux-sparcm=117243416104218w=2
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.27 forwarded 409313 http://marc.theaimsgroup.com/?l=linux-sparcm=117243416104218w=2 Bug#409313: linux-image-2.6.18-4-sparc64: Netra X1 - Kernel unaligned access in rp_rcv and ip_fast_csum Noted your statement that Bug has been forwarded to http://marc.theaimsgroup.com/?l=linux-sparcm=117243416104218w=2. 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]
Processed: Re: linux-2.6: capi_{cmsg,message}2str not thread-safe; vulnerable to buffer overflow
Processing commands for [EMAIL PROTECTED]:
tags 411294 patch
Bug#411294: linux-2.6: capi_{cmsg,message}2str not thread-safe; vulnerable to
buffer overflow
Tags were: upstream security
Tags added: patch
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]
Bug#411294: linux-2.6: capi_{cmsg,message}2str not thread-safe; vulnerable to buffer overflow
tags 411294 patch thanks There's a patch upstream: http://bugzilla.kernel.org/attachment.cgi?id=10526action=view It applies cleanly to version 2.6.18.dfsg.1-10 with a small offset in some files, but I haven't checked whether any other changes might be needed for 2.6.18. Ben. -- Ben Hutchings When you say `I wrote a program that crashed Windows', people just stare ... and say `Hey, I got those with the system, *for free*'. - Linus Torvalds signature.asc Description: This is a digitally signed message part
Bug#411294: linux-2.6: capi_{cmsg,message}2str not thread-safe; vulnerable to buffer overflow
user debian-kernel@lists.debian.org usertags 411294 dkt-waiting-etch-update thanks On Sun, Feb 25, 2007 at 10:11:54PM +0100, Ben Hutchings wrote: It applies cleanly to version 2.6.18.dfsg.1-10 with a small offset in some files, but I haven't checked whether any other changes might be needed for 2.6.18. The current patch includes an abi change. Also we should wait for the final version to appear in linus tree. Bastian -- Violence in reality is quite different from theory. -- Spock, The Cloud Minders, stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376652: USB problem on kernel linux-image-2.6.18-4-686
How did you solve your problem? On 2/21/07, Scott Anderson [EMAIL PROTECTED] wrote: I have the same problem with my Sansa c240 MP3 player. When I connect to the USB port, my syslog shows: Feb 21 15:00:09 kernel: usb 5-7: new high speed USB device using ehci_hcd and address 2 Feb 21 15:00:09 kernel: usb 5-7: device descriptor read/64, error -71 Feb 21 15:00:09 kernel: usb 5-7: device descriptor read/64, error -71 Feb 21 15:00:09 kernel: usb 5-7: new high speed USB device using ehci_hcd and address 3 Feb 21 15:00:10 kernel: usb 5-7: device descriptor read/64, error -71 Feb 21 15:00:10 kernel: usb 5-7: device descriptor read/64, error -71 This problem is quite common in Linux 2.6.10 it seems. Removing ehci_hdc allows the MP3 player to be detected, but now I don't have high speed use of my USB bus. Feb 21 15:04:52 kernel: ehci_hcd :00:1d.7: remove, state 1 Feb 21 15:04:52 kernel: usb usb5: USB disconnect, address 1 Feb 21 15:04:52 kernel: ehci_hcd :00:1d.7: USB bus 5 deregistered Feb 21 15:04:52 kernel: ACPI: PCI interrupt for device :00:1d.7disabled Feb 21 15:05:10 kernel: usb 4-1: new full speed USB device using uhci_hcd and address 3 Feb 21 15:05:10 kernel: usb 4-1: configuration #128 chosen from 1 choice Feb 21 15:05:11 kernel: Initializing USB Mass Storage driver... Feb 21 15:05:11 kernel: scsi2 : SCSI emulation for USB Mass Storage devices Feb 21 15:05:11 kernel: usbcore: registered new driver usb-storage Feb 21 15:05:11 kernel: USB Mass Storage support registered. Feb 21 15:05:11 kernel: usb-storage: device found at 3 Feb 21 15:05:11 kernel: usb-storage: waiting for device to settle before scanning Feb 21 15:05:16 kernel: Vendor: SanDisk Model: Sansa c240Rev: Sans Feb 21 15:05:16 kernel: Type: Direct-Access ANSI SCSI revision: 00 Feb 21 15:05:16 kernel: Vendor: SanDisk Model: Sansa c240Rev: Sans Feb 21 15:05:16 kernel: Type: Direct-Access ANSI SCSI revision: 00 Feb 21 15:05:16 kernel: usb-storage: device scan complete Feb 21 15:05:16 kernel: SCSI device sda: 2006528 512-byte hdwr sectors (1027 MB) Feb 21 15:05:16 kernel: sda: Write Protect is off Feb 21 15:05:16 kernel: sda: Mode Sense: 3f 00 00 08 Feb 21 15:05:16 kernel: sda: assuming drive cache: write through Feb 21 15:05:16 kernel: SCSI device sda: 2006528 512-byte hdwr sectors (1027 MB) Feb 21 15:05:16 kernel: sda: Write Protect is off Feb 21 15:05:16 kernel: sda: Mode Sense: 3f 00 00 08 Feb 21 15:05:16 kernel: sda: assuming drive cache: write through Feb 21 15:05:16 kernel: sda: sda1 sda2 Feb 21 15:05:16 kernel: sd 2:0:0:0: Attached scsi removable disk sda Feb 21 15:05:16 kernel: sd 2:0:0:1: Attached scsi removable disk sdb I'll add my kernel log, just in case it helps track down the problem. Scott Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.com
where does initramfs get the /init script?
Hello, I extract the /boot/initrd.img-2.6.18-3-486 and I see the following, all directories: /bin/conf/etc/lib/modules/sbin/scripts I have grub set to go no further than (initramfs) Once I have booted to that point I see the file /init script. How is the /init script created when I don't see this within the initrd file: initrd.img-2.6.18-3-486? background info I boot into (initramfs) by having the following in my grub menu.1st: title test root (hd0,0) kernel /boot/vmlinuz-2.6.18-3-486 root=/ ramdisk_size=1048576 rw init=/bin/sh initrd /boot/initrd.img-2.6.18-3-486 /background info Anyone? Thanks and best regards, Richard Jenniss. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
