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: 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/
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: 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: 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: [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/
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: 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/
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: [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: [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/
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/
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: 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: 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: 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 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: 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: 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: 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: 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: [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=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] [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: 2.6.23-rc4-mm1
On Monday 03 September 2007 09:06:25 Nicolas Mailhot wrote: Mats Johannesson spamcan at 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-kernelm=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: 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: [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(_driver,
> > > > subminor))) { - dev_err(>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: [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
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: res
40/00:34:4a:c0:fc/00:00:04:00:00/40 Emask 0x42 (HSM violation)
Aug 24 13:55:31
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: 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: 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: 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- TAbort- MAbort- SERR- PERR- 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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/
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: 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/
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: 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: [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: 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: 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: 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: [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: [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] 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 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-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: 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/
