Re: random wedges with 2.6.25-rc*
On Tuesday 19 February 2008 18:10:35 Pierre Ossman wrote: > Primarily, the udev startup locks up. If I abort it, it just locks up on > more or less every action after that. Some quick debugging showed that I > had a whole bunch of modprobe processes sitting around. The new > CONFIG_USB_ANNOUNCE_NEW_DEVICES setting makes every startup of udev lock up > consistently on at least two machines. It does not seem to be the root of > the problem as disabling the option just makes the bug very unlikely. You're not alone, I'm seeing these intermittent hangs at init time on Debian unstable at: "Waiting for /dev to be fully populated" (udevsettle) "Loading kernel modules" (which I assume is modprobe) But, I'm not seeing any hangs in X11 (yet). -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Force enable HPET on (some?) ICH9 boards
On Tuesday 29 January 2008 01:12:33 Pallipadi, Venkatesh wrote: > Patch looks good. > If BIOS does not report HPET on more of such systems we may have to add > other chipsets in ICH9 family (ICH9_8, ...) as well. > > Acked-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> Hi Ingo, Are you going to pick this patch up via the x86 tree, or shall I forward it to Andrew or [EMAIL PROTECTED] Do you want me to re-send with Venki's ack? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Force enable HPET on (some?) ICH9 boards
Some consumer ICH9 boards (such as the Abit IP35 Pro) do not provide a BIOS option for enabling the HPET. The same ICH workaround used for 6,7,8 can be applied to 9. Here I enable the only PCI id that was visible on my system. I have confirmed the HPETs work both from userspace and as a clocksource for the running kernel (2.6.24 here) after applying this patch. Force enabled HPET at base address 0xfed0 hpet clockevent registered hpet0: at MMIO 0xfed0, IRQs 2, 8, 0, 0 hpet0: 4 64-bit timers, 14318180 Hz Signed-off-by: Alistair John Strachan <[EMAIL PROTECTED]> --- arch/x86/kernel/quirks.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/quirks.c b/arch/x86/kernel/quirks.c index fab30e1..150ba29 100644 --- a/arch/x86/kernel/quirks.c +++ b/arch/x86/kernel/quirks.c @@ -162,6 +162,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH7_31, ich_force_enable_hpet); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_1, ich_force_enable_hpet); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_7, +ich_force_enable_hpet); static struct pci_dev *cached_dev; -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: r8169 and out of space
Bugzilla for this report: http://bugzilla.kernel.org/show_bug.cgi?id=9468 On Thursday 10 January 2008 17:28:22 you wrote: > I saw your thread on LKML about the problem with r8169. Did you ever > find a patch or solution? No, we have not diagnosed the cause of the problem, beyond the swiotlb usage. I'm adding the r8169 maintainer, linux-net and linux-kernel to CC, to pass on your information, I hope you don't mind. > I have a Abit AB9 Pro motherboard with Intel P965 chipset, 4gb of > memory, and two onboard r8169. The kernel is > kernel-2.6.23.9-85.fc8.x86_64. I am using jumbo frames, the MTU set at > 5924. The error is mentions 5946 bytes. 5946 - 5924 is 22. The same as > your 7200 MTU subtracted from your bytes, 7222. > > I can set my MTU to 7200, and I can ping with 6 byte packets just > fine, but tcp connections hang unless I set the MTU to 5924 or lower. > The other side is a Nvidia based board with a forcedeth driver that has > in the past taken 9000 just fine. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New question on that sata controller
On Saturday 15 December 2007 21:24:09 Gene Heskett wrote: > On Saturday 15 December 2007, Robert Hancock wrote: > >Gene Heskett wrote: > >> Greetings; > >> > >> When I asked about a sata controller earlier this week, I gave a link to > >> it. Unforch (maybe) when it actually arrived, the cards box showed a > >> silicon image chip, and the card had a via. So much for getting what I > >> ordered... > >> > >> The required module then was sata_via, not sata_uli, and it seems to be > >> working ok. However, this one claims its a raid controller according to > >> an lspci -v: > >> > >> 01:0a.0 RAID bus controller: VIA Technologies, Inc. VT6421 IDE RAID > >> Controller (rev 50) > >> Subsystem: VIA Technologies, Inc. VT6421 IDE RAID Controller > >> Flags: bus master, medium devsel, latency 32, IRQ 19 > >> I/O ports at 9400 [size=16] > >> I/O ports at 9800 [size=16] > >> I/O ports at 9c00 [size=16] > >> I/O ports at a000 [size=16] > >> I/O ports at a400 [size=32] > >> I/O ports at a800 [size=256] > >> [virtual] Expansion ROM at e900 [disabled] [size=64K] > >> Capabilities: [e0] Power Management version 2 > >> > >> I just noted that the Expansion ROM is disabled, but I didn't see any > >> jumpers to enable it on the card prior to installing it. Does anyone > >> know how this is supposed to work? I would like to make it directly > >> bootable but I believe this has to be 'enabled' for that. > > > >It's usually normal for it to be disabled after boot, I believe. Are you > >getting anything showing up on boot indicating its BIOS is active? > > No, not a thing. Also invisible in the mainboards bios config AFAICT. Normally this option is called "Enable Option ROM" or enable "INT 13/19h hook". See if you have such an option. It's surprising this isn't enabled by default. However, the BIOS still might not support directly booting off the controller, I'm afraid. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT] Port 0x80 I/O speed
On Tuesday 11 December 2007 23:31:18 Rene Herman wrote: > Good day. > > Would some people on x86 (both 32 and 64) be kind enough to compile and run > the attached program? This is about testing how long I/O port access to > port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in > reporting. cycles: out 2712, in 2606 1.5GHz C7, Via chipset. 32bit OS. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space
On Sunday 25 November 2007 01:27:54 Francois Romieu wrote:
> Francois Romieu <[EMAIL PROTECTED]> :
> > Alistair John Strachan <[EMAIL PROTECTED]> :
> > [...]
> >
> > > The "choke" affects other devices on the system too, notably libata,
> > > which does not recover gracefully. In my logs, I see a stream of:
> > >
> > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
> > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
> >
> > You are using jumbo frames, aren't you ?
>
> See below for my late night crap. At least it should avoid the driver
> issuing Rx/Tx DMA with the single static buffer of lib/swiotlb.c
> (io_tlb_overflow_buffer). Ghee.
No improvement. It might be possible to reproduce the problem on your end if
you add iommu support and force enable the swiotlb (which should be possible
even with <4GB RAM).
> diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
> index 1f647b9..72a7370 100644
> --- a/drivers/net/r8169.c
> +++ b/drivers/net/r8169.c
> @@ -2262,10 +2262,16 @@ static struct sk_buff *rtl8169_alloc_rx_skb(struct
> pci_dev *pdev, mapping = pci_map_single(pdev, skb->data, rx_buf_sz,
>PCI_DMA_FROMDEVICE);
>
> + if (pci_dma_mapping_error(mapping))
> + goto err_kfree_skb;
> +
> rtl8169_map_to_asic(desc, mapping, rx_buf_sz);
> out:
> return skb;
>
> +err_kfree_skb:
> + dev_kfree_skb(skb);
> + skb = NULL;
> err_out:
> rtl8169_make_unusable_by_asic(desc);
> goto out;
> @@ -2486,6 +2492,7 @@ static int rtl8169_xmit_frags(struct rtl8169_private
> *tp, struct sk_buff *skb, dma_addr_t mapping;
> u32 status, len;
> void *addr;
> + int rc;
>
> entry = (entry + 1) % NUM_TX_DESC;
>
> @@ -2493,6 +2500,22 @@ static int rtl8169_xmit_frags(struct rtl8169_private
> *tp, struct sk_buff *skb, len = frag->size;
> addr = ((void *) page_address(frag->page)) + frag->page_offset;
> mapping = pci_map_single(tp->pci_dev, addr, len,
> PCI_DMA_TODEVICE);
> + rc = pci_dma_mapping_error(mapping);
> + if (unlikely(rc < 0)) {
> + while (cur_frag-- > 0) {
> + frag = info->frags + cur_frag;
> + entry = (entry - 1) % NUM_TX_DESC;
> + txd = tp->TxDescArray + entry;
> + len = frag->size;
> + mapping = le64_to_cpu(txd->addr);
> + pci_unmap_single(tp->pci_dev, mapping, len,
> + PCI_DMA_TODEVICE);
> + txd->opts1 = 0x00;
> + txd->opts2 = 0x00;
> + txd->addr = 0x00;
> + }
> + return rc;
> + }
>
> /* anti gcc 2.95.3 bugware (sic) */
> status = opts1 | len | (RingEnd * !((entry + 1) % NUM_TX_DESC));
> @@ -2534,13 +2557,13 @@ static inline u32 rtl8169_tso_csum(struct sk_buff
> *skb, struct net_device *dev) static int rtl8169_start_xmit(struct sk_buff
> *skb, struct net_device *dev) {
> struct rtl8169_private *tp = netdev_priv(dev);
> - unsigned int frags, entry = tp->cur_tx % NUM_TX_DESC;
> + unsigned int entry = tp->cur_tx % NUM_TX_DESC;
> struct TxDesc *txd = tp->TxDescArray + entry;
> void __iomem *ioaddr = tp->mmio_addr;
> dma_addr_t mapping;
> u32 status, len;
> u32 opts1;
> - int ret = NETDEV_TX_OK;
> + int frags, ret = NETDEV_TX_OK;
>
> if (unlikely(TX_BUFFS_AVAIL(tp) < skb_shinfo(skb)->nr_frags)) {
> if (netif_msg_drv(tp)) {
> @@ -2557,7 +2580,11 @@ static int rtl8169_start_xmit(struct sk_buff *skb,
> struct net_device *dev) opts1 = DescOwn | rtl8169_tso_csum(skb, dev);
>
> frags = rtl8169_xmit_frags(tp, skb, opts1);
> - if (frags) {
> + if (frags < 0) {
> + printk(KERN_ERR "%s: PCI mapping failure (%d).\n", dev->name,
> +frags);
> + goto err_busy;
> + } else if (frags > 0) {
> len = skb_headlen(skb);
> opts1 |= FirstFrag;
> } else {
> @@ -2605,6 +2632,7 @@ out:
>
> err_stop:
> netif_stop_queue(dev);
> +err_busy:
> ret = NETDEV_TX_BUSY;
> err_update_stats:
> dev->stats.tx_dropped++;
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space
On Sunday 25 November 2007 00:25:10 Francois Romieu wrote: > Alistair John Strachan <[EMAIL PROTECTED]> : > [...] > > > The "choke" affects other devices on the system too, notably libata, > > which does not recover gracefully. In my logs, I see a stream of: > > > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 > > DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 > > You are using jumbo frames, aren't you ? Yes, 7200 byte frames. I'll certainly try out your patch and report back. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space
Hi, I have recently assembled a Core 2 Duo system with 4GB RAM and I believe there might be a bug in the r8169 driver in >4GB RAM configurations. Initially I can use one of two active r8169 NICs on the motherboard with this quantity of RAM with other devices, without issue. But after some amount of data (generally about 50MB), no more network packets are sent/received. The "choke" affects other devices on the system too, notably libata, which does not recover gracefully. In my logs, I see a stream of: DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0 The device :04:00.0 corresponds to one of the r8169s. The reason I believe r8169 is at fault is that I was doing a rebuild of my RAID5 across 3 SATA drives via libata's ahci driver, and transferring over the network. When the "choke" occurred the RAID sync stopped, libata errors were seen, and I simply did a "ifconfig br0 down" (which contained the r8169) and the messages went away. Bringing the NIC up again would see some initial functionality then very rapidly it would go back to the same error messages. The Intel chipset I am using does not support any kind of hardware IOMMU, so I am forced to use swiotlb in a 4GB RAM configuration. In an attempt to delay the failures, I used the swiotlb option to increase the swiotlb's page allocation with "swiotlb=65536" (which seems to correspond to a 256MB bounce buffer). Assuming both libata and r8169 use the swiotlb, and both systems are impaired when these messages appear, removing r8169 would appear to be key. Indeed, if there is no significant libata activity, the problem still occurs on the NIC within approximately the same amount of transfer. This option delays the failure for some time but it will happen eventually, which makes me suspicious that maybe the driver is somehow pinning an area of the buffer and not releasing it. (I hunted bugzilla for reports similar to this one, but couldn't find anything.) Having tested the r8169 driver on an AMD system I did not experience the same problems with 4GB RAM, so this could be a bug specific to swiotlb. I would have added more people to CC but I have no idea who might be responsible. Andrew, I've added you just in case you're aware of other similar reports (maybe r8169 on big iron) and have anybody from the sw-iommu camp that could be added to CC. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 44/59] drivers/scsi: Add missing "space"
On Tuesday 20 November 2007 01:53:31 Joe Perches wrote:
> diff --git a/drivers/scsi/NCR_D700.c b/drivers/scsi/NCR_D700.c
> index 9e64b21..99403a6 100644
> --- a/drivers/scsi/NCR_D700.c
> +++ b/drivers/scsi/NCR_D700.c
> @@ -182,7 +182,7 @@ NCR_D700_probe_one(struct NCR_D700_private *p, int
> siop, int irq,
>
> hostdata = kzalloc(sizeof(*hostdata), GFP_KERNEL);
> if (!hostdata) {
> - printk(KERN_ERR "NCR D700: SIOP%d: Failed to allocate host"
> + printk(KERN_ERR "NCR D700: SIOP%d: Failed to allocate host "
> "data, detatching\n", siop);
> return -ENOMEM;
> }
If you're going to sneak in unrelated spelling/grammar changes, you might as
well do it unilaterally.
"detached" please.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.24-rc1-git: crash on shutdown/unmount?
On Thursday 01 November 2007 11:51:08 Sebastian Siewior wrote: > * Jens Axboe | 2007-11-01 11:51:09 [+0100]: > >On Wed, Oct 31 2007, Alistair John Strachan wrote: > >> Hi Jens, > >> > >> I guessed from the oops that you might have an idea what's causing this > >> oops on shutdown/unmount. The git version (describe), a screenshot > >> showing the oops, a config, and dmesg for a booted kernel are available > >> from: > >> > >> http://devzero.co.uk/~alistair/oops-20071031/ > >> > >> I went back to -rc1 and it still happens there too. If you need any more > >> information or want me to bisect it, please let me know. > > > >Does this work for you? > > Yes it does. > > Acked-by Sebastian Siewior <[EMAIL PROTECTED]> Yep, thanks Jens. Working fine here. Tested-by: Alistair John Strachan <[EMAIL PROTECTED]> -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.24-rc1-git: crash on shutdown/unmount?
Hi Jens, I guessed from the oops that you might have an idea what's causing this oops on shutdown/unmount. The git version (describe), a screenshot showing the oops, a config, and dmesg for a booted kernel are available from: http://devzero.co.uk/~alistair/oops-20071031/ I went back to -rc1 and it still happens there too. If you need any more information or want me to bisect it, please let me know. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Which companies are helping developing the kernel
On Sunday 14 October 2007 23:06:22 Stefan Heinrichsen wrote: > Hello, > > I posted this question at comp.linux.misc and where told this would be a > better place therefore. I would like to do a internship in the field of the > Linux kernel. > Can someone tell me where to find a list of companies (don't matter in > which country) that employ kernel developers? I think Greg wrote a paper on this subject, so I've added him to CC in case he has the link handy. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
On Friday 05 October 2007 09:32:40 you wrote: > On Fri, 5 Oct 2007, Sam Ravnborg wrote: > > > > cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory > > > > > > > > Obviously, this file has moved to arch/x86/boot, but it seems like > > > > possibly unnecessary breakage. I've been copying bzImage for years > > > > from arch/x86_64/boot, and I'm sure there's a handful of scripts > > > > (other than Debian's kernel-image) doing this too. > > > > > > > > For now, I hacked the tool[1]. Maybe, if we care, a symlink could be > > > > set up between arch/x86/boot and arch/$ARCH/boot ? Or would papering > > > > over this be more trouble than it's worth? > > > > > > yeah, a symlink is the right solution i think. Our first-step goal is > > > to make the switchover seamless for all practical purposes, and a > > > compatibility symlink in arch/i386/boot/ will not hurt. (we shouldnt > > > worry about the really old zImage target though) > > > > But when can we then get rid of it? > > This is a simple question about when we take the noise.. > > And right now people know we are shifting to x86 - so it makes > > sense to let the dependent userspace tools take the pain now and not > > later. > > > > Starting to fill up a build kernel with symlinks for compatibility with > > random progarms seems to be the wrong approach. > > > > Sam - that dislike especially the asm symlink > > Sam, > > I completely agree with you, but we want to keep the migration noise > as low as possible. Adding the symlink right now along with an entry > into features-removal.txt (6 month grace period) allows a smoother > transition. The distro folks should better get their gear together > until then. I'll certainly file a bug report with the Debian BTS, but the fix will probably involve something as abortive as my original patch. How did the PPC merge handle this? I can't see any similar hacks in kernel-image for these architectures. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Monday 08 October 2007 00:10:10 Rene Herman wrote: > I find Alan's suggestion to provide the functionality the same way you'd > provide for translated kernel messages (seeing as how there also are people > that want those) much more sensible. By the way, I agree that this is the best approach. Feasibly, it could be used by the same splash engines you mention to colour their console redirect, though most of the engines I've seen (e.g. SuSE/Ubuntu) don't let you switch messages on until after init (at which point kernel colours are probably irrelevant). -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Monday 08 October 2007 00:10:10 Rene Herman wrote: > On 10/08/2007 12:40 AM, Alistair John Strachan wrote: > > Splash screens are clearly cosmetic, and it's kind of shameful (imo) that > > important messages explaining real problems are obscured from view by > > functionless splash screens. > > They're not functionless. You (and I) might not care for the function, but > their function is providing a "slick" bootup. That's why so many if not > basically all distributions of recent origin use them. Go ask Ubuntu for > example. > > > Personally, I think muddying the vga colour argument with splash screen > > stuff is bogus, they're very functionally separable ideas. A coloured > > oops seems to be a good way of telling novice users what information is > > relevant to their bug report. > > But when they're hidden by a splash screen, you don't see them any better > when they're red than when they're white. Splash screens were not mentioned > as any sort of alternative, their prevalence was mentioned as indication > that VGA console is only ever getting less important. Obviously true, but that's not a reason to bar enhancements to the VGA console. Right now, there's no sane way to have a splash screen in userspace handle an oops, so people looking to reproduce and detect the root of a problem will inevitably fall back to VGA (or vesa, presumably), where colour might be useful. I recall seeing a distro kernel oops early in boot, where the palette had been corrupted by the splash so the oops wasn't readable. That's bad, right? Don't get me wrong, I don't care for the feature much, I just don't think "splash screens are defacto" is a reason to shy away from a feature that could be useful for novices reporting kernel bugs. These people are probably inbetween those that must have a shiny splash and those that fix the kernel bugs. Of course, what Alan said elsewhere about breaking things that work is a good reason to not add the feature, or at least make it only happen on a real display. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sunday 07 October 2007 20:13:09 you wrote: > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > > >>ago. > > > > > >Congratulations, this is the most stupid argument i've ever read on > > >lkml. > > > > "Ay. World is finished. Everyone can go home and watch Friends reruns > > now." > > > > But well, there actually have been worse arguments given that VGA console > > is getting less and less important. I recently did a perusal of > > alternative distributions and didn't find a single one that didn't > > default to having a splash screen hide the kernel during boot (and if I'm > > not mistaken, only one of them provided me with the option during > > installation to not boot into X immediately afterwards). > > I don't recall having seen any splash screen on Slackware. And fortunately, > the mainstream distros still provide the option to boot in text mode. Debian defaultly doesn't use framebuffer or any kind of splash screen. Splash screens are clearly cosmetic, and it's kind of shameful (imo) that important messages explaining real problems are obscured from view by functionless splash screens. Personally, I think muddying the vga colour argument with splash screen stuff is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc9 and a heads-up for the 2.6.24 series..
On Tuesday 02 October 2007 04:41:49 Linus Torvalds wrote: [snip] > In other words, people who know they may be affected and would want to > prepare can look at (for example) > > git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git x86 > > and generally get ready for the switch-over. This is certainly a tool issue, but if I use Debian's kernel-image "make-kpkg" wrapper around the kernel build system, it fails with: cp: cannot stat `arch/x86_64/boot/bzImage': No such file or directory Obviously, this file has moved to arch/x86/boot, but it seems like possibly unnecessary breakage. I've been copying bzImage for years from arch/x86_64/boot, and I'm sure there's a handful of scripts (other than Debian's kernel-image) doing this too. For now, I hacked the tool[1]. Maybe, if we care, a symlink could be set up between arch/x86/boot and arch/$ARCH/boot ? Or would papering over this be more trouble than it's worth? [1] http://devzero.co.uk/~alistair/kernel-package-changes.diff -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in fsck or ext2/ext3?
On Monday 24 September 2007 17:56:39 Antoine Martin wrote: > Hi Ted / LKML, > > I've got this snapshot of an ext3 filesystem with a directory that > simply cannot be removed! (image below is just 1.2MB) > As root: > # wget http://users.nagafix.co.uk/~antoine/root-broken.bz2 > # bunzip2 root-broken.bz2 > # mount -o loop -t ext2 root-broken ./tmp > # rm -fr tmp/chroot.broken > rm: cannot remove directory (...) > Same result when trying to do anything to those files chown/chmod/touch: > "Operation not permitted" > > Tested with e2fsprogs v1.39 on 3 systems. > Not sure where else to post this... URL is broken. Tried doing a "lsattr" to ensure no xattrs (like +i) are set? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH 0/4] Virtual Machine Time Accounting
On Monday 10 September 2007 14:08:45 Laurent Vivier wrote: > Avi Kivity wrote: > > Ingo Molnar wrote: > >> * Laurent Vivier <[EMAIL PROTECTED]> wrote: > >>> Ingo, please, could you have a look to these patches ? > >>> > >>> The aim of these four patches is to introduce Virtual Machine time > >>> accounting. > >>> > >>> [PATCH 1/4] as recent CPUs introduce a third running state, after > >>> "user" and "system", we need a new field, "guest", in cpustat to > >>> store the time used by the CPU to run virtual CPU. Modify /proc/stat > >>> to display this new field. > >> > >> the concept certainly looks sane to me. > >> > >> The heavy-handed use of #ifdefs uglifies the code to a large degree, > >> but this is not a fundamental problem: since basically all distros > >> have KVM enabled (and lguest benefits from this too), could you just > >> make all this new code unconditional? > > > > I imagine the embedded people will complain... perhaps move all the code > > to a #ifdef section above with a full implementation and a stub > > implementation. > > I'm going to repost patches without #ifdefs for readability. > Then we could discuss if we should introduce #ifdefs and how. If you could provide a summary of the size increase from your latest post (i.e., size of the kernel before and after) that might lay rest to some theoretical complaints. This doesn't look like enough code to warrant ifdefs. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1
On Tuesday 04 September 2007 16:26:27 Andi Kleen wrote: > > Seconded. It's been largely ignored which is annoying because the HPET > > works perfectly on this board. I assume the reason is still that nobody > > from NVIDIA verified hardward support for the hack. > > It's IMHO a bad idea to add any overrides without access to data sheets > and errata sheets. The hardware might be broken and do bad > (subtle) bad things with HPET. That's not a theoretical case. > There used to be at least one case where a chipset would occasionally > destroy the BIOS flash when HPET was force enabled. I haven't used any CK804 with an HPET which is BIOS enabled by default, so it's probably most likely that the reference BIOS didn't enable it. As this technology is quite antiquated, the usual "well Vista uses HPET, so maybe vendors will enable it" probably won't apply. I know for my board, no BIOS has been released since early 2006. > That means for Intel it's fine to do (because errata sheets are public); > but for Nvidia and VIA it's dangerous and should not be done. I don't disagree with you and I think you're right in the general case, but even if we could pin somebody down from NVIDIA (which is seeming unlikely, considering the right people have already been CCed), it would still be a BIOS override. In this case, there's a perfectly good HPET masked behind what I can only speculate is a BIOS misfeature (my kernel's behaved itself with Mikko's patch applied and Thomas's HRT patchset on x86-64). What about an expert option which could force the HPET on (rather than "find" and enable it)? Are you opposed to this too? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc4-mm1
On Monday 03 September 2007 09:06:25 Nicolas Mailhot wrote: > Mats Johannesson bredband.net> writes: > > On 2007-09-01 16:07:48 Torsten Kaiser wrote: > > [...] > > > > > The good: > > >> +hpet-force-enable-on-vt8235-37-chipsets.patch > > >> +hpet-force-enable-on-vt8235-37-chipsets-fix.patch > > > > > > Kernel 2.6.23-rc4-mm1 works on one of my systems with: > > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host > > > Bridge (rev 01) > > > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge > > > [K8T800/K8T890 South] > > > > And glory, glory, my Acer Aspire 1520 (1524) AMD64 notebook with the > > old vt8235 chipset got a good kick in the behind as well. > > Now we have working HPET override for Intel and Via, could Nvidia users be > considered too? The required info has been known for ages: > > http://marc.info/?l=linux-kernel&m=117679014505031 Seconded. It's been largely ignored which is annoying because the HPET works perfectly on this board. I assume the reason is still that nobody from NVIDIA verified hardward support for the hack. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [ALSA] Added new pin config for first gen macbook.
On Tuesday 04 September 2007 15:18:23 Abhijit Bhopatkar wrote: [snip] > > Anyway, it'd be helpful if someone else can check the same MacBook > > (1st generation, not Pro?) whether the problem is reproducible. > > To be precise its Macbook 1st Generation non pro. with subsystem id > 0x106b0a00 > > Well a friend of mine has the same model and i tried things out on his > machine. to my surprise :(, the original 2.6.23-rc5 is working fine on his > machine. > > So on my machine we booted to windows and tested things out. The sound > on my machine doesn't work in windows either, although its working in > OSX. > > So sorry for all the noise its most likely a hardware problem after all. > Although i am baffled as to why old pin config works on this > particular broken hardware. > > I hope i didn't bug you too much, i appreciate your quick responses. I think the first generation macbook firmwares weren't completely other-OS ready when they were shipped (no bootcamp in firmware, iirc). Have you applied all available firmware updates? Do you use bootcamp? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] sisusbvga: Fix bug and build warnings
On Sunday 02 September 2007 21:23:16 Jesper Juhl wrote:
> On 02/09/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:
> > Hi Jesper,
> >
> > On Sun, 2 Sep 2007, Jesper Juhl wrote:
> > > > - if (!(interface = usb_find_interface(&sisusb_driver,
> > > > subminor))) { - dev_err(&sisusb->sisusb_dev->dev,
> > > > "Failed to find interface¥n");
> > >
> > > Odd how in your patch the line ends with "¥n" but if I look in my
> > > local copy of the source tree I see "\n".
> >
> > Odd, indeed. I see correct '\n' in the mail I sent, but in your mail
> > here it's coming out wrong -- lkml.org shows badness as well. Hmmm,
> > "insert file" using ^R in alpine never gave any problems before ...
The encoding is set to ISO-2022-JP, this is probably breaking things.
--
Cheers,
Alistair.
137/1 Warrender Park Road, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: "exception Emask: 0x42" errors with 2.6.22.x and SATA drives
On Monday 27 August 2007 10:28:09 Dermot Bradley wrote:
[snip]
> Thanks for the help Alistair! One other point you may be able to help
> with - this is the first time I've used a dual core processor and I
> expected that /proc/interrupts would should interrupts distributed
> between both cores whereas they actually seem to be mainly handled by
> the 1st core:
>
>CPU0 CPU1
> 0:251 0 IO-APIC-edge timer
> 1: 2208 11 IO-APIC-edge i8042
> 8: 0 1 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-fasteoi acpi
> 16: 5291 3 IO-APIC-fasteoi ehci_hcd:usb1, eth0
> 17: 223026 13 IO-APIC-fasteoi ahci
> 18: 0 1 IO-APIC-fasteoi ohci_hcd:usb2
> 19: 0126 IO-APIC-fasteoi ohci_hcd:usb3,
> ohci_hcd:usb5
> 20: 0 2 IO-APIC-fasteoi ohci_hcd:usb4,
> ohci_hcd:usb6
> 21: 188591 1 IO-APIC-fasteoi HFC-multi
> NMI: 0 0
> LOC:30363931527288
> ERR: 0
> MIS: 0
>
> Is this to be expected for dual core systems?
I assume that's with irqbalance installed (if not, try installing it). My
understanding is that not every interrupt can be balanced and it's not always
valuable to do it. On an Athlon64, there's probably no point.
> I'm currently rebuilding the kernel with the following patch to disable
> NCQ for these drives:
>
> --- linux-2.6.22.5/drivers/ata/libata-core.c2007-08-23
> 00:23:54.0 +0100
> +++ linux-2.6.22.5.new/drivers/ata/libata-core.c2007-08-27
> 10:25:16.0 +0100
> @@ -3788,6 +3788,7 @@
> /* NCQ is broken */
> { "Maxtor 6L250S0", "BANC1G10", ATA_HORKAGE_NONCQ },
> { "Maxtor 6B200M0", "BANC1B10", ATA_HORKAGE_NONCQ },
> +{ "WDC WD800BEVS-07", NULL, ATA_HORKAGE_NONCQ },
> /* NCQ hard hangs device under heavier load, needs hard power
> cycle */
> { "Maxtor 6B250S0", "BANC1B70", ATA_HORKAGE_NONCQ },
> /* Blacklist entries taken from Silicon Image 3124/3132
I've added Jeff to CC in case he's interested about the workaround for this
drive (I assume you're using the AHCI driver with your ATI controller).
(Dermot's been having problems with his WD drive on an ATI chipset)
> Aug 24 13:55:31 playpbx kernel: ata3.00: exception Emask 0x42 SAct
> 0x7fc77 SErr0x800 action 0x6 frozen
> Aug 24 13:55:31 playpbx kernel: ata3.00: (spurious completions during
> NCQ issue=0x0 SAct=0x7fc77 FIS=004040a1:0008)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:00:9a:b7:fc/00:00:04:00:00/40 tag 0 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:08:72:ba:fc/00:00:04:00:00/40 tag 1 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/10:10:f2:bd:fc/00:00:04:00:00/40 tag 2 cdb 0x0 data 8192 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:20:8a:be:fc/00:00:04:00:00/40 tag 4 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:28:12:bf:fc/00:00:04:00:00/40 tag 5 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/10:30:4a:c0:fc/00:00:04:00:00/40 tag 6 cdb 0x0 data 8192 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:50:4a:b5:fc/00:00:04:00:00/40 tag 10 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:58:d2:b5:fc/00:00:04:00:00/40 tag 11 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/10:60:02:b7:fc/00:00:04:00:00/40 tag 12 cdb 0x0 data 8192 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/08:68:22:b8:fc/00:00:04:00:00/40 tag 13 cdb 0x0 data 4096 out
> Aug 24 13:55:31 playpbx kernel: res
> 40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
> Aug 24 13:55:31 playpbx kernel: ata3.00: cmd
> 61/10:70:52:b9:fc/00:00:04:00:00/40 tag 14 cdb 0x0 data 8192 out
> Aug 24 13:55:31 playpbx kernel
Re: "exception Emask: 0x42" errors with 2.6.22.x and SATA drives
On Friday 24 August 2007 20:20:02 Alan Cox wrote: > On Fri, 24 Aug 2007 14:39:10 +0100 > > "Dermot Bradley" <[EMAIL PROTECTED]> wrote: > > I've just built a new machine using a ASUS M2A-VM boardboard (ATI SB600 > > chipset), AMD X2 3800+ processor, and 2 Western Digital 2.5" 80Gb drives > > running in RAID-1 using MD. I've had these problems with both 2.6.22.1 > > and now 2.6.22.5 kernels. > > > > I'm getting the following errors on occasion: > > > > Aug 24 13:19:22 playpbx kernel: APIC error on CPU0: 00(40) > > Aug 24 13:19:33 playpbx kernel: APIC error on CPU0: 40(40) > > This is not good. FWIW, I've got the HDMI version of this board and I have exactly the same problem (even with the newest BIOS) if nmi_watchdog is not set to zero. Try booting with nmi_watchdog=0 (default on x86-64, I think) and see if these go away. I guess the APIC has some difficulties handling NMIs. > > Aug 24 13:55:31 playpbx kernel: ata3.00: exception Emask 0x42 SAct > > 0x7fc77 SErr0x800 action 0x6 frozen > > Aug 24 13:55:31 playpbx kernel: ata3.00: (spurious completions during > > NCQ issue=0x0 SAct=0x7fc77 FIS=004040a1:0008) > > Probably not connected - your drive seems to be talking rubbish > > Neither are good, the latter is probably a drive firmware problem and the > kernel will give up using NCQ with it if it keeps doing that, which > should be just fine. I get the feeling this problem is independent of the APIC errors, and I don't see it here. I'm using Hitachi Deskstars on the on-board controller in AHCI mode, and everything works fine. As Alan said, it's very possibly just the drive not properly supporting NCQ. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: troubles with r8169
On Sunday 12 August 2007 21:06:43 Vadim Dyadkin wrote: > Robert Hancock пишет: > > This could well be a problem with the nvidia driver as it shares the > > same IRQ. The first step would be to see if the problem still shows up > > without the nvidia binary module loaded. > > Thank for your answer. This problem never shows up if I use only nvidia > driver (the work without network), or if I use only r8169 (without > x.org). If I use both of them I have the hang. Usually the hang appears > if OpenGL is used or network rate is maximal. I tested this regimes many > times before. If you haven't already, I'd drop [EMAIL PROTECTED] an email to see if they have any insight. Not that this can't be a kernel bug, just that it's a bit difficult for kernel developers to debug when you're using a driver for which we don't have the sources. As for changing the IRQ assignments, I don't have any immediate suggestions. I notice that this laptop has a dual core processor, so I'm guessing disabling APIC isn't an option. Have you tried that anyway, just to see if the IRQ assignment differs? -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sb-400 audigy prob
On Saturday 11 August 2007 17:58:43 Gene Heskett wrote: > Greetings; > > Running 23-rc2 since it came out, I've just discovered I have only the > system beep for sound. From lspci: > 01:08.0 Multimedia audio controller: Creative Labs SB0400 Audigy2 Value > Subsystem: Creative Labs Unknown device 1001 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (500ns min, 5000ns max) > Interrupt: pin A routed to IRQ 12 > Region 0: I/O ports at c000 [size=64] > Capabilities: [dc] Power Management version 2 > Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > > But I have a line in my rc.local that reloads the sound fonts: > [EMAIL PROTECTED] rulesdujour]# sfxload /usr/music/SoundFonts/CT4MGM.SF2 > No AWE synth device is found I'm not 100% sure, but (at least) Debian has two programs "sfxload" and "asfxload", which work with OSS and ALSA respectively. I've found that both can work, but the former will only work with OSS emulation loaded. If you have an "asfxload", I would try it instead. > This occurred once before and a reboot fixed it, so I'm going to try it > again. BRB > > About 4 reboots later, it finally works again, after it had hung in udev, > and apparently did an auto reboot while I was looking for my flashlight. I > had selected in that case to boot to 2.6.22-rt9 since 2.6.23-rc1 didn't > work either and udev had hung after spitting out that useless screenfull of > missing attributes messages like it always does, (when do we get rid of > that?) and it had been hung in udev for about 3 minutes before I got up and > left to find my flashlight. On arrival with light in hand, I found the > same screenfull of udev messages and assumed it was still hung, but as I > was crawling under the desk I heard the speakers thump like they do when > udev finds the device, and the boot continued. I didn't realize it had > spontainiously rebooted till I saw the login message said 2.6.23-rc2, the > grub default. Not that it explains any of this, of course. I hope you can reproduce it. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1, KVM-AMD problem
On Saturday 04 August 2007 14:17:34 Prakash Punnoor wrote: > Unfortunately this doesn't seem to have made it into 2.6.23-rc2. I need it > as well, to make Windows XP boot up w/o hanging or reebooting my host > machine. It isn't in 2.6.23-rc2. I guess Avi should re-send to Linus and hopefully it'll be in -rc3. Thanks for pointing this out. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler Situation
On Friday 03 August 2007 15:51:59 T. J. Brumfield wrote: > > I'm not going to argue with this point because I think this is exactly > > what Linus meant. He wanted a scheduler that worked. And he knew it > > wouldn't work immediately after merging it. So he had to go with the > > person that he trusted the most to make it work, quickly. And this was > > Ingo. That might not be a "purely" technical reason, but I suspect it's a > > correct one. > > You're demonstrating a lack of reason here. In the same post Linus > said repeatedly that he feels Con isn't someone he wanted to work with > because he felt Con refused to listen to bug reports and was > argumentative. Which is refuted only by your personal experience, not by any facts that have yet been posted. > And never once did Linus say that CFS would work out > of the box. He said it was new code that needs plenty of testing. In > fact he said that is why he was against plugsched, because if people > ran different schedulers, then CFS would get less testing. You're > just putting motives in Linus' mouth that weren't there to begin with. This has gone too far. I said NO such thing. I repeatedly stated in previous emails that the decision was based on code that, _although not perfect on submission_ could most rapidly be made to work. You have just twisted what I've said here to contradict that. Please read ALL of my emails, instead of selectively attacking only what you disagree with. ( I also don't appreciate being copied back onto LKML, after a long email diatribe (which you selectively did not copy). It's just bad netiquette. ) > > Who cares? You can't say either Linus or Ingo are any worse in this > > regard, so it's irrelevant when discussing why SD wasn't chosen. This is > > just as political as anything negative that Linus said. > > I imagine if it was your pet project, and you were trampled on in this > manner, you'd care. And I don't like seeing people abused like this. I certainly wouldn't expect my code to be taken. If somebody else's was taken, I would accept that I was powerless to make them do otherwise. That's what benevolent dictatorships are all about and what somebody familiar with Linux development should expect. The best way to deal with "injustices" is to constructively move past them. Con decided to leave the community, and that's another option. I just think everybody's lost out, himself included. > I also don't care to see a project I care about weakened due to petty > drama and politics. I had hoped the Linux community was above this. > Your lack of compassion in the matter however is duly noted. We have > polar views and aren't going to agree. LKML isn't _normally_ a place for compassion, but for code, and I'm pretty sure that if there was less compassion we'd have fewer flamewars and less of the petty politics that you are complaining so loudly about. Either you can convince Linus to change his mind, or you can't. Complaining about it will achieve nothing other than to increase the noise to signal on LKML. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler Situation
On Friday 03 August 2007 14:27:30 Андрій Мішковський wrote: > Bad things may happen if Linus gives a right of making decision to > other people (a big group of people). ;) > As you said, Linux is a public OS, so Con's code never will be lost. > That's the base of open source - people come and go, but the code > stays. :) Unfortunately Con undermined this by leaving all kernel development. So unless somebody else is sufficiently motivated to constructively improve SD (and I think we all hope they will, competition is good), it will probably die. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Scheduler Situation
The real question is WHY do people keep writing essays about topics that have _already_ been exhaustively explored in other threads? If you want a better understanding of the situation, read the archives, DON'T post another duplicate message about the same scheduler parade. Unless you've got some constructive input that goes further than asking the same questions that have already been asked and answered multiple times before, please just do not pollute this list. It's becoming so repetitive this almost sounds like a 419. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1, KVM-AMD problem
On Monday 30 July 2007 14:00:13 Avi Kivity wrote: > How about the attached patch? (I haven't yet tried to reproduce, but > this can cause an AMD-only oops). This seems to have fixed the problem. Thanks Avi. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nvidia installer DIW with 2.6.23-rc1
On Sunday 29 July 2007 15:57:33 Gene Heskett wrote: > Is this a known problem? Do I need to report it to nvidia somehow? It > looks to me like it may be their problem, and I have submitted it, but if > anyone has a better idea, please advise. System is FC6, uptodate as of > yesterday. Gene, this happens almost every kernel version. You should know that binary drivers are OT for LKML, and if you want to report the problem you go through the [EMAIL PROTECTED] address clearly printed in the driver documentation, and on their website. (As it turns out, the fix is very easy and you could easily fix it yourself. Just run --extract-only on the installer and poke around the affected files, removing the extra "NULL" argument to kmem_cache_create().) -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1, KVM-AMD problem
On Sunday 29 July 2007 14:47:57 you wrote: > Alistair John Strachan wrote: > > On Sunday 29 July 2007 12:34:28 you wrote: > > [snip] > > > >>> Doesn't help, I still get the same crashes. I tried 2.6.22 again and > >>> it's rock solid by comparison. > >> > >> Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22? > >> Please describe your configuration *exactly*. > > > > I'm using the kvm-33 *userspace* package (based on Debian's kvm-28 > > packaging) and 2.6.23-rc1's KVM modules. I patched 2.6.23-rc1 with the > > patch you provided in your last email. So I'm not using -git HEAD. > > > > Maybe there's been additional necessary fixes to -git requiring me to > > update to HEAD? That wasn't clear from your last email. > > No, that patch is the only potential fix post -rc1. There are a few > other fixes there, but they are intended to avoid guest crashes, not > host crashes. > > What guest are you running? Maybe I can reproduce it here. Right now, Windows XP. I'm pretty sure Linux (well, Debian Etch) works fine. I could only get Windows to install with -no-acpi, but I run it with the following (if this is at all useful): kvm -no-acpi -m 256 -hda $IMAGE -net nic -net tap,script=/etc/kvm/kvm-ifup Basically, the installer seems to work fine, but Windows seemed to have problems after installing post-SP2 updates. Maybe that's why not everybody is seeing it yet. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1, KVM-AMD problem
On Sunday 29 July 2007 12:34:28 you wrote: [snip] > > Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's > > rock solid by comparison. > > Do you mean, kvm-33 on top of 2.6.22, or the kvm modules from 2.6.22? > Please describe your configuration *exactly*. I'm using the kvm-33 *userspace* package (based on Debian's kvm-28 packaging) and 2.6.23-rc1's KVM modules. I patched 2.6.23-rc1 with the patch you provided in your last email. So I'm not using -git HEAD. Maybe there's been additional necessary fixes to -git requiring me to update to HEAD? That wasn't clear from your last email. > And what do you mean, "rock solid by comparison"? Either it's rock > solid or it isn't. It's rock solid. It does not crash. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc1, KVM-AMD problem
On Sunday 29 July 2007 09:16:43 Avi Kivity wrote: > Alistair John Strachan wrote: > > Hi, > > > > I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a > > digital photo of the oops. Alarmingly, a lot of the time it triple faults > > the machine and I don't get a chance to grab it. This time I was lucky, > > though. > > > > http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg > > > > Unfortunately, some of the oops text scrolled out of the screen. I will > > endeavour to reproduce the bug over serial console, but I can make no > > guarantees. > > > > The CPU is an AMD X2 BE-2350, chipset is AMD 690G. > > If you are using the modules from 2.6.23-rc1, try upgrading to latest > -git, which contains a patch that might fix this problem. If you are > using the modules from kvm-33, try applying the attached patch. Doesn't help, I still get the same crashes. I tried 2.6.22 again and it's rock solid by comparison. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel panic w/ 2.6.22.1, VIA EPIA Mini ITX
> I have absolutely no idea what triggers this crash. Checked the RAM on the box? Kinda weird if you're getting VRAM corruption, I wonder if this is due to the RAM failing at the point where the framebuffer is mapped? Try running memtest86 on it. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.23-rc1, KVM-AMD problem
Hi, I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital photo of the oops. Alarmingly, a lot of the time it triple faults the machine and I don't get a chance to grab it. This time I was lucky, though. http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg Unfortunately, some of the oops text scrolled out of the screen. I will endeavour to reproduce the bug over serial console, but I can make no guarantees. The CPU is an AMD X2 BE-2350, chipset is AMD 690G. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Sunday 22 July 2007 22:04:24 Linus Torvalds wrote: > So give it all a good whacking, and report back about all the neat new > features! I'm fairly sure this is already known about on SPARC64 (see David Miller's email ""build-id" changes break sparc64"), but I just thought I'd let people know the warnings are also visible on x86_64: "ld: warning: Cannot create .note.gnu.build-id section, --build-id ignored." gcc (GCC) 4.1.3 20070718 (prerelease) (Debian 4.1.2-14) GNU assembler (GNU Binutils for Debian) 2.17.50.20070718 The kernel boots and works fine, however. The above tools are from Debian unstable. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gmail and flowed text (was Re: Correction to LZO1X)
On Wednesday 11 July 2007 16:21:44 Christoph Hellwig wrote: > On Wed, Jul 11, 2007 at 07:06:23PM +0530, Satyam Sharma wrote: > > Which leaves Gmail, but Gmail has the flowed text disease (that > > cannot be disabled) and although Gmail offers SMTP/POP, our evil > > proxy/NAT setup here wouldn't let me make any use of it to access > > it from some other MUA such as pine/mutt. > > Given the amount of google people here maybe someone can get this > piece of junk called gmail fixed? If google claims they're not > evil they should stop sending broken patches around.. It'd be nice if they stopped mangling headers too (spaces->tabs). -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sb1250-duart.c: SB1250 DUART serial support
On Thursday 12 July 2007 19:16:20 Maciej W. Rozycki wrote: > On Thu, 12 Jul 2007, Andy Whitcroft wrote: [snip] > > WARNING: declaring multiple variables together should be avoided > > #372: FILE: drivers/serial/sb1250-duart.c:246: > > + unsigned int mctrl, status; > > Well, this is probably superfluous -- why would anyone prefer: > > int r0; > int r1; > int r2; > int r3; > int r4; > > to: > > int r0, r1, r2, r3, r4; > > unconditionally? Imagine you're working on a piece of kernel code that has a lot of parallel churn. Conflicts on lines like "int a,b,c,d;" are more likely to cause Andrew et al pain, which I guess is the rationale for discouraging it. Conversely, if the variables are kept separate, diff handles it fine. I think as long as the variables are logically grouped, the pain is minimised, but there's a few good reasons for the verbose style. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Frequent SATA resets with sata_nv (fwd)
(Sorry, accidentally dropped LKML) On Sunday 24 June 2007 01:52:30 you wrote: > Googling around lkml.org, I found a few threads investigating what look > like very similar problems, some of which never seemed to find the > solution, but one of which came up with a fairly quick answer it seemed, > namely that the drive's NCQ implementation was horked: > http://lkml.org/lkml/2007/4/18/32 Well, there's been generic problems with the ADMA code on the CK804, but I think Robert fixed them (added CC). I've certainly had NO problems since 2.6.21. However, assuming the drive's NCQ _is_ busted and needs to be blacklisted, you might find you can temporarily work around the problem by loading the sata_nv module with adma=0, or boot with sata_nv.adma=0. Not to point the finger at ADMA support specifically, of course, but simply that ADMA enables the NCQ features. It'd be good if you could report back whether this helps fix it. > While I don't have older logs to verify exactly when this started, it > was fairly recent, perhaps around my 2.6.20.1 to 2.6.21.1 kernel > upgrade. Yes, this is probably around the time adma became the default. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch-mm 00/25] High resolution timer updates and x86_64 support - V2
On Saturday 16 June 2007 11:36:00 Thomas Gleixner wrote: > The -hrt tree at http://www.tglx.de/projects/hrtimers/2.6.22-rc4/ contains > also an hpet force patch series from Venki Pallipadi, but I leave this up > to Venki to send it mainline wards. What's the status on the nForce "hpet force fix" (Subject: "Enable hidden HPET on NVidia motherboards") that also exists? I think if one board can have its HPET forced, so can another. Last I heard we were waiting on NVIDIA to confirm whether Mikko's logic was supported by specifications? Any update on this? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFD] Documentation/stable_api_nonsense.txt translated into Japanese
On Sunday 10 June 2007 13:03:15 you wrote: > 訳注(2) > 「引火性の高い」の原文は "valatile"。 > valatile には「揮発性の」「爆発しやすい」という意味の他、「変わり > やすい」「移り気な」という意味がある。 > 「（この話題は）爆発的に激しい論争を巻き起こしかねない」ということ > を、「（カーネルのソースレベルインターフェースは）移ろい行くもので > ある」ということを連想させる "valatile" という単語で表現している。 Not speaking Japanese, I'm probably missing some fundamental translation issue, but the English word is "volatile", not "valatile". -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel-rng: Undo mess made by an 80 column extremist
On Thursday 07 June 2007 22:17:18 Krzysztof Halasa wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > > The intel-rng printed a nice well formatted message when the port was > > disabled. Someone then came along and blindly trashed it by screwing up a > > trim down to 80 columns. > > Perhaps we should drop that 80-column style and use some 120+? > X or no X, almost all people now have more lines and columns on their > displays than MDA 20 years ago. > > 132 to match text VGA perhaps? > 80 can be left for the actual _output_, I mean number of chars printed > by kernel code. I personally buy the argument that 80 cols helps remind people that they've used too many indentation depths and should redesign their code. I think it's a good thing to stick to where possible, even if just from a design perspective. There are some cases such as the one Alan has pointed out here where being strictly 80 cols seems more destructive than useful, but those are the exception, not the rule (IMO). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
On Tuesday 22 May 2007 23:09:39 Richard Griffiths wrote:
> Venerable cramfs fs Linear XIP patch originally from MontaVista, used in
> the embedded Linux community for years, updated for 2.6.21. Tested on
> several systems with NOR Flash. PXA270, TI OMAP2430, ARM Versatile and
> Freescale iMX31ADS.
> +#else /* CONFIG_CRAMFS_LINEAR */
> +/*
> + * The physical location of the cramfs image is specified as
> + * a mount parameter. This parameter is mandatory for obvious
You've used spaces here instead of tabs, probably worth replacing.
> +/*
> + * We hold the mm semaphore for reading and vma->vm_mm->page_table_lock
> + */
> +static inline void break_cow(struct vm_area_struct * vma, struct page *
new_page, unsigned long address,
> +pte_t *page_table)
> +{
> +pte_t entry;
Here again.
> +/*
> + * Handle COW of XIP memory.
> + * Note that the source memory actually isn't a ram
> + * page so no struct page is associated to the
source
> + * pte.
> + */
This whole section too.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v4
On Tuesday 15 May 2007 09:18:02 Thomas Gleixner wrote: > I've uploaded a new version of the x86_64 highres/dyntick patches: > > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-hig >hres-v4.patch > > Broken out version: > > http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc1-x86_64-hig >hres-v4.patches.tar.bz2 > > Changes since last version: > > - TSC calibration against PM-Timer Working fine now, thanks a lot. Great latencies on usleep() now too, just what I was looking for. (BTW, with HRT (but not NO_HZ), does the HZ value have any effect on usleep() (and friends) latencies?) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v1
On Monday 14 May 2007 23:05:14 Thomas Gleixner wrote: > On Mon, 2007-05-14 at 22:15 +0100, Alistair John Strachan wrote: > > On Monday 14 May 2007 11:26:08 Thomas Gleixner wrote: > > > I'm pleased to announce an updated version of the x86_64 > > > highres/dyntick support patches against 2.6.22-rc1: > > > > [snip] > > > > > - Various fixups from Chris Wright > > > - TSC calibration fix (pointed out by Alistair John Strachan) > > > > > > Comments, bugreports, patches are welcome as ususal > > > > Neither of the bugs I reported appear to be fixed. > > > > I took a clean git tree from the 2.6.22-rc1 tag and patched with this > > version; my CPU MHz and dmesg counter still appear to be broken (v3 was > > used). > > Sigh. /me feels stupid. > > Can you please apply the following patch on top and check, whether it > fixes the problem ? Please provide the debug output, when it fails. Doesn't fix the problem, and here is the debug: TSC calibrated against pm_timer 8927439 9106459 179020 640810145 tsckhz: 1350695500 640810145 210779356 Marking TSC unstable due to TSCs unsynchronized time.c: Detected 210779.356 MHz processor. (Perhaps if this debug effort has to continue, we could remove some of these gentlemen from CC?) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v1
On Monday 14 May 2007 11:26:08 Thomas Gleixner wrote: > I'm pleased to announce an updated version of the x86_64 highres/dyntick > support patches against 2.6.22-rc1: [snip] > - Various fixups from Chris Wright > - TSC calibration fix (pointed out by Alistair John Strachan) > > Comments, bugreports, patches are welcome as ususal Neither of the bugs I reported appear to be fixed. I took a clean git tree from the 2.6.22-rc1 tag and patched with this version; my CPU MHz and dmesg counter still appear to be broken (v3 was used). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] Intel announces the PowerTOP utility for Linux
On Monday 14 May 2007 21:22:50 Jan Engelhardt wrote: > On May 12 2007 22:12, Alistair John Strachan wrote: > >On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote: > >> What's eating the battery life of my laptop? Why isn't it many more > >> hours? Which software component causes the most power to be burned? > >> These are important questions without a good answer... until now. > > > >This is a really great tool and presents a very intuitive alternative to > > the timer stats file.. > > > >On a Core 2 Duo Macbook, Linux always gets around 3.2h battery, OS X about > >4.2h. This tool has identified that uhci_hcd is where 75% of the ticks are > >going when X is not loaded. Unloading uhci_hcd drops the battery life back > > to around 4.2h, but I lose the keyboard. > > > >Is there any way to find out what USB driver is causing usb_uhci to be > > this busy? > > At its worst, it _is_ the USB chip that draws the power when it is active > (when uhci_hcd is loaded); does not need to be usbhid or so. This is certainly true, and to a significant extent it _was_ the uhci_hcd, but it turns out the main contributor to HZ here were the appletouch and hci_usb drivers. Disabling both drops the ticks down from about 850 to 150. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: converting appletouch to usb autosuspend...
On Monday 14 May 2007 06:50:39 Oliver Neukum wrote: > Am Montag, 14. Mai 2007 02:53 schrieb Alistair John Strachan: > > > What did you use instead of hci_usb then ? usbkbd ? This won't give you > > > the special keys etc... > > > > Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's > > got nothing to do with the keyboard. I unloaded both appletouch AND > > hci_usb. > > If you want large power savings from USB autosuspend, all > loaded drivers must support autosuspend. The HCD can suspend > only if all connected devices are suspended. > Are you willing to test patches for HID & the new last_busy based > usb core infrastructure? Of course. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86-64 highres/dyntick support
On Sunday 06 May 2007 21:58:47 Thomas Gleixner wrote: > I'm pleased to announce the first cut of the final x86_64 > highres/dyntick support, which I did based on Chris Wright's patch set, > which is again based on Arjan van de Ven's initial work: I've noticed a few problems with this patch series, which I manually (without difficulty) ported to 2.6.22-rc1. Firstly, the output of /proc/interrupts looks a bit strange. NO_HZ isn't enabled, just high resolution timers. HZ was set to 1000. [EMAIL PROTECTED]:~$ cat /proc/interrupts CPU0 CPU1 0:195 0 IO-APIC-edge timer 1: 21 13698 IO-APIC-edge i8042 8: 0 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 14:117 51178 IO-APIC-edge libata 15: 0 0 IO-APIC-edge libata 18:455 449373 IO-APIC-fasteoi lan-sky, EMU10K1 19: 0 3 IO-APIC-fasteoi yenta, ohci1394 20:220 86188 IO-APIC-fasteoi ohci_hcd:usb2 21: 0 26 IO-APIC-fasteoi ehci_hcd:usb1 22: 0273 IO-APIC-fasteoi sata_nv 23:928 507781 IO-APIC-fasteoi sata_nv, lan NMI: 0 0 LOC:47232724797930 ERR: 0 Only 195 timer interrupts? I only see this on an AMD Opteron, it doesn't occur on an Intel Core 2 Duo. Mainline reports this counter regularly increasing with or without the acpi_pm clocksource loaded. Secondly, /proc/cpuinfo seems to be broken: [EMAIL PROTECTED]:~$ cat /proc/cpuinfo | grep MHz cpu MHz : 210779.550 cpu MHz : 210779.550 Unless my CPU is just under 80 times faster than it used to be, these numbers are incorrect. I expect 2700.50, or something similar. cpufreq isn't compiled in. Finally, and possibly related, the dmesg timestamps seem to be totally broken. Apparently my machine booted in less than 1 second, with the last messages as: [0.607862] bridge: topology change detected, propagating [0.607862] bridge: port 2(lan-sky) entering forwarding state [0.830472] Linux agpgart interface v0.102 (c) Dave Jones Of course, all of these problems might be PEBKAC, but I'm sceptical. Find the kernel config, updated patch (for 2.6.22-rc1), dmesg, contents of /proc/interrupts and /proc/cpuinfo here: http://devzero.co.uk/~alistair/2.6.22-rc1-hrt/ -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: converting appletouch to usb autosuspend...
On Monday 14 May 2007 01:46:10 Soeren Sonnenburg wrote: > On Sat, 2007-05-12 at 22:47 +0100, Alistair John Strachan wrote: > > On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote: > > > Dear all, > > [...] > > > > While we are at it usb related powerhogs on this macbook pro are > > > uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) > > > too... > > > > I've found that hci_usb also hogs power on the Macbook; blacklisting this > > module cuts down HZ considerably. I also found appletouch consumed ticks, > > I guess without loading appletouch ? Then there really is something in > there that needs to be fixed.. > > > just as you did. > > What did you use instead of hci_usb then ? usbkbd ? This won't give you > the special keys etc... Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got nothing to do with the keyboard. I unloaded both appletouch AND hci_usb. > > uhci_hcd then drops to noise; my Macbook's sitting on 10W with the > > backlight on minimum, which is about what it can manage in OS X on > > maximum life settings. > > Thats quite some improvement... Yes indeed. The only thing left to improve, as I understand it, is enabling the C4/C4e power states available on the Core 2 Duo, which don't currently seem to be utilised by Linux. I notice, however, that the screenshot on the Intel Powertop page does seem to have these states available? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: converting appletouch to usb autosuspend...
On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote: > Dear all, > > I've realized using the great powertop ( http://www.linuxpowertop.org/ ) > that loading the appletouch driver (and touching it once) makes consumes > about 0.3 W even when not touching the pad. As rmmod'ing appletouch > fixes this I wonder why the driver does not do this alone. So my > question is what does one have to do to convert a driver (such as > appletouch) to make use of usb autosuspend except for > > .supports_autosuspend = 1 > > ... > > While we are at it usb related powerhogs on this macbook pro are > uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func) > too... I've found that hci_usb also hogs power on the Macbook; blacklisting this module cuts down HZ considerably. I also found appletouch consumed ticks, just as you did. uhci_hcd then drops to noise; my Macbook's sitting on 10W with the backlight on minimum, which is about what it can manage in OS X on maximum life settings. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [announce] Intel announces the PowerTOP utility for Linux
On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote: > What's eating the battery life of my laptop? Why isn't it many more > hours? Which software component causes the most power to be burned? > These are important questions without a good answer... until now. This is a really great tool and presents a very intuitive alternative to the timer stats file.. On a Core 2 Duo Macbook, Linux always gets around 3.2h battery, OS X about 4.2h. This tool has identified that uhci_hcd is where 75% of the ticks are going when X is not loaded. Unloading uhci_hcd drops the battery life back to around 4.2h, but I lose the keyboard. Is there any way to find out what USB driver is causing usb_uhci to be this busy? (BTW, the link to Keith's patch for dhcdbd seems to be broken on your homepage.) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Probable PCIE prob
On Saturday 28 April 2007 20:53:37 Syren Baran wrote: > Hi, > > i got a problem with the combination of an Asrock AM2NF4G-SATA2 > mainboard with a Radeon X1900 (chip 1002,724b) graphics > card. /i386/pci/mmconfig.c reports a buggy bios (e000 is not > E820-reserved). System crashes only happen when viewing films (neither > xine nor mplayer run with root privileges) and independent of video > drivers (framebuffer, vesa and fglrx). Logs dont show any anomalies > before crashing. Anybody got a clue? This is a pretty bizarre crash. It might be a hardware problem. Try running a load intensive task, something that heats your CPU up, for a long period. See if it lasts longer than 30 minutes.. Another thing you could try doing was eliminating X completely, by using mplayer on a vesafb console.. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Move LOG_BUF_SHIFT to a more sensible place
Several people have observed that perhaps LOG_BUF_SHIFT should be in a more obvious place than under DEBUG_KERNEL. Under some circumstances (such as the PARISC architecture), DEBUG_KERNEL can increase kernel size, which is an undesirable trade off for something as trivial as increasing the kernel log buffer size. Instead, move LOG_BUF_SHIFT into "General Setup", so that people are more likely to be able to change it such a circumstance that the default buffer size is insufficient. Signed-off-by: Alistair John Strachan <[EMAIL PROTECTED]> --- diff --git a/init/Kconfig b/init/Kconfig index b170aa1..cc9eb35 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -262,6 +262,23 @@ config IKCONFIG_PROC This option enables access to the kernel configuration file through /proc/config.gz. +config LOG_BUF_SHIFT + int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" + range 12 21 + default 17 if S390 || LOCKDEP + default 16 if X86_NUMAQ || IA64 + default 15 if SMP + default 14 + help + Select kernel log buffer size as a power of 2. + Defaults and Examples: +17 => 128 KB for S/390 +16 => 64 KB for x86 NUMAQ or IA-64 +15 => 32 KB for SMP +14 => 16 KB for uniprocessor +13 => 8 KB +12 => 4 KB + config CPUSETS bool "Cpuset support" depends on SMP diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 3f3e740..de82401 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -86,23 +86,6 @@ config DEBUG_SHIRQ Drivers ought to be able to handle interrupts coming in at those points; some don't and need to be caught. -config LOG_BUF_SHIFT - int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" if DEBUG_KERNEL - range 12 21 - default 17 if S390 || LOCKDEP - default 16 if X86_NUMAQ || IA64 - default 15 if SMP - default 14 - help - Select kernel log buffer size as a power of 2. - Defaults and Examples: -17 => 128 KB for S/390 -16 => 64 KB for x86 NUMAQ or IA-64 -15 => 32 KB for SMP -14 => 16 KB for uniprocessor -13 => 8 KB -12 => 4 KB - config DETECT_SOFTLOCKUP bool "Detect Soft Lockups" depends on DEBUG_KERNEL && !S390 -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21 - something wrong with dmesg.
On Friday 27 April 2007 15:31:37 Sunil Naidu wrote: > On 4/26/07, Alistair John Strachan <[EMAIL PROTECTED]> wrote: > > > Don't you need to increase CONFIG_LOG_BUF_SHIFT ? > > Yep, I need to. But, have to enable the Kernel Debug (DEBUG_KERNEL) to > increase the value from default 14 value to 15/16. I feel that this > might increase the kernel size? >From a quick grep, DEBUG_KERNEL will only increase the kernel size on PARISC (arch/parisc/mm/init.c), so setting it won't have any adverse affect on your kernel size (if you disable all the options under it). > Ummm, is it possible to move CONFIG_LOG_BUF_SHIFT under the General > Setup area? (say, down the Kernel .config support - IKCONFIG). I agree with this. It's also quite interesting to see that one can enable DEBUG_KERNEL, increase CONFIG_LOG_BUF_SHIFT, and then disable DEBUG_KERNEL, and the changed value is still used. I think it should be easier to change this value, as anybody with it set too low has a useless kernel log buffer and it can make reporting more difficult. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.21 - something wrong with dmesg.
On Thursday 26 April 2007 14:03:39 you wrote: > On Thu, Apr 26, 2007 at 05:44:40PM +0530, Sunil Naidu wrote: > > Hello, > > > > I did compile the kernel, boots good ;-) BTW, does anyone (on P-III) > > facing a memory check skip or sort of? Not getting RAM info in the > > dmesg. Unable to get dmseg from the start of the gcc check! Any clue? > > Here is the dmesg I get on my box: > > Don't you need to increase CONFIG_LOG_BUF_SHIFT ? May also simply be that you need to pass dmesg -s 64000 or something similar, because it defaultly only dumps 16K of the kernel log buffer (regardless of the CONFIG setting). (Also, does Andrew really need to be CCed twice?) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ZFS with Linux: An Open Plea
On Tuesday 17 April 2007 15:48, Alan Cox wrote: > > So who is responsible for potential changing Linux code licensing for > > allow if not incorporate CDDL code correct interraction without breaking > > some law ? > > Every single contributor, individually. Which won't happen. > > The real test of whether Sun were serious about ZFS being anywhere but > Solaris is what they do to license it - they've patented everything they > can, and made the code available only under licenses incompatible with > other OS products. Their intent is quite clear, and quite sad. This isn't universally true. Look at Java, for example, which Sun recently released parts of under an open source license -- not the CDDL, not a CDDL/xxx dual license, the GPL proper. Indeed, Sun already have products that are dual licensed CDDL/GPL, for example the J2EE product. > If Sun want ZFS to get used all over the place in free software then I'd > have expected at the very least to see them throw out a copy of the code, > docs and patent grant in a form that could be used, even if it came with > no other assistance of any kind. I couldn't speculate on the rationale, but it does seem that Sun's choice to use _only_ the CDDL with certain software (like ZFS) is deliberate. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hpet: Enable hidden HPET on NVidia motherboards
On Sunday 15 April 2007 21:14, Mikko Tiihonen wrote: > Enables HPET for NVidia motherboards with broken BIOS. The patch reads the > HPET address from the pci config space. The patch should also work if ACPI > is disabled. > > The HPET search is done in early-quirks because even > DECLARE_PCI_FIXUP_EARLY was too late. If the new quirk causes problems it > can be disabled with the nohpet boot option. > > The patch assumes that the BIOS has done the basic setup of HPET, but has > not published the result in ACPI tables. This is at least true for some > Asus and Gigabyte motherboards. This works fine on my DFI Lanparty UT nForce4 CK804 mainboard: [EMAIL PROTECTED]:~$ dmesg | grep hpet [ 25.677099] hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31 [ 25.677102] hpet0: 3 32-bit timers, 2500 Hz [ 25.678799] Time: hpet clocksource has been installed. I've been wanting hpets for a while, this patch is extremely useful to me. Unfortunately your patch does not seem to apply with standard tools, perhaps your mailer corrupted it (I just hand applied it). Thanks Mikko. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Use C++ in kernel module?
On Friday 30 March 2007 07:59, Bongani Hlope wrote: > On Friday 30 March 2007 05:49:14 Jan Engelhardt wrote: > > On Mar 30 2007 11:37, Conke Hu wrote: > > > Is it possible to use C++ in linux kernel module? how? > > > I've tested but failed, there is an unknown symbol in the .o file from > > > c++ source code. > > > > You answered it yourself. Linux does not have a C++ runtime. > > It is possible to use a very limited set of C++ features, usually not > > worth the fight. > > > > > > Jan > > Do the "C++ kernel modules" crowd actually know C++? If they knew how C++ > was designed, they would know that it requires some runtime support, which > will stop them from asking this question over and over again. I'm begining > to think that most of these questions are asked by people who think OO > programing should used in the kernel (which is already done anyway) Not to mention this, attached to every single LKML email: > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ http://www.tux.org/lkml/#s15-3 "Why don't we rewrite the Linux kernel in C++?" "Why not add a C++ interface layer to the kernel to support C++ drivers?" "Can we make the kernel headers C++-friendly?" -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why is /dev on a different filesystem ? [Kernel 2.6.20.3]
On Wednesday 21 March 2007 19:13, Paul Rolland wrote: > So, obviously, /dev is on /, but the stat(2) says no. > Who is right, and where is the bug ? > > Kernel 2.4 had it right : /dev was on /, no doubt. Some distros will mount tmpfs over /dev so that a minimal "real dev" can be provided as a fallback, but udev can add and remove nodes from /dev ad hoc during regular runtime. So I don't think there's a bug and I don't think anything is lying. If you want the dev your distro gave you, just mount your rootfs on another mount point in read-only and run tar over that instead. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA problems in 2.6.20.3
On Friday 16 March 2007 23:44, you wrote: > Charles Shannon Hendrix wrote: > > I normally run a modified 2.6.19 kernel and it works great. > > > > I recently tried 2.6.20 and had severe SATA problems with it. > > > > Yesterday I tried 2.6.20.3, and the problems are still there. > > Can you try 2.6.21-rc and see if the problem is fixed in those kernels? -rc4 specifically, it's the first one that's worked for me (possibly related). (BTW Robert, the sata_nv shadow registers patch has been fine here with a patched -rc3 for just over a week now.) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in select() in linux
On Monday 12 March 2007 15:02, Lluís Batlle wrote: > Oh, of course you're right. I was inside too much layers to think of > the tcp protocol, and I did not pay attention to it. > > Maybe something could be added to the manpage anyway. > > The bad thing is that there's no way I can use a socket for writing > using select() if that connection has been half-closed by the other > end. Moo. This question comes up from time to time. I think the answer is ultimately "select() sucks, use poll()". I can't exactly remember the details, but I believe POLLHUP or POLLOUT as flags do what you want. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20*: PATA DMA timeout, hangs (2)
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote: [snip] > So, are /dev/hd* going to disappear in a few years? iow, does it make > sense to _slowly_ start to migrate to /dev/sd*? How would you propose doing this? I'm sure modern distros with an initrd/initramfs probably already do some sort of root detection. Doesn't fix the fstab issue, but I suppose this could be auto-generated too. > The problem is there's no plan B in case of any troubles except rename > everything back again to boot an old kernel. I doubt this matters for distributors, as they'll simply switch over when you upgrade the distro, and the earliest supported kernel will be the one that shipped with the newer version. I accept that it's a bit of a drag, but it's better to have a standard naming convention for all disks, isn't it? Glad this is working for you. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20*: PATA DMA timeout, hangs (2)
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
> On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
> > 2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
> > -d 1 /dev/hda):
> >
> > hda: dma_timer_expiry: dma status == 0x20
> > hda: DMA timeout retry
> > hda: timeout waiting for DMA
> > hda: status error: status=0x58 {
> > DriveReady
> > SeekComplete
> > DataRequest
> > }
[snip]
> This system has SATA but there's only one PATA disk
Not a solution, unfortunately, but try disabling CONFIG_IDE and using Alan's
new PATA drivers. For your Intel systems, this should mean you need only:
CONFIG_ATA_PIIX
For both SATA and PATA support. You'll need the appropriate SCSI modules built
in (if you say =y), i.e. SCSI disk and SCSI CDROM should be built in.
--
Cheers,
Alistair.
Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 29/30] sata_nv: don't read shadow registers when in ADMA mode
On Friday 09 March 2007 14:27, you wrote: > Jeff Garzik wrote: > > [EMAIL PROTECTED] wrote: > >> From: Robert Hancock <[EMAIL PROTECTED]> > >> > >> Reading from the ATA shadow registers while we are in ADMA mode may > >> cause undefined behavior. Don't read the ATA status register when > >> completing commands for this reason, it shouldn't be needed as the > >> controller will notify us if the command failed. Also, don't allow > >> commands with result taskfile requested to execute in ADMA mode, since > >> that requires accessing the shadow registers. We also still need to > >> override tf_read since libata > >> will read the result taskfile on a command failure, and we need to go > >> into > >> port register mode before allowing this. > >> > >> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> > >> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > >> --- > >> > >> drivers/ata/sata_nv.c | 33 - > >> 1 file changed, 20 insertions(+), 13 deletions(-) > > > > Robert, do you think this should be pushed into #upstream-fixes > > (2.6.21-rc)? > > > > I lean towards "yes", since it is a needed-by-hardware fix, but I also > > am interested in testing feedback since it is so late in the 2.6.21-rc > > game. > > I would lean toward that as well, but it would be good to get some > testing from some sata_nv ADMA users to make sure it doesn't do anything > funny for them.. Since I've been a bit of a problem case this time, I'd be happy to test it. Can I assume that I can apply the patch you sent to Jeff "[PATCH] sata_nv: revert use of notifiers for now", and apply this one, to -rc3, and then be able to usefully test? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux v2.6.21-rc3
(Dropped LKML, whoops.) On Wednesday 07 March 2007 04:59, you wrote: > We've finally hopefully started to put a dent in the regressions, > especially the suspend/resume problems introduced since 2.6.20. > > So 2.6.21-rc3 is out there now, and there's some hope that it will work > more widely than -rc1 and -rc2 did. Please do give it a good testing, and > update Adrian and the mailing list (and me) about any regressions > (hopefully many more of the "it's fixed now" than other kinds, but all > regressions are interesting). Robert and Jeff already know about these, but I thought I'd send out a reminder. ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata2: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd 35/00:30:b5:c1:8f/00:01:01:00:00/e0 tag 0 cdb 0x0 data 155648 out res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA They didn't happen (or didn't happen as frequently) in 2.6.20; it's a serious bug. Happened in -rc2 and -rc3. A patch from Robert reverting 721449bf0d51213fe3abf0ac3e3561ef9ea7827a seems to make them go away. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CK804 SATA Errors (still got them)
On Sunday 04 March 2007 23:25, Robert Hancock wrote: > Alistair John Strachan wrote: > >> Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a > >> (link below) and see what effect that has? > >> > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi > >>t;h =721449bf0d51213fe3abf0ac3e3561ef9ea7827a > > > > Obviously, I'll let you know if it happens again, but I've reverted this > > commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on > > an NVIDIA sata controller, and this error hasn't appeared. > > > > So I'm inclined to (very unscientifically) say that this brings it back > > to 2.6.20's level of stability. > > Interesting. Can you try un-reverting that patch, and applying this one? > > The reading of the status register is something that was part of the > original NVidia code, which I'm not really sure why is there. Given that > reading the status register clears the drive's interrupt status, that might > be causing some wierd interaction with the ADMA controller. Also, I added > in a printk for cases where notifiers are triggered but the command doesn't > indicate completion - if you still get problems, let me know if you see > that message. Didn't take long to observe the problem again, so I'm guessing that this isn't it. I was definitely using a kernel compiled with your patch: [EMAIL PROTECTED]:~$ uname -v #1 SMP Sun Mar 4 23:39:56 GMT 2007 I got the following in dmesg: ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd c8/00:08:37:77:61/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Your debugging message did not appear in dmesg, however. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CK804 SATA Errors (still got them)
On Sunday 04 March 2007 23:25, Robert Hancock wrote: > Alistair John Strachan wrote: > >> Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a > >> (link below) and see what effect that has? > >> > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi > >>t;h =721449bf0d51213fe3abf0ac3e3561ef9ea7827a > > > > Obviously, I'll let you know if it happens again, but I've reverted this > > commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on > > an NVIDIA sata controller, and this error hasn't appeared. > > > > So I'm inclined to (very unscientifically) say that this brings it back > > to 2.6.20's level of stability. > > Interesting. Can you try un-reverting that patch, and applying this one? Sorry for the newbie question, but is it adequate to do a: git reset --hard v2.6.21-rc2 To ensure a patch is "unreverted" (I reverted it with "git revert"), before applying your patch? I've done so now, assuming this _will_ work. The reason I ask is that your diff was offset by 12 lines versus -rc2. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20, Java, unresponsive userspace
Hi, I've had some problems with 2.6.20 (but also with earlier kernels, like Debian's 2.6.18) where one of the users on our system, running a Java6 application, is somehow able to make the userspace on the machine totally unresponsive, denying all remote _and_ local access to the machine. - The AMD64 port of Linux and Java are in use - The process runs as an unprivileged user - The OOM killer doesn't kick in - No swap is enabled on the machine - I'm told that the program doesn't fork bomb (but I've not got a reproducible test case yet) - The program is able to deny service even to a getty login. If I SAK the machine, init respawns getty and everything is fine again. [EMAIL PROTECTED]:~$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited max nice(-e) 0 file size (blocks, -f) unlimited pending signals (-i) unlimited max locked memory (kbytes, -l) 1000 max memory size (kbytes, -m) 1000 open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) unlimited max rt priority (-r) 0 stack size (kbytes, -s) 2048 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Any ideas with how to proceed for debugging this issue? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CK804 SATA Errors (still got them)
On Friday 02 March 2007 02:40, Robert Hancock wrote: > Alistair John Strachan wrote: > > On Thursday 01 March 2007 15:13, Alistair John Strachan wrote: > >> On Thursday 01 March 2007 14:45, Robert Hancock wrote: > >>> This one seems a bit different. This time it's not related to NCQ vs. > >>> non-NCQ (this is a non-NCQ write here), it's in ADMA mode (so it's > >>> presumably not related to switching between ADMA and register mode, > >>> unless perhaps a flush cache or something executed just before), and > >>> from the CPB data it appears the command completed but the controller's > >>> registers aren't indicating that it has. Not sure if I've seen one like > >>> that before.. > >>> > >>> How easily can you reproduce this? > >> > >> It's the first one since -rc2, so apparently not easily. I'm more than > >> willing to find loads that expose it, though, so I might try that this > >> afternoon. > > > > Got another: > > > > ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 > > status 0x500 next cpb count 0x0 next cpb idx 0x0 ata2: CPB 0: ctl_flags > > 0xd, resp_flags 0x1 > > ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen > > ata2.00: cmd c8/00:80:85:c4:ed/00:00:00:00:00/e3 tag 0 cdb 0x0 data 65536 > > in res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft > > resetting port > > ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > > ata2.00: configured for UDMA/133 > > ata2: EH complete > > SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) > > sdb: Write Protect is off > > sdb: Mode Sense: 00 3a 00 00 > > SCSI device sdb: write cache: enabled, read cache: enabled, doesn't > > support DPO or FUA > > > > Different HD, similar problem. > > Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a > (link below) and see what effect that has? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h >=721449bf0d51213fe3abf0ac3e3561ef9ea7827a Obviously, I'll let you know if it happens again, but I've reverted this commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on an NVIDIA sata controller, and this error hasn't appeared. So I'm inclined to (very unscientifically) say that this brings it back to 2.6.20's level of stability. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata Kconfig: Update the various experimentality levels
On Friday 02 March 2007 15:05, you wrote: > Signed-off-by: Alan Cox <[EMAIL PROTECTED]> [snip] > config PATA_OLDPIIX > - tristate "Intel PATA old PIIX support (Experimental)" > + tristate "Intel PATA support for the original PIIX" > depends on PCI && EXPERIMENTAL > help > - This option enables support for old(?) PIIX PATA support. > + This option enables support for early Intel PIIX PATA support. Probably nothing, but is it intentional to remove the "(Experimental)" text here, but not the dependency on EXPERIMENTAL? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CK804 SATA Errors (still got them)
On Thursday 01 March 2007 15:13, Alistair John Strachan wrote: > On Thursday 01 March 2007 14:45, Robert Hancock wrote: > > This one seems a bit different. This time it's not related to NCQ vs. > > non-NCQ (this is a non-NCQ write here), it's in ADMA mode (so it's > > presumably not related to switching between ADMA and register mode, > > unless perhaps a flush cache or something executed just before), and > > from the CPB data it appears the command completed but the controller's > > registers aren't indicating that it has. Not sure if I've seen one like > > that before.. > > > > How easily can you reproduce this? > > It's the first one since -rc2, so apparently not easily. I'm more than > willing to find loads that expose it, though, so I might try that this > afternoon. Got another: ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata2: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata2.00: cmd c8/00:80:85:c4:ed/00:00:00:00:00/e3 tag 0 cdb 0x0 data 65536 in res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft resetting port ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata2.00: configured for UDMA/133 ata2: EH complete SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB) sdb: Write Protect is off sdb: Mode Sense: 00 3a 00 00 SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO or FUA Different HD, similar problem. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CK804 SATA Errors (still got them)
On Thursday 01 March 2007 14:45, Robert Hancock wrote: > This one seems a bit different. This time it's not related to NCQ vs. > non-NCQ (this is a non-NCQ write here), it's in ADMA mode (so it's > presumably not related to switching between ADMA and register mode, > unless perhaps a flush cache or something executed just before), and > from the CPB data it appears the command completed but the controller's > registers aren't indicating that it has. Not sure if I've seen one like > that before.. > > How easily can you reproduce this? It's the first one since -rc2, so apparently not easily. I'm more than willing to find loads that expose it, though, so I might try that this afternoon. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CK804 SATA Errors (still got them)
Hi Robert, Despite all the work that went into making these less frequent with ADMA, they're still possible to trigger. [EMAIL PROTECTED]:~$ cat /proc/version Linux version 2.6.21-rc2-damocles ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Wed Feb 28 21:58:41 GMT 2007 [EMAIL PROTECTED]:~$ dmesg | tail -n 13 ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 0x500 next cpb count 0x0 next cpb idx 0x0 ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen ata1.00: cmd ca/00:38:ae:08:c2/00:00:00:00:00/e0 tag 0 cdb 0x0 data 28672 out res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata1: soft resetting port ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata1.00: configured for UDMA/133 ata1: EH complete SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA These cause the same ~30 second stalls. Machine was not under load. No 3rd party modules were loaded. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
On Wednesday 21 February 2007 22:40, Lennart Sorensen wrote: > On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote: > > Do you mean both slots on the riser card? No, they have to be rotated. > > > > Given the table from the manual: > > > The IRQ (interrupt request line) are hardware lines over which devices > > > can send interrupt signals to the microprocessor. The ??PCI & LAN?? IRQ > > > pins are typically connected to the PCI bus INT A# ~ INT D# pins as > > > follows: Order 1 Order 2 Order 3 Order 4 > > > PCI Slot 1INT B# INT C# INT D# INT A# > > > IEEE1394 INT B# > > > > (I assume Order 1 is device's INT A and so on) > > the chipset-centric view is: > > Well someone said the VIA uses INTA for the DN19 on their riser card, > although is that INTA from the CPUs point of view or INTA from the slot > the riser card is plugged into? There was also mention of a BIOS update > needed on some boards to even support the riser card at all. Maybe that > applies. It applies on the M1, I'm sure the newer EN series boards have always supported the feature. One warning to you though, I found the riser to be pretty flaky, causing bizarre lockups and periodic crashes of Linux. Maybe this is a Linux bug, but it really didn't seem like it. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
On Tuesday 20 February 2007 15:44, you wrote: > Alistair John Strachan wrote: > > On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: > >> Krzysztof Halasa wrote: > >>> Is it a VIA ITX board? I think I have VIA's riser card somewhere, > >>> could check what it does. > >> > >> Yes, VIA Epia EN12000. > >> Interesting to check the riser card. > > > > Just be aware that there are two types of PCI riser -- risers that work > > in any board, and Via Epia-specific risers. The latter requires a BIOS > > update on some Epias and presumably has some advantages, possible the > > ones you're looking for. > > This card is sold by TranquilPC for their T2e case which holds Mini-ITX > boards. My EN12000 has the latest BIOS I could find on the VIA site: > http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=3 >99#BIOS The riser I have here is called "ext-pci rev b" and is marked "Via Tech Inc". My understanding is that this is not an "active riser" and requires explicit BIOS support. A quick googling for the device revealed this: http://forums.viaarena.com/messageview.aspx?catid=32&threadid=41622&highlight_key=y&keyword1=riser A poster here seems to suggest the following: "As far as I know the only dual riser card that is supported by the EPIA BIOS is the one from VIA (that faces out). That one has some logic on it to get both slots working. The upper slot uses device 19 and INT_A, allocated through the EPIA BIOS." This may perhaps describe the issue you are having, and from the PDF you linked I do not believe you have a riser that is the same as mine. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote: > Krzysztof Halasa wrote: > > Udo van den Heuvel <[EMAIL PROTECTED]> writes: > >> At the bottom I added a dmesg output of the kernel after boot. > >> I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is > >> 'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for > >> i2c although the card does work perfectly for DVB-T reception (picture, > >> low CPU load, etc) with only reception as the bottleneck. > > > > BTW: Can you check which device # and IRQ does the card get if plugged > > directly into the PCI slot on board (without the riser)? > > DN is 20 I believe (from the tranquilPC doc). > irq I'd have to check. > > > Is it a VIA ITX board? I think I have VIA's riser card somewhere, > > could check what it does. > > Yes, VIA Epia EN12000. > Interesting to check the riser card. Just be aware that there are two types of PCI riser -- risers that work in any board, and Via Epia-specific risers. The latter requires a BIOS update on some Epias and presumably has some advantages, possible the ones you're looking for. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
On Sunday 18 February 2007 19:39, Lennart Sorensen wrote: [snip] > > > On a PC, the BIOS is supposed to assign interrupts to devices based on > > > those rules, since that is how the hardware must be done according to > > > the PCI specifications. > > > > I set the BIOS for 'PnP OS installed'. Should I change that? > > I would NEVER do that. That actually disables the BIOS from doing > configuration of most hardware since it really means "Microsoft wants to > do configuration themselves and asked us to put in a setting to make the > bios only configure drive controllers and sound cards". I know some > people have worked towards making linux a "PnP OS" by microsoft > standards, but whether it is entirely there or not by now I am not sure. > Fortunately most motherboards I have ever bought come preset at 'pnp os > installed' off, which is how I like it. I have had a number of > problems on systems with that setting on, which went away when the > setting was set back to off. I think this option actually _used_ to mean whether the BIOS would _provide_ PNP services to the host OS, allowing it to detect peripherals like parallel ports, etc. In reality, very few devices on modern PCs use or require BIOS PNP support, and in some situations it's just annoying (for example, disabling the parallel port on my Thinkpad has no effect because Linux just uses PNP to redetect it). > It might actually work better if you change that, although it may also > just make no difference. In my experience it just makes no difference. I strongly doubt the option has _anything_ to do with this problem. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: User tools for March 11
On Tuesday 13 February 2007 21:19, linux-os (Dick Johnson) wrote: > Hi! > In the United States, some idiots have decided that the year 2000 scare > wasn't enough so they changed the start date for daylight savings time > from the first Sunday in April to the second Sunday in March. > Does anybody know if there are new tools like `hwclock` and `date`? > Will new 'C' runtime libraries be necessary as well? Unless there are utilities homebrewing locales, glibc (locales) should be the only package that requires an update. Some distros may sub-package this as "timezone". SLES got an updated "timezone" package for the Western Australian changes, but I'm not sure about the US changes. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 doesn't compile with gcc-3.2.2
On Monday 05 February 2007 18:04, you wrote: > Alistair John Strachan wrote: > > On Monday 05 February 2007 13:48, Bodo Eggert wrote: > > > Al Boldi <[EMAIL PROTECTED]> wrote: > > > > Doing the following results in an incomplete vmlinuz: > > > > > > > > # make bzlilo > > > > > > > > objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated > > > > make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1 > > > > make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2 > > > > make: *** [bzlilo] Error 2 > > > > > > > > gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) > > > > > > I just compiled using gcc 3.3.5 (debian stable). Please verify that > > > your disk is not full and gcc is the cause. If it is, this patch should > > > do the trick: :) > > > > Not so fast.. post your config? If you've got anything referring to > > relocatable kernel support, try disabling it? > > No luck disabling relocatable kernel, but using a mem-split other than 3/1 > compiles fine. There is a catch though, the kernel won't boot anymore. > > # ld -v > GNU ld version 2.13.90.0.18 20030121 > > Which binutils version is now the minimum required, and why is a binutils > upgrade necessary? Another obvious question is, did -rc1/-rc2 compile correctly? If you have the time, go through all the -rc's, that'll make a bisection easier (if you end up having to do one). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 doesn't compile with gcc-3.2.2
On Monday 05 February 2007 18:04, Al Boldi wrote: > Alistair John Strachan wrote: > > On Monday 05 February 2007 13:48, Bodo Eggert wrote: > > > Al Boldi <[EMAIL PROTECTED]> wrote: > > > > Doing the following results in an incomplete vmlinuz: > > > > > > > > # make bzlilo > > > > > > > > objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated > > > > make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1 > > > > make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2 > > > > make: *** [bzlilo] Error 2 > > > > > > > > gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) > > > > > > I just compiled using gcc 3.3.5 (debian stable). Please verify that > > > your disk is not full and gcc is the cause. If it is, this patch should > > > do the trick: :) > > > > Not so fast.. post your config? If you've got anything referring to > > relocatable kernel support, try disabling it? > > No luck disabling relocatable kernel, but using a mem-split other than 3/1 > compiles fine. There is a catch though, the kernel won't boot anymore. > > # ld -v > GNU ld version 2.13.90.0.18 20030121 > > Which binutils version is now the minimum required, and why is a binutils > upgrade necessary? Documentation/Changes still says 2.12, and your binutils is closer to 2.14. I can't think of a particular patch to point the finger at (looking now). If you want an interim workaround, grab a newer binutils (probably 2.17), install it to a prefix like $HOME/binutils, then: export PATH=$HOME/binutils/bin:$PATH And confirm the resulting kernel builds and works. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 doesn't compile with gcc-3.2.2
On Monday 05 February 2007 13:48, Bodo Eggert wrote: > Al Boldi <[EMAIL PROTECTED]> wrote: > > Doing the following results in an incomplete vmlinuz: > > > > # make bzlilo > > > > objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated > > make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1 > > make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2 > > make: *** [bzlilo] Error 2 > > > > gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) > > I just compiled using gcc 3.3.5 (debian stable). Please verify that your > disk is not full and gcc is the cause. If it is, this patch should do the > trick: :) Not so fast.. post your config? If you've got anything referring to relocatable kernel support, try disabling it? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 doesn't compile with gcc-3.2.2
On Monday 05 February 2007 12:31, you wrote: > Doing the following results in an incomplete vmlinuz: > > # make mrproper > # make allnoconfig > # make bzlilo > > objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated > make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1 > make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2 > make: *** [bzlilo] Error 2 > > # gcc -v > Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs > Configured with: ../configure --prefix=/usr --libdir=/usr/lib > --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info > --enable-shared --enable-threads=posix --disable-checking > --enable-long-long --enable-__cxa_atexit > --enable-languages=c,c++,ada,f77,objc,java > --host=i586-mandrake-linux-gnu --with-system-zlib > Thread model: posix > gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) > > > Is gcc-4.0.1 now the minimum required to compile the kernel? A patch went in to remove support for GCC 3.1, but as far as I know, 3.2 should be a supported compiler. At any rate, this might be a binutils issue. What version of binutils are you using? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: More pata_ stuff
On Sunday 04 February 2007 18:20, Patrick Ale wrote: > On 2/4/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > > ata_piix should drive that chipset. Was that driver enabled in the > > kernel configuration, and if it's built modular is the initrd, etc. set > > up to load it on boot? > > Hi, > > Yep, piix was configured as built-in, I don't use ramdisks. > And, the SD driver is configured built-in aswell. > Hence, this is more or less the same kernel config as I used with my > Gigabyte GA-VAXP Ultra mainboard. The things I changed in this new > config are: > > - Enable SMP > - Enable ata_piix > - CPU Type set to Pentium II And this config has clearly: # CONFIG_ATA_PIIX is not set Which for a PIIX4 chipset is what you want. Somewhat confusingly: CONFIG_PATA_MPIIX=y CONFIG_PATA_OLDPIIX=y Should be "n", I've been told. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.18-stable release plans?
On Thursday 25 January 2007 09:16, Chris Rankin wrote: > But anyway - can someone please tell me what "Eeek! page_mapcount(page) > went negative! (-1)" is *really* saying/implying? Because I am currently > translating this as "I WANT TO EAT YOUR FILESYSTEMS". Hugh already did, multiple times. If there's an external hardware event that corrupts memory, code executing on your CPU is no longer going to behave deterministically. So cases that are typically "impossible" in the design of the code have a chance to trigger. You can continue to flame 2.6.19, but you're an extreme minority when it comes to this kind of bug and as, again, Hugh already said, almost all of the reports of this and similar other bugs have led to hardware problems that were either unchecked or difficult to detect. Imagine this scenario. It might seem unrealistic to you, but it's not impossible! First Use of Linux -> Upgrading to 2.6.19 Undetected hardware error never triggered. Running 2.6.19 Hardware error triggers. Linux crashes. Going back to 2.6.18 Hardware error has not yet triggered again. Will it eat your filesystem? Maybe. But it probably won't, if you claim the memory is tested, it could have been a single bit error, or a cosmic ray event, or a brownout, or anything similar. It's much more likely to simply crash your machine, as it did. Not running the affected kernel again is a sure way to have _nobody_ listen to your complaints about 2.6.19 having a real software bug, because you're totally unwilling to test the kernel again and see if it triggers. A single report is simply not enough evidence. Additionally, reports from other users (who may have a million different experimental variables involved) are also insufficient, for reasons which have already been explained (drivers, proprietary code, et cetera). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Strange
On Wednesday 24 January 2007 00:01, Christoph Anton Mitterer wrote: > Alan wrote: > >> kernel: Error: Illegal request -- (Sense key=0x05) > >> kernel: Read of scrambled sector without authentication -- (asc=0x6f, > >> ascq=0x03) > > > > The disc is using digital rights management. If you are in a country that > > permits it you can use a dvd reader library with decss support, if not > > you'll have to either watch your disks on a system approved by the movie > > industry enforcers or commit a crime to read the disc. > > I knew of course about libdvdcss but I've never noticed before that the > kernel issues these error messages to the syslog. If you've replaced the drive, the decss keys might have changed for inserted media (this is especially true if your old drive had a different region setting). First set the DVD region on the drive to where you are (probably 2), using "regionset". Then rm -rf ~/.dvdcss and restart your video playing application. It should rescan the dvd, figure out the keys, no error messages. > So you say this is normal?! But the problem with ejecting isn't probably > normal. Yeah, like Alan says it's just the DRM nonsense built into your drive trying to "protect" the media. You can find firmware modifications which remove this logic from the drive, but I'm not sure of their legality. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On Tuesday 23 January 2007 01:24, Robert Hancock wrote: > As a final aside, this is another case where the hardware docs for this > controller would really be useful, in order to know whether we are > actually supposed to be reading that register in ADMA mode or not. I > sent a query to Allen Martin at NVIDIA asking if there's a way I could > get access to the documents, but I haven't heard anything yet. Obviously, NVIDIA's response is disappointing, but thank you for putting the time in to debug this problem. Definitely sounds like a hardware defect, I'm just glad there's a workaround. Will we see this fix in 2.6.20? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On Saturday 20 January 2007 19:59, Robert Hancock wrote: > Ian Kumlien wrote: > > Hi, > > > > I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama > > enabled, to 2.6.20-rc5, which gave me problems almost instantly. > > > > I just thought that it might be interesting to know that it DID work > > nicely. > > > > CC since i'm not on the ml > > (I'm ccing more of the people who reported this) > > Well that's interesting.. The only significant change that went into > 2.6.20-rc5 in that driver that wasn't in that version you mentioned was > this one: > > http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com >mit;h=2dec7555e6bf2772749113ea0ad454fcdb8cf861 > > Could you (or anyone else) test what happens if you take the 2.6.20-rc5 > version of sata_nv.c and try it on 2.6.19? That would tell us whether > it's this change or whether it's something else (i.e. in libata core). I'm still running an -rc5 kernel with ADMA switched off entirely and I can't reproduce the problem. How is everybody else reproducing this? I've been successful installing bonnie++, then going to a large XFS partition and running "bonnie++ -u 1000:1000" and letting it run through, all defaults. It doesn't cause the problem I was seeing in -rc5 with ADMA on, when I switch ADMA off, so I think this is sufficient to fix it. Others have reported differently. Did you guys do: [EMAIL PROTECTED]:~$ cat /proc/cmdline root=/dev/sda1 ro sata_nv.adma=0 Or something similar? This is how Jeff suggested disabling ADMA and indeed the messages about its use disappear from dmesg. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On Saturday 20 January 2007 02:41, Robert Hancock wrote: > By the way, I assume that you guys are using reiserfs or xfs, as it > appears no other file systems issue flush commands automatically. I had > to test this by "echo 1 > delete" on the SCSI disk in sysfs, as I am > using ext3. I'll give it a spin now, and yes I'm using several large XFS partitions on this machine, layered on top of md RAID5. That's why this particular defect is so catastrophic (literally _everything_ is stalled). -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On Tuesday 16 January 2007 01:53, Jeff Garzik wrote: > Robert Hancock wrote: > > I'll try your stress test when I get a chance, but I doubt I'll run into > > the same problem and I haven't seen any similar reports. Perhaps it's > > some kind of wierd timing issue or incompatibility between the > > controller and that drive when running in ADMA mode? I seem to remember > > various reports of issues with certain Maxtor drives and some nForce > > SATA controllers under Windows at least.. > > Just to eliminate things, has disabling ADMA been attempted? > > It can be disabled using the sata_nv.adma module parameter. Setting this option fixes the problem for me. I suggest that ADMA defaults off in 2.6.20, if there's still time to do that. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SATA exceptions with 2.6.20-rc5
On Tuesday 16 January 2007 00:34, Robert Hancock wrote: > I'll try your stress test when I get a chance, but I doubt I'll run into > the same problem and I haven't seen any similar reports. Perhaps it's > some kind of wierd timing issue or incompatibility between the > controller and that drive when running in ADMA mode? I seem to remember > various reports of issues with certain Maxtor drives and some nForce > SATA controllers under Windows at least.. I have exactly the same problem on -rc5 and it causes all I/O to stall periodically if I do _anything_ I/O intensive. On my box, I have 4 sata_nv handled SATA ports, with two pairs of different drives (two Maxtor, two WD) and it happens randomly on both. So it's absolutely nothing to do with the drive make/model. I'll try Jeff's suggestion of disabling ADMA now, but I think something more radical than this workaround should make it into 2.6.20 final, otherwise a lot of people are going to have broken boxes. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19: BUG: soft lockup detected on CPU#0!
Hi, After a few days uptime on a 2.6.19 kernel, I see this: http://devzero.co.uk/~alistair/2.6.19-softlockup.jpg At which point magic sysrq doesn't work and the machine requires a hard reboot. Is there anything that can be done to produce a more verbose message when such a soft lockup occurs? -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Gaming Interface
On Monday 08 January 2007 13:04, Dirk wrote: > But I don't see top titles ported to SDL/OpenGL. This is because you're not looking very hard. If you look at Ryan's ports over at http://icculus.org/ many of the games (some he's _paid_ to port) use SDL statically linked in. There's no legal or technical problem with this. Really, what you're talking about already exists. If anything, you need to convince the SDL guys (not the kernel guys) to make SDL more comprehensive OR write your own multimedia library, perhaps based on or backending to SDL. As noted elsewhere in this thread, most games use 3D hardware exclusively, and only really care about the OS for initialising a video mode and playing sound. Most ports probably suffer the worst from the lack of DirectX APIs on Linux, something which the WINE project is trying to solve. Using libwine, one will eventually be able to write native Linux applications that use the DirectX APIs. Porting should then be very much easier. Of course, vendors using OpenGL gain Macintosh portability amongst other things, and most of the really big titles do have OpenGL render modes, which are already largely portable. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Sunday 07 January 2007 00:36, Pavel Machek wrote: [snip] > > However, this patch is mostly useless if you have a separate stack for > > IRQ's (since if that happens, any interrupt will be taken on a different > > stack which we don't see any more), so you should NOT enable the 4KSTACKS > > config option if you try this out. > > stupid idea... perhaps gcc-4.1 generates bigger stackframe somewhere, > and stack overflows? The primary reason it's not 4KSTACKS already is that I run multiple XFS partitions on top of an md RAID 1. LVM isn't involved, however, and I'm not using any other filesystem overlays like dm. I'm fairly sceptical that it's a stack overflow, but I'll be sure to enable the debugging option on the next try. > that hw monitoring thingie... I'd turn it off. Its interactions with > acpi are non-trivial and dangerous. Well, GCC 3.4 kernels seem to run fine with it, but as I said to Linus I'll be sure to turn this and the sound drivers off in the next build. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Friday 05 January 2007 16:02, Linus Torvalds wrote: > On Fri, 5 Jan 2007, Alistair John Strachan wrote: > > This didn't help. After about 14 hours, the machine crashed again. > > > > cmov is not the culprit. > > Ok. Have you ever tried to limit the drivers you have loaded? I notice you > had the prism54 wireless thing in your modules list and the vt1211 hw > monitoring thing. I'm wondering about the vt1211 thing - it probably isn't > too common. Sure, and it only got added to 2.6.19 anyway (however GCC 3.4.6 really does seem to have no problem with it). > But if you can use that machine without the wireless too, it > might be good to try without either. Required, plus I've been running prism54 on three different machines with a huge number of compilers since the early 2.6 days with no problems. > (The rest of your module list looked bog-standard, so if it's not > hardware-specific, I don't think it's there) Agreed, the config is already _very_ minimal for this machine. > Turning of the VIA sound driver just in case would be good too. I'm not even really sure why that's enabled. I can do that. > The reason I mention vt1211 in particular is that it does things like > regulate fan activity etc. Is the problem perhaps heat-related? It definitely isn't heat related. This CPU puts out 7-10W, has a ridiculous 5000 RPM fan on it (that works) and the temp never exceeds 40C. If anything, the -O2, 3.4.6 kernel with CMOV ran the chip a little hotter. As far as I can see, all the other components are either cool to touch or have stupidly big heatsinks on them. (I realise with problems like these it's almost always some sort of obscure hardware problem, but I find that very difficult to believe when I can toggle from 3 years of stability to 6-18 hours crashing by switching compiler. I've also ran extensive stability test programs on the hardware with absolutely no negative results.) -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Wednesday 03 January 2007 02:20, Alistair John Strachan wrote: > On Wednesday 03 January 2007 02:12, Mikael Pettersson wrote: > > On Tue, 2 Jan 2007 17:43:00 -0800 (PST), Linus Torvalds wrote: > > > > The suggestions I've had so far which I have not yet tried: > > > > > > > > - Select a different x86 CPU in the config. > > > > - Unfortunately the C3-2 flags seem to simply > > > > tell GCC > > > > to schedule for ppro (like i686) and enabled > > > > MMX and SSE > > > > - Probably useless > > > > > > Actually, try this one. Try using something that doesn't like "cmov". > > > Maybe the C3-2 simply has some internal cmov bugginess. > > > > That's a good suggestion. Earlier C3s didn't have cmov so it's > > not entirely unlikely that cmov in C3-2 is broken in some cases. > > Configuring for P5MMX or 486 should be good safe alternatives. > > Or just C3 (not C3-2), which is what I've done. > > I'll report back whether it crashes or not. This didn't help. After about 14 hours, the machine crashed again. cmov is not the culprit. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
