Re: What's up with 2.6.20?
On Friday 08 June 2007 14:57:45 Paul Albrecht wrote: > > Seems like an obvious regression so I was wondering if I could get some > help resolving the problem here? > I see a reply from Dimitry Torokhov which you haven't acknowledged. Did you miss it? Andrew Walrond PS 'Nudge' messages like this should be in reply to your original message. People aren't going to hunt back through 450 messages to find out what you said yesterday... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: diff-patch
On Saturday 02 June 2007 12:00:28 Shahbaz Khan wrote: > I need help with my homework > Both tools come with extensive documentation, but such questions are unwelcome here. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (Sparc64) 2.6.20 seems to ignore initramfs
On Saturday 24 February 2007 15:23, Jan Engelhardt wrote: > On Feb 23 2007 15:47, Andrew Walrond wrote: > > > >I have tracked this down to a broken version of gnu cpio (latest release, > > 2.7) which was used to create the initramfs archive. Bloody annoying > > since this has bitten me before! Last time I even sent the maintainer a > > bug report, and apparently a fix is in CVS waiting for the next release. > > Ho hum. > > Forgot the -c flag, right? > No, I use '-H newc' as per the instrucions in Documentation/filesystems/ramfs-rootfs-initramfs.txt. Does -c do the same thing? [checks man cpio...] But there is a real bug in cpio 2.7 which can break the archive. Its been fixed in cpio cvs awaiting the next release. My report to the cpio ML: Hello list, I've been experimenting with large (500Mb) initramfs cpio archives on linux, x86_64, using cpio 2.7, compiled 64bit with gcc4.1.1. If I create a cpio archive, then extract it and compare with the original, I see broken symlinks. I don't know if the archives themselves are corrupt, or whether the extraction code is broken, but I guess you guys can work that out. An example: [EMAIL PROTECTED] initramfs $ cd rootfs [EMAIL PROTECTED] rootfs $ find . | cpio -o -H newc > ../rootfs.cpio 857030 blocks [EMAIL PROTECTED] rootfs $ cd .. [EMAIL PROTECTED] initramfs $ mkdir tmp [EMAIL PROTECTED] initramfs $ cd tmp [EMAIL PROTECTED] tmp $ cpio -i -d -H newc -F ../rootfs.cpio --no-absolute-filenames 857030 blocks [EMAIL PROTECTED] tmp $ ll ../rootfs/pkg/linux/lib/modules/2.6.19.2/ total 1.1M lrwxrwxrwx 1 root root 17 Jan 11 13:39 build -> /pkg/linux/source drwxrwxr-x 11 root root 4.0K Jan 11 11:14 kernel -rw-rw-r-- 1 root root 229K Jan 11 11:14 modules.alias -rw-rw-r-- 1 root root 69 Jan 11 11:14 modules.ccwmap -rw-rw-r-- 1 root root 246K Jan 11 11:14 modules.dep -rw-rw-r-- 1 root root 813 Jan 11 11:14 modules.ieee1394map -rw-rw-r-- 1 root root 788 Jan 11 11:14 modules.inputmap -rw-rw-r-- 1 root root 2.6K Jan 11 11:14 modules.isapnpmap -rw-rw-r-- 1 root root 74 Jan 11 11:14 modules.ofmap -rw-rw-r-- 1 root root 161K Jan 11 11:14 modules.pcimap -rw-rw-r-- 1 root root 967 Jan 11 11:14 modules.seriomap -rw-rw-r-- 1 root root 100K Jan 11 11:14 modules.symbols -rw-rw-r-- 1 root root 306K Jan 11 11:14 modules.usbmap lrwxrwxrwx 1 root root 17 Jan 11 13:39 source -> /pkg/linux/source [EMAIL PROTECTED] tmp $ ll pkg/linux/lib/modules/2.6.19.2/ total 1.1M lrwxrwxrwx 1 root root 23 Jan 12 12:08 build -> /pkg/linux/sourceodules drwxrwxr-x 11 root root 4.0K Jan 12 12:08 kernel -rw-rw-r-- 1 root root 229K Jan 12 12:08 modules.alias -rw-rw-r-- 1 root root 69 Jan 12 12:08 modules.ccwmap -rw-rw-r-- 1 root root 246K Jan 12 12:08 modules.dep -rw-rw-r-- 1 root root 813 Jan 12 12:08 modules.ieee1394map -rw-rw-r-- 1 root root 788 Jan 12 12:08 modules.inputmap -rw-rw-r-- 1 root root 2.6K Jan 12 12:08 modules.isapnpmap -rw-rw-r-- 1 root root 74 Jan 12 12:08 modules.ofmap -rw-rw-r-- 1 root root 161K Jan 12 12:08 modules.pcimap -rw-rw-r-- 1 root root 967 Jan 12 12:08 modules.seriomap -rw-rw-r-- 1 root root 100K Jan 12 12:08 modules.symbols -rw-rw-r-- 1 root root 306K Jan 12 12:08 modules.usbmap lrwxrwxrwx 1 root root 23 Jan 12 12:08 source -> /pkg/linux/sourceodules [EMAIL PROTECTED] tmp $ The extra 'odules' is suspiciously like 'modules'... I am now using version 2.6 with debian patches to 2.6-17, and this works fine. I've tried making a small test case, but it only seems to occur with my large (500Mb) root filesystem archives. If I just archive the modules directory in the example above, the corruption does not occur. Anyhow; if I can do anything to chase this down further, let me know. I have joined the ML. Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (Sparc64) 2.6.20 seems to ignore initramfs
On Friday 23 February 2007 15:17, Tomasz Chmielewski wrote: > > Try to decrease the initramfs size just to know if it boots correctly. > > I.e., put just a sh/bash/ash/dash binary there (probably /dev/console > node, too), executed in init. > > Then, try to start the kernel with initramfs embedded in the kernel, > then as initrd etc. - this will show if the fault is on your side, or > kernel's. I have tracked this down to a broken version of gnu cpio (latest release, 2.7) which was used to create the initramfs archive. Bloody annoying since this has bitten me before! Last time I even sent the maintainer a bug report, and apparently a fix is in CVS waiting for the next release. Ho hum. Sorry for the noise. Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (Sparc64) 2.6.20 seems to ignore initramfs
On Friday 23 February 2007 13:32, Tomasz Chmielewski wrote: > Andrew Walrond schrieb: > > On a Sun T1000 I am trying to boot 2.6.20 using initramfs. (I use the > > same procedure successfully on x86_64 and itanium2 servers). > > > > The relevent silo section looks like this: > > > > image=/boot/2.6.20.image > > label=2.6.20 > > initrd=/boot/2.6.20.initramfs > > partition=2 > > read-only > > > > The kernel loads and boots and I see > > (...) > > > So it knows about the initramfs, but then tries to mount a root > > filesystem instead... > > > > I haven't tried this (initramfs) with earlier kernels, so I don't know > > whether this is a regression. Any clues about how to solve this would be > > greatly appreciated. > > Does it make a difference if you embed initramfs directly in the kernel? > > CONFIG_INITRAMFS_SOURCE="/path/to/your/initramfs/directory" Hi Tomasz. I can't tell; The combined kernel+initramfs is bigger than the 8Mb silo allocates for the kernel, and it does this: boot: chunky Allocated 8 Megs of memory at 0x4000 for kernel / Fatal error: Image too large to fit in destination Fatal error: Image too large to fit in destination Error loading /boot/chunky Image not found try again I don't see any silo config options to increase this value in the docs. Good idea though :) Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
(Sparc64) 2.6.20 seems to ignore initramfs
On a Sun T1000 I am trying to boot 2.6.20 using initramfs. (I use the same procedure successfully on x86_64 and itanium2 servers). The relevent silo section looks like this: image=/boot/2.6.20.image label=2.6.20 initrd=/boot/2.6.20.initramfs partition=2 read-only The kernel loads and boots and I see Allocated 8 Megs of memory at 0x4000 for kernel Loaded kernel version 2.6.20 Loading initial ramdisk (127932430 bytes at 0x100 phys, 0x40C0 virt)... / Remapping the kernel... done. Booting Linux... PROMLIB: Sun IEEE Boot Prom 'OBP 4.23.0 2006/06/02 16:14' PROMLIB: Root node compatible: sun4v Linux version 2.6.20 ([EMAIL PROTECTED]) (gcc version 4.1.1) #1 SMP Thu Feb 22 16:25:18 GMT 2007 ARCH: SUN4V Ethernet address: 00:14:4f:2a:90:92 PROM: Built device tree with 65903 bytes of memory. Built 1 zonelists. Total pages: 242541 Kernel command line: ro [snip] checking if image is initramfs... it is Freeing initrd memory: 124934k freed [snip] VFS: Cannot open root device "" or unknown-block(0,0) Please append a correct "root=" boot option Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) <0>Press Stop-A (L1-A) to return to the boot prom So it knows about the initramfs, but then tries to mount a root filesystem instead... I haven't tried this (initramfs) with earlier kernels, so I don't know whether this is a regression. Any clues about how to solve this would be greatly appreciated. Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 header change breaks linux-atm userspace build
On Friday 09 February 2007 00:01, David Miller wrote:
> From: Andrew Walrond <[EMAIL PROTECTED]>
> Date: Thu, 8 Feb 2007 21:31:25 +
>
> > Sometime between 2.6.18.3 and 2.6.20, this change...
> >
> > --- /include/linux/atmarp.h 2007-01-10 16:32:05.0 +
> > +++ pkg/linux/include/linux/atmarp.h2007-02-08 20:02:08.0
> > + @@ -34,7 +34,7 @@
> > struct atmarp_ctrl {
> > enum atmarp_ctrl_type type; /* message type */
> > int itf_num;/* interface number (if present)
> > */ - uint32_tip; /* IP address (act_need only)
> > */ + __be32 ip; /* IP address (act_need only)
> > */ };
> >
> > #endif
> >
> > was introduced, but __be32 is undefined, so atmarp.h should include
> > linux/types.h
>
> I'll fix this, thanks for reporting.
Actually, it seems that several other atm headers are also missing
linux/types.h. I guess you can tell which ones have changed recently using
git (I just patched linux-atm with liberal #include ). But let
me know if you want a full list.
Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux header change breaks linux-atm userspace build
Sometime between 2.6.18.3 and 2.6.20, this change...
--- /include/linux/atmarp.h 2007-01-10 16:32:05.0 +
+++ pkg/linux/include/linux/atmarp.h2007-02-08 20:02:08.0 +
@@ -34,7 +34,7 @@
struct atmarp_ctrl {
enum atmarp_ctrl_type type; /* message type */
int itf_num;/* interface number (if present) */
- uint32_tip; /* IP address (act_need only) */
+ __be32 ip; /* IP address (act_need only) */
};
#endif
was introduced, but __be32 is undefined, so atmarp.h should include
linux/types.h
I've cc'ed Adrian Bunk since he seemed interested last time I reported
something like this.
http://lkml.org/lkml/2007/1/19/39
Hope that is useful.
Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Kernel headers - linux-atm userspace build broken by recent change; __be16 undefined
Don't know exactly when this change went in, but it's not in 2.6.18.3 and is in 2.6.19.2+ $ diff linux/include/linux/if_arp.h linux-2.6/include/linux/if_arp.h 133,134c133,134 < unsigned short ar_hrd; /* format of hardware address */ < unsigned short ar_pro; /* format of protocol address */ --- > __be16 ar_hrd; /* format of hardware address */ > __be16 ar_pro; /* format of protocol address */ 137c137 < unsigned short ar_op; /* ARP opcode (command) */ --- > __be16 ar_op; /* ARP opcode (command) */ This causes the linux-atm userspace compile to fail like this: In file included from arp.c:19: /usr/include/linux/if_arp.h:133: error: expected specifier-qualifier-list before '__be16' I guess if_arp.h needs to include include/linux/byteorder/big_endian.h? Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and /sbin/hotplug fun
Olaf Hering wrote: Why do you need /sbin/hotplug anyway, just for firmware loading for a non-modular kernel? I guess this is unusual, but FWIW... I have a custom distro and I was just looking for the easiest way to create a bootable rescue pen-drive. So I just took a working distro, added an init->sbin/init symlink, cpio'ed it into an initramfs, and booted it up. Works a treat, except for the early hotplug calls. Andrew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Initramfs and /sbin/hotplug fun
Olaf Hering wrote: On Mon, Jan 15, Andrew Walrond wrote: To solve this, I deleted /sbin/hotplug from the initramfs archive and modified /init to reinstate it once it gets control. This works fine, but seems inelegant. Is there a better solution? Should sbin/hotplug be called at all before the kernel has passed control to /init? Yes, it should be called. Ok /sbin/hotplug and /init are two very different and unrelated things. Well, of course. But looking at the thread provided by Jan, it seems the kernel might not be in any fit state to service the (userspace) hotplug infrastructure when it makes the calls (Ie can't create pipes yet). The kernel wouldn't call /init (or /sbin/init) before it was fully ready to handle userspace processes, so why should it feel able to call the hotplug userspace? Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initramfs and /sbin/hotplug fun
If the initramfs root filesystem contains /sbin/hotplug, the kernel starts calling it very early in the kernel boot process, well before /init has been called. In my case this resulted in lots of hotplug segfault messages as the kernel boots, followed by a thoroughly unhappy hotplug+udev once /init actually gets control. To solve this, I deleted /sbin/hotplug from the initramfs archive and modified /init to reinstate it once it gets control. This works fine, but seems inelegant. Is there a better solution? Should sbin/hotplug be called at all before the kernel has passed control to /init? Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops on x86_64 after upgrade to 2.6.19.1. (ACPI related?)
I was running 2.6.18.3 before, which worked fine. Only managed to get a screen grab from remote KVM, but hope its useful. I'll try latest rc when I can get someone to reset the (remote) box. Andrew Walrond <>
Sparc64 kernel oops (caused by bad scsi disk?)
Installing a bad disk in a Sun D1000 (JBOD 12 disk scsi 2 array)
attached to a Sun E4500 (8proc, 8Gb ram) running a 64bit sparc64
2.6.18.3 SMP kernel causes this or similar oops when accessing the bad
disk:
sda: Current: sense key: Recovered Error
Additional sense: Address mark not found for data field
Info fld=0xa8d
sda: Current: sense key: Recovered Error
Additional sense: Write error - recovered with auto reallocation
Info fld=0xa98
sda: Current: sense key: Recovered Error
Additional sense: Address mark not found for data field
Info fld=0xad6
sda: Current: sense key: Recovered Error
Additional sense: Recovered data with retries
Info fld=0xaff
sda: Current: sense key: Recovered Error
Additional sense: Recovered data with retries
Info fld=0xb0f
eth5: Auto-Negotiation unsuccessful, trying force link mode
sda: Current: sense key: Recovered Error
Additional sense: Recovered data with negative head offset
Info fld=0xb2b
sda: Current: sense key: Recovered Error
Additional sense: Recovered data with retries
Info fld=0xb52
sda: Current: sense key: Recovered Error
Additional sense: Recovered data with retries
Info fld=0xb68
sda: Current: sense key: Recovered Error
Additional sense: Recovered data with retries
Info fld=0xbba
eth5: Link down, cable problem?
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 05a4
tsk->{mm,active_mm}->pgd = f80113976000
\|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
swapper(0): Oops [#1]
TSTATE: 80f09607 TPC: 0052b51c TNPC: 0052b520 Y:
Not tainted
TPC:
g0: f80003d03660 g1: 11010080 g2: g3:
f801feaf
g4: 0072d280 g5: f8000350c000 g6: 00729280 g7:
0050
o0: 00c0 o1: f801feaf1d60 o2: o3:
07fe0150e360
o4: 00c0 o5: f30bcf28 sp: 0072c3d1 ret_pc:
005d7e24
RPC:
l0: f801feaf1d40 l1: 0076 l2: l3:
0076
l4: l5: l6: f80004a74140 l7:
0001
i0: i1: f80004faa4c0 i2: 0072cf90 i3:
i4: i5: f80003d6b660 i6: 0072c491 i7:
0046d20c
I7:
Caller[0046d20c]: handle_IRQ_event+0x38/0x78
Caller[0046d308]: __do_IRQ+0xbc/0x13c
Caller[0041bec8]: handler_irq+0x7c/0x94
Caller[004108b4]: tl0_irq5+0x1c/0x20
Caller[004180e4]: cpu_idle+0x2c/0xa4
Caller[007ce6c0]: start_kernel+0x28c/0x294
Caller[004045d8]: setup_trap_table+0x0/0x100
Caller[]: 0x8
Instruction DUMP: da5a6000 c25a6008 8ea1e010 92026008 c272400b
186a 92026008 808aa008
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Press Stop-A (L1-A) to return to the boot prom
Let me know if I can do anything to help chase this down.
Andrew Walrond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Crosspost] GNU/Linux userland?
On Wednesday 13 April 2005 20:40, Oliver Korpilla wrote: > Hello! > > I wondered if there is a project or setup that does allow me to build a > GNU/Linux userland including kernel, build environment, basic tools with > a single script just as you can in NetBSD (build.sh) or FreeBSD (make > world). > > I do not refer to a step-by-step instruction like "Linux From Scratch" > (which I do find commendable, but is not quite the same), but an > automated, cross-compilation aware foundation for a Linux system. > Heretix does everything except cross-compile. It's a complete rewrite of rubyx (http://www.rubyx.org) but doesn't have its own website yet. Discussion is happening on the rubyx ML. Cross compilation support would be a simple extension to Heretix, if you fancy a project :) Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 SCM saga..
On Wednesday 06 April 2005 16:42, Linus Torvalds wrote: > > PS. Don't bother telling me about subversion. If you must, start reading > up on "monotone". That seems to be the most viable alternative, but don't > pester the developers so much that they don't get any work done. They are > already aware of my problems ;) Care to share your monotone wishlist? Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 SCM saga..
I recently switched from bk to darcs (actually looked into it after the author mentioned on LKML that he had imported the kernel tree). Very impressed so far, but as you say, > 1. It's rather slow and quite CPU consuming and certainly I/O consuming I expect something as large as the kernel tree would cause problems in this respect. > 2. It has an impressive set of dependencies around Glasgow Haskell >Compiler. I don't personally have issues with that, but I can already >hear the moaning and bitching. :) I try to built everthing from the original source, but in this case I couldn't. The GHC needs the GHC + some GHC addons in order to compile itself... > > 3. DARCS is written in Haskell. This is not a problem either, but I'd >think there are fewer people who can hack Haskell than people who >can hack C, C++, Java, Python or similar. It is still better than True, though as you say, not a show-stopper. >From a functionality standpoint, darcs seem very similar to monotone, with a couple minor trade-offs in either direction. I wonder if Linus would mind publishing his feature requests to the monotone developers, so that other projects, like darcs, would know what needs working on. Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.11.6 (x86_64) Scsi-detect Oops
On Saturday 02 April 2005 20:10, Andrew Walrond wrote: > > In the meantime, I'm going to remove this driver from the .config > Boots fine without this driver compiled in (SCSI_FUTURE_DOMAIN=n) Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11.6 (x86_64) Scsi-detect Oops
This kernel has all ide and scsi drivers built in (config attached) I can do the complete serial boot thing if really necessary, but someboby might have an inkling from these details jotted down by hand: __fdomain_16x0_detect+29 init_this_scsi_driver+94 (RIP __fdomain_16x0_detect+419) Looks like the "Future Domain 16xx SCSI/AHA-2920A" scsi driver detect routine is doing something naughty. This is a Tyan 2885 dual x86_64 running a 64bit generic x86_64 kernel. It doesn't have any scsi hardware. In the meantime, I'm going to remove this driver from the .config Andrew Walrond 2.6.11.6-x86_64.config.bz2 Description: BZip2 compressed data
Re: [patch] Real-Time Preemption, -RT-2.6.11-final-V0.7.40-00
On Friday 11 March 2005 09:28, Ingo Molnar wrote: > i have released the -V0.7.40-00 Real-Time Preemption patch, which can be > downloaded from the usual place: > I've lost the thread a little; Is this still x86 only? Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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][i386] HPET setup, duplicate HPET_T0_CMP needed for some platforms
On Friday 04 February 2005 23:41, Venkatesh Pallipadi wrote: > + /* > + * Some systems seems to need two writes to HPET_T0_CMP, > + * to get interrupts working > + */ I think you should update this comment in light of the information from Vojtech: /* * The first write after writing TN_SETVAL to the config register sets the * counter value, the second write sets the threshold. */ Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 HPET code
On Thursday 03 February 2005 20:02, Venkatesh Pallipadi wrote: > On Thu, Feb 03, 2005 at 11:30:56AM -0800, john stultz wrote: > > On Thu, 2005-02-03 at 06:28 -0800, Pallipadi, Venkatesh wrote: > > > Can you check whether only the following change makes the problem go > > > away. If yes, then it looks like a hardware issue. > > > > > > > hpet_writel(hpet_tick, HPET_T0_CMP); > > > >+ hpet_writel(hpet_tick, HPET_T0_CMP); /* AK: why twice? */ > > > > Yep. Adding only the second write seems to make the box boot. > > Just to confirm that this also fixes the problem for two types of MSI dual opteron motherboards. (MSI K8D Master 2/3) Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386 HPET code
On Thursday 03 February 2005 02:05, john stultz wrote: > Hey Venkatesh, > I've been looking into a bug where i386 2.6 kernels do not boot on IBM > e325s if HPET_TIMER is enabled (hpet=disable works around the issue). > When running x86-64 kernels, the issue isn't seen. It appears that after FWIW The problem is not limited to the IBM e325. I cannot boot a HPET_TIMER enabled x86 kernel on any of the various Tyan and MSI opteron boards I have here without hpet=disable. x86_64 kernels work fine. Andrew Walrond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: brought up 4 cpu's
On Monday 17 January 2005 16:32, Mark Watts wrote: > > Thats your answer then. HyperThreading makes one cpu act as two (with a > suitable performance increase for some workloads) > Me thinks you should reread the original message ;) Andrew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
