Re: random wedges with 2.6.25-rc*

2008-02-19 Thread Alistair John Strachan
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

2008-01-30 Thread Alistair John Strachan
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: r8169 and out of space

2008-01-10 Thread Alistair John Strachan
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

2007-12-15 Thread Alistair John Strachan
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

2007-12-11 Thread Alistair John Strachan
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/


2.6.24-rc3, 4GB RAM, swiotlb, r8169, out of space

2007-11-24 Thread Alistair John Strachan
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

2007-11-24 Thread Alistair John Strachan
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

2007-11-24 Thread Alistair John Strachan
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

2007-11-20 Thread Alistair John Strachan
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?

2007-11-01 Thread Alistair John Strachan
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?

2007-10-31 Thread Alistair John Strachan
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

2007-10-14 Thread Alistair John Strachan
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: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage

2007-10-07 Thread Alistair John Strachan
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

2007-10-07 Thread Alistair John Strachan
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

2007-10-07 Thread Alistair John Strachan
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..

2007-10-07 Thread Alistair John Strachan
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..

2007-10-02 Thread Alistair John Strachan
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?

2007-09-24 Thread Alistair John Strachan
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

2007-09-10 Thread Alistair John Strachan
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: [PATCH] [ALSA] Added new pin config for first gen macbook.

2007-09-04 Thread Alistair John Strachan
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

2007-09-04 Thread Alistair John Strachan
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

2007-09-04 Thread Alistair John Strachan
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

2007-09-02 Thread Alistair John Strachan
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

2007-08-27 Thread Alistair John Strachan
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

2007-08-26 Thread Alistair John Strachan
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

2007-08-12 Thread Alistair John Strachan
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

2007-08-11 Thread Alistair John Strachan
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

2007-08-04 Thread Alistair John Strachan
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

2007-08-03 Thread Alistair John Strachan
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

2007-08-03 Thread Alistair John Strachan
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

2007-08-03 Thread Alistair John Strachan
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

2007-07-30 Thread Alistair John Strachan
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

2007-07-29 Thread Alistair John Strachan
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

2007-07-29 Thread Alistair John Strachan
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

2007-07-29 Thread Alistair John Strachan
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

2007-07-29 Thread Alistair John Strachan
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/


2.6.23-rc1, KVM-AMD problem

2007-07-28 Thread Alistair John Strachan
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

2007-07-28 Thread Alistair John Strachan
 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

2007-07-22 Thread Alistair John Strachan
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: [PATCH] sb1250-duart.c: SB1250 DUART serial support

2007-07-12 Thread Alistair John Strachan
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)

2007-07-12 Thread Alistair John Strachan
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)

2007-06-24 Thread Alistair John Strachan
(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

2007-06-16 Thread Alistair John Strachan
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

2007-06-10 Thread Alistair John Strachan
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

2007-06-07 Thread Alistair John Strachan
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

2007-05-23 Thread Alistair John Strachan
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

2007-05-15 Thread Alistair John Strachan
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: converting appletouch to usb autosuspend...

2007-05-14 Thread Alistair John Strachan
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: [announce] Intel announces the PowerTOP utility for Linux

2007-05-14 Thread Alistair John Strachan
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: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v1

2007-05-14 Thread Alistair John Strachan
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: [PATCH] x86-64 highres/dyntick support 2.6.22-rc1-v1

2007-05-14 Thread Alistair John Strachan
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: converting appletouch to usb autosuspend...

2007-05-13 Thread Alistair John Strachan
On Monday 14 May 2007 01:46:10 Soeren Sonnenburg wrote:
 On Sat, 2007-05-12 at 22:47 +0100, Alistair John Strachan wrote:
  On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote:
   Dear all,

 [...]

   While we are at it usb related powerhogs on this macbook pro are
   uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func)
   too...
 
  I've found that hci_usb also hogs power on the Macbook; blacklisting this
  module cuts down HZ considerably. I also found appletouch consumed ticks,

 I guess without loading appletouch ? Then there really is something in
 there that needs to be fixed..

  just as you did.

 What did you use instead of hci_usb then ? usbkbd ? This won't give you
 the special keys etc...

Sorry, I wasn't clear. hci_usb is actually part of the BlueZ stack, it's got 
nothing to do with the keyboard. I unloaded both appletouch AND hci_usb.

  uhci_hcd then drops to noise; my Macbook's sitting on 10W with the
  backlight on minimum, which is about what it can manage in OS X on
  maximum life settings.

 Thats quite some improvement...

Yes indeed. The only thing left to improve, as I understand it, is enabling 
the C4/C4e power states available on the Core 2 Duo, which don't currently 
seem to be utilised by Linux. I notice, however, that the screenshot on the 
Intel Powertop page does seem to have these states available?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] x86-64 highres/dyntick support

2007-05-13 Thread Alistair John Strachan
On Sunday 06 May 2007 21:58:47 Thomas Gleixner wrote:
 I'm pleased to announce the first cut of the final x86_64
 highres/dyntick support, which I did based on Chris Wright's patch set,
 which is again based on Arjan van de Ven's initial work:

I've noticed a few problems with this patch series, which I manually (without 
difficulty) ported to 2.6.22-rc1.

Firstly, the output of /proc/interrupts looks a bit strange. NO_HZ isn't 
enabled, just high resolution timers. HZ was set to 1000.

[EMAIL PROTECTED]:~$ cat /proc/interrupts
   CPU0   CPU1
  0:195  0   IO-APIC-edge  timer
  1: 21  13698   IO-APIC-edge  i8042
  8:  0  0   IO-APIC-edge  rtc
  9:  0  0   IO-APIC-fasteoi   acpi
 14:117  51178   IO-APIC-edge  libata
 15:  0  0   IO-APIC-edge  libata
 18:455 449373   IO-APIC-fasteoi   lan-sky, EMU10K1
 19:  0  3   IO-APIC-fasteoi   yenta, ohci1394
 20:220  86188   IO-APIC-fasteoi   ohci_hcd:usb2
 21:  0 26   IO-APIC-fasteoi   ehci_hcd:usb1
 22:  0273   IO-APIC-fasteoi   sata_nv
 23:928 507781   IO-APIC-fasteoi   sata_nv, lan
NMI:  0  0
LOC:47232724797930
ERR:  0

Only 195 timer interrupts? I only see this on an AMD Opteron, it doesn't occur 
on an Intel Core 2 Duo. Mainline reports this counter regularly increasing 
with or without the acpi_pm clocksource loaded.

Secondly, /proc/cpuinfo seems to be broken:

[EMAIL PROTECTED]:~$ cat /proc/cpuinfo | grep MHz
cpu MHz : 210779.550
cpu MHz : 210779.550

Unless my CPU is just under 80 times faster than it used to be, these numbers 
are incorrect. I expect 2700.50, or something similar. cpufreq isn't compiled 
in.

Finally, and possibly related, the dmesg timestamps seem to be totally broken. 
Apparently my machine booted in less than 1 second, with the last messages 
as:

[0.607862] bridge: topology change detected, propagating
[0.607862] bridge: port 2(lan-sky) entering forwarding state
[0.830472] Linux agpgart interface v0.102 (c) Dave Jones

Of course, all of these problems might be PEBKAC, but I'm sceptical.

Find the kernel config, updated patch (for 2.6.22-rc1), dmesg, contents 
of /proc/interrupts and /proc/cpuinfo here:

http://devzero.co.uk/~alistair/2.6.22-rc1-hrt/

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [announce] Intel announces the PowerTOP utility for Linux

2007-05-12 Thread Alistair John Strachan
On Saturday 12 May 2007 00:07:18 Arjan van de Ven wrote:
 What's eating the battery life of my laptop? Why isn't it many more
 hours? Which software component causes the most power to be burned?
 These are important questions without a good answer... until now.

This is a really great tool and presents a very intuitive alternative to the 
timer stats file..

On a Core 2 Duo Macbook, Linux always gets around 3.2h battery, OS X about 
4.2h. This tool has identified that uhci_hcd is where 75% of the ticks are 
going when X is not loaded. Unloading uhci_hcd drops the battery life back to 
around 4.2h, but I lose the keyboard.

Is there any way to find out what USB driver is causing usb_uhci to be this 
busy?

(BTW, the link to Keith's patch for dhcdbd seems to be broken on your 
homepage.)

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: converting appletouch to usb autosuspend...

2007-05-12 Thread Alistair John Strachan
On Saturday 12 May 2007 19:51:26 Soeren Sonnenburg wrote:
 Dear all,

 I've realized using the great powertop ( http://www.linuxpowertop.org/ )
 that loading the appletouch driver (and touching it once) makes consumes
 about 0.3 W even when not touching the pad. As rmmod'ing appletouch
 fixes this I wonder why the driver does not do this alone. So my
 question is what does one have to do to convert a driver (such as
 appletouch) to make use of usb autosuspend except for

  .supports_autosuspend = 1

 ...

 While we are at it usb related powerhogs on this macbook pro are
 uhci_hcd (usb keyboard) and usb_hcd_poll_rh_status (rh_timer_func)
 too...

I've found that hci_usb also hogs power on the Macbook; blacklisting this 
module cuts down HZ considerably. I also found appletouch consumed ticks, 
just as you did.

uhci_hcd then drops to noise; my Macbook's sitting on 10W with the backlight 
on minimum, which is about what it can manage in OS X on maximum life 
settings.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Probable PCIE prob

2007-04-29 Thread Alistair John Strachan
On Saturday 28 April 2007 20:53:37 Syren Baran wrote:
 Hi,

 i got a problem with the combination of an Asrock AM2NF4G-SATA2
 mainboard with a Radeon X1900 (chip 1002,724b) graphics
 card. /i386/pci/mmconfig.c reports a buggy bios (e000 is not
 E820-reserved). System crashes only happen when viewing films (neither
 xine nor mplayer run with root privileges) and independent of video
 drivers (framebuffer, vesa and fglrx). Logs dont show any anomalies
 before crashing. Anybody got a clue?

This is a pretty bizarre crash. It might be a hardware problem. Try running a 
load intensive task, something that heats your CPU up, for a long period. See 
if it lasts longer than 30 minutes..

Another thing you could try doing was eliminating X completely, by using 
mplayer on a vesafb console..

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux 2.6.21 - something wrong with dmesg.

2007-04-27 Thread Alistair John Strachan
On Friday 27 April 2007 15:31:37 Sunil Naidu wrote:
 On 4/26/07, Alistair John Strachan [EMAIL PROTECTED] wrote:
   Don't you need to increase CONFIG_LOG_BUF_SHIFT ?

 Yep, I need to. But, have to enable the Kernel Debug (DEBUG_KERNEL) to
 increase the value from default 14 value to 15/16. I feel that this
 might increase the kernel size?

From a quick grep, DEBUG_KERNEL will only increase the kernel size on PARISC 
(arch/parisc/mm/init.c), so setting it won't have any adverse affect on your 
kernel size (if you disable all the options under it).

 Ummm, is it possible to move CONFIG_LOG_BUF_SHIFT under the General
 Setup area? (say, down the Kernel .config support - IKCONFIG).

I agree with this. It's also quite interesting to see that one can enable 
DEBUG_KERNEL, increase CONFIG_LOG_BUF_SHIFT, and then disable DEBUG_KERNEL, 
and the changed value is still used.

I think it should be easier to change this value, as anybody with it set too 
low has a useless kernel log buffer and it can make reporting more difficult.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] Move LOG_BUF_SHIFT to a more sensible place

2007-04-27 Thread Alistair John Strachan
Several people have observed that perhaps LOG_BUF_SHIFT should be in a more 
obvious place than under DEBUG_KERNEL. Under some circumstances (such as the 
PARISC architecture), DEBUG_KERNEL can increase kernel size, which is an 
undesirable trade off for something as trivial as increasing the kernel log 
buffer size.

Instead, move LOG_BUF_SHIFT into General Setup, so that people are more 
likely to be able to change it such a circumstance that the default buffer 
size is insufficient.

Signed-off-by: Alistair John Strachan [EMAIL PROTECTED]
---

diff --git a/init/Kconfig b/init/Kconfig
index b170aa1..cc9eb35 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -262,6 +262,23 @@ config IKCONFIG_PROC
  This option enables access to the kernel configuration file
  through /proc/config.gz.
 
+config LOG_BUF_SHIFT
+   int Kernel log buffer size (16 = 64KB, 17 = 128KB)
+   range 12 21
+   default 17 if S390 || LOCKDEP
+   default 16 if X86_NUMAQ || IA64
+   default 15 if SMP
+   default 14
+   help
+ Select kernel log buffer size as a power of 2.
+ Defaults and Examples:
+17 = 128 KB for S/390
+16 = 64 KB for x86 NUMAQ or IA-64
+15 = 32 KB for SMP
+14 = 16 KB for uniprocessor
+13 =  8 KB
+12 =  4 KB
+
 config CPUSETS
bool Cpuset support
depends on SMP
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 3f3e740..de82401 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -86,23 +86,6 @@ config DEBUG_SHIRQ
  Drivers ought to be able to handle interrupts coming in at those
  points; some don't and need to be caught.
 
-config LOG_BUF_SHIFT
-   int Kernel log buffer size (16 = 64KB, 17 = 128KB) if DEBUG_KERNEL
-   range 12 21
-   default 17 if S390 || LOCKDEP
-   default 16 if X86_NUMAQ || IA64
-   default 15 if SMP
-   default 14
-   help
- Select kernel log buffer size as a power of 2.
- Defaults and Examples:
-17 = 128 KB for S/390
-16 = 64 KB for x86 NUMAQ or IA-64
-15 = 32 KB for SMP
-14 = 16 KB for uniprocessor
-13 =  8 KB
-12 =  4 KB
-
 config DETECT_SOFTLOCKUP
bool Detect Soft Lockups
depends on DEBUG_KERNEL  !S390

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux 2.6.21 - something wrong with dmesg.

2007-04-26 Thread Alistair John Strachan
On Thursday 26 April 2007 14:03:39 you wrote:
 On Thu, Apr 26, 2007 at 05:44:40PM +0530, Sunil Naidu wrote:
  Hello,
 
  I did compile the kernel, boots good ;-) BTW, does anyone (on P-III)
  facing a memory check skip or sort of? Not getting RAM info in the
  dmesg.  Unable to get dmseg from the start of the gcc check! Any clue?
  Here is the dmesg I get on my box:

 Don't you need to increase CONFIG_LOG_BUF_SHIFT ?

May also simply be that you need to pass dmesg -s 64000 or something similar, 
because it defaultly only dumps 16K of the kernel log buffer (regardless of 
the CONFIG setting).

(Also, does Andrew really need to be CCed twice?)

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: ZFS with Linux: An Open Plea

2007-04-17 Thread Alistair John Strachan
On Tuesday 17 April 2007 15:48, Alan Cox wrote:
  So who is responsible for potential changing Linux code licensing for
  allow if not incorporate CDDL code correct interraction without breaking
  some law ?

 Every single contributor, individually. Which won't happen.

 The real test of whether Sun were serious about ZFS being anywhere but
 Solaris is what they do to license it - they've patented everything they
 can, and made the code available only under licenses incompatible with
 other OS products. Their intent is quite clear, and quite sad.

This isn't universally true. Look at Java, for example, which Sun recently 
released parts of under an open source license -- not the CDDL, not a 
CDDL/xxx dual license, the GPL proper.

Indeed, Sun already have products that are dual licensed CDDL/GPL, for example 
the J2EE product.

 If Sun want ZFS to get used all over the place in free software then I'd
 have expected at the very least to see them throw out a copy of the code,
 docs and patent grant in a form that could be used, even if it came with
 no other assistance of any kind.

I couldn't speculate on the rationale, but it does seem that Sun's choice to 
use _only_ the CDDL with certain software (like ZFS) is deliberate.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] hpet: Enable hidden HPET on NVidia motherboards

2007-04-15 Thread Alistair John Strachan
On Sunday 15 April 2007 21:14, Mikko Tiihonen wrote:
 Enables HPET for NVidia motherboards with broken BIOS. The patch reads the
 HPET address from the pci config space. The patch should also work if ACPI
 is disabled.

 The HPET search is done in early-quirks because even
 DECLARE_PCI_FIXUP_EARLY was too late. If the new quirk causes problems it
 can be disabled with the nohpet boot option.

 The patch assumes that the BIOS has done the basic setup of HPET, but has
 not published the result in ACPI tables. This is at least true for some
 Asus and Gigabyte motherboards.

This works fine on my DFI Lanparty UT nForce4 CK804 mainboard:

[EMAIL PROTECTED]:~$ dmesg | grep hpet
[   25.677099] hpet0: at MMIO 0xfefff000, IRQs 2, 8, 31
[   25.677102] hpet0: 3 32-bit timers, 2500 Hz
[   25.678799] Time: hpet clocksource has been installed.

I've been wanting hpets for a while, this patch is extremely useful to me.

Unfortunately your patch does not seem to apply with standard tools, perhaps 
your mailer corrupted it (I just hand applied it).

Thanks Mikko.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Use C++ in kernel module?

2007-03-30 Thread Alistair John Strachan
On Friday 30 March 2007 07:59, Bongani Hlope wrote:
 On Friday 30 March 2007 05:49:14 Jan Engelhardt wrote:
  On Mar 30 2007 11:37, Conke Hu wrote:
   Is it possible to use C++ in linux kernel module? how?
   I've tested but failed, there is an unknown symbol in the .o file from
   c++ source code.
 
  You answered it yourself. Linux does not have a C++ runtime.
  It is possible to use a very limited set of C++ features, usually not
  worth the fight.
 
 
  Jan

 Do the C++ kernel modules crowd actually know C++? If they knew how C++
 was designed, they would know that it requires some runtime support, which
 will stop them from asking this question over and over again. I'm begining
 to think that most of these questions are asked by people who think OO
 programing should used in the kernel (which is already done anyway)

Not to mention this, attached to every single LKML email:

 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/

http://www.tux.org/lkml/#s15-3

Why don't we rewrite the Linux kernel in C++?

Why not add a C++ interface layer to the kernel to support C++ drivers?

Can we make the kernel headers C++-friendly?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Why is /dev on a different filesystem ? [Kernel 2.6.20.3]

2007-03-21 Thread Alistair John Strachan
On Wednesday 21 March 2007 19:13, Paul Rolland wrote:
 So, obviously, /dev is on /, but the stat(2) says no.
 Who is right, and where is the bug ?

 Kernel 2.4 had it right : /dev was on /, no doubt.

Some distros will mount tmpfs over /dev so that a minimal real dev can be 
provided as a fallback, but udev can add and remove nodes from /dev ad hoc 
during regular runtime. So I don't think there's a bug and I don't think 
anything is lying.

If you want the dev your distro gave you, just mount your rootfs on another 
mount point in read-only and run tar over that instead.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA problems in 2.6.20.3

2007-03-16 Thread Alistair John Strachan
On Friday 16 March 2007 23:44, you wrote:
 Charles Shannon Hendrix wrote:
  I normally run a modified 2.6.19 kernel and it works great.
 
  I recently tried 2.6.20 and had severe SATA problems with it.
 
  Yesterday I tried 2.6.20.3, and the problems are still there.

 Can you try 2.6.21-rc and see if the problem is fixed in those kernels?

-rc4 specifically, it's the first one that's worked for me (possibly related).

(BTW Robert, the sata_nv shadow registers patch has been fine here with a 
patched -rc3 for just over a week now.)

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20*: PATA DMA timeout, hangs (2)

2007-03-12 Thread Alistair John Strachan
On Monday 12 March 2007 11:24, Frank van Maarseveen wrote:
 On Mon, Mar 12, 2007 at 09:54:47AM +0100, Frank van Maarseveen wrote:
  2.6.19 is ok, 2.6.20.[12] hangs from the moment DMA is turned on (hdparm
  -d 1 /dev/hda):
 
  hda: dma_timer_expiry: dma status == 0x20
  hda: DMA timeout retry
  hda: timeout waiting for DMA
  hda: status error: status=0x58 {
  DriveReady
  SeekComplete
  DataRequest
  }
[snip]
 This system has SATA but there's only one PATA disk

Not a solution, unfortunately, but try disabling CONFIG_IDE and using Alan's 
new PATA drivers. For your Intel systems, this should mean you need only:

CONFIG_ATA_PIIX

For both SATA and PATA support. You'll need the appropriate SCSI modules built 
in (if you say =y), i.e. SCSI disk and SCSI CDROM should be built in.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20*: PATA DMA timeout, hangs (2)

2007-03-12 Thread Alistair John Strachan
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote:
[snip]
 So, are /dev/hd* going to disappear in a few years? iow, does it make
 sense to _slowly_ start to migrate to /dev/sd*?

How would you propose doing this? I'm sure modern distros with an 
initrd/initramfs probably already do some sort of root detection. Doesn't fix 
the fstab issue, but I suppose this could be auto-generated too.

 The problem is there's no plan B in case of any troubles except rename
 everything back again to boot an old kernel.

I doubt this matters for distributors, as they'll simply switch over when you 
upgrade the distro, and the earliest supported kernel will be the one that 
shipped with the newer version.

I accept that it's a bit of a drag, but it's better to have a standard naming 
convention for all disks, isn't it?

Glad this is working for you.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: bug in select() in linux

2007-03-12 Thread Alistair John Strachan
On Monday 12 March 2007 15:02, Lluís Batlle wrote:
 Oh, of course you're right. I was inside too much layers to think of
 the tcp protocol, and I did not pay attention to it.

 Maybe something could be added to the manpage anyway.

 The bad thing is that there's no way I can use a socket for writing
 using select() if that connection has been half-closed by the other
 end. Moo.

This question comes up from time to time. I think the answer is 
ultimately select() sucks, use poll().

I can't exactly remember the details, but I believe POLLHUP or POLLOUT as 
flags do what you want.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 29/30] sata_nv: don't read shadow registers when in ADMA mode

2007-03-09 Thread Alistair John Strachan
On Friday 09 March 2007 14:27, you wrote:
 Jeff Garzik wrote:
  [EMAIL PROTECTED] wrote:
  From: Robert Hancock [EMAIL PROTECTED]
 
  Reading from the ATA shadow registers while we are in ADMA mode may
  cause undefined behavior.  Don't read the ATA status register when
  completing commands for this reason, it shouldn't be needed as the
  controller will notify us if the command failed.  Also, don't allow
  commands with result taskfile requested to execute in ADMA mode, since
  that requires accessing the shadow registers.  We also still need to
  override tf_read since libata
  will read the result taskfile on a command failure, and we need to go
  into
  port register mode before allowing this.
 
  Signed-off-by: Robert Hancock [EMAIL PROTECTED]
  Signed-off-by: Andrew Morton [EMAIL PROTECTED]
  ---
 
   drivers/ata/sata_nv.c |   33 -
   1 file changed, 20 insertions(+), 13 deletions(-)
 
  Robert, do you think this should be pushed into #upstream-fixes
  (2.6.21-rc)?
 
  I lean towards yes, since it is a needed-by-hardware fix, but I also
  am interested in testing feedback since it is so late in the 2.6.21-rc
  game.

 I would lean toward that as well, but it would be good to get some
 testing from some sata_nv ADMA users to make sure it doesn't do anything
 funny for them..

Since I've been a bit of a problem case this time, I'd be happy to test it.

Can I assume that I can apply the patch you sent to Jeff [PATCH] sata_nv: 
revert use of notifiers for now, and apply this one, to -rc3, and then be 
able to usefully test?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux v2.6.21-rc3

2007-03-08 Thread Alistair John Strachan
(Dropped LKML, whoops.)

On Wednesday 07 March 2007 04:59, you wrote:
 We've finally hopefully started to put a dent in the regressions,
 especially the suspend/resume problems introduced since 2.6.20.

 So 2.6.21-rc3 is out there now, and there's some hope that it will work
 more widely than -rc1 and -rc2 did. Please do give it a good testing, and
 update Adrian and the mailing list (and me) about any regressions
 (hopefully many more of the it's fixed now than other kinds, but all
 regressions are interesting).

Robert and Jeff already know about these, but I thought I'd send out a
reminder.

ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 
status 0x500 next cpb count 0x0 next cpb idx 0x0
ata2: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd 35/00:30:b5:c1:8f/00:01:01:00:00/e0 tag 0 cdb 0x0 data 155648 out
 res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
ata2: EH complete
SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA

They didn't happen (or didn't happen as frequently) in 2.6.20; it's a serious
bug. Happened in -rc2 and -rc3. A patch from Robert reverting
721449bf0d51213fe3abf0ac3e3561ef9ea7827a seems to make them go away.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CK804 SATA Errors (still got them)

2007-03-04 Thread Alistair John Strachan
On Sunday 04 March 2007 23:25, Robert Hancock wrote:
 Alistair John Strachan wrote:
  Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a
  (link below) and see what effect that has?
 
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
 t;h =721449bf0d51213fe3abf0ac3e3561ef9ea7827a
 
  Obviously, I'll let you know if it happens again, but I've reverted this
  commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on
  an NVIDIA sata controller, and this error hasn't appeared.
 
  So I'm inclined to (very unscientifically) say that this brings it back
  to 2.6.20's level of stability.

 Interesting. Can you try un-reverting that patch, and applying this one?

Sorry for the newbie question, but is it adequate to do a:

git reset --hard v2.6.21-rc2

To ensure a patch is unreverted (I reverted it with git revert), before 
applying your patch?

I've done so now, assuming this _will_ work. The reason I ask is that your 
diff was offset by 12 lines versus -rc2.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CK804 SATA Errors (still got them)

2007-03-04 Thread Alistair John Strachan
On Sunday 04 March 2007 23:25, Robert Hancock wrote:
 Alistair John Strachan wrote:
  Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a
  (link below) and see what effect that has?
 
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
 t;h =721449bf0d51213fe3abf0ac3e3561ef9ea7827a
 
  Obviously, I'll let you know if it happens again, but I've reverted this
  commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on
  an NVIDIA sata controller, and this error hasn't appeared.
 
  So I'm inclined to (very unscientifically) say that this brings it back
  to 2.6.20's level of stability.

 Interesting. Can you try un-reverting that patch, and applying this one?

 The reading of the status register is something that was part of the
 original NVidia code, which I'm not really sure why is there. Given that
 reading the status register clears the drive's interrupt status, that might
 be causing some wierd interaction with the ADMA controller. Also, I added
 in a printk for cases where notifiers are triggered but the command doesn't
 indicate completion - if you still get problems, let me know if you see
 that message.

Didn't take long to observe the problem again, so I'm guessing that this isn't
it. I was definitely using a kernel compiled with your patch:

[EMAIL PROTECTED]:~$ uname -v
#1 SMP Sun Mar 4 23:39:56 GMT 2007

I got the following in dmesg:

ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 
0x500 next cpb count 0x0 next cpb idx 0x0
ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd c8/00:08:37:77:61/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
 res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

Your debugging message did not appear in dmesg, however.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.20, Java, unresponsive userspace

2007-03-03 Thread Alistair John Strachan
Hi,

I've had some problems with 2.6.20 (but also with earlier kernels, like 
Debian's 2.6.18) where one of the users on our system, running a Java6 
application, is somehow able to make the userspace on the machine totally 
unresponsive, denying all remote _and_ local access to the machine.

- The AMD64 port of Linux and Java are in use
- The process runs as an unprivileged user
- The OOM killer doesn't kick in
- No swap is enabled on the machine
- I'm told that the program doesn't fork bomb
  (but I've not got a reproducible test case yet)
- The program is able to deny service even to a getty login.

If I SAK the machine, init respawns getty and everything is fine again.

[EMAIL PROTECTED]:~$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) unlimited
max nice(-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) unlimited
max locked memory   (kbytes, -l) 1000
max memory size (kbytes, -m) 1000
open files  (-n) 1024
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) unlimited
max rt priority (-r) 0
stack size  (kbytes, -s) 2048
cpu time   (seconds, -t) unlimited
max user processes  (-u) 100
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Any ideas with how to proceed for debugging this issue?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CK804 SATA Errors (still got them)

2007-03-02 Thread Alistair John Strachan
On Friday 02 March 2007 02:40, Robert Hancock wrote:
 Alistair John Strachan wrote:
  On Thursday 01 March 2007 15:13, Alistair John Strachan wrote:
  On Thursday 01 March 2007 14:45, Robert Hancock wrote:
  This one seems a bit different. This time it's not related to NCQ vs.
  non-NCQ (this is a non-NCQ write here), it's in ADMA mode (so it's
  presumably not related to switching between ADMA and register mode,
  unless perhaps a flush cache or something executed just before), and
  from the CPB data it appears the command completed but the controller's
  registers aren't indicating that it has. Not sure if I've seen one like
  that before..
 
  How easily can you reproduce this?
 
  It's the first one since -rc2, so apparently not easily. I'm more than
  willing to find loads that expose it, though, so I might try that this
  afternoon.
 
  Got another:
 
  ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000
  status 0x500 next cpb count 0x0 next cpb idx 0x0 ata2: CPB 0: ctl_flags
  0xd, resp_flags 0x1
  ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
  ata2.00: cmd c8/00:80:85:c4:ed/00:00:00:00:00/e3 tag 0 cdb 0x0 data 65536
  in res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) ata2: soft
  resetting port
  ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
  ata2.00: configured for UDMA/133
  ata2: EH complete
  SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB)
  sdb: Write Protect is off
  sdb: Mode Sense: 00 3a 00 00
  SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
  support DPO or FUA
 
  Different HD, similar problem.

 Can you try reverting commit 721449bf0d51213fe3abf0ac3e3561ef9ea7827a
 (link below) and see what effect that has?

 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h
=721449bf0d51213fe3abf0ac3e3561ef9ea7827a

Obviously, I'll let you know if it happens again, but I've reverted this 
commit and transferred 22.5GB over 45 minutes onto a RAID5 with 4 HDs on an 
NVIDIA sata controller, and this error hasn't appeared.

So I'm inclined to (very unscientifically) say that this brings it back to 
2.6.20's level of stability.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] libata Kconfig: Update the various experimentality levels

2007-03-02 Thread Alistair John Strachan
On Friday 02 March 2007 15:05, you wrote:
 Signed-off-by: Alan Cox [EMAIL PROTECTED]
[snip]
  config PATA_OLDPIIX
 - tristate Intel PATA old PIIX support (Experimental)
 + tristate Intel PATA support for the original PIIX
   depends on PCI  EXPERIMENTAL
   help
 -   This option enables support for old(?) PIIX PATA support.
 +   This option enables support for early Intel PIIX PATA support.

Probably nothing, but is it intentional to remove the (Experimental) text 
here, but not the dependency on EXPERIMENTAL?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


CK804 SATA Errors (still got them)

2007-03-01 Thread Alistair John Strachan
Hi Robert,

Despite all the work that went into making these less frequent with ADMA,
they're still possible to trigger.

[EMAIL PROTECTED]:~$ cat /proc/version
Linux version 2.6.21-rc2-damocles ([EMAIL PROTECTED]) (gcc version 4.1.2 
20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Wed Feb 28 21:58:41 GMT 2007

[EMAIL PROTECTED]:~$ dmesg | tail -n 13
ata1: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 
0x500 next cpb count 0x0 next cpb idx 0x0
ata1: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.00: cmd ca/00:38:ae:08:c2/00:00:00:00:00/e0 tag 0 cdb 0x0 data 28672 out
 res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata1: soft resetting port
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: configured for UDMA/133
ata1: EH complete
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

These cause the same ~30 second stalls. Machine was not under load.

No 3rd party modules were loaded.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CK804 SATA Errors (still got them)

2007-03-01 Thread Alistair John Strachan
On Thursday 01 March 2007 14:45, Robert Hancock wrote:
 This one seems a bit different. This time it's not related to NCQ vs.
 non-NCQ (this is a non-NCQ write here), it's in ADMA mode (so it's
 presumably not related to switching between ADMA and register mode,
 unless perhaps a flush cache or something executed just before), and
 from the CPB data it appears the command completed but the controller's
 registers aren't indicating that it has. Not sure if I've seen one like
 that before..

 How easily can you reproduce this?

It's the first one since -rc2, so apparently not easily. I'm more than willing 
to find loads that expose it, though, so I might try that this afternoon.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: CK804 SATA Errors (still got them)

2007-03-01 Thread Alistair John Strachan
On Thursday 01 March 2007 15:13, Alistair John Strachan wrote:
 On Thursday 01 March 2007 14:45, Robert Hancock wrote:
  This one seems a bit different. This time it's not related to NCQ vs.
  non-NCQ (this is a non-NCQ write here), it's in ADMA mode (so it's
  presumably not related to switching between ADMA and register mode,
  unless perhaps a flush cache or something executed just before), and
  from the CPB data it appears the command completed but the controller's
  registers aren't indicating that it has. Not sure if I've seen one like
  that before..
 
  How easily can you reproduce this?

 It's the first one since -rc2, so apparently not easily. I'm more than
 willing to find loads that expose it, though, so I might try that this
 afternoon.

Got another:

ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 status 
0x500 next cpb count 0x0 next cpb idx 0x0
ata2: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd c8/00:80:85:c4:ed/00:00:00:00:00/e3 tag 0 cdb 0x0 data 65536 in
 res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
ata2: EH complete
SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support DPO 
or FUA

Different HD, similar problem.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PCI riser cards and PCI irq routing, etc

2007-02-21 Thread Alistair John Strachan
On Wednesday 21 February 2007 22:40, Lennart Sorensen wrote:
 On Wed, Feb 21, 2007 at 10:35:05PM +0100, Krzysztof Halasa wrote:
  Do you mean both slots on the riser card? No, they have to be rotated.
 
  Given the table from the manual:
   The IRQ (interrupt request line) are hardware lines over which devices
   can send interrupt signals to the microprocessor. The ??PCI  LAN?? IRQ
   pins are typically connected to the PCI bus INT A# ~ INT D# pins as
   follows: Order 1  Order 2 Order 3 Order 4
   PCI Slot 1INT B#  INT C#  INT D#  INT A#
   IEEE1394  INT B#
 
  (I assume Order 1 is device's INT A and so on)
  the chipset-centric view is:

 Well someone said the VIA uses INTA for the DN19 on their riser card,
 although is that INTA from the CPUs point of view or INTA from the slot
 the riser card is plugged into?  There was also mention of a BIOS update
 needed on some boards to even support the riser card at all.  Maybe that
 applies.

It applies on the M1, I'm sure the newer EN series boards have always 
supported the feature.

One warning to you though, I found the riser to be pretty flaky, causing 
bizarre lockups and periodic crashes of Linux. Maybe this is a Linux bug, but 
it really didn't seem like it.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PCI riser cards and PCI irq routing, etc

2007-02-20 Thread Alistair John Strachan
On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote:
 Krzysztof Halasa wrote:
  Udo van den Heuvel [EMAIL PROTECTED] writes:
  At the bottom I added a dmesg output of the kernel after boot.
  I more or less know that irq 20 for the DVB-S card (saa7146 (1)) is
  'working'. I know that irq 16 for saa7146 (0) (DVB-T) is not working for
  i2c although the card does work perfectly for DVB-T reception (picture,
  low CPU load, etc) with only reception as the bottleneck.
 
  BTW: Can you check which device # and IRQ does the card get if plugged
  directly into the PCI slot on board (without the riser)?

 DN is 20 I believe (from the tranquilPC doc).
 irq I'd have to check.

  Is it a VIA ITX board? I think I have VIA's riser card somewhere,
  could check what it does.

 Yes, VIA Epia EN12000.
 Interesting to check the riser card.

Just be aware that there are two types of PCI riser -- risers that work in any 
board, and Via Epia-specific risers. The latter requires a BIOS update on 
some Epias and presumably has some advantages, possible the ones you're 
looking for.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PCI riser cards and PCI irq routing, etc

2007-02-20 Thread Alistair John Strachan
On Tuesday 20 February 2007 15:44, you wrote:
 Alistair John Strachan wrote:
  On Tuesday 20 February 2007 04:17, Udo van den Heuvel wrote:
  Krzysztof Halasa wrote:
  Is it a VIA ITX board? I think I have VIA's riser card somewhere,
  could check what it does.
 
  Yes, VIA Epia EN12000.
  Interesting to check the riser card.
 
  Just be aware that there are two types of PCI riser -- risers that work
  in any board, and Via Epia-specific risers. The latter requires a BIOS
  update on some Epias and presumably has some advantages, possible the
  ones you're looking for.

 This card is sold by TranquilPC for their T2e case which holds Mini-ITX
 boards. My EN12000 has the latest BIOS I could find on the VIA site:
 http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=3
99#BIOS

The riser I have here is called ext-pci rev b and is marked Via Tech Inc. 
My understanding is that this is not an active riser and requires explicit 
BIOS support.

A quick googling for the device revealed this:

http://forums.viaarena.com/messageview.aspx?catid=32threadid=41622highlight_key=ykeyword1=riser

A poster here seems to suggest the following:

As far as I know the only dual riser card that is supported by the EPIA BIOS 
is the one from VIA (that faces out). That one has some logic on it to get 
both slots working. The upper slot uses device 19 and INT_A, allocated 
through the EPIA BIOS.

This may perhaps describe the issue you are having, and from the PDF you 
linked I do not believe you have a riser that is the same as mine.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PCI riser cards and PCI irq routing, etc

2007-02-18 Thread Alistair John Strachan
On Sunday 18 February 2007 19:39, Lennart Sorensen wrote:
[snip]
   On a PC, the BIOS is supposed to assign interrupts to devices based on
   those rules, since that is how the hardware must be done according to
   the PCI specifications.
 
  I set the BIOS for 'PnP OS installed'. Should I change that?

 I would NEVER do that.  That actually disables the BIOS from doing
 configuration of most hardware since it really means Microsoft wants to
 do configuration themselves and asked us to put in a setting to make the
 bios only configure drive controllers and sound cards.  I know some
 people have worked towards making linux a PnP OS by microsoft
 standards, but whether it is entirely there or not by now I am not sure.
 Fortunately most motherboards I have ever bought come preset at 'pnp os
 installed' off, which is how I like it.  I have had a number of
 problems on systems with that setting on, which went away when the
 setting was set back to off.

I think this option actually _used_ to mean whether the BIOS would _provide_ 
PNP services to the host OS, allowing it to detect peripherals like parallel 
ports, etc. In reality, very few devices on modern PCs use or require BIOS 
PNP support, and in some situations it's just annoying (for example, 
disabling the parallel port on my Thinkpad has no effect because Linux just 
uses PNP to redetect it).

 It might actually work better if you change that, although it may also
 just make no difference.

In my experience it just makes no difference. I strongly doubt the option has 
_anything_ to do with this problem.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: User tools for March 11

2007-02-13 Thread Alistair John Strachan
On Tuesday 13 February 2007 21:19, linux-os (Dick Johnson) wrote:
 Hi!
 In the United States, some idiots have decided that the year 2000 scare
 wasn't enough so they changed the start date for daylight savings time
 from the first Sunday in April to the second Sunday in March.
 Does anybody know if there are new tools like `hwclock` and `date`?
 Will new 'C' runtime libraries be necessary as well?

Unless there are utilities homebrewing locales, glibc (locales) should be the 
only package that requires an update. Some distros may sub-package this 
as timezone.

SLES got an updated timezone package for the Western Australian changes, but 
I'm not sure about the US changes.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20 doesn't compile with gcc-3.2.2

2007-02-05 Thread Alistair John Strachan
On Monday 05 February 2007 12:31, you wrote:
 Doing the following results in an incomplete vmlinuz:

 # make mrproper
 # make allnoconfig
 # make bzlilo

 objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
 make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
 make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
 make: *** [bzlilo] Error 2

 # gcc -v
 Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.2.2/specs
 Configured with: ../configure --prefix=/usr --libdir=/usr/lib
 --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info
 --enable-shared --enable-threads=posix --disable-checking
 --enable-long-long --enable-__cxa_atexit
 --enable-languages=c,c++,ada,f77,objc,java
 --host=i586-mandrake-linux-gnu --with-system-zlib
 Thread model: posix
 gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)


 Is gcc-4.0.1 now the minimum required to compile the kernel?

A patch went in to remove support for GCC 3.1, but as far as I know, 3.2 
should be a supported compiler.

At any rate, this might be a binutils issue. What version of binutils are you 
using?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20 doesn't compile with gcc-3.2.2

2007-02-05 Thread Alistair John Strachan
On Monday 05 February 2007 13:48, Bodo Eggert wrote:
 Al Boldi [EMAIL PROTECTED] wrote:
  Doing the following results in an incomplete vmlinuz:
 
  # make bzlilo
 
  objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
  make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
  make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
  make: *** [bzlilo] Error 2
 
  gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)

 I just compiled using gcc 3.3.5 (debian stable). Please verify that your
 disk is not full and gcc is the cause. If it is, this patch should do the
 trick: :)

Not so fast.. post your config? If you've got anything referring to 
relocatable kernel support, try disabling it?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20 doesn't compile with gcc-3.2.2

2007-02-05 Thread Alistair John Strachan
On Monday 05 February 2007 18:04, Al Boldi wrote:
 Alistair John Strachan wrote:
  On Monday 05 February 2007 13:48, Bodo Eggert wrote:
   Al Boldi [EMAIL PROTECTED] wrote:
Doing the following results in an incomplete vmlinuz:
   
# make bzlilo
   
objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzlilo] Error 2
   
gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)
  
   I just compiled using gcc 3.3.5 (debian stable). Please verify that
   your disk is not full and gcc is the cause. If it is, this patch should
   do the trick: :)
 
  Not so fast.. post your config? If you've got anything referring to
  relocatable kernel support, try disabling it?

 No luck disabling relocatable kernel, but using a mem-split other than 3/1
 compiles fine.  There is a catch though, the kernel won't boot anymore.

 # ld -v
 GNU ld version 2.13.90.0.18 20030121

 Which binutils version is now the minimum required, and why is a binutils
 upgrade necessary?

Documentation/Changes still says 2.12, and your binutils is closer to 2.14.
I can't think of a particular patch to point the finger at (looking now).

If you want an interim workaround, grab a newer binutils (probably 2.17), 
install it to a prefix like $HOME/binutils, then:

export PATH=$HOME/binutils/bin:$PATH

And confirm the resulting kernel builds and works.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.20 doesn't compile with gcc-3.2.2

2007-02-05 Thread Alistair John Strachan
On Monday 05 February 2007 18:04, you wrote:
 Alistair John Strachan wrote:
  On Monday 05 February 2007 13:48, Bodo Eggert wrote:
   Al Boldi [EMAIL PROTECTED] wrote:
Doing the following results in an incomplete vmlinuz:
   
# make bzlilo
   
objcopy: arch/i386/boot/compressed/vmlinux.bin: File truncated
make[2]: *** [arch/i386/boot/compressed/vmlinux.bin] Error 1
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzlilo] Error 2
   
gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk)
  
   I just compiled using gcc 3.3.5 (debian stable). Please verify that
   your disk is not full and gcc is the cause. If it is, this patch should
   do the trick: :)
 
  Not so fast.. post your config? If you've got anything referring to
  relocatable kernel support, try disabling it?

 No luck disabling relocatable kernel, but using a mem-split other than 3/1
 compiles fine.  There is a catch though, the kernel won't boot anymore.

 # ld -v
 GNU ld version 2.13.90.0.18 20030121

 Which binutils version is now the minimum required, and why is a binutils
 upgrade necessary?

Another obvious question is, did -rc1/-rc2 compile correctly? If you have the 
time, go through all the -rc's, that'll make a bisection easier (if you end 
up having to do one).

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: More pata_ stuff

2007-02-04 Thread Alistair John Strachan
On Sunday 04 February 2007 18:20, Patrick Ale wrote:
 On 2/4/07, Robert Hancock [EMAIL PROTECTED] wrote:
  ata_piix should drive that chipset. Was that driver enabled in the
  kernel configuration, and if it's built modular is the initrd, etc. set
  up to load it on boot?

 Hi,

 Yep, piix was configured as built-in, I don't use ramdisks.
 And, the SD driver is configured built-in aswell.
 Hence, this is more or less the same kernel config as I used with my
 Gigabyte GA-VAXP Ultra mainboard. The things I changed in this new
 config are:

 - Enable SMP
 - Enable ata_piix
 - CPU Type set to Pentium II

And this config has clearly:

# CONFIG_ATA_PIIX is not set

Which for a PIIX4 chipset is what you want. Somewhat confusingly:

CONFIG_PATA_MPIIX=y
CONFIG_PATA_OLDPIIX=y

Should be n, I've been told.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.18-stable release plans?

2007-01-25 Thread Alistair John Strachan
On Thursday 25 January 2007 09:16, Chris Rankin wrote:
 But anyway - can someone please tell me what Eeek! page_mapcount(page)
 went negative! (-1) is *really* saying/implying? Because I am currently
 translating this as I WANT TO EAT YOUR FILESYSTEMS.

Hugh already did, multiple times. If there's an external hardware event that 
corrupts memory, code executing on your CPU is no longer going to behave 
deterministically. So cases that are typically impossible in the design of 
the code have a chance to trigger.

You can continue to flame 2.6.19, but you're an extreme minority when it comes 
to this kind of bug and as, again, Hugh already said, almost all of the 
reports of this and similar other bugs have led to hardware problems that 
were either unchecked or difficult to detect.

Imagine this scenario. It might seem unrealistic to you, but it's not 
impossible!

First Use of Linux - Upgrading to 2.6.19
Undetected hardware error never triggered.

Running 2.6.19
Hardware error triggers. Linux crashes.

Going back to 2.6.18
Hardware error has not yet triggered again.

Will it eat your filesystem? Maybe. But it probably won't, if you claim the 
memory is tested, it could have been a single bit error, or a cosmic ray 
event, or a brownout, or anything similar. It's much more likely to simply 
crash your machine, as it did.

Not running the affected kernel again is a sure way to have _nobody_ listen to 
your complaints about 2.6.19 having a real software bug, because you're 
totally unwilling to test the kernel again and see if it triggers. A single 
report is simply not enough evidence. 

Additionally, reports from other users (who may have a million different 
experimental variables involved) are also insufficient, for reasons which 
have already been explained (drivers, proprietary code, et cetera).

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Strange

2007-01-23 Thread Alistair John Strachan
On Wednesday 24 January 2007 00:01, Christoph Anton Mitterer wrote:
 Alan wrote:
  kernel:   Error: Illegal request -- (Sense key=0x05)
  kernel:   Read of scrambled sector without authentication -- (asc=0x6f,
  ascq=0x03)
 
  The disc is using digital rights management. If you are in a country that
  permits it you can use a dvd reader library with decss support, if not
  you'll have to either watch your disks on a system approved by the movie
  industry enforcers or commit a crime to read the disc.

 I knew of course about libdvdcss but I've never noticed before that the
 kernel issues these error messages to the syslog.

If you've replaced the drive, the decss keys might have changed for inserted 
media (this is especially true if your old drive had a different region 
setting).

First set the DVD region on the drive to where you are (probably 2), 
using regionset. Then rm -rf ~/.dvdcss and restart your video playing 
application. It should rescan the dvd, figure out the keys, no error 
messages.

 So you say this is normal?! But the problem with ejecting isn't probably
 normal.

Yeah, like Alan says it's just the DRM nonsense built into your drive trying 
to protect the media. You can find firmware modifications which remove this 
logic from the drive, but I'm not sure of their legality.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA exceptions with 2.6.20-rc5

2007-01-22 Thread Alistair John Strachan
On Tuesday 23 January 2007 01:24, Robert Hancock wrote:
 As a final aside, this is another case where the hardware docs for this
 controller would really be useful, in order to know whether we are
 actually supposed to be reading that register in ADMA mode or not. I
 sent a query to Allen Martin at NVIDIA asking if there's a way I could
 get access to the documents, but I haven't heard anything yet.

Obviously, NVIDIA's response is disappointing, but thank you for putting the 
time in to debug this problem. Definitely sounds like a hardware defect, I'm 
just glad there's a workaround.

Will we see this fix in 2.6.20?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA exceptions with 2.6.20-rc5

2007-01-20 Thread Alistair John Strachan
On Saturday 20 January 2007 19:59, Robert Hancock wrote:
 Ian Kumlien wrote:
  Hi,
 
  I went from 2.6.19+sata_nv-adma-ncq-v7.patch, with no problems and adama
  enabled, to 2.6.20-rc5, which gave me problems almost instantly.
 
  I just thought that it might be interesting to know that it DID work
  nicely.
 
  CC since i'm not on the ml

 (I'm ccing more of the people who reported this)

 Well that's interesting.. The only significant change that went into
 2.6.20-rc5 in that driver that wasn't in that version you mentioned was
 this one:

 http://www2.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=com
mit;h=2dec7555e6bf2772749113ea0ad454fcdb8cf861

 Could you (or anyone else) test what happens if you take the 2.6.20-rc5
 version of sata_nv.c and try it on 2.6.19? That would tell us whether
 it's this change or whether it's something else (i.e. in libata core).

I'm still running an -rc5 kernel with ADMA switched off entirely and I can't 
reproduce the problem. How is everybody else reproducing this?

I've been successful installing bonnie++, then going to a large XFS partition 
and running bonnie++ -u 1000:1000 and letting it run through, all defaults.

It doesn't cause the problem I was seeing in -rc5 with ADMA on, when I switch 
ADMA off, so I think this is sufficient to fix it.

Others have reported differently. Did you guys do:

[EMAIL PROTECTED]:~$ cat /proc/cmdline
root=/dev/sda1 ro sata_nv.adma=0

Or something similar? This is how Jeff suggested disabling ADMA and indeed the 
messages about its use disappear from dmesg.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA exceptions with 2.6.20-rc5

2007-01-19 Thread Alistair John Strachan
On Tuesday 16 January 2007 00:34, Robert Hancock wrote:
 I'll try your stress test when I get a chance, but I doubt I'll run into
 the same problem and I haven't seen any similar reports. Perhaps it's
 some kind of wierd timing issue or incompatibility between the
 controller and that drive when running in ADMA mode? I seem to remember
 various reports of issues with certain Maxtor drives and some nForce
 SATA controllers under Windows at least..

I have exactly the same problem on -rc5 and it causes all I/O to stall 
periodically if I do _anything_ I/O intensive.

On my box, I have 4 sata_nv handled SATA ports, with two pairs of different 
drives (two Maxtor, two WD) and it happens randomly on both. So it's 
absolutely nothing to do with the drive make/model.

I'll try Jeff's suggestion of disabling ADMA now, but I think something more 
radical than this workaround should make it into 2.6.20 final, otherwise a 
lot of people are going to have broken boxes.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA exceptions with 2.6.20-rc5

2007-01-19 Thread Alistair John Strachan
On Tuesday 16 January 2007 01:53, Jeff Garzik wrote:
 Robert Hancock wrote:
  I'll try your stress test when I get a chance, but I doubt I'll run into
  the same problem and I haven't seen any similar reports. Perhaps it's
  some kind of wierd timing issue or incompatibility between the
  controller and that drive when running in ADMA mode? I seem to remember
  various reports of issues with certain Maxtor drives and some nForce
  SATA controllers under Windows at least..

 Just to eliminate things, has disabling ADMA been attempted?

 It can be disabled using the sata_nv.adma module parameter.

Setting this option fixes the problem for me. I suggest that ADMA defaults off 
in 2.6.20, if there's still time to do that.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: SATA exceptions with 2.6.20-rc5

2007-01-19 Thread Alistair John Strachan
On Saturday 20 January 2007 02:41, Robert Hancock wrote:
 By the way, I assume that you guys are using reiserfs or xfs, as it
 appears no other file systems issue flush commands automatically. I had
 to test this by echo 1  delete on the SCSI disk in sysfs, as I am
 using ext3.

I'll give it a spin now, and yes I'm using several large XFS partitions on 
this machine, layered on top of md RAID5. That's why this particular defect 
is so catastrophic (literally _everything_ is stalled).

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.19: BUG: soft lockup detected on CPU#0!

2007-01-10 Thread Alistair John Strachan
Hi,

After a few days uptime on a 2.6.19 kernel, I see this:

http://devzero.co.uk/~alistair/2.6.19-softlockup.jpg

At which point magic sysrq doesn't work and the machine requires a hard 
reboot. Is there anything that can be done to produce a more verbose message 
when such a soft lockup occurs?

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Gaming Interface

2007-01-08 Thread Alistair John Strachan
On Monday 08 January 2007 13:04, Dirk wrote:
 But I don't see top titles ported to SDL/OpenGL.

This is because you're not looking very hard. If you look at Ryan's ports over 
at http://icculus.org/ many of the games (some he's _paid_ to port) use SDL 
statically linked in. There's no legal or technical problem with this.

Really, what you're talking about already exists. If anything, you need to 
convince the SDL guys (not the kernel guys) to make SDL more comprehensive OR 
write your own multimedia library, perhaps based on or backending to SDL.

As noted elsewhere in this thread, most games use 3D hardware exclusively, and 
only really care about the OS for initialising a video mode and playing 
sound.

Most ports probably suffer the worst from the lack of DirectX APIs on Linux, 
something which the WINE project is trying to solve. Using libwine, one will 
eventually be able to write native Linux applications that use the DirectX 
APIs. Porting should then be very much easier.

Of course, vendors using OpenGL gain Macintosh portability amongst other 
things, and most of the really big titles do have OpenGL render modes, which 
are already largely portable.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: kernel + gcc 4.1 = several problems

2007-01-06 Thread Alistair John Strachan
On Sunday 07 January 2007 00:36, Pavel Machek wrote:
[snip]
  However, this patch is mostly useless if you have a separate stack for
  IRQ's (since if that happens, any interrupt will be taken on a different
  stack which we don't see any more), so you should NOT enable the 4KSTACKS
  config option if you try this out.

 stupid idea... perhaps gcc-4.1 generates bigger stackframe somewhere,
 and stack overflows?

The primary reason it's not 4KSTACKS already is that I run multiple XFS 
partitions on top of an md RAID 1. LVM isn't involved, however, and I'm not 
using any other filesystem overlays like dm.

I'm fairly sceptical that it's a stack overflow, but I'll be sure to enable 
the debugging option on the next try.

 that hw monitoring thingie... I'd turn it off. Its interactions with
 acpi are non-trivial and dangerous.

Well, GCC 3.4 kernels seem to run fine with it, but as I said to Linus I'll be 
sure to turn this and the sound drivers off in the next build.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: kernel + gcc 4.1 = several problems

2007-01-05 Thread Alistair John Strachan
On Wednesday 03 January 2007 02:20, Alistair John Strachan wrote:
 On Wednesday 03 January 2007 02:12, Mikael Pettersson wrote:
  On Tue, 2 Jan 2007 17:43:00 -0800 (PST), Linus Torvalds wrote:
The suggestions I've had so far which I have not yet tried:
   
-   Select a different x86 CPU in the config.
-   Unfortunately the C3-2 flags seem to simply 
tell GCC
to schedule for ppro (like i686) and enabled 
MMX and SSE
-   Probably useless
  
   Actually, try this one. Try using something that doesn't like cmov.
   Maybe the C3-2 simply has some internal cmov bugginess.
 
  That's a good suggestion. Earlier C3s didn't have cmov so it's
  not entirely unlikely that cmov in C3-2 is broken in some cases.
  Configuring for P5MMX or 486 should be good safe alternatives.

 Or just C3 (not C3-2), which is what I've done.

 I'll report back whether it crashes or not.

This didn't help. After about 14 hours, the machine crashed again.

cmov is not the culprit.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: kernel + gcc 4.1 = several problems

2007-01-05 Thread Alistair John Strachan
On Friday 05 January 2007 16:02, Linus Torvalds wrote:
 On Fri, 5 Jan 2007, Alistair John Strachan wrote:
  This didn't help. After about 14 hours, the machine crashed again.
 
  cmov is not the culprit.

 Ok. Have you ever tried to limit the drivers you have loaded? I notice you
 had the prism54 wireless thing in your modules list and the vt1211 hw
 monitoring thing. I'm wondering about the vt1211 thing - it probably isn't
 too common.

Sure, and it only got added to 2.6.19 anyway (however GCC 3.4.6 really does 
seem to have no problem with it).

 But if you can use that machine without the wireless too, it
 might be good to try without either.

Required, plus I've been running prism54 on three different machines with a 
huge number of compilers since the early 2.6 days with no problems.

 (The rest of your module list looked bog-standard, so if it's not
 hardware-specific, I don't think it's there)

Agreed, the config is already _very_ minimal for this machine.

 Turning of the VIA sound driver just in case would be good too.

I'm not even really sure why that's enabled. I can do that.

 The reason I mention vt1211 in particular is that it does things like
 regulate fan activity etc. Is the problem perhaps heat-related?

It definitely isn't heat related. This CPU puts out 7-10W, has a ridiculous 
5000 RPM fan on it (that works) and the temp never exceeds 40C. If anything, 
the -O2, 3.4.6 kernel with CMOV ran the chip a little hotter.

As far as I can see, all the other components are either cool to touch or have 
stupidly big heatsinks on them.

(I realise with problems like these it's almost always some sort of obscure 
hardware problem, but I find that very difficult to believe when I can toggle 
from 3 years of stability to 6-18 hours crashing by switching compiler. I've 
also ran extensive stability test programs on the hardware with absolutely no 
negative results.)

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: S.M.A.R.T no longer available in 2.6.20-rc2-mm2 with libata

2007-01-03 Thread Alistair John Strachan
On Thursday 04 January 2007 01:50, Ed Sweetman wrote:
 Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in
 libata land but SMART is no longer available on my hdds.   I'm assuming
 this is not the intended behavior.

 In case this is chipset specific, IDE interface: nVidia Corporation
 CK804 Serial ATA Controller (rev f3)

 I'm using Libata nvidia driver, the drives happen to be sata drives, but
 even the pata ones no longer report having SMART.

What program are you trying to use here? As I reported around -rc1 time, 
hddtemp is broken by 2.6.20-rc but Jens posted a patch to fix it.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


  1   2   3   >