Little Bang timing
Hi maks I wanted to time the new pre cached boot scripts when I read about them, but no watch battery... Anyways, today I grabbed my old pocketwatch and timed the boot. 45 seconds from grub-pc selection to cli login. I upgraded both initramfs-tools and linux-image-2.6.32-4-686 than timed the reboot at 30 seconds from Grub to login. Very nice. I have a few more installations to test all of next week and will look for boot messages as I try to follow what the team has done vvill -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/733269.42823...@web35605.mail.mud.yahoo.com
Bug#577534: base: fails too with -11 kernel
#wodim --devices might show the correct /dev that is on the #lshw list --- On Thu, 4/22/10, Javier Barroso javier.barr...@isotrol.com wrote: From: Javier Barroso javier.barr...@isotrol.com # lshw # cdrom output *-cdrom description: DVD writer product: DVD+-RW GSA-H53L vendor: HL-DT-ST physical id: 0.0.0 bus info: s...@0:0.0.0 logical name: /dev/cdrom logical name: /dev/cdrom1 logical name: /dev/cdrw logical name: /dev/cdrw1 logical name: /dev/dvd logical name: /dev/dvd1 logical name: /dev/dvdrw logical name: /dev/dvdrw1 logical name: /dev/scd0 logical name: /dev/sr0 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/390827.70227...@web35602.mail.mud.yahoo.com
Bug#583390: linux-image-2.6.32-5-686: Hangs with ata frozen on boot
[sorry for the noise]
I haven't filed my own bugreport because it's not a big issue for me, ATM.
I'd rather wait the extra minute or so during boot, than change my disk maps
and menus...
I have a very similar dmesg ata1: lost interrupt (Status 0x58) - and the
kernel times out for about (30 seconds on each PATA Channel)
while waiting for dma [on the slave of both PATA channels]...
Both primary and secondary channel masters are hard disks and both primary and
seconardy slaves are DVD burners...
The primary PATA channel slave is initialized at 33mbs
and the secondary channel slave is initialzed at 25mbs on the bus..
I saw this behavior once before while testing the last pre-release of the d-i
just before Lenny was released. I worked around the issue at that time by
fiddling with (ATA/IDE Configuration - enhanced/legacy SATA/PATA) and onboard
(SATA RAID) BIOS settings...
Before sending this I
Unplugged both DVD burners, rebooted
Double checked disk jumpers, rebooted.
Disabled BIOS setting PCI ATA Bus Master rebooted
Installed 2.6.34-1-686, rebooted
Disabled ATA/IDE Configuration BIOS setting, rebooted
Changing BIOS setting:
Drive Configuration -
ATA/IDE Configuration (Legacy) -
Legacy IDE Channels (SATA PO/P1 only)
gets rid of the kernel timeout
but no longer initializes any of the PATA Channels
Intel D865PERLK mobo - 2 SATA channels - first generation
All disk channels populated.
--- On Thu, 5/27/10, Adrian Lang deb...@adrianlang.de wrote:
From: Adrian Lang deb...@adrianlang.de
Subject: Bug#583390: linux-image-2.6.32-5-686: Hangs with ata frozen on boot
To: Debian Bug Tracking System sub...@bugs.debian.org
Date: Thursday, May 27, 2010, 10:44 AM
Package: linux-2.6
Version: 2.6.32-13
Severity: important
Tags: sid
After Loading, please wait..., linux hangs for 30
seconds. after that, it logs:
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
frozen
ata1.00: cmd a0/01:00:00:80:00/00:00:00:00:00/a0 tag 0 dma
16512 in
res
40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
ata1.00: status: { DRDY }
These messages are repeated after 40 seconds, and again 40
seconds.
linux-image-2.6.32-3-686 works, linux-image-2.6.33-2-686
and linux-image-2.6.34-1-686 show the same behaviour.
-- Package-specific info:
** Kernel log: boot messages should be attached
** Model information
not available
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation
82G33/G31/P35/P31 Express DRAM Controller [8086:29c0] (rev
10)
Subsystem: ASUSTeK Computer Inc.
P5KPL-VM Motherboard [1043:82b0]
Control: I/O- Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+
ParErr- DEVSEL=fast TAbort- TAbort- MAbort+
SERR- PERR- INTx-
Latency: 0
Capabilities: access denied
00:01.0 PCI bridge [0604]: Intel Corporation
82G33/G31/P35/P31 Express PCI Express Root Port [8086:29c1]
(rev 10) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B-
ParErr- DEVSEL=fast TAbort- TAbort- MAbort-
SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=01,
subordinate=01, sec-latency=0
Memory behind bridge: fc00-fe9f
Prefetchable memory behind bridge:
e000-efff
Secondary status: 66MHz- FastB2B-
ParErr- DEVSEL=fast TAbort- TAbort- MAbort+
SERR- PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA+
MAbort- Reset- FastB2B-
PriDiscTmr-
SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: access denied
Kernel driver in use: pcieport
00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7
Family High Definition Audio Controller [8086:27d8] (rev
01)
Subsystem: ASUSTeK Computer Inc.
P5KPL-VM Motherboard [1043:8290]
Control: I/O- Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B-
ParErr- DEVSEL=fast TAbort- TAbort- MAbort-
SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at fbffc000 (64-bit,
non-prefetchable) [size=16K]
Capabilities: access denied
Kernel driver in use: HDA Intel
00:1c.0 PCI bridge [0604]: Intel Corporation N10/ICH 7
Family PCI Express Port 1 [8086:27d0] (rev 01) (prog-if 00
[Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle-
MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B-
ParErr- DEVSEL=fast TAbort- TAbort- MAbort-
SERR- PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=03,
subordinate=03, sec-latency=0
I/O behind bridge: 1000-1fff
Memory behind bridge: 8000-801f
Prefetchable memory behind bridge:
Re: Kernel package for powerpcspe
http://wiki.debian.org/DerivativesFrontDesk --- On Wed, 6/30/10, Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote: From: Sebastian Andrzej Siewior sebast...@breakpoint.cc Subject: Kernel package for powerpcspe To: debian-kernel@lists.debian.org Cc: Moffett, Kyle D kyle.d.moff...@boeing.com Date: Wednesday, June 30, 2010, 5:32 AM Hello Kernel team, Currently I plan to come up with a kernel package for the powercpspe which is currently in debian-ports. I have a few questions: - what is the easy way to create the kernel config? I guess you don't use vim for that :) I've found a ruby script in an earlier svn revision but it is gone now. - what are the rules for out-of-tree patches? I guess patches which are merged upstream but not yet in the debian-kernel are okay, everything else is unlikely to be accepted. - the initrd has to have an uImage header around it. Currently I install a script to /etc/kernel/postinst.d/$(REAL_VERSION) to get this done during installation of the package. Is this okay or is something else prefered? - besides the kernel and initrd I have a device tree which contains all the relevant device informations for a single board. Is it okay to throw them in at $(INSTALL_DIR)/$(BOARD)-$(REAL_VERSION).dtb? It is very convinient in the D-I case because after the install the user has everything in /boot. Sebastian more info http://www.debian.org/ports/ http://www.debian-ports.org/ http://wiki.debian.org/PowerPCSPEPort -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/320517.97067...@web35605.mail.mud.yahoo.com
2.6.35-rc5-686, nouveau, stumpwm - cleanest boot
2.6.35-rc5-686 is loading without any errors. at least without any errors that I can find... Thanks! -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/692095.81192...@web35603.mail.mud.yahoo.com
Bug#593432: Black screen with kms and i915
I have a i830 also.. If you turn off KMS the old framebuffer driver works fine obviously, this means 2.6.34 and beyond are unusable at this point in time on the i830 although I did get the blacklight on in the terminal using 2.6.35 with KMS on My Toshiba 1200-S212 i830 only has 8 megs of video ram, which I concluded was not enough to run the new drmframebuffer drivers... Than intel introduced the virtual memory stuff, but AFAICT it's not active on the i830 yet from memory (so forgive the incomplete description) both pipe A and pipe B are active when cloning the xorg.conf device and [screen or monitor] sections... but I also haven't attached an external monitor to look at how it behaves... 1there are only so many (24) hours in one day [-) ... - Original Message From: Julien Cristau jcris...@debian.org To: san...@zedat.fu-berlin.de; 593...@bugs.debian.org Sent: Wed, August 18, 2010 8:55:35 AM Subject: Bug#593432: Black screen with kms and i915 retitle 593432 [i830] Black screen with kms and i915 kthxbye On Wed, Aug 18, 2010 at 07:53:29 +0200, san...@zedat.fu-berlin.de wrote: When booting the screen goes black at the moment the frame buffer is switched on. Booting continues until the 'login prompt', but the screen remains black. When switching to a text screen, the screen gets darker for a second, but no text login appears. I can then, however, login blind and the machine works. For example, I can reboot it when logging in as root and calling 'shutdown' (all blind, of course). The problem goes away when adding the line options i915 modeset=0 to the file /etc/modprobe.d/i915-kms.conf, so I guess it is a kms problem. If I wasn't a newbie I'd mark this bug as 'important', because it left a freshly installed machine more or less completely unusable. Is this a regression from a previous revision? Can you attach the dmesg from a kms boot? Cheers, Julien -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/855539.98275...@web35604.mail.mud.yahoo.com
2.6.39-5-686-pae
Ben Max Julien Kibi Sven I''m getting a segfault with Bug listed in dmesg, but different after today's upgrade than it was yesterday. I'm very happy to wait till tomorrow for a possible fix to be uploaded. I'm also very happy to file a bug if anyone wants to look at my old intel i865 chipset mobo with nvidai 6600 /256MB agp card showing a few boot issues ( I think loading modules - but it changes daily, so it hard for me to say for sure. KUDO to kernel KUDO to xfs Will -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/816864.79759...@web35602.mail.mud.yahoo.com
upgrading from rc kernel [patch?]
Could adding a 0 to the rc kernel name reduce kernel upgrade issues, without causing other issues? - 2.6.39-rc4-686-pae + 2.6.39-0rc4-686-pae -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/237917.83710...@web35607.mail.mud.yahoo.com
re:627019 39 steadily improving on i865 chipset
After upgrading to 2.6.39-1-686-pae I have fewer boot attempts hanging. Usually one or two before a successful boot. It appears that if I downgrade udev one version (udev_169-1) I get better results (at least with today set of packages). http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627019 I've also noticed that the 2 i865 chipset machines are much more sensitive to booting the 39 kernels than the i915 chipset machine. The i915 machine was booting 39 consistently with 39-rc6 and beyond, -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/613067.17361...@web35606.mail.mud.yahoo.com
Re: upgrading from rc kernel [patch?]
Tue, May 24, 2011 5:18:21 UTC Ben wrote: On Tue, 2011-05-24 at 07:35 -0700, Will Set wrote: Could adding a 0 to the rc kernel name reduce kernel upgrade issues, without causing other issues? - 2.6.39-rc4-686-pae + 2.6.39-0rc4-686-pae The linux-version command can be used for sorting kernel version numbers, if that's what you are concerned about. After switching the debian pre release kernel names from trunk to rc, I read in an email from the kernel team, iirc the rc naming convention is also problematic . I notice the rc kernels initramfs images being updated after a newer kernel has been installed. $ kernel-version list --paths 2.6.39-1-686-pae /boot/vmlinuz-2.6.39-1686-pae 2.6.39-rc4-686-pae /boot/vmlinuz-2.6.39-rc4-686-pae 2.6.39-rc5-686-pae /boot/vmlinuz-2.6.39-rc5-686-pae 2.6.39-rc6-686-pae /boot/vmlinuz-2.6.39-rc6-686-pae 2.6.39-rc7-686-pae /boot/vmlinuz-2.6.39-rc7-686-pae so, whenever update-initramfs -u is called, initrd.img-2.6.39-rc7-686-pae is updated. Adding a 0 to the rc name[s] /var/lib/initramfs-tools/2.6.39-0rc*-686-pae fixes that updating issue on my installs. Ben. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/710747.80886...@web35606.mail.mud.yahoo.com
Bug#627837: linux-2.6: Aufs apparently silently dropped, breaking debian-live
Daniel Baumann daniel.baum...@progress-technologies.netMay 29, 2011 5:18:27 PM On 05/29/2011 10:34 PM, Julien Cristau wrote: The maintainers have already made that call, and I don't see a reason to override their decision. so no change after squeeze, the release team gives a shit about breaking debian-live, sigh. but don't worry, from now on, i will not care anymore either. It's not fun here either. fwiw: 38 started getting less stable than what I'm used to seeing for at least a year now. 39 is much more volatile than any other kernel I've seen in unstable for more than a year. I have no advice for either side of this. bye, have fun. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/257056.62243...@web35602.mail.mud.yahoo.com
Re: kernel oops and kerneloops.org
Stappers stapp...@stappers.nlTue, June 14, 2011 2:24:17 AM wrote: [...] I have the package kerneloops installed. Yesterdag I had in /var/log/syslog these lines: Jun 13 21:04:44 debian kerneloops: Submitted 1 kernel oopses to www.kerneloops.org Jun 13 21:04:44 debian kerneloops: kerneloops.org: oops is posted as \ http://www.kerneloops.org/submitresult.php?number=3337652 Today is still no data at that URL. a few hints: On the kerneloops.org page you can find in the upper right hand corner both a, Function Search Box and a Filename Search Box. as well as other searchable statistics at the home page http://www.kerneloops.org/ What should I change so that my next kernel oops will be visible at kerneloops.org? I'm waiting till next time to see if mine shows up (wink).. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/867817.7116...@web35602.mail.mud.yahoo.com
Bug#632734: Strange
--- On Mon, 7/25/11, Frank McCormick fmccorm...@videotron.ca wrote: From: Frank McCormick fmccorm...@videotron.ca Subject: Bug#632734: Strange To: Ben Hutchings b...@decadent.org.uk Cc: 632...@bugs.debian.org Date: Monday, July 25, 2011, 1:09 PM On 22/07/11 02:04 PM, Frank McCormick wrote: On 21/07/11 08:10 PM, Ben Hutchings wrote: Please always cc the bug address when replying to bug-related mails. On Sat, 2011-07-16 at 09:54 -0400, Frank McCormick wrote: On 11/07/11 12:12 AM, Ben Hutchings wrote: On Tue, 2011-07-05 at 17:29 -0400, Frank wrote: On 05/07/11 04:23 PM, Ben Hutchings wrote: On Tue, Jul 05, 2011 at 02:48:26PM -0400, Frank M wrote: I find it strange that the PAE kernel is the ONLY one which gives me any trouble. I guess it could be hardware related, but 2.6.38-1 and 2.6.38-2 have both been booting fine for months. Is there something about the PAE series that would uncover hardware faults which may have existed for a long time ? Have you tried booting those earlier versions recently? Yes I've been booting them everyday for the past month or so - the PAE series is the first time in years, literally, that I have had problems like this. Frank, I reported very similar findings also. I also have been keeping track of 5 or 6 other bug reports that look similar, with a Pentium 4 3GHz 800 MHz bus / 512kb of L2 cache see my bug report at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627019 My Pentium D 3GHz 800 MHz bus / 1mb of L2 cache ( next generation) is not showing any of these issues ( yet). This sounds like there is some sort of hardware fault, but I can't see why it would only occur when using PAE. It is just possible that the circuitry for PAE is faulty, but I think that is only a very small part of the chip. Please do consider the suggestions inhttp://www.bitwizard.nl/sig11/. Will do. Well I have solved this problem..but I'm not sure I like the solution. I installed the new 3.0.0 kernel this morning and started trying changing things in the BIOS setup. Nothing worked to allow me to boot UNTIL I turned off what Intel calls hyper-threading. Now the kernel boots fine, but according to lshw-gtk, the system sees only one CPU. This is a dual-core system which was always seen by Linux as a dual core with in effect two CPU's. What's the connection between hyper-threading , and PAE which is apparently the only change in the new kernels ?? Again, very similarly, I have been able to boot successfully using the 486 flavor kernel ( but also not gettting SMP support for hyper threading. I have had some success boot the 686-pae flavor by adding debug=3 or debug=4 to the linux commandline in grub-pc I also have compiled a vanilla (upstreams default config) linux-image-3.0-rc7 and it worked well for several days ( but still showing minor glitches at boot time) But, after the udev upgrade to 172-1 the upstream kernel started showing the same seg faults and other stuff the debian 686-pae flavor kernels since 2.6.39-rc3-686-pae (iirc) have been showing. I just upgraded to 3.0.0-1-686-pae and it took three reboots to get to a login screen. The hang point on the second boot attempt was waiting for dev to be fully populated ( which froze there, but I only waited a minute or two before I shut down than rebooted. Than the third time I still got a udevd seg fault, but it was not fatal this time and I'm able to login. I didn't upgrade the grub packages yet, holding for next time. -- Cheers Frank -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1311695544.23330.yahoomailclas...@web35607.mail.mud.yahoo.com
Re: lkcl interference with initramfs-tools bug handling
On Tuesday, August 23, 2011 9:37 PM Ben Hutchings wrote: On Tue, Aug 23, 2011 at 11:58:33PM +0300, Touko Korpela wrote: On Tue, Aug 23, 2011 at 08:05:26PM +, maximilian attems wrote: On Mon, Aug 22, 2011 at 09:10:17PM +0100, Ben Hutchings wrote: Luke Kenneth Casson Leighton l...@lkcl.net (lkcl) reported bug #636123, which then received a follow-up which is very clearly (to me) this guy is adding to much noise, so that various bug reports get useless. if strong words didn't help yet, please cut him off. Maybe give him one more chance. I told him that messages to bug address don't reach bug submitter (he wasn't aware of it, now he knows). That has caused some miscommunication before. It would be good if more people could help with bugs if right ways are told. Kernel team: Thanks for the work keeping debian kernel clean... Sorry in advance, for any noise this email may produce. The whole problem at the moment is that he is contacting another bug submitter and wasting the other persons's time. So it would have been better if you had not let him know hbout the submitter address. We absolutely do welcome people helping to triage bugs, but lkcl is hindering us through bad information and a worse attitude. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110823213707.gh29...@decadent.org.uk -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314194550.88560.yahoomail...@web35608.mail.mud.yahoo.com
Re: e1000e update for Debian 6.0 'squeeze'
From: Jeff Kirsher jeffrey.t.kirs...@intel.com To: Ben Hutchings b...@decadent.org.uk Cc: Debian kernel maintainers debian-kernel@lists.debian.org; e1000-de...@lists.sourceforge.net e1000-de...@lists.sourceforge.net Sent: Tuesday, August 30, 2011 7:59 AM Subject: Re: e1000e update for Debian 6.0 'squeeze' On Mon, 2011-08-29 at 20:12 -0700, Ben Hutchings wrote: On Fri, 2011-06-03 at 04:16 +0100, Ben Hutchings wrote: On Thu, 2011-05-19 at 15:29 +0100, Ben Hutchings wrote: The Debian kernel team regularly backports driver updates to the Linux kernel in stable releases to add support for new hardware. In the current stable release, the Linux kernel is based on longterm series 2.6.32.y. We generally prefer to cherry-pick bug fixes and new hardware support, but there are so many interrelated changes to e1000e since 2.6.32 that this seems to be impossible. So I've prepared a backport of e1000e from Linux 2.6.38, which is available in the git branch: git://git.debian.org/kernel/linux-2.6.git e1000e-test The kernel configuration files we use are at http://kernel.alioth.debian.org/config/2.6.32-33/. We would appreciate any help Intel can provide in testing this, and any advice on changes that should be added or reverted. I'll also be looking at doing this for igb later. Full source and binary packages containing e1000e, igb, and other backported drivers can now be found at: http://people.debian.org/~benh/packages/ I have not yet received any testing feedback, and without that we will have to defer any updates to Debian 6.0.3 (about another 3 months away). Unfortunately that's exactly what happened. But let's try this again. I updated igb and igbvf to 3.0 as there seemed to be significant additions in hardware support. e1000e is still at 2.6.38 with one later fix. The backports of e1000e, igb and igbvf are available in the git branch: git://git.debian.org/kernel/linux-2.6.git squeeze The changes start after tag debian/2.6.32-35squeeze1. The kernel configuration files we use are at http://kernel.alioth.debian.org/config/2.6.32-33/. Full source and binary packages containing these and other backported drivers can now be found at: http://people.debian.org/~benh/packages/ We would appreciate any help you can provide in testing this, and any advice on changes that should be added or reverted. Ben. Ben, I cannot guarantee any testing resources right now, when would like testing to be done/completed? Hi Jeff, I think the main idea here is to get a test of the e1000e driver, to see if it works on the hardware, before the updates for Debian stable are released, in 3 months or so. It seems that there has been no response from anyone that has the new intel e1000e gigabit nic yet to verify Ben's work on the driver. Any, testing of hardware using the e1000e driver found http://people.debian.org/~benh/packages/ here or development documentation intel is willing to provide for e1000e and/or other newer released intel hardware ie: igb would help Debian speed it's release of updates to the Debian Stable Release in 3 months or so. Will Cheers, Jeff -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314715674.24054.yahoomail...@web35606.mail.mud.yahoo.com
Bug#627019: Bug#632734: 627019:
Tuesday, August 30, 2011 5:59 PM wzab w...@ise.pw.edu.pl wrote: I found this bug, when I was looking for solution for my problem related to the newest kernels and a machine based on D865GBF motherboard. I have two i865 mobos D865GRH, D865PERLK that both have trouble booting 2.6.39 and 3.0.0 kernels I was striked by the fact, that problem reported here occured in a machine with the same motherboard and the newest kernel. My problem (machine not starting when HT is on) is reported as Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597 and was later redirected to https://bugzilla.kernel.org/show_bug.cgi?id=38262 Yes Len Brown suggested workaround processor.nocst=1 is working for me so far too.. Will Maybe these two problems are correlated? (The same applies also to Debian bug 630031 ) -- Regards, WZab -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314811360.47922.yahoomail...@web35607.mail.mud.yahoo.com
Bug#627019: Bug#632734: 627019:
Wednesday, August 31, 2011 1:22 PM Will Set debiandu...@yahoo.com wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627019 I have two i865 mobos D865GRH, D865PERLK that both have trouble booting 2.6.39 and 3.0.0 kernels Yes Len Brown suggested workaround https://bugzilla.redhat.com/show_bug.cgi?id=727865#c16 processor.nocst=1 is working for me so far too.. Will -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1314813144.49867.yahoomail...@web35608.mail.mud.yahoo.com
Bug#641176: xserver-xorg-video-radeon: Radeon 9200SE, Detected VRAM RAM=0M, BAR=0M
Monday, September 19, 2011 9:18 AM Michel Dänzer wrotew: On Mon, 2011-09-19 at 15:55 +0300, Tomi Leppänen wrote: ma, 2011-09-19 kello 12:53 +0200, Michel Dänzer kirjoitti: On Son, 2011-09-18 at 11:38 +0300, Tomi Leppänen wrote: la, 2011-09-17 kello 06:10 -0700, Will Set kirjoitti: Saturday, September 17, 2011 6:49 AM Tomi Leppänen wrote: pe, 2011-09-16 kello 15:43 -0500, Jonathan Nieder kirjoitti: I wonder why my grub is just some colorful crap on bottom of my screen. I can't really edit anything on fly but I have to always make changes to /etc/default/grub and then issue update-grub. That may have something to do with this bug. It's further indication that the problem may stem from the BIOS, or possibly even the hardware itself. If it helps, I have a Nvidia GeForce 2 MX (AGP) and it seems to work completely. (though that card doesn't support interlacing) I can get dmesg for that too if needed but it takes probably a bit longer. I don't think that'll buy anything at this point. Problem iirc, both your other video cards -- ATI Rage 128VR and Nvidia GeForce 2 MX (AGP) -- have less than 64 MB of VRAM. I've found with my old AGP cards, 64MBs VRAM to be a minimum for mode switching as a general rule. Mobos with video onboard have different limits. I'm starting to see other pentium 4 limits with the newer 3.0.0 kernels, so I'm not really surprised having troubles trying 3.0.0 kernels And the PCI card is IMHO way to new to be used in the PCI slot of that old mobo. The video card has almost as much processing power as the mobo does. I'll bet the mobo's chipset can't access even half that Radeon 9200SE's resources. I also noticed that all of my memory is LOWMEM. Though graphics card doesn't change that (tried with ATI Rage 128VR that has trouble with DRI on Debian 6). Does that card basically work though? Do you also get PCI related errors in dmesg with it? Yes, it does work. Then it seems most likely that the problem is with the BIOS or the card. At this point I don't see many options left other than trying if the card works in another machine or with another OS, or maybe trying to re-flash the ROM image on the card if that's possible. I agree, especially if the BIOS is not being changed to reflect the PCI socket is being used for video instead of the mobos AGP slot. http://www.gigabyte.lv/products/mb/specs/ga-6bxe.html?print_page=1 I'd suggest using a Debian Live CD while testing, especially with older and oddly mixed hardware. http://cdimage.debian.org/cdimage/release/current-live/i386/iso-hybrid/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1316443018.87530.yahoomail...@web35607.mail.mud.yahoo.com
Bug#656375: libdrm-intel1: screen corruptions, kernel message *ERROR* Prepared flip multiple times
Saturday, January 21, 2012 4:17 AMJonathan Nieder wrote: Cyril Brulebois wrote: Jonathan Nieder jrnie...@gmail.com (21/01/2012): After logging into GNOME, I started getting LOTS of [ 239.494761] [drm:intel_prepare_page_flip] *ERROR* Prepared flip multiple times in kernel log repeated ever few microseconds. Already fixed 2 weeks ago... Kernel log = kernel bug. :) Reassigning. No. Please don't waste our time. Sorry to waste your time. My tongue was in cheek when I said kernel log = kernel bug, and I apologize for that. However, I fear I must have committed some other offense on top of that. Could you elaborate so I know what not to do again? Confused, Jonathan Will
Bug#656375: libdrm-intel1: screen corruptions, kernel message *ERROR* Prepared flip multiple times
Saturday, January 21, 2012 5:20 AMCyril Brulebois wrote: [...] a couple of my installs ( syslogs ) grew to several GiB`s for the two weeks of so I noticed this page_flip spamming on my old i865g stuff. Back to the original topic: it is very difficult for Intel techs to support old (and I'm just echo-ing their views on hardware) hardware, even if older versions of the x driver might have worked at some point. That is sad, but that's the state of affairs today. I follow right behind you on this note. I'm still amazed at how much hardware (old and new) this OS supports. Sorry for the extra noise. Will Mraw, KiBi.
Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing
Thursday, October 13, 2011 9:06 AM martin f krafft wrote: also sprach Jort Koopmans jort.koopm...@gmail.com [2011.10.12.2143 +0200]: In the mean while I've checked another solution; moving the call to the local-top scripts till after the ROOTDELAY loop (within the local file). init-top/udev also uses it. thanks for the clues :) This works in my config. But this would delay finding the ROOT dir in normal instances (where devices are quick enough) So? Instead of patching this here and there with band aids, I suggest that everyone with an interest instead invests time in testing mdadm/experimental, which provides event-based assembly, I was wondering what documentation the reporter was following. I haven't seen RAID on USB supported in stable. and helps porting the changes to current mdadm (since I don't have the time at the moment). And then, LVM is up next.
Bug#644876: initramfs-tools: Boot failure from software RAID1 + LVM2 by timing
Thursday, October 13, 2011 10:07 AM Jort Koopmans wrote: Instead of patching this here and there with band aids, I suggest that everyone with an interest instead invests time in testing mdadm/experimental, which provides event-based assembly, I was wondering what documentation the reporter was following. I haven't seen RAID on USB supported in stable. I've not followed any documentation, I posted my question to the list for a reason. hint! I was just hoping to get it working since I assumed it would be possible. It was not aware of Raid 1 on USB being explicitly not supported, if that's the case you can also consider my report to be a feature request :), even though it applies to all slowly initialized devices (not per definition USB devices).
Bug#642066: linux-image-loongson-2f: Please include gnewsense patches [bug #34331] Request to submit linux patches upstream
please re-read the reply to your wishlist bug report. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642066#10 Which is directing you to ask gnewsense project to submit their kernel changes to upstream kernel.org 1: Ask please, the gnewsense project http://www.gnewsense.org/Main/HomePage to submit their changes upstream. At http://kernel.org 2: And please ask to have both wishlist bug reports you opened at savannah http://savannah.nongnu.org/bugs/?34331 and debian http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642066 closed[...] or linked to a new wishlist request you make at the gnewsense project. thanks for your cooperation.
Bug#627019: several kernel hangs before geting to login
Tuesday, November 15, 2011 3:10AM Jonathan Nieder wrote: Hi, Will Set wrote: - you have tested some 3.1.0-1-686-pae kernel (I assume 3.1.0-1~experimental.1 from experimental). Yes, 3.1.0-1~experimental.1 from experimental - unless you add processor.nocst=1, it reliably hangs at boot time. - adding processor.nocst=1 makes it boot without hanging. - in addition to this machine, you have another machine that has an i865 chipset. It produces the same symptoms. - in addition, you have a machine with an i915 chipset, which works fine, with no need for special boot parameters. Yes. In the bug log, I see: - this is an Acer Aspire One AO521, board JV01-NL, BIOS v1.08 - the chipset is indeed an 82865G - oopses are all over the place. Feels like corruption somewhere. - with debug=3, we see that the DMI says this is board D865GRH, BIOS BF86510A.86A.0077.P25.0508040031 --- wait, are these even the same machine? - the other i865 is D865PERLK. What I have gathered so far from reading docs and reports it looks like a C state problem. I think there isn't a CST in this processor... If CST adjusts processor voltage and stepping for energy saving when idle? I;m thinking legacy FADT is all this chip can use.. It's not a big deal for me to use the workaround Len Brown suggested https://bugzilla.redhat.com/show_bug.cgi?id=727865#c16 for 2.6.38-rc and newer kernels. --- Debian stable / 2.6.32-5-686 kernel still works fine. And I'm still OK if it's an upstream ( will not fix issue). But I would like a fix as well, if one is possible. Ok. The processor.nocst=1 workaround indicates that the ACPI tables might be incorrect or being incorrectly parsed. For the D865GBF, such a problem is being tracked as bug#630031 and upstream bug 38262. Compare v2.6.22-rc1~1112^2^2 (ACPICA: clear fields reserved before FADT r3, 2007-04-28). To move forward on that, the right thing to do would be to get in touch with Len Brown, for example by answering his questions from the Fedora bugtracker at https://bugzilla.redhat.com/show_bug.cgi?id=727865. All my answers to Len Browns questions are identical to Adam 's https://bugzilla.redhat.com/show_bug.cgi?id=727865#c17 answers to Len Browns questions. $ grep . /sys/devices/system/cpu/cpu0/cpuidle/*/* -- doesn't exist. $/sys/firmware/acpi/tables/dynamic/* -- doesn't exist in the filesystem. For the D865PERLK, a quick web search does not show anyone but you having this problem. You've said you have three boards you're checking with and only two exhibit the problem. I'm not sure where the JV01-NL fits into the picture. I'm not sure how the JV01-NL got into the picture either. Anyway, for the future, it would be way less confusing to have one bug per machine, Yes, I agree 100% unless they are identically configured or we can be reasonably certain for some other reason that the same fix will apply to all of them. Yes, at this preliminary stage, I think the issue is exactly the same, or at least close enough, on my two Intel 865 chipset machines. Even though the two mobos are not identical, the processors, memory and disks are identical in both machines. Please provide a summary of which machines that you use are affected and not affected, and I can clone this bug and let you know the bug number assigned to each. I will file a separate bug report from the other machine. Thanks for your help and patience. Regards, Jonathan Best Regards, Will
Bug#649304: linux-image-3.1.0-1-686-pae: processor.nocst=1 needed for 686-pae kernels
Package: linux-2.6 Version: 3.1.1-1 Severity: normal Tags: d-i I first noticed this issue using 2.6.38-rc5-686 and 2.6.38-rc6-686. Although, 2.6.38-1-686 worked out of the box, the regession showed again using 2.6.39-rcX kernels, and continues to show using all 686-pae kernels. Adding processor.nocst=1 to the kernel commandline works around the issue. Using 486 kernels is another workaround to this issue. see: #627019 linux-image-2.6.39-rc7-686-pae: several kernel hangs ... -- Package-specific info: ** Version: Linux version 3.1.0-1-686-pae (Debian 3.1.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Mon Nov 14 08:24:20 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-686-pae root=/dev/sdb8 ro processor.nocst=1 ** Not tainted ** Kernel log: [5.702701] [drm] nouveau :01:00.0: Detected an NV40 generation card (0x04a100a1) [5.704709] IR RC5(x) protocol handler initialized [5.706708] [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN [5.798468] [drm] nouveau :01:00.0: ... appears to be valid [5.798533] [drm] nouveau :01:00.0: BIT BIOS found [5.798591] [drm] nouveau :01:00.0: Bios version 05.44.a2.07 [5.798650] [drm] nouveau :01:00.0: TMDS table version 1.1 [5.798707] [drm] nouveau :01:00.0: BIT table 'd' not found [5.798765] [drm] nouveau :01:00.0: Found Display Configuration Block version 3.0 [5.798836] [drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 0028 [5.798895] [drm] nouveau :01:00.0: Raw DCB entry 1: 02011310 0028 [5.798953] [drm] nouveau :01:00.0: Raw DCB entry 2: 01011312 [5.799012] [drm] nouveau :01:00.0: Raw DCB entry 3: 020223f1 0084c030 [5.799071] [drm] nouveau :01:00.0: DCB connector table: VHER 0x30 5 7 2 [5.799131] [drm] nouveau :01:00.0: 0: 0x: type 0x00 idx 0 tag 0xff [5.799202] [drm] nouveau :01:00.0: 1: 0x2230: type 0x30 idx 1 tag 0x08 [5.799272] [drm] nouveau :01:00.0: 2: 0x0110: type 0x10 idx 2 tag 0xff [5.799341] [drm] nouveau :01:00.0: 3: 0x0111: type 0x11 idx 3 tag 0xff [5.799410] [drm] nouveau :01:00.0: 4: 0x0113: type 0x13 idx 4 tag 0xff [5.799484] [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xDD1E [5.802028] [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xE00C [5.807894] IR RC6 protocol handler initialized [5.815248] [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xE546 [5.815342] [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xE6A3 [5.816531] [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xE82C [5.816604] [drm] nouveau :01:00.0: mem timing table length unknown: 14 [5.816664] [drm] nouveau :01:00.0: timingset 255 does not exist [5.833530] i2c-core: driver [msp3400] using legacy suspend method [5.833597] i2c-core: driver [msp3400] using legacy resume method [5.836820] [drm] nouveau :01:00.0: 1 available performance level(s) [5.836885] [drm] nouveau :01:00.0: 0: memory 532MHz core 350MHz fanspeed 100% [5.836963] [drm] nouveau :01:00.0: c: memory 401MHz core 200MHz [5.837330] [TTM] Zone kernel: Available graphics memory: 448398 kiB. [5.837449] [TTM] Zone highmem: Available graphics memory: 516082 kiB. [5.837514] [TTM] Initializing pool allocator. [5.837601] [drm] nouveau :01:00.0: Detected 256MiB VRAM [5.837895] agpgart-intel :00:00.0: AGP 3.0 bridge [5.837974] agpgart: modprobe tried to set rate=x12. Setting to AGP3 x8 mode. [5.838116] IR JVC protocol handler initialized [5.838325] agpgart-intel :00:00.0: putting AGP V3 device into 8x mode [5.838540] nouveau :01:00.0: putting AGP V3 device into 8x mode [5.838634] [drm] nouveau :01:00.0: 256 MiB GART (aperture) [5.838876] [drm] nouveau :01:00.0: Saving VGA fonts [5.914955] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [5.915027] [drm] No driver support for vblank timestamp query. [5.917941] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0) [5.918021] [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 1) [5.918097] [drm] nouveau :01:00.0: Setting dpms mode 3 on tmds encoder (output 2) [5.918179] [drm] nouveau :01:00.0: Setting dpms mode 3 on TV encoder (output 3) [5.948032] intel8x0_measure_ac97_clock: measured 55898 usecs (2693 samples) [5.948101] intel8x0: clocking to 48000 [5.962545] IR Sony protocol handler initialized [5.971068] IR MCE Keyboard/mouse protocol handler initialized [5.979526] bttv0: audio absent, no audio device found! [6.057390] i2c-core: driver [tuner] using legacy suspend method [6.057461] i2c-core: driver [tuner] using legacy resume method [6.058546] lirc_dev: IR Remote Control driver
Bug#649304: processor.nocst=1 needed for 686-pae kernels
Saturday, November 19, 2011 2:32 PM Jonathan Nieder : wrote forcemerge 627019 649304 quit Hi Will, Will Set wrote: [Subject: processor.nocst=1 needed for 686-pae kernels] You haven't described the actual symptoms here. I assume that they are segfaults and hangs, as before? Yes, the kernel still hangs early in boot. The difference being the kernel hang without processor.nocst=1 looks to me to be more consistent now, than when I originally reported the problem with the 2.6.39-rc7-686 kernel. I first noticed this issue using 2.6.38-rc5-686 and 2.6.38-rc6-686. Although, 2.6.38-1-686 worked out of the box, the regession showed again using 2.6.39-rcX kernels, and continues to show using all 686-pae kernels. Adding processor.nocst=1 to the kernel commandline works around the issue. Using 486 kernels is another workaround to this issue. Please send full dmesg output from booting up and reproducing the bug. Attaching acpidump output would be useful, too. I'll also be away from my desk for a few days, and will followup, with dmesg and acpidump, as soon as I return. Best Regards, Will see: #627019 linux-image-2.6.39-rc7-686-pae: several kernel hangs ... Thanks for filing a separate bug so we can keep track of the information about each machine separately. I'm marking the two reports as related for easy reference. Thanks and hope that helps, Jonathan
Bug#627019: several kernel hangs before geting to login
Friday, December 23, 2011 6:54 PMJonathan Nieder wrote Hi Will, Will Set wrote: I was able to take three pictures of the boot messages by scrolling up the boot buffer from the login prompt, while booting 3.2.0-rc4-686-pae to illustrate what I did my best to explain yesterday. I'll also attach the dmesg.udev-2 and acpidump-udev-2 Thanks. If I understand you correctly, udev 175-2 segfaults at boot. No, Not always a segfault. Sometimes udev just hangs, leaving the machine without keyboard access. And it's way to early in the boot process to get normal network connectivity, Other times the kernel will panic. And when the kernel panics I'm not able to save any data from the boot buffer other than the screen full of data showing when the boot buffer finishes sending the trace data to the buffer. Boot also fails in at least one other way. Where I can see a udev settle message and messages showing the /sys directory structure. But when this type of issue happens I am able to login and run the system console. But, if I start the xserver under these condition I have no keyboard or mouse. These failures have not changed much since I initially reported this. But I have seen the failures so may times now that I'm a bit less confused by them. udev 175-3 does _not_ segfault, No, udev 175-3 also segaults iirc but I have not re - upgraded udev to 175-3 to test exactly what it shows, yet. but the boot fails in some way unless you add processor.nocst=1 to the kernel command line. Yes, Adding processor.nocst=1 has always worked for me on all effected kernels I've tested so far. But, the boot fails consistently when using udev 175-3 unstable with 3.2.0-rc4-686-pae and without processor.nocst=1 added to the boot command. Which is already weird, since the only advertised changes in 175-3 were a fix to the systemd service file and a fix to udev rules for Xen support. Based on the kernel log you sent, you are not using systemd, and I assume you're not using Xen. Please understand that a failed boot, appears - at least from what I can see here, always to have something to do with udev. This is on the machine with a D865GBF motherboard. No, This report is and always will be Intel D865GRH mobo. My other mobo is an Intel D865PERLK There is another Debian user that has an Intel D865GBF mobo with a very similar debian bug report filed. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597 [9.132009] Pid: 311, comm: modprobe Tainted: G D 2.6.39-2-686-pae #1 /D865GBF And this user has also filed a bug report upstream after Ben requested he do so. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631597#15 Anyway, you were able to take advantage of this situation to get an acpidump. Are these results reproducible? Yes, But, the fail is not consistently one failure. I had three failed boot attempts today while testing with a clean kernel commandline. ie: processor.nocst=1 was not added to the commandline. on any of my 4 boot attempts today. The fourth time the machine booted to a useable state. I hope you can find some clues in this email that will make this issue less weird to understand. And as always I'll do my best to get timely responses back to you, even though I have been busy elsewhere recently. I've not had my usual amount of time to devote to testing and learning about the kernel. Best Regards, Will Hope that helps, Jonathan
Bug#627019: several kernel hangs before geting to login
Monday, December 26, 2011 5:24 PMWill Set wrote: Sunday, December 25, 2011 4:24 AM Jonathan Nieder wrote: Will Set wrote: Jonathan Nieder wrote but the boot fails in some way unless you add processor.nocst=1 to the kernel command line. [...] I had to test using 3.1.0-1-686-pae ( which I believe is an old experiemtnal kernel and not a sid or wheezy kernel) ooops : sorry for confusion: 3.1.0-1-686-pae is a sid kernel. I rebooted 3.1.0-1-686-pae 10 times with hyperthreading enabled, and got 10 different dmesg problems very near if not exactly while udev was populating /dev Best Regards, Will
Bug#665413: BUG: unable to handle kernel paging request
Friday, March 23, 2012 6:42 PM Daniel Kahn Gillmor The only kernel boot parameter on this run was console=ttyS0,115200n8 -- i brought up the rest of the system by hand during this fallback attempt. According to HP, http://h18000.www1.hp.com/products/quickspecs/11632_ca/11632_ca.html --- http://h18000.www1.hp.com/products/quickspecs/11632_di/11632_div.html#Standard%20Features%20-%20Select%20Models the mobo has an 865g chipset. I know of 5 bug reports that confirm using boot parameter - processor.nocst=1 as a workaround for kernels 2.6.38 linux-image-2.6.39 through linux-image 3.3.0-rc6-686-pae - on both of my 865g based boxes. Also, iirc, the bigmem kernel was swallowed by the 686-pae kernel, which might be a reason for the instability when using 486. I've run memtest86+ on this machine and the memory shows no errors in that program. Let me know if there are other details i can report that would help with this bug report; sorry i'm not able to get the machine to a stable point yet to run reportbug on it directly. best regards, Will
Bug#665413: BUG: unable to handle kernel paging request
Friday, March 23, 2012 11:06 PMDaniel Kahn Gillmor wrote: On Fri, 23 Mar 2012 19:51:37 -0700 (PDT), Will Set debiandu...@yahoo.com wrote: I know of 5 bug reports that confirm using boot parameter - processor.nocst=1 as a workaround for kernels 2.6.38 Thanks, i will try this the next time i get a chance to restart this machine (it's currently crashed again and i don't have physical access right now). Probably not necessary since you are using 2.6.32 (squeeze) kernels. Normally, kernels older than 2.6.39 don't need the extra boot parameter. But 4 GiB of ram is max for the board and although HP has spec for 4 GiB of ram for your model, they also have notes recommending only 2 GiB of Ram, in another doc. http://bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c00072736/c00072736.pdf Do you have a link to a couple of these bug reports so i could read them myself? I'd appreciate it if you do. https://bugzilla.redhat.com/show_bug.cgi?id=727865 linux-image-2.6.39 through linux-image 3.3.0-rc6-686-pae - on both of my 865g based boxes. I'm not sure what this sentence means -- is it related to the sentence above? if so, how? I have two computers with i865g chipsets and 1 GiB of ram each. I'm not sure what I was thinking when I refered to kernels your not using. Also, iirc, the bigmem kernel was swallowed by the 686-pae kernel, which might be a reason for the instability when using 486. I wouldn't expect the -486 flavor to be able to fully address all 4GiB of RAM (i.e. i doubt it would make use of the physical address extensions). But i don't understand why this would cause instability. My workload during these crashes is definitely not memory-intensive. This is the first i'm hearing that the -486 flavor would cause instability on highmem machines. Can you point me to some documentation so i could understand why that might be the case? Here is a link to linux-image-2.6.32-5-686-bigmem http://packages.debian.org/squeeze/linux-image-2.6-686-bigmem. best regards, Will
Bug#649304: linux-image-3.1.0-1-686-pae: processor.nocst=1 needed for 686-pae kernels
3.2.15 fixed for me.
Bug#627019: linux-image-2.6.39-rc7-686-pae: several kernel hangs before geting to login
3.2.15 fixed for me.
Bug#351412: Ecards Top
Pictures remove picture select. Picture select next load new from where saved computer. Users nt place mouse? Spelling spelled startrec are using can list. Plus or xtheme manager of choice file. Most cases may check see there readme! WE HELP THE WORLD MOVE! TRANSFORMING THE LIVES OF DEVELOPING NATIONS This is an amazing story. WE urge you to go read the news on this company and visit the website. The company website will be listed in news releases. Watch this company closely starting NOW! TRANSNATIONAL AUTOMOTIVE GROUP TAMG.OB Founded in 2005, TAMG Provides transportation systems and infrastructure to the developing world. Our bus fleets provide an efficient way for communities in need to travel and prosper. Affordable for riders, and economically sustainable for the company, TAMG has turned capital investments in the developing world into sustainable and profitable transportation solutions NEWS February 15, 2007 - Transnational Automotive Group Launches LeCar Inter-Urban Bus Operations between YaoundE and Douala, Cameroon *** December 18 , 2006 - After Le Bus, Here comes Le Car *** December 11 , 2006 - Transnational Automotive Announces $800,000 USD Investment by the Chamber of Commerce of Cameroon *** November 30, 2006 - Transnational Automotive Announces Purchase of 60 City Buses for its Urban Transportation Operation in Cameroon *** November 16, 2006 - Transnational Automotive Announces $800,000 USD Investment by the Chamber of Commerce of Cameroon Called star trek probably! Sensual celeb savers funny. More, help suggest yours do you. Folder, named same title. Named same title example called star trek probably? Theme program ms plus or xtheme manager of choice. Cprogram some create, folder named same, title example called. Flowers, humorous hunks, military movies? Savers funny women fashion romance fun quizes. Australia beach bikini cars cartoons. Sexy space sports valentine, the newest! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
