All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: problem with Andrew's patch ext3
From: Vergoz Michael (SYSDOOR) @ 2002-12-15 15:15 UTC (permalink / raw)
  To: Octave, Andrew Morton; +Cc: linux-kernel, ext3-users
In-Reply-To: <20021215144050.GY12395@ovh.net>

Hi,

@@ -454,6 +456,7 @@ static struct super_operations ext3_sops
      delete_inode: ext3_delete_inode, /* BKL not held.  We take it */
      put_super: ext3_put_super,  /* BKL held */
      write_super: ext3_write_super, /* BKL held */
    + sync_fs: ext3_sync_fs,
      write_super_lockfs: ext3_write_super_lockfs, /* BKL not held. Take it
*/
      unlockfs: ext3_unlockfs,  /* BKL not held.  We take it */
      statfs:  ext3_statfs,  /* BKL held */
  @@ -1577,24 +1580,22 @@ int ext3_force_commit(struct super_block
  * This implicitly triggers the writebehind on sync().
  */

Someone can explain to me how he can put a sync_fs label into a
super_operation structure ?
The segfault is normal.

==> Linux/Documentation/filesystems/vfs.txt
177 struct super_operations {
178         void (*read_inode) (struct inode *);
179         void (*write_inode) (struct inode *, int);
180         void (*put_inode) (struct inode *);
181         void (*delete_inode) (struct inode *);
182         int (*notify_change) (struct dentry *, struct iattr *);
183         void (*put_super) (struct super_block *);
184         void (*write_super) (struct super_block *);
185         int (*statfs) (struct super_block *, struct statfs *, int);
186         int (*remount_fs) (struct super_block *, int *, char *);
187         void (*clear_inode) (struct inode *);
188 };

Well,

==> Linux/Documentation/filesystems/vfs.txt
327 struct file_operations {
328         loff_t (*llseek) (struct file *, loff_t, int);
329         ssize_t (*read) (struct file *, char *, size_t, loff_t *);
330         ssize_t (*write) (struct file *, const char *, size_t, loff_t
*);
331         int (*readdir) (struct file *, void *, filldir_t);
332         unsigned int (*poll) (struct file *, struct poll_table_struct
*);
333         int (*ioctl) (struct inode *, struct file *, unsigned int,
unsigned long);
334         int (*mmap) (struct file *, struct vm_area_struct *);
335         int (*open) (struct inode *, struct file *);
336         int (*release) (struct inode *, struct file *);
337         int (*fsync) (struct file *, struct dentry *);
338         int (*fasync) (struct file *, int);
339         int (*check_media_change) (kdev_t dev);
340         int (*revalidate) (kdev_t dev);
341         int (*lock) (struct file *, int, struct file_lock *);
342 };

You can only use a sync function into the file_operation structure.
Well the patch can't work.

Octave, anyway you don't need this patch :P
Everything is already implemented.

Or perhaps i'v lost something ?!

Regards,
Michael

============================================================================
===
===============================ORIGINAL
MESSAGE===============================
============================================================================
===
From: "Octave" <oles@ovh.net>
To: "Andrew Morton" <akpm@digeo.com>
Cc: <linux-kernel@vger.kernel.org>; <ext3-users@redhat.com>
Sent: Sunday, December 15, 2002 3:40 PM
Subject: problem with Andrew's patch ext3


> Hello Andrew,
>
> I patched 2.4.20 with your patch found out on
http://lwn.net/Articles/17447/
> and I have a big problem with:
> once server is booted on 2.4.20 with your patch, when I want to reboot
> with /sbin/reboot, server makes a Segmentation fault and it crashs.
> I tested it on 50-60 servers and it is the same problem. I tested kernel
> 2.4.20 without your patch: no problem.
>
> # uname -a
> Linux XXXXXX 2.4.20 #1 ven déc 13 17:21:23 CET 2002 i686 unknown
> # /sbin/reboot
>
> Broadcast message from root (pts/0) Sun Dec 15 14:26:03 2002...
>
> The system is going down for reboot NOW !!
> Segmentation fault
> #
> # dmRead from remote host XXXXXXXX: Connection reset by peer
>
> It is crashed.
>
> no logs :/
>
> Regards
> Octave
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>


^ permalink raw reply

* Re: Mirrored Display?
From: Michael Kaufmann @ 2002-12-15 17:03 UTC (permalink / raw)
  To: linux-fbdev-devel
In-Reply-To: <1039911076.1000.39.camel@localhost.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

On Saturday 14 December 2002 23:29, you wrote:
> On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote:
> > Hello,
> >
> > i would like to use a mono LCD with a framebuffer driver.
> >
> > I've modified existing drivers, and after a lot of work i now have a
> > clear picture on my display. Unfortunately, the complete picture is
> > mirrored. The Bootlogo is top/right instead of top/left and the ascii
> > output starts from right to left.
> >
> > Where is the right place to modify this behaviour?
> > I'm also looking for a possibility to rotate the picture.
> > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp.
> >
> > It would be very nice, if someone can guide me in the right direction.
>
> Are you using fbcon-cfb4.c to draw the characters?  Is the whole display
> mirrored, including individual characters?  If you run an fb-based app
> (like fbtest for instance), is the display also mirrored?

Yes,  i'm using fbon-cfb4.c. The console is on my display, i see the boot logo 
and the kernel messages in the display mirrored. I never used fbtest. By the 
way, where can i find fbtest? But i already startet nanox/microwindows on top 
of the fb, and the picture is also mirrored.  

> If it's the whole display, maybe your hardware supports mirroring (some
> hardware with video overlay need this to support YUV formats that are
> either vertically or horizontally mirrored).  Maybe it has something
> like that.  Otherwise, it will be difficult to correct this without
> rewriting practically everything.

No, i don't think so. It is a simple video controller. Nevertheless, i have 
just looked in the datasheet, and do not found such a feature. 

I don't think that this is a bug or something like this in the framebuffer. 
Because everthing works like i exect it, but i have to mirror the picture.
I have also measured with a scope all signals to the display, and the 
generated output looks like i expect it. The datastream starts with the first 
pixel (in the picture top/left) and continues with the second pixel (on the 
right of the first pixel) and so on.
But my display is mapping this datastream from the right to the left.
Please take a look on the attached picture, i think it explains the behaviour.
I can reproduce it without Linux with a simple monitor programm

At the moment i have two explanations:
1) I have a display witch must be accessed unusual, and the LINUX FB doesn't
    support this kind of access (not yet).
2) There is a hardware problem with the signals to the display (changed 
   signals like frame-pulse, and line-pulse, or something like this.

I don't think that it is a hardware problem, but i will check the connection 
again. Is there really no way in the framebuffer to mirror and/or rotate the 
picture data?
When i have to fix it in software, what kind of code do i have to rewrite? 

And, thank's for your reply!
 
Bye
Michael

[-- Attachment #2: FB_with_cfb4.png --]
[-- Type: image/png, Size: 32931 bytes --]

^ permalink raw reply

* Re: Loop Detection
From: Thomas Heinz @ 2002-12-15 15:04 UTC (permalink / raw)
  To: netfilter-devel, netfilter
In-Reply-To: <3DFC8933.9030607@hipac.org>

I wrote:
> The other definition which is tighter is:
> 
> Def2: If a packet is matched it traverses certain chains until a
>       terminal target is reached. Those chains form a path.
>       A loop exists if and only if there exists a packet whose path
>       through the chains contains some chain at least twice.

It must be stated that implementing a loop detection based on Def2
is not possible if general function based matches are used (like
netfilter does).

As we want nf-hipac to support function based matches we have in fact
no choice. Our loop detection will use Def1.




^ permalink raw reply

* Re: How to do -nostdinc?
From: Russell King @ 2002-12-15 15:11 UTC (permalink / raw)
  To: Keith Owens; +Cc: linux-kernel
In-Reply-To: <1357.1039954001@ocs3.intra.ocs.com.au>

On Sun, Dec 15, 2002 at 11:06:41PM +1100, Keith Owens wrote:
> The second format is simpler but there have been reports that it does
> not work with some versions of gcc.  I have been unable to find a
> definitive statement about which versions of gcc fail and whether the
> problem has been fixed.  Anybody care to provide a definitive
> statement?

When the problem appeared, it turned out to be an incorrectly configured
and/or built gcc installation.  (therefore, by definition,  not a kernel
problem.)

I believe the reporter of the problem subsequently fixed his compiler
installation.

I do, however, think we need to lobby the gcc people to get the
"depreciated" status of -iwithprefix reversed - it is a simple solution
to an otherwise disgusting amount of grep/awk/sed.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply

* [parisc-linux] HP 712/80, LASI Harmony Audio and 16-bit's
From: Jussi Sallinen @ 2002-12-15 14:59 UTC (permalink / raw)
  To: parisc-linux

I have HP 712/80, with LASI-chip - So soundcard is Harmony audio.
I just compiled kernel, PA Harmony audio driver included into kernel,
but without any kind of OSS sound modules. 
mikmod gives this: 
MikMod initialisation error : This driver supports uLaw output (8 bit mono, 8 kHz) only
Do i need to have OSS sound modules to be able to play 16bit stereo?
And if so, as modules or into kernel?
And what kind of OSS sound modules do i need :o

^ permalink raw reply

* Re: early_serial_setup is broken in the 2.5 series
From: Russell King @ 2002-12-15 15:07 UTC (permalink / raw)
  To: Brian Murphy; +Cc: linux-kernel
In-Reply-To: <3DFC921C.1030302@murphy.dk>

On Sun, Dec 15, 2002 at 03:30:52PM +0100, Brian Murphy wrote:
> As far as I can see early_serial_setup should be capable of being
> used to dynamically setup a serial port at any time in the boot
> process - this is certainly the case in the 2.4 kernels.
> 
> However if it is used during architecture initialization, for example,
> then the serial8250_reg uart driver has not been registered and
> initialized even though it is used in the early_serial_setup call.
> 
> What was wrong with the 2.4 implimentation where the registered
> serial ports were saved until the serial driver was ready to use them?

Its broken at present.  Last I heard, Khalid is working on a fix (since
he has the hardware to be able to test it, its sensible that I wait
until he has a fix.)

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply

* RE: Kernel for Pentium 4 hyperthreading?
From: Scott Robert Ladd @ 2002-12-15 15:07 UTC (permalink / raw)
  To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20021215134408.GA20335@suse.de>

Hi,

What I have is, indeed, a hyperthread-enabled Pentium 4. They aren't common;
I obtained this one direct from Intel through their Early Access Program.
The proof in the pudding is that both Windows XP and Linux 2.5.51 recognize
it as having "two" processors. The motherboard is an Intel Maryville2 (i850E
chipset), with an option to enable/disable HT on the first BIOS set-up
screen.

> Note that just because /proc/cpuinfo shows 'ht' does not mean you can
> use it in hyperthreaded mode. To do that, you also have to have >1
> sibling in the physical package. Non-Xeon type P4's don't have the
> extra sibling, so don't function as a hyperthreaded CPU.

Mine does, and so will any 3.06 or 3.6 GHz Pentium 4.

As it is, I'm past the worst of my troubles (knock on wood!) We'll see what
happens in the coming days the machine gets stressed. It looks stable with
2.5.51 -- so I guess I'm now a Linux kernel beta tester... ;)

Thanks much.

..Scott

--
Scott Robert Ladd
Coyote Gulch Productions,  http://www.coyotegulch.com
No ads -- just very free (and somewhat unusual) code.


^ permalink raw reply

* NFS oopses on smp servers
From: Peter Lojkin @ 2002-12-15 14:58 UTC (permalink / raw)
  To: nfs

Hello,

we keep getting nfs related oopses on our servers. we tried stock
2.4.19 and 2.4.20, ac kernels, aa kernels, with and without different
mix of trond and neilb patches.
the setup is:
 - intel 4-way smp general-purpose servers with debian 3.0
 - intel and sparc fileservers with solaris8
 - intel workstations with solaris7/8, redhat 7.2/7.3 and debian 3.0

the workload is mostly software development. developers are running
simultaneous builds on our genereal-purpose servers, accessing a
multitude of files exported from fileservers and workstations in
parallel. there's no nfsd running on workservrs. we use autofs with
no special mount options, so we get
rw,nosuid,v3,rsize=8192,wsize=8192,hard,intr,udp,lock
for linux exports and
rw,nosuid,v3,rsize=32768,wsize=32768,hard,intr,udp,lock
for solaris exports.

oopses are hard to track, they happen once or twice a week on random
server with nothing unusual in workload or logs prior to it. none of
our tests (high load, network disconnects, lost packets, etc.)
triggered the problem, so we can't provide a test case.

when we had nfs compiled as module (autoloaded) we had this oopses
(ksymoops from kern.log):
==================================================================
Nov 14 11:44:43 server kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Nov 14 11:44:43 server kernel: f8a4d441
Nov 14 11:44:43 server kernel: *pde = 00000000
Nov 14 11:44:43 server kernel: Oops: 0000
Nov 14 11:44:43 server kernel: CPU:    2
Nov 14 11:44:43 server kernel: EIP:    0010:[nfs:__insmod_nfs_S.text_L62016+21473/62016]    Not tainted
Nov 14 11:44:43 server kernel: EFLAGS: 00010246
Nov 14 11:44:43 server kernel: eax: 00000000   ebx: e7c48f80   ecx: e7c48f88   edx: e7c48f88
Nov 14 11:44:43 server kernel: esi: f1ac9e00   edi: f28b30fc   ebp: e7c48f80   esp: f1ac9de0
Nov 14 11:44:43 server kernel: ds: 0018   es: 0018   ss: 0018
Nov 14 11:44:43 server kernel: Process test1 (pid: 10621, stackpage=f1ac9000)
Nov 14 11:44:43 server kernel: Stack: 00000000 f8a4dabc e7c48f80 e7c48f80 ec8897c0 f28b30fc 00000000 f1ac8000 
Nov 14 11:44:43 server kernel:        f1ac9e00 f1ac9e00 f8a4d2e8 f28b30fc 00000000 ebb1a780 00000000 ebb1a938 
Nov 14 11:44:43 server kernel:        f8a5204e f8a507c8 00000000 ebb1a780 c418f168 00000000 00001000 c418f168 
Nov 14 11:44:43 server kernel: Call Trace:    [nfs:__insmod_nfs_S.text_L62016+23132/62016] [nfs:__insmod_nfs_S.text_L62016+21128/62016] [nfs:__insmod_nfs_S.text_L62016+40942/62016] [nfs:__insmod_nfs_S.text_L62016+34664/62016] [nfs:__insmod_nfs_S.text_L62016+32758/62016]
Nov 14 11:44:43 server kernel: Code: 8b 00 85 c0 7d 08 0f 0b a9 00 57 86 a5 f8 53 e8 0b ff ff ff 
Using defaults from ksymoops -t elf32-i386 -a i386


>>ebx; e7c48f80 <_end+2790d20c/386b428c>
>>ecx; e7c48f88 <_end+2790d214/386b428c>
>>edx; e7c48f88 <_end+2790d214/386b428c>
>>esi; f1ac9e00 <_end+3178e08c/386b428c>
>>edi; f28b30fc <_end+32577388/386b428c>
>>ebp; e7c48f80 <_end+2790d20c/386b428c>
>>esp; f1ac9de0 <_end+3178e06c/386b428c>

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 00                     mov    (%eax),%eax
Code;  00000002 Before first symbol
   2:   85 c0                     test   %eax,%eax
Code;  00000004 Before first symbol
   4:   7d 08                     jge    e <_EIP+0xe> 0000000e Before first symbol
Code;  00000006 Before first symbol
   6:   0f 0b                     ud2a   
Code;  00000008 Before first symbol
   8:   a9 00 57 86 a5            test   $0xa5865700,%eax
Code;  0000000d Before first symbol
   d:   f8                        clc    
Code;  0000000e Before first symbol
   e:   53                        push   %ebx
Code;  0000000f Before first symbol
   f:   e8 0b ff ff ff            call   ffffff1f <_EIP+0xffffff1f> ffffff1f <END_OF_CODE+75a5ba4/????>

Nov 15 18:58:33 server kernel: 3136MB HIGHMEM available.
Nov 15 18:58:34 server kernel: cpu: 0, clocks: 1002260, slice: 200452
Nov 15 18:58:34 server kernel: cpu: 1, clocks: 1002260, slice: 200452
Nov 15 18:58:34 server kernel: cpu: 2, clocks: 1002260, slice: 200452
Nov 15 18:58:34 server kernel: cpu: 3, clocks: 1002260, slice: 200452
Nov 15 18:58:34 server kernel:   Receiver lock-up bug exists -- enabling work-around.
Nov 15 18:58:34 server kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex
==================================================================



when we tried to compile nfs in kernel we start getting this oopes:
==================================================================
Dec 12 04:09:46 server kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Dec 12 04:09:46 server kernel: c018d381
Dec 12 04:09:46 server kernel: *pde = 00000000
Dec 12 04:09:46 server kernel: Oops: 0000 2.4.20-aa1 #1 SMP Thu Dec 5 12:01:04 GMT 2002
Dec 12 04:09:46 server kernel: CPU:    0
Dec 12 04:09:46 server kernel: EIP:    0010:[nfs_release_request+137/180]    Not tainted
Dec 12 04:09:46 server kernel: EFLAGS: 00010246
Dec 12 04:09:46 server kernel: eax: 00000000   ebx: dab0f240   ecx: dab0f248   edx: dab0f248
Dec 12 04:09:46 server kernel: esi: c68fb4fc   edi: c68fb4fc   ebp: dab0f240   esp: edfd9e4c
Dec 12 04:09:46 server kernel: ds: 0018   es: 0018   ss: 0018
Dec 12 04:09:46 server kernel: Process test2 (pid: 19656, stackpage=edfd9000)
Dec 12 04:09:46 server kernel: Stack: 00000000 c018da0c dab0f240 dab0f240 c82d3700 c68fb4fc 00000000 edfd8000 
Dec 12 04:09:46 server kernel:        edfd9e6c edfd9e6c c018d228 c68fb4fc 00000000 00000000 00000000 d83d4bb8 
Dec 12 04:09:46 server kernel:        c544f4d4 c01906c8 d3962c20 d83d4a00 c14ff2e0 00000000 00000200 d4cd3ce0 
Dec 12 04:09:46 server kernel: Call Trace:    [nfs_try_to_free_pages+268/288] [nfs_create_request+168/288] [nfs_update_request+544/828] [nfs_updatepage+165/516] [nfs_commit_write+63/108]
Dec 12 04:09:46 server kernel: Code: 8b 00 85 c0 7d 08 0f 0b a9 00 52 0c 2a c0 53 e8 0b ff ff ff 


>>ebx; dab0f240 <END_OF_CODE+13fecfbd/????>
>>ecx; dab0f248 <END_OF_CODE+13fecfc5/????>
>>edx; dab0f248 <END_OF_CODE+13fecfc5/????>
>>esi; c68fb4fc <_end+651f120/6723c24>
>>edi; c68fb4fc <_end+651f120/6723c24>
>>ebp; dab0f240 <END_OF_CODE+13fecfbd/????>
>>esp; edfd9e4c <END_OF_CODE+274b7bc9/????>

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 00                     mov    (%eax),%eax
Code;  00000002 Before first symbol
   2:   85 c0                     test   %eax,%eax
Code;  00000004 Before first symbol
   4:   7d 08                     jge    e <_EIP+0xe> 0000000e Before first symbol
Code;  00000006 Before first symbol
   6:   0f 0b                     ud2a   
Code;  00000008 Before first symbol
   8:   a9 00 52 0c 2a            test   $0x2a0c5200,%eax
Code;  0000000d Before first symbol
   d:   c0 53 e8 0b               rclb   $0xb,0xffffffe8(%ebx)
Code;  00000011 Before first symbol
  11:   ff                        (bad)  
Code;  00000012 Before first symbol
  12:   ff                        (bad)  
Code;  00000013 Before first symbol
  13:   ff 00                     incl   (%eax)

Dec 15 11:06:01 server kernel: 3136MB HIGHMEM available.
Dec 15 11:06:01 server kernel: cpu: 0, clocks: 1002300, slice: 200460
Dec 15 11:06:01 server kernel: cpu: 1, clocks: 1002300, slice: 200460
Dec 15 11:06:01 server kernel: cpu: 3, clocks: 1002300, slice: 200460
Dec 15 11:06:01 server kernel: cpu: 2, clocks: 1002300, slice: 200460
Dec 15 11:06:01 server kernel:   Receiver lock-up bug exists -- enabling work-around.
Dec 15 11:06:01 server kernel: e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex
==================================================================




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply

* Re: Re: kernel: matrox fb - missing files, doesn't compile
From: Antonino Daplas @ 2002-12-15 17:45 UTC (permalink / raw)
  To: Petr Vandrovec; +Cc: Ariel, Linux Fbdev development list
In-Reply-To: <20021214224426.GG1186@ppc.vc.cvut.cz>

On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> On Sun, Dec 15, 2002 at 05:30:43AM +0500, Antonino Daplas wrote:
> > On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > > Current interface just supports only cfb, and only very bad for my needs.
> > > And because of matroxfb supports also other modes (such as native text
> > > mode, or loading font into accelerator), bye-bye. For now I recommend you 
> > > either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> > > call fb_sync when using font width which is not multiple of 8, and that 
> > Can you explain why an fb_sync is needed for every character?
> 
> It is not needed after every character. But I thought that it will be called
> before we return to userspace... And I want to rely on fb_sync
> because of hardware setup to change fg_color and bg_color is very costly.
> 
I see. 

> In my tests I'm not able to get accelerated code running faster than
> at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
> two PCI writes could speed it a bit... It will not get on par, but better than
> nothing.
>  
> > > with fonts greater than 16*16 pixels (I believe that such fonts are still 
> > > supported...) it will corrupt memory...
> > 
> > I agree.  To be more specific, buffer overruns will occur if (xres *
> > fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
> > resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> > was removed).  For those concerned about this problem, you can try this
> > patch as a temporary measure until fbcon is fixed. It should not cause
> > to much slowdown:
> 
> But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
> if I remember fork() problems with allocating stack with order=1 correctly,
> it is not best idea under the sun. But using physically non-continuous
> area is probably even worse idea.
You mean the multiple buffering?  Sorry, I did not mean classic
multi-buffering, just a single buffer with size at least 2x that
required.  Then the buffer will just be "walked" by adjusting the buffer
offset.  Once the offset reaches the end of the buffer, we just call
fb_sync() then reset the offset to 0.

> 
> > For anyone concerned, this is a heads up:  The data in the pixmap must
> > be read completely by the hardware before exiting, otherwise font
> > corruption will occur.  If you think this will be a problem, the
> > function can be easily modified to do multiple buffering instead.
> 
> What if I'll decide to paint characters through busmastering? Then
> I need font data in buffers allocated by pci_alloc_consistent...
> In the past it was not a win to use busmastering, but now, when
> upper layers might prepare images much larger than 8x16, it may be 
> worth of rechecking that...

True, using kmalloc() to cache a good-sized pixmap is probably not the
best idea in all cases (in my case, it is best when the pixmap is in
graphics memory). I submitted a proposal before that allows more
flexibility: it will let the drivers decide on how it wants the buffers
allocated, the size of the buffer, specific alignment requirements, or
if it even actually needs one. Other driver-specific needs can probably
be added if necessary.

However, the change is a bit more invasive and complex and thus probably
did not hold very well with the maintainers.  So I submitted a patch
that is simpler but less flexible.  In my case, I have to do an extra
copy of the pixmap contents to graphics memory or directly to the
graphics pipeline depending on the size/alignment and proceed from
there.  It's not the best solution, but definitely better than doing one
imageblit/character.

I really don't have a say on any of this... I just submit patches, you
have to ask James or Geert about these.

Tony



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* ACK packets being dropped from yahoo
From: Jon Wyatt @ 2002-12-15 14:50 UTC (permalink / raw)
  To: netfilter


I have set up a firewall/gateway to handle all internet requests. 
Everything's looking great and I'm surfing the web quite happily from my 
Linux box. Then I try to run a search from yahoo (www.yahoo.com) and hit 
problems. Once I've entered a search string and hit the search button the 
browser just sits there an eventually times out.

It appears that yahoo is sending an ACK which I'm blocking (because it's not 
part of an initialisation), unless I've misunderstood the communication 
process.

Here's the rules where I set them:-
$IPTABLES -N bad_tcp_packets
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j LOG 
--log-prefix "New not syn:"
$IPTABLES -A bad_tcp_packets -p tcp ! --syn -m state --state NEW -j DROP



And here's the message I get when yahoo attempts to send the ACK.

New not syn:IN=ppp0 OUT= MAC= SRC=212.158.*.* DST=217.135.*.* LEN=52 
TOS=0x00 PREC=0x00 TTL=63 ID=27155 PROTO=TCP SPT=80 DPT=32782 WINDOW=8760 
RES=0x00 ACK RST URGP=0

What's going on there then?

Thanks.

jon.


Better than having your body rubbed vigorously with a cheese grater.
http://www.samuri.co.uk.


_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail



^ permalink raw reply

* Re: Anti-virus for Sendmail
From: Douglas J Hunley @ 2002-12-15 14:45 UTC (permalink / raw)
  To: Keith Morse; +Cc: Manoj Sharma, linux-admin
In-Reply-To: <Pine.LNX.4.44.0212142305340.30258-100000@antares.mpcu.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith Morse spewed electrons into the ether that resembled:
> On Fri, 13 Dec 2002, Douglas J Hunley wrote:
> > check out MIMEDefang (www.roaringpenguin.org/mimedefang). You can
> > configure it to for anti-virus (using a plethora of different scanners)
> > as well as anti-spam. I personally use it along with File::Scan and
> > ClamAV (for anti-virus) and SpamAssassin and Razor (for anti-spam). Works
> > awesome. You can see stats of what it catches at
> > http://hunley.homeip.net/smtp/spam/
>
> very nice Doug.  What are you using to generate the graphs?

a program called graphdefang. it comes with mimedefang.
- -- 
Douglas J Hunley (doug at hunley.homeip.net) - Linux User #174778
Admin: Linux StepByStep - http://www.linux-sxs.org
	and http://jobs.linux-sxs.org

panic("esp_handle: current_SC == penguin within interrupt!");
	2.2.16 /usr/src/linux/drivers/scsi/esp.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE9/JWHSrrWWknCnMIRAojiAKDMNhdy2+QH9lAoXojeNGMlvH46gACfUMcu
0U86WPlzP8QntDLsbBkZujE=
=RZef
-----END PGP SIGNATURE-----


^ permalink raw reply

* Re: Mirrored and shiftet fonts and logos
From: Michael Kaufmann @ 2002-12-15 16:33 UTC (permalink / raw)
  To: linux-fbdev-devel
In-Reply-To: <004501c2a3ab$015a5eb0$ee3c078b@nb1>

On Saturday 14 December 2002 18:53, André Stierenberg wrote:

> i´m using the framebuffer driver pxafb for my board using the pxa processor
> (Accelent IDP). I have a 4 bit monocrom display. when I run the framebuffer
> I have some problems. The text in the console it in some way shifted. The
> two parts of the font are switched. The first 4 pixels are at dest+2 and
> the last 4 pixels at dest+0. And both parts are mirrored. Now I have done
> the following in fbcon_cfb4.c in function fbcon_cfb4_putcs:
>
>   for (rows = fontheight(p), dest = dest0; rows-- ; dest += bytes) {
>       fb_writew((nibbletab_cfb4[rv(*cdat) >> 4] & eorx) ^ bgx, dest+2);
>       fb_writew((nibbletab_cfb4[rv(*cdat++) & 0xf] & eorx) ^ bgx, dest+0);
>   }
>
>
> The function rv will reverse the bit order (bit 1 is bit 8, bit 2 is bit
> 7.. etc.).
> And i have swaped the destination offset.
> Now the characters are printed correctly. And in the linux logo, the
> pinguin, something is also wrong. It seems the some pixels are mirrored too
> whereas other pixels are correct.
>
> What could this be and in what way can i fix the problem?

i had exactly the same problem, but i fixed it on the hardware side.
I changed the databus between the video controller and the LCD.
My display has a 4bit width databus, so i exchanged D0 with D3 and D1 with D2.
Now i have a clear picture (logo, font, ...).

Bye
Michael


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* problem with Andrew's patch ext3
From: Octave @ 2002-12-15 14:40 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, ext3-users

Hello Andrew,

I patched 2.4.20 with your patch found out on http://lwn.net/Articles/17447/
and I have a big problem with:
once server is booted on 2.4.20 with your patch, when I want to reboot
with /sbin/reboot, server makes a Segmentation fault and it crashs.
I tested it on 50-60 servers and it is the same problem. I tested kernel
2.4.20 without your patch: no problem.

# uname -a 
Linux XXXXXX 2.4.20 #1 ven déc 13 17:21:23 CET 2002 i686 unknown
# /sbin/reboot

Broadcast message from root (pts/0) Sun Dec 15 14:26:03 2002...

The system is going down for reboot NOW !!
Segmentation fault
# 
# dmRead from remote host XXXXXXXX: Connection reset by peer

It is crashed.

no logs :/

Regards
Octave



^ permalink raw reply

* [Linux-ia64] can linux support intel 870 chipset now?
From: wu qingbo @ 2002-12-15 14:25 UTC (permalink / raw)
  To: linux-ia64

Hi all, I am new to this maillist. I do not know if
linux can support intel 870 chipset now? If can,
where can I download the kernel for it? If someone
knows, please help me. Thanks in advance!

Qingbo





_________________________________________________________________
与联机的朋友进行交流,请使用 MSN Messenger: http://messenger.msn.com/cn 



^ permalink raw reply

* early_serial_setup is broken in the 2.5 series
From: Brian Murphy @ 2002-12-15 14:30 UTC (permalink / raw)
  To: linux-kernel

As far as I can see early_serial_setup should be capable of being
used to dynamically setup a serial port at any time in the boot
process - this is certainly the case in the 2.4 kernels.

However if it is used during architecture initialization, for example,
then the serial8250_reg uart driver has not been registered and
initialized even though it is used in the early_serial_setup call.

What was wrong with the 2.4 implimentation where the registered
serial ports were saved until the serial driver was ready to use them?

/Brian


^ permalink raw reply

* Re: Modem Identification
From: Frank Roberts - SOTL @ 2002-12-15 14:01 UTC (permalink / raw)
  To: Linux Newbie
In-Reply-To: <5.1.0.14.1.20021214171540.020e0cb0@celine>

Thanks Ray

Actually your response is very close to my intent.

What I am trying to do is identify which port I have a modem which may or may 
not be a win modem connected to. 
It was purchased as a full modem but I sincerely question that it is.

As far as using minicom that is another slight problem there in that for some 
reason I do not have minicom functioning correctly or something resulting in 
that being the next major issue to be resolved since I need minicom for 
another major reason.

Isn't there a command that allows one to "ping" a modem from the command line 
and which returns the modem identification annd type? I seem to recall that 
there is but I can not recall it but again this may be falty network memory.

Thanks
Frank

On Saturday 14 December 2002 20:19, Ray Olszewski wrote:
> At 08:14 PM 12/14/02 -0500, Frank Roberts - SOTL wrote:
> >Hi All
> >
> >Question:
> > >From the command line how does one determine which port a modem is on?
>
> It depends on exactly what you mean. I'm guessing that you intend to refer
> to a situation where you have 2 or more serial ports in a computer, and a
> modem conencted to one of them, but the ports are unlabeled so you dont
> know which one the modem is attached to. In that case, I would use a
> terminal app (such as minicom) to connect to each port, and see which port
> (actuall, its associated /dev/ttyS* entry) gets responses from the modem to
> typical AT commands.
>
> There are many more things you *might* mean, though. So if I've guessed
> wrong (and someone else does not guess right), please post a followup that
> asks the question in a different, more specific form.

-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

^ permalink raw reply

* Re: [LARTC] OSPF on the lartc howto
From: Petru Paler @ 2002-12-15 13:55 UTC (permalink / raw)
  To: lartc
In-Reply-To: <marc-lartc-103995840611934@msgid-missing>

On Sun, Dec 15, 2002 at 02:18:56PM +0100, Pedro Larroy wrote:
> As you can see, we are doing an effort to document setting up dynamic
> routing with zebra on the lartc howto. Although some issues are still
> unknown for me, for example making default routes replicate through OSPF.

They propagate like any other external route, but on the originating
router you need to do:

default-information originate [and optionally metric and metric type]

See this for more details:

http://www.cisco.com/warp/public/104/3.html#16.0


Petru
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

^ permalink raw reply

* Loop Detection
From: Thomas Heinz @ 2002-12-15 13:52 UTC (permalink / raw)
  To: netfilter-devel, netfilter

Hi

Michael Bellion and I are busy implementing user-defined chains support
for nf-hipac. When it comes to user-defined chains one has to
consider a way of detecting loops. Now, there are at least two
definitions of what a loop actually is. The netfilter one (Def1) and
and a "tighter" one (Def2).

Def1: The chains and their rules having another chain as target can
       be considered to define a directed graph. In this graph the
       chains are the nodes and for each chain X we have an edge
       (X, Y) if X contains a rule whose target is Y.
       Now, a loop exists if and only if the graph contains a cycle.

Example: Assume we have 3 chains: A, B, C. We only consider those
          rules within the chains that have another chain as target:
          A: Rule 1 -j B    B: Rule 2 -j A    C: Rule 4 -j B
             Rule 4 -j C
             Rule 5 -j C
             Rule 7 -j B
          The resulting graph is:
                     C
                   /\  \
                   /   \/
                  A <-> B
          This graph contains a cycle and therefore a loop according to
          Def1. If Rule 2 of Chain B is removed there is no loop.


The other definition which is tighter is:

Def2: If a packet is matched it traverses certain chains until a
       terminal target is reached. Those chains form a path.
       A loop exists if and only if there exists a packet whose path
       through the chains contains some chain at least twice.

Example: Assume we have 3 chains: INPUT, A, B.
          INPUT: (1) -s 1.0.0.0/16 -j A
                 (2) -s 2.0.0.0/16 -j B
          A:     (1) -s 1.0.0.0/24 -j B      B: (1) -s 2.0.0.0/24 -j A
                                                (2) -s 1.0.0.5 -j A
          Consider a packet with source ip 1.0.0.5 destined for the
          host running the firewall. The path is:
          INPUT, A, B, A, B, A, ...
          Clearly, there is a loop according to Def2. If rule (2) is
          removed from B there is no loop according to Def2 but there is
          still a loop according to Def1.

I hope the differences between the two definitions are clear. Obviously,
a loop according to Def2 always leads to a invalid ruleset but this is
not necessarily true for Def1.

Now, I'm asking you what definition is more beneficial to the users.
The question goes to both users and developers.

Clearly, a loop detection based on Def1 disallows some rulesets that are
indeed valid. On the other hand the question is whether such rulesets
really make sense. It is possible that Def1 is in fact more beneficial
to users in order to help them to design sane rulesets.

What is your opinion?


Regards,

Thomas



^ permalink raw reply

* Re: [PATCHSET] PC-9800 addtional for 2.5.50-ac1 (21/21)
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2002-12-15 13:59 UTC (permalink / raw)
  To: tomita; +Cc: linux-kernel, alan
In-Reply-To: <3DFC818F.80E3DC00@cinet.co.jp>

In article <3DFC818F.80E3DC00@cinet.co.jp> (at Sun, 15 Dec 2002 22:20:15 +0900), Osamu Tomita <tomita@cinet.co.jp> says:

> +#ifndef CONFIG_PC9800
>  			if (mpf->mpf_physptr)
>  				reserve_bootmem(mpf->mpf_physptr, PAGE_SIZE);
> +#else
> +			/*
> +			 * PC-9800's MPC table places on the very last of
> +			 * physical memory; so that simply reserving PAGE_SIZE
> +			 * from mpg->mpf_physptr yields BUG() in
> +			 * reserve_bootmem.
> +			 */
> +			if (mpf->mpf_physptr) {
> +				/*
> +				 * We cannot access to MPC table to compute
> +				 * table size yet, as only few megabytes from
> +				 * the bottom is mapped now.
> +				 */
> +				unsigned long size = PAGE_SIZE;
> +				unsigned long end = max_low_pfn * PAGE_SIZE;
> +				if (mpf->mpf_physptr + size > end)
> +					size = end - mpf->mpf_physptr;
> +				reserve_bootmem(mpf->mpf_physptr, size);
> +			}
> +#endif
> +

I'm not sure if we need this #ifdef; 
it doesn't seem that this #ifdef CONFIG_PC9800 part is harmful 
for others at all.

Well, if it is required, I prefer putting #ifdef..#endif inside the 
if-clause like this:

 			if (mpf->mpf_physptr) {
				unsigned long size = PAGE_SIZE;
#ifdef CONFIG_PC9800
				/*
				 * PC-9800's MPC table places on the very last of
				 * physical memory; so that simply reserving PAGE_SIZE
				 * from mpg->mpf_physptr yields BUG() in
				 * reserve_bootmem.
				 *
				 * We cannot access to MPC table to compute
				 * table size yet, as only few megabytes from
				 * the bottom is mapped now.
				 */
				unsigned long end = max_low_pfn * PAGE_SIZE;

				if (mpf->mpf_physptr + size > end)
					size = end - mpf->mpf_physptr;
#endif
				reserve_bootmem(mpf->mpf_physptr, size);
			}

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

^ permalink raw reply

* Re: aic7xxx woes in 2.5
From: Ishikawa @ 2002-12-15 13:48 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-scsi
In-Reply-To: <3DFC25A2.B497FA6@digeo.com>

Hi,

> I expect it supports everything.  It is a 1998-vintage Intel
> ad450nx server - these things cost $70,000 in their day.  It
> is built like a battleship.  See
> http://images.google.com/images?hl=en&lr=&ie=ISO-8859-1&q=ad450nx
> 
> But that error is a scsi bus error, not a PCI bus error.
> 
> > ...
> > > scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.5
> > >         <Adaptec 29160 Ultra160 SCSI adapter>
> > >         aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
> > >
> >
> > I noticed that you have many disks.
> > Are they in external enclosure?
> 
> They are internal.
> 
> > If not, is the power-supply in your
> > PC box spec'ed to supply enough power?
> 
> It has four power supplies and approximately 13 fans ;)

I agree that you have ample reason to suspect
driver problem, not hardware! :-)

I tried to locate my old posting, but somehow could not find
it in my local folder, but if I recall correctly
mine is certainly the PCI parity error which appeared
somewhere after the PCI_COMMAND_PARITY line in the
startup message below.

> scsi: host order: sym53c8xx:tmscsim
> sym53c8xx: at PCI bus 0, device 12, function 0
> sym53c8xx: setting PCI_COMMAND_PARITY...(fix-up)
> sym53c8xx: 53c895 detected with Tekram NVRAM
> sym53c895-0: rev 0x1 on pci bus 0 device 12 function 0 irq 10
> sym53c895-0: Tekram format NVRAM, ID 7, Fast-40, Parity Checking
> sym53c895-0: SCSI bus mode change from 80 to 80.
> scsi0 : sym53c8xx-1.7.3c-20010512
> sym53c895-0-<4,*>: FAST-20 WIDE SCSI 40.0 MB/s (50.0 ns, offset 15)
> sym53c895-0-<6,*>: FAST-20 WIDE SCSI 40.0 MBu (50.0 ns, offset 31)

Again, possibly the high(er) speed of I/O might
affect the electrical cable condition, but
given the hardware you have, I trust that
you have high-quality cable and terminator, and
so maybe someone who is familiar with the driver code
can help us here.


 


-- 
int main(void){int j=2002;/*(c)2002 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="h>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

^ permalink raw reply

* Re: Kernel with acpi hangs on compaq presario 1700
From: Jaap Hogenberg @ 2002-12-15 13:47 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <3DFB9888.2050803-hi6Y0CQ0nG0@public.gmane.org>

On Saturday 14 December 2002 21:46, Heiko Ettelbrueck wrote:
> Hi Jaap,
>
> if you don't want to use ACPI because of its IRQ routing, you could
> simply try adding "pci=noacpi" at the boot prompt (or into lilo.conf /
> grub's menu.lst) for your acpi kernel and try once again. I have a
> Compaq Evo N160 and had the same problem (hang during boot) before I
> tried the above kernel option.
>
> > I've tried kernel 2.4.20 with the acpi patches of 12052002 and 12122002
> > as well as a 2.5.51 with and without patch (12132002) and when I include
> > acpi support , the kernel will hang when probing the PCI bus.
> >

Yes , this works. But that presents me with another problem, upon
inserting pcmcia cards, I get the message "request IRQ:resource in use"
and  "resorce temporarily unavailable" messages.

Are there any other ways to set up the interrupt routing for this machine ?
Or should I try compiling all the drivers into the kernel instead of modules ?

Regards,
Jaap


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* Re: Compaq Evo N160: Fixed DSDT - battstat_applet works now
From: Andrew Kohlsmith @ 2002-12-15 13:46 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f; +Cc: Heiko Ettelbrueck
In-Reply-To: <3DFB6C25.4030805-hi6Y0CQ0nG0@public.gmane.org>

> Today I fixed the DSDT of my Compaq Evo N160 so that it knows the design
> capacity of its battery and allows tools like battstat_applet to
> calculate the percentage of remaining capacity.

Thank you so much.  I am currently using it.  I wonder if anything you changed 
also fixes the "polling battery state causes hard lockup" bug that myself and 
another N160 user are experiencing.

I take it you have also not had any trouble with LNKG having an incorrect 
initialization -- I have to boot with pci=noacpi or the system hangs after 
initializing the LNKF device.  I will see what I can do on this one, it was 
suggested that the ACPI entry for the LNKG device was not correct with regard 
to interrupts.

At any rate, thank you for your efforts on this.

Regards,
Andrew


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

^ permalink raw reply

* Union mounts
From: John Bradford @ 2002-12-15 14:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: junkio, andrew
In-Reply-To: <200212151258.gBFCwEDZ000672@darkstar.example.net>

> I disagree.  It should create it in directory d, even though that is
> the mount point.
> 
> A union mount should include files from another directory, but writes
> should go to the actual named directory.
> 
> Union mounts should be read only.
> 
> If read-write union mounts are needed, I don't think that we should
> implement them significantly differently to the way they work in BSD.

That wasn't very well explained, what I mean is this:

Example:

# cd /
# mkdir foo
# mount -o union /dev/hda2 /foo
# echo foobar > foo/bar
# umount /dev/hda2
# cat foo/bar
foobar

That's what I would consider to be the most useful way to implement
union mounts - the contents of /dev/hda2 would be accessible,
read-only, at /foo/bar, with files that already exist in /foo/bar
replacing files that would otherwise be visible from /dev/hda2.

Writes would go to the directory foo, which is just an ordinary
subdirectory of the root filesystem.

This is completely different to the mount_union behavior in BSD, where
writes go to the most recently added union mount.

However, it might be best to implement things the BSD way for
compatibility reasons, but I'm not sure how widespread the use of
mount_union is.  It's probably not widely used.

John.

^ permalink raw reply

* Re: How to do -nostdinc?
From: Marius Gedminas @ 2002-12-15 13:47 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <1357.1039954001@ocs3.intra.ocs.com.au>

On Sun, Dec 15, 2002 at 11:06:41PM +1100, Keith Owens wrote:
> There are two ways of setting the -nostdinc flag in the kernel Makefile :-
> 
> (1) -nostdinc $(shell $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')
> (2) -nostdinc -iwithprefix include
> 
> The first format breaks with non-English locales, however the fix is trivial.
> 
> (1a) -nostdinc $(shell LANG=C $(CC) -print-search-dirs | sed -ne 's/install: \(.*\)/-I \1include/gp')

Wouldn't LC_ALL=C be more reliable?

Marius Gedminas
-- 
No proper program contains an indication which as an operator-applied
occurrence identifies an operator-defining occurrence which as an
indication-applied occurrence identifies an indication-defining occurrence
different from the one identified by the given indication as an
indication-applied occurrence.
                -- ALGOL 68 Report

^ permalink raw reply

* Re: Kernel for Pentium 4 hyperthreading?
From: Dave Jones @ 2002-12-15 13:44 UTC (permalink / raw)
  To: Scott Robert Ladd; +Cc: linux-kernel
In-Reply-To: <FKEAJLBKJCGBDJJIPJLJMEGPDLAA.scott@coyotegulch.com>

On Sat, Dec 14, 2002 at 08:11:45PM -0500, Scott Robert Ladd wrote:

 > I've just received a new computer based on a 2.8 GHz Pentium 4 with
 > hyper-threading enabled. Yes, HT is enabled in the BIOS; yes, /proc/cpuinfo
 > shows the 'ht' flag; yes, I've compiled 2.4.20 (stock) with SMP and ACPI
 > enabled.
 > No, it doesn't work. cat /proc/cpuinfo reports a single CPU.

Note that just because /proc/cpuinfo shows 'ht' does not mean you can
use it in hyperthreaded mode. To do that, you also have to have >1
sibling in the physical package. Non-Xeon type P4's don't have the
extra sibling, so don't function as a hyperthreaded CPU.

 > Can 2.4.20 handle a Pentium 4 (not Xeon, mind you) with HT? What could I be
 > missing in my kernel build?

It's more a case of whats missing in your CPU package 8-)
 
		Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.