All of lore.kernel.org
 help / color / mirror / Atom feed
* rq_data_dir() in linux/blkdev.h is redundant
From: Xiaogeng (Shawn) Jin @ 2003-01-10  2:37 UTC (permalink / raw)
  To: linux-mtd, linuxppc-embedded

Hi,

When compiling linuxppc_2_4_devel (2.4.21-pre3) with the latest 
MTD/JFFS2 code, I had such error posted in a previous message.

ppc_8xx-gcc -D__KERNEL__ 
-I/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_
devel/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 
-fno-strict-aliasing
-fno-common -fomit-frame-pointer 
-I/u/xjin/2_4_devel/Software/Linux/MPC855/linux
ppc_2_4_devel/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2 
-Wno-uninitia
lized -mmultiple -mstring   -nostdinc -I 
/opt/eldk2.0/usr/lib/gcc-lib/ppc-linux/
2.95.4/include -DKBUILD_BASENAME=mtdblock_core  -c -o mtdblock-core.o 
mtdblock-c
ore.c
In file included from 
/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_devel
/include/linux/blk.h:4,
                  from mtdblock-core.c:18:
/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_devel/include/linux/blkdev.
h:147: parse error before `struct'

After traced down the problem, I found that it was caused by the 
definition of rq_data_dir() in linux/blkdev.h. The definition is as 
follows, which seems to be useless.

extern inline int rq_data_dir(struct request *rq)
{
	if (rq->cmd == READ)
		return READ;
	else if (rq->cmd == WRITE)
		return WRITE;
	else {
		BUG();
		return -1;
	}
}

Actually linux/mtd/compacmatmac.h defines rq_data_dir() as
   #define rq_data_dir(x) ((x)->cmd)
if the kernel version is older than 2.5.0.

-- 
Shawn Jin
RedSwitch Inc.

^ permalink raw reply

* Re: FYI: Etherleak
From: Andi Kleen @ 2003-01-10  2:12 UTC (permalink / raw)
  To: Yan-Fa Li, netdev
In-Reply-To: <D71BEAC27500D51199DF0002B328BA8D4FBF2B@ivexs1.intruvert.com>

On Thu, Jan 09, 2003 at 05:49:47PM -0800, Yan-Fa Li wrote:
> An interesting report into frame-padding information leakage violations in
> ethernet drivers.  The authors use linux drivers in their examples.
> 
> http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf

It's an old bug, it was discussed years ago on l-k.

Unfortunately the drivers weren't fixed at that time.

-Andi

^ permalink raw reply

* [RFC][PATCH] linux-2.5.55_x86-tsc-cleanup_A0
From: john stultz @ 2003-01-10  2:18 UTC (permalink / raw)
  To: lkml

All,
	This patch simply removes one more of the remaining CONFIG_X86_TSC
#ifdefs from get_cycles(). It is replaced w/ a if(cpu_has_tsc) switch,
so if you think this will cause a major performance impact, let me know
and I'll leave it alone. 

Otherwise I'll send it in for real on monday. 

thanks
-john

diff -Nru a/include/asm-i386/timex.h b/include/asm-i386/timex.h
--- a/include/asm-i386/timex.h	Thu Jan  9 17:17:17 2003
+++ b/include/asm-i386/timex.h	Thu Jan  9 17:17:17 2003
@@ -40,14 +40,10 @@
 
 static inline cycles_t get_cycles (void)
 {
-#ifndef CONFIG_X86_TSC
-	return 0;
-#else
-	unsigned long long ret;
-
-	rdtscll(ret);
+	unsigned long long ret = 0;
+	if(cpu_has_tsc)
+		rdtscll(ret);
 	return ret;
-#endif
 }
 
 extern unsigned long cpu_khz;




^ permalink raw reply

* RE: FYI: Etherleak
From: Yan-Fa Li @ 2003-01-10  2:14 UTC (permalink / raw)
  To: 'Andi Kleen', Yan-Fa Li, netdev

thought I'd seen it before.  Looks like a way for someone to generate
some consulting fees...

> -----Original Message-----
> From: Andi Kleen [mailto:ak@suse.de] 
> Sent: Thursday, January 09, 2003 6:13 PM
> To: Yan-Fa Li; netdev@oss.sgi.com
> Subject: Re: FYI: Etherleak
> 
> 
> On Thu, Jan 09, 2003 at 05:49:47PM -0800, Yan-Fa Li wrote:
> > An interesting report into frame-padding information leakage 
> > violations in ethernet drivers.  The authors use linux drivers in 
> > their examples.
> > 
> > 
> http://www.atstake.com/research/advisories/200> 3/atstake_etherleak_repo
> > rt.pdf
> 
> It's an old bug, it was discussed years ago on l-k.
> 
> Unfortunately the drivers weren't fixed at that time.
> 
> -Andi
> 


[[HTML alternate version deleted]]

^ permalink raw reply

* Re: Linux 2.4.21pre3-ac2
From: Alan Cox @ 2003-01-10  2:25 UTC (permalink / raw)
  To: Jean-Daniel Pauget; +Cc: Alan Cox, linux-kernel
In-Reply-To: <Pine.LNX.4.51.0301100021050.5467@mint>

>     I had some strange bug using 2.4.21pre3-ac2 :
>     at rebooting after a freeze (my machine freezes from time to time
>     whatever the kernel is, I'm still diging that point)

If its freezing with old kernels I'm somewhat less interested

>     this triggers two questions :
> 	o is the new piix-ide faulty ?

Not from reports I have except for two reports about MWDMA (old non UDMA)
which appear to be a chipset errata I need to deal with


^ permalink raw reply

* Re: Beginner questions about soundmodem and others
From: mvw @ 2003-01-10  2:17 UTC (permalink / raw)
  To: James Washer; +Cc: linux-hams
In-Reply-To: <20030109175607.0c94ab8f.washer@trlp.com>

james

I can answer one of your questions:

> 1)I'm confused by this whole AX.25 kernel thing... I had assumed that
> (most) TNCs handled the AX.25 protocol themselves. I understand that
> with a soundmodem, the linux system would have to do the AX.25, but what
> about if I use an off-the-shelf TNC ( kpc3 for example ). Does linux
> arrange to turn the AX.25 handling OFF in the TNC and do it in software?

Yes. The TNC is put into "KISS" ('Keep It Simple St...') mode, and becomes 
a dumb bitmodem, in affect. The kernel then handles everything. The gives 
you much more control, of course - otherwise you could not have your PC 
directing (and driected by) ax25.

Alternately, you could use a TNC and its inbuilt ax.25 plus PBBS, and no 
PC at all except to read messages people leave you. But then you'd miss 
out on all this fun. ;)

Michael VA3MVW







^ permalink raw reply

* Re: Kaaza 2 jammer.
From: Joel Newkirk @ 2003-01-10  2:18 UTC (permalink / raw)
  To: Darrell Dieringer, netfilter
In-Reply-To: <IMEDICLPAGAOCBLCCKLPGENAEKAA.netfilter@darrelldieringer.com>

On Thursday 09 January 2003 01:58 pm, Darrell Dieringer wrote:
> I've always wondered something about the string matching, but never
> having used it, I haven't researched it enough to know...
>
> Wouldn't netfilter also see the string "KazzaClient" in this email
> message?  I can imagine how that might cause problems if the string
> matching rules aren't well crafted.
>
> I see in the example posted by Tomasz Wrona that it only applies to
> tcp packets forwared from the internal interface, narrowing the focus
> qiute a bit.  But wouldn't that also block an email message having
> that string if sent from an internal machine?
>
> Of course, the sender of that message may have indeed sent it from a
> client on his internal network, and since I'm reading it, it must have
> worked as intended.
>
> I imagine placing a string matching rule, like the example, _after_
> rules which accept other legitimate traffic (like smtp) would work
> completely fine.
>
> Looking for eduction on the topic.

With any rules you're usually better off accepting 'normal' traffic and 
very precise matches before trying to catch others.  This helps prevent 
the situation you mentioned, and it also helps with large rulesets to 
get the common traffic through the firewall with minimal testing 
necessary. (IE if all 3000 client machines have port 80 access, but only 
some have 110 and 25, don't waste time and power matching IP's for http) 

There are surely counter-examples that will come to mind, but as a 
general rule putting the most important/common traffic and most specific 
matches earlier in the chain is better.  Especially with things like 
DNAT to a DMZ, it is easy to break a service by putting a general rule 
ahead of a specific one, and if there are many rules (or subchains of 
rules) the cause may not be obvious.  Also, with a default DROP policy 
and mostly ACCEPT rules, you have to be careful where you put a DROP 
rule in the sequence, unless it is a very specific match.

Finally, in the case of the string match, it takes quite a bit more to 
search for a string in the packet than to compare IPs in the header, so 
you DON'T want to have this rule early in the chain if speed is an 
issue.  (and it usually is, isn't it?  :^)  As an experiment, try a site 
that measures bandwidth, (like http://bandwidthplace.com/speedtest/ ) 
then insert a string match rule (with no target, so the packets all 
continue past it) first in the INPUT chain and try again. I don't have 
p-o-m added in, so I don't have string match available to me.  I'm 
curious though how much overhead this match actually incurs....

> Darrell Dieringer - Madison, WI

j



^ permalink raw reply

* 2.4.19 -- ac97_codec failure ALi 5451
From: Peter @ 2003-01-10  2:35 UTC (permalink / raw)
  To: linux-kernel; +Cc: Alan Cox
In-Reply-To: <Pine.LNX.4.44.0209111934280.11402-100000@greenie.frogspace.net>


Sound fails on 2.4.19 with ALi 5451 built-in audio:

        Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
		version 0.14.9d, 00:57:19 Jan  9 2003
        PCI: Enabling device 00:06.0 (0000 -> 0003)
        PCI: Assigned IRQ 10 for device 00:06.0
        trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
        ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
        ali: AC97 CODEC read timed out.
        last message repeated 127 times
        ali: AC97 CODEC write timed out.
        ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)

The trident driver was compiled in during this run. lspci --

00:06.0 Multimedia audio controller: Acer Laboratories Inc. [ALi] M5451 
PCI AC-Link Controller Audio Device (rev 02)

I've also tried Alsa, and the snd-ali5451 module loads under lengthy
protests from

alsa-kernel/pci/ali5451/ali5451.c:389 ali_codec_ready: codec not ready

The related modules also load and everything looks fine.

No sound in either case, trident or snd-ali5451. 

This is a matrix vpr 200A5 laptop running Debian's kernel 2.4.19-5.

I've seen other people have had similar problems; is this a problem with 
recent AC-97 codec revisions?

Cheers,
Peter



^ permalink raw reply

* Re: [Linux-fbdev-devel] Re: xxx_check_var
From: James Simmons @ 2003-01-10  2:29 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Benjamin Herrenschmidt, Paul Mackerras, Linux Kernel Development,
	Linux Frame Buffer Device Development
In-Reply-To: <Pine.GSO.4.21.0212221315451.11715-100000@vervain.sonytel.be>


> > > Yes, this wrong, and afaik, it's your original port to 2.5 that did that
> > > ;)
> > 
> > Yeap. The idea of check_var is to validate a mode. Note modedb uses just
> > check_var. It is okay to READ the values in your par. You shouldn't alter
> > the values in par.
> 
> Perhaps it makes sense to make the info parameter of fb_check_var() const to
> prevent this from happening?

Easy fix. I can whip up a quick patch for that.

^ permalink raw reply

* Re: UnitedLinux violating GPL?
From: John Jasen @ 2003-01-10  2:40 UTC (permalink / raw)
  To: Philip Dodd; +Cc: Jeff Garzik, linux-kernel
In-Reply-To: <3E1DFB8E.9050805@free.fr>

On Thu, 9 Jan 2003, Philip Dodd wrote:

> Jeff Garzik wrote:
> > Anybody know where the source rpm for UnitedLinux kernel is?
> > [to be distinguished from kernel-source rpm]

if they supply the kernel source rpm, how are they in violation? Since you 
can compile a kernel from the source rpm.

Then again, I shouldn't be feeding another open-source-uber-alles 
flamefest on lkml, should I?

-- 
-- John E. Jasen (jjasen@realityfailure.org)
-- User Error #2361: Please insert coffee and try again.



^ permalink raw reply

* Re: UnitedLinux violating GPL?
From: Jeff Garzik @ 2003-01-10  2:47 UTC (permalink / raw)
  To: John Jasen; +Cc: Philip Dodd, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301092139450.4282-100000@geisha.realityfailure.org>

On Thu, Jan 09, 2003 at 09:40:50PM -0500, John Jasen wrote:
> On Thu, 9 Jan 2003, Philip Dodd wrote:
> 
> > Jeff Garzik wrote:
> > > Anybody know where the source rpm for UnitedLinux kernel is?
> > > [to be distinguished from kernel-source rpm]
> 
> if they supply the kernel source rpm, how are they in violation? Since you 
> can compile a kernel from the source rpm.

Read the GPL :)  The source code "preferred form" is clearly not an
on-disk kernel tree with no information about the changes [patches]
that were processed in a specific sequence, to produce that end result.

Anyway, I would rather the thread die, since it is clear that they are
_not_ in violation of the GPL, and the source code is available.  :)

	Jeff




^ permalink raw reply

* Re: 2.4.19 -- ac97_codec failure ALi 5451
From: Alan Cox @ 2003-01-10  2:50 UTC (permalink / raw)
  To: Peter; +Cc: linux-kernel, Alan Cox
In-Reply-To: <Pine.LNX.4.44.0301090206290.30969-100000@greenie.frogspace.net>

>         Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, 
> 		version 0.14.9d, 00:57:19 Jan  9 2003
>         PCI: Enabling device 00:06.0 (0000 -> 0003)
>         PCI: Assigned IRQ 10 for device 00:06.0
>         trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
>         ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)

So far so good.

>         ali: AC97 CODEC read timed out.
>         last message repeated 127 times
>         ali: AC97 CODEC write timed out.
>         ac97_codec: AC97  codec, id: 0x0000:0x0000 (Unknown)

Something lost the codec. Could be power management - was the laptop
suspended before it went funny ?

Alan

^ permalink raw reply

* [PATCH] Fix atyfb
From: Paul Mackerras @ 2003-01-10  2:48 UTC (permalink / raw)
  To: James Simmons; +Cc: linux-kernel

Here is a patch which fixes a couple of problems in atyfb.

1. It was modifying the par structure in the check_var routine and not
   reading info->var in the set_par routine.

2. It was relying on info->var.accel_flags and consequently we were
   getting a situation where it was trying to use the drawing engine
   without having initialized it.  This caused my G3 powerbook to hang
   on boot when the console text got to the bottom of the screen and
   it tried to scroll.  I have added an accel_flags field to the par
   structure so that the driver can control when it starts and stops
   using acceleration.  I also added code to the accelerated drawing
   routines so that they will fall back to the cfb routines if
   acceleration is disabled.

3. It was accessing the pseudo_palette as 16-bit quantities in 15/16
   bpp mode rather than as u32.

The driver generally is badly formatted, particularly in the
atyfb_init routine, which is very long and should be split up.  James,
would you accept a patch to split up atyfb_init and fix the
formatting?

Paul.

diff -urN linux-2.5/drivers/video/aty/atyfb.h pmac-2.5/drivers/video/aty/atyfb.h
--- linux-2.5/drivers/video/aty/atyfb.h	2002-11-24 06:49:51.000000000 +1100
+++ pmac-2.5/drivers/video/aty/atyfb.h	2003-01-01 22:15:45.000000000 +1100
@@ -79,6 +79,7 @@
 	u8 ram_type;
 	u8 mem_refresh_rate;
 	u8 blitter_may_be_busy;
+	u32 accel_flags;
 #ifdef __sparc__
 	struct pci_mmap_map *mmap_map;
 	u8 mmaped;
diff -urN linux-2.5/drivers/video/aty/atyfb_base.c pmac-2.5/drivers/video/aty/atyfb_base.c
--- linux-2.5/drivers/video/aty/atyfb_base.c	2002-12-22 09:07:14.000000000 +1100
+++ pmac-2.5/drivers/video/aty/atyfb_base.c	2003-01-10 13:41:01.000000000 +1100
@@ -173,9 +173,6 @@
 			   struct crtc *crtc);
 static int aty_crtc_to_var(const struct crtc *crtc,
 			   struct fb_var_screeninfo *var);
-static int atyfb_encode_var(struct fb_var_screeninfo *var,
-			    const struct atyfb_par *par,
-			    const struct fb_info *info);
 static void set_off_pitch(struct atyfb_par *par,
 			  const struct fb_info *info);
 #ifdef CONFIG_PPC
@@ -772,11 +769,17 @@
 static int atyfb_set_par(struct fb_info *info)
 {
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
-	int accelmode;
+	struct fb_var_screeninfo *var = &info->var;
 	u8 tmp;
 	u32 i;
+	int err;
 
-	accelmode = info->var.accel_flags;	/* hack */
+	if ((err = aty_var_to_crtc(info, var, &par->crtc)) ||
+	    (err = par->pll_ops->var_to_pll(info, var->pixclock,
+					var->bits_per_pixel, &par->pll)))
+		return err;
+
+	par->accel_flags = var->accel_flags;	/* hack */
 
 	if (par->blitter_may_be_busy)
 		wait_for_idle(par);
@@ -786,13 +789,14 @@
 	/* better call aty_StrobeClock ?? */
 	aty_st_8(CLOCK_CNTL + par->clk_wr_offset, CLOCK_STROBE, par);
 
-	par->dac_ops->set_dac(info, &par->pll, info->var.bits_per_pixel, accelmode);
+	par->dac_ops->set_dac(info, &par->pll, var->bits_per_pixel,
+			      par->accel_flags);
 	par->pll_ops->set_pll(info, &par->pll);
 
 	if (!M64_HAS(INTEGRATED)) {
 		/* Don't forget MEM_CNTL */
 		i = aty_ld_le32(MEM_CNTL, par) & 0xf0ffffff;
-		switch (info->var.bits_per_pixel) {
+		switch (var->bits_per_pixel) {
 		case 8:
 			i |= 0x02000000;
 			break;
@@ -808,7 +812,7 @@
 		i = aty_ld_le32(MEM_CNTL, par) & 0xf00fffff;
 		if (!M64_HAS(MAGIC_POSTDIV))
 			i |= par->mem_refresh_rate << 20;
-		switch (info->var.bits_per_pixel) {
+		switch (var->bits_per_pixel) {
 		case 8:
 		case 24:
 			i |= 0x00000000;
@@ -841,20 +845,20 @@
 	}
 	aty_st_8(DAC_MASK, 0xff, par);
 
-	info->fix.line_length = info->var.xres_virtual * info->var.bits_per_pixel/8;
-	info->fix.visual = info->var.bits_per_pixel <= 8 ? FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
+	info->fix.line_length = var->xres_virtual * var->bits_per_pixel/8;
+	info->fix.visual = var->bits_per_pixel <= 8 ?
+		FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
 
 	/* Initialize the graphics engine */
-	if (info->var.accel_flags & FB_ACCELF_TEXT)
+	if (par->accel_flags & FB_ACCELF_TEXT)
 		aty_init_engine(par, info);
 
 #ifdef CONFIG_BOOTX_TEXT
 	btext_update_display(info->fix.smem_start,
-			     (((par->crtc.h_tot_disp >> 16) & 0xff) +
-			      1) * 8,
+			     (((par->crtc.h_tot_disp >> 16) & 0xff) + 1) * 8,
 			     ((par->crtc.v_tot_disp >> 16) & 0x7ff) + 1,
-			     info->var.bits_per_pixel,
-			     par->crtc.vxres * info->var.bits_per_pixel / 8);
+			     var->bits_per_pixel,
+			     par->crtc.vxres * var->bits_per_pixel / 8);
 #endif				/* CONFIG_BOOTX_TEXT */
 	return 0;
 }
@@ -863,41 +867,24 @@
 			   struct fb_info *info)
 {
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
+	struct crtc crtc;
+	union aty_pll pll;
 	int err;
 
-	if ((err = aty_var_to_crtc(info, var, &par->crtc)) ||
-	    (err =
-	     par->pll_ops->var_to_pll(info, var->pixclock, var->bits_per_pixel,
-				       &par->pll)))
+	if ((err = aty_var_to_crtc(info, var, &crtc)) ||
+	    (err = par->pll_ops->var_to_pll(info, var->pixclock,
+					var->bits_per_pixel, &pll)))
 		return err;
 
-#if 0				/* fbmon is not done. uncomment for 2.5.x -brad */
+#if 0	/* fbmon is not done. uncomment for 2.5.x -brad */
 	if (!fbmon_valid_timings(var->pixclock, htotal, vtotal, info))
 		return -EINVAL;
 #endif
-	atyfb_encode_var(var, par, info);
-	return 0;
-}
-
-static int atyfb_encode_var(struct fb_var_screeninfo *var,
-			    const struct atyfb_par *par,
-			    const struct fb_info *info)
-{
-	int err;
-
-	memset(var, 0, sizeof(struct fb_var_screeninfo));
-
-	if ((err = aty_crtc_to_var(&par->crtc, var)))
-		return err;
-	var->pixclock = par->pll_ops->pll_to_var(info, &par->pll);
-
-	var->height = -1;
-	var->width = -1;
+	aty_crtc_to_var(&crtc, var);
+	var->pixclock = par->pll_ops->pll_to_var(info, &pll);
 	return 0;
 }
 
-
-
 static void set_off_pitch(struct atyfb_par *par,
 			  const struct fb_info *info)
 {
@@ -1410,7 +1397,7 @@
 	for (info = first_display; info != NULL; info = par->next) {
 		int nb;
 
-		par = (struct atyfb_par *) info->fb.par;
+		par = (struct atyfb_par *) info->par;
 		nb = info->var.yres * info->fix.line_length;
 
 		switch (when) {
@@ -1429,7 +1416,7 @@
 			if (par->blitter_may_be_busy)
 				wait_for_idle(par);
 			/* Stop accel engine (stop bus mastering) */
-			if (info->accel_flags & FB_ACCELF_TEXT)
+			if (par->accel_flags & FB_ACCELF_TEXT)
 				aty_reset_engine(par);
 
 			/* Backup fb content */
@@ -2306,9 +2293,7 @@
 
 #ifdef CONFIG_PMAC_PBOOK
 			if (first_display == NULL)
-				pmu_register_sleep_notifier
-				    (&aty_sleep_notifier);
-			/* FIXME info->next = first_display; */
+				pmu_register_sleep_notifier(&aty_sleep_notifier);
 			default_par->next = first_display;
 #endif
 		}
@@ -2346,7 +2331,7 @@
 		info->fix.smem_start = info->screen_base;	/* Fake! */
 		default_par->ati_regbase = (unsigned long)ioremap(phys_guiregbase[m64_num],
 							  0x10000) + 0xFC00ul;
-		info->fix.mmio_start = par->ati_regbase; /* Fake! */
+		info->fix.mmio_start = default_par->ati_regbase; /* Fake! */
 
 		aty_st_le32(CLOCK_CNTL, 0x12345678, default_par);
 		clock_r = aty_ld_le32(CLOCK_CNTL, default_par);
@@ -2544,6 +2529,7 @@
 {
 	struct atyfb_par *par = (struct atyfb_par *) info->par;
 	int i, scale;
+	u32 *pal = info->pseudo_palette;
 
 	if (regno > 255)
 		return 1;
@@ -2570,17 +2556,14 @@
 	if (regno < 16)
 		switch (info->var.bits_per_pixel) {
 		case 16:
-			((u16 *) (info->pseudo_palette))[regno] =
-			    (regno << 10) | (regno << 5) | regno;
+			pal[regno] = (regno << 10) | (regno << 5) | regno;
 			break;
 		case 24:
-			((u32 *) (info->pseudo_palette))[regno] =
-			    (regno << 16) | (regno << 8) | regno;
+			pal[regno] = (regno << 16) | (regno << 8) | regno;
 			break;
 		case 32:
 			i = (regno << 8) | regno;
-			((u32 *) (info->pseudo_palette))[regno] =
-			    (i << 16) | i;
+			pal[regno] = (i << 16) | i;
 			break;
 		}
 	return 0;
diff -urN linux-2.5/drivers/video/aty/mach64_accel.c pmac-2.5/drivers/video/aty/mach64_accel.c
--- linux-2.5/drivers/video/aty/mach64_accel.c	2002-08-08 07:29:36.000000000 +1000
+++ pmac-2.5/drivers/video/aty/mach64_accel.c	2003-01-01 22:36:44.000000000 +1100
@@ -179,6 +179,12 @@
 
 	if (!area->width || !area->height)
 		return;
+	if (!par->accel_flags) {
+		if (par->blitter_may_be_busy)
+			wait_for_idle(par);
+		cfb_copyarea(info, area);
+		return;
+	}
 
 	pitch_value = info->var.xres_virtual;
 	if (info->var.bits_per_pixel == 24) {
@@ -216,6 +222,12 @@
 
 	if (!rect->width || !rect->height)
 		return;
+	if (!par->accel_flags) {
+		if (par->blitter_may_be_busy)
+			wait_for_idle(par);
+		cfb_fillrect(info, rect);
+		return;
+	}
 
 	rect->color |= (rect->color << 8);
 	rect->color |= (rect->color << 16);

^ permalink raw reply

* Re: NFS as a Cluster File System.
From: Alan Cox @ 2003-01-10  3:34 UTC (permalink / raw)
  To: Lorn Kay; +Cc: lmb, nfs, linux-ha
In-Reply-To: <F43H06Ym8Es5FEnoLH80000317f@hotmail.com>

On Thu, 2003-01-09 at 23:13, Lorn Kay wrote:
> Sorry, still confused about what a "CFS" really is. In "In Search Of 
> Clusters" Gregory Pfister takes the position that a distributed file system 
> is what he calls a valid "single system image" file system, what I would 
> take to mean a cluster file system (though he doesn't use those words).
> 
> I guess you are saying a clustered file system isn't necessarily supporting 
> a cluster of application servers but is itself stored on a cluster. (A 
> single server can be the only server using a cluster file system.) ?

It seems to mean about three different things 

1.   "A clusterwide view of the file store implemented by any unspecified
means"  - ie an application view point.

2.   "A filesystem which supports operation of a cluster"

3.   "A filesystem with multiple systems accessing a single shared 
file system on shared storage"

Meaning #3 can be really confusing because a 'cluster file system' in that
sense is actually exactly what you don't want for many cluster setups,
especially those with little active shared storage'

[For example if you are doing database failover you can do I/O fencing
 and mount/umount of a more normal fs]




-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

^ permalink raw reply

* Re: [Linux-fbdev-devel] Re: rotation.
From: Alan Cox @ 2003-01-10  3:45 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Linux Kernel Mailing List
In-Reply-To: <avktge$22o$1@penguin.transmeta.com>

On Thu, 2003-01-09 at 22:35, Linus Torvalds wrote:
> UTF8 delete behaviour should be pretty trivial to add.  It's liketly to
> be more involved than simply adding a
> 
> 	/* multi-char UTF8 thing? Continue until we hit the first one */
> 	if (tty->utf8 && (c & 0x80) && !(c & 0x40))
> 		continue;
> 
> to the loop in n_tty.c: eraser(), but it might not be _much_ more than
> that. 

That should do the delete case yes. The other cases are more interestingly horrible
and I hope don't need solving (suppose you want your intr character to be the 
chinese symbol for 'stop' ...)

Its on the todo list, and someone sent me a test patch for 3-4 byte utf8 input


^ permalink raw reply

* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Alan Cox @ 2003-01-10  3:49 UTC (permalink / raw)
  To: Benjamin Herrenschmidt
  Cc: Linus Torvalds, Ivan Kokshaysky, Grant Grundler, Paul Mackerras,
	Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <1042151210.523.34.camel@zion.wanadoo.fr>

On Thu, 2003-01-09 at 22:26, Benjamin Herrenschmidt wrote:
> I completely agree. For example, I have already a bunch of cases where I
> have to explicitely "hide" the host bridge from linux PCI layer as those
> have BARs that mustn't be touched. A typical example is the 405gp
> internal PCI host. It has a BAR that represents the view of system RAM
> from bus mastering PCI devices. Of course, the kernel doesn't understand
> that and tries to remap it away from 0 where it belongs ;)

Ditto The X-box people would like to explicitly hide a pile of apparently ghost
devices that hang the bus solid if you read them.

^ permalink raw reply

* ISO-9660 Rock Ridge gives different links different inums
From: Peter Chubb @ 2003-01-10  3:08 UTC (permalink / raw)
  To: eric; +Cc: linux-kernel


In linux 2.5.54, multiple links to the same file on a rock-ridge CD
have different inode numbers.  This confuses cpio, tar and cp -ra
because the multiple links are each copied separately as a single file.

It'll probably also confuse NFS, but I haven't tried that.

Example from the knoppix CD:

$ ls -il gunzip gzip uncompress zcat
1896278 -rwxr-xr-x    4 root     root        49256 Oct 10 01:31 gunzip
1896564 -rwxr-xr-x    4 root     root        49256 Oct 10 01:31 gzip
1902292 -rwxr-xr-x    4 root     root        49256 Oct 10 01:31 uncompress
1902856 -rwxr-xr-x    4 root     root        49256 Oct 10 01:31 zcat

(For comparison, here's what I see on XFS:
100663485 -rwxr-xr-x    4 root     root        49288 Nov  7 11:37 gunzip
100663485 -rwxr-xr-x    4 root     root        49288 Nov  7 11:37 gzip
100663485 -rwxr-xr-x    4 root     root        49288 Nov  7 11:37 uncompress
100663485 -rwxr-xr-x    4 root     root        49288 Nov  7 11:37 zcat
)


Currently the inode number appears to be the offset in bytes from the start of
the file system to the iso directory entry.  Files with multiple
directory entries (i.e., links) therefore have different inums.

I don't know enough about the ISO9660 standard to be sure what's best
to do about this.

--
Dr Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

^ permalink raw reply

* [LARTC] I can't add my code in linux-2.4.7-10/net/sched/sch_wfq.c,
From: Sittichai Amornrojvorawut @ 2003-01-10  3:06 UTC (permalink / raw)
  To: lartc

I have a trouble.I can't add my code in linux-2.4.7-10/net/sched/sch_wfq.c,I 
edit Config.in,Makefile,sch_api.c and edit 
linux-2.4.7-10/include/linux/pkt_sched.h already after that I do make 
menuconfig(select my code as build-in(*) or as modules);make dep;make 
bzImage(and edit liloconf);make modules;make modules_install;reboot(select 
new kernel); it does not have any error occur during making(And I see object 
file appear after make it),then I built tc with diffserv support,set 
TC_CONFIG_DIFFSERV=y,copy code q_wfq.c,tc_wfq.c,tc_wfq.h into tc 
directory&edit Makefile in same directory and run make on 
iproute2(iproute2-2.4.7-now-ss020116-try.tar.gz) directory.It's not any 
problem.(I have ever run make on tc directory but have an error occur(the 
error is tc.c : SNAPSHOT,h& utils.h : no such file or directory,I solve this 
problem by copy any header file in iproute2/include(But I don’t copy include 
file in include-glibc directory) to /usr/include/ ,but it does not work and 
have error again.The error is /usr/include/rt_names.h : parse error before 
‘*’)).Finally I use tc command(using my queueing discipline) but tc unknow 
my qdisc.I sure that my code absolutely correct.What's happen?Can you tell 
me?How can I do?I need&must solve my problem for the early time!Please tell 
me step by step because I'm a beginner.HELP ME!Thanks you very much.





_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* 
http://join.msn.com/?pageþatures/virus

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

^ permalink raw reply

* ACPI problems on Athlon MP system
From: Martin Siegert @ 2003-01-10  3:07 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Hi,

I am not sure whether this is the correct place to ask this question,
but hopefully you can point me in the right direction.

Here is the problem:
I am trying to get the "poweroff" command working on an Athlon MP
(Tyan S2462) system (linux-2.4.21-pre2; otherwise RedHat 7.3).

The machine has ACPI enabled in the bios. When I compile the kernel
with ACPI disabled, the poweroff command shuts down the system, but
does not shut off the power (it acts exactly like the halt command).
In order to shutoff the machine I must press the power switch.

When I compile the kernel with ACPI enabled the situation is worse:
the halt and poweroff commands still work in exactly the same way
(shutdown the system), but now I cannot switch off the machine
anymore: pressing the power switch has absolutely no effect
(regardless of how long I hold the switch). The only way to
switch off the machine is to either pull the power cord or to
press the reset button on then the power switch (which will then
switch off the machine when it reboots).

What am I doing wrong? Am I missing some kernel switches, options?
Do I need additional software?

Any help or suggestions, hints are appreciated!

Thanks in advance,

Martin

========================================================================
Martin Siegert
Academic Computing Services                        phone: (604) 291-4691
Simon Fraser University                            fax:   (604) 291-4242
Burnaby, British Columbia                          email: siegert-z1KUqvL5UUQ@public.gmane.org
Canada  V5A 1S6
========================================================================


-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: Brian Tinsley @ 2003-01-10  3:17 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: linux-kernel

 >>>At some point in the past, I wrote:
 >>> Either pollwait tables (invisible in 2.4 and 2.5), kernel stacks of
 >>> threads (which don't get pae_pgd's and are hence invisible in 2.4
 >>> and 2.5), or pagecache, with a much higher likelihood of pagecache.

 >>On Thu, Jan 09, 2003 at 06:44:10PM -0600, Brian Tinsley wrote:
 >> The "kernel stacks of threads" may have some bearing on my incarnation
 >> of this problem. We have several heavily threaded Java applications
 >> running at the time the live-locks occur. At our most problematic site,
 >> one application has a bug that can cause hundreds of timer threads (I
 >> mean like 800 or so!) to be "accidentally" created. This site is
 >> scheduled for an upgrade either tonight or tomorrow, so I will leave the
 >> system as it is and see if I can still cause the live-lock to manifest
 >> itself after the upgrade.

 >There is no extant implementation of paged stacks yet.

For the most part, this is probably a boundary condition, right? Anyone 
that intentionally has 800+ threads in a single application probably 
needs to reevaluate their design :)

 >I'm working on a different problem (mem_map on 64GB on 2.5.x). I probably
 > won't have time to implement it in the near future, I probably won't 
be doing it
 >vs. 2.4.x, and I won't have to if someone else does it first.

Is that a hint to someone in particular?



-- 

-[========================]-
-[      Brian Tinsley     ]-
-[ Chief Systems Engineer ]-
-[        Emageon         ]-
-[========================]-



^ permalink raw reply

* Re: "Mother" == "computer-illiterate"
From: Val Henson @ 2003-01-10  3:20 UTC (permalink / raw)
  To: jdow; +Cc: Chris Adams, linux-kernel
In-Reply-To: <04a701c2b84e$2bd7ad70$1125a8c0@wizardess.wiz>

On Thu, Jan 09, 2003 at 06:15:39PM -0800, jdow wrote:
> From: "Chris Adams" <cmadams@hiwaay.net>
> 
> > Once upon a time, Alan Cox  <alan@lxorguk.ukuu.org.uk> said:
> > >and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
> > >who know what her networking related patent is on)
> > 
> > That's HEDLEY!  Oh, but he doesn't have any patents.
> 
> No, it's Hedy Lamarr and she invented frequency hopping spread spectrum
> with George Anthiel. I worked on one of the first practical implementations
> of the concept back in the early 70s. Somehow it seems appropriate.

Chris was making a joke which you won't get unless you watch "Blazing
Saddles" (something I've never gotten around to myself).  Hedley
Lamarr was a character in the movie who, indeed, doesn't have any
patents.

Neat to hear you got to work on such an interesting project!

-VAL

^ permalink raw reply

* Re: ISO-9660 Rock Ridge gives different links different inums
From: Andrew McGregor @ 2003-01-10  3:23 UTC (permalink / raw)
  To: Peter Chubb, eric; +Cc: linux-kernel
In-Reply-To: <15902.14667.489252.346007@wombat.chubb.wattle.id.au>



--On Friday, January 10, 2003 14:08:59 +1100 Peter Chubb 
<peter@chubb.wattle.id.au> wrote:

>
> In linux 2.5.54, multiple links to the same file on a rock-ridge CD
> have different inode numbers.  This confuses cpio, tar and cp -ra
> because the multiple links are each copied separately as a single file.
>
> It'll probably also confuse NFS, but I haven't tried that.

Shouldn't do, but it will probably make the buffer cache on the server less 
effective.

> Currently the inode number appears to be the offset in bytes from the
> start of the file system to the iso directory entry.  Files with multiple
> directory entries (i.e., links) therefore have different inums.
>
> I don't know enough about the ISO9660 standard to be sure what's best
> to do about this.

Change it to be the offset to the data area, which should be the same for 
all of them?

>
> --
> Dr Peter Chubb				    peterc@gelato.unsw.edu.au
> You are lost in a maze of BitKeeper repositories, all almost the same.


^ permalink raw reply

* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: William Lee Irwin III @ 2003-01-10  3:29 UTC (permalink / raw)
  To: Brian Tinsley; +Cc: linux-kernel
In-Reply-To: <3E1E3B64.5040803@emageon.com>

At some point in the past, I wrote:
>> There is no extant implementation of paged stacks yet.

On Thu, Jan 09, 2003 at 09:17:56PM -0600, Brian Tinsley wrote:
> For the most part, this is probably a boundary condition, right? Anyone 
> that intentionally has 800+ threads in a single application probably 
> needs to reevaluate their design :)

IMHO multiprogramming is as valid a use for memory as any other. Or
even otherwise, it's not something I care to get in design debates
about, it's just how the things are used.

The only trouble is support for what you're doing is unimplemented.


At some point in the past, I wrote:
>> I'm working on a different problem (mem_map on 64GB on 2.5.x). I
>> probably won't have time to implement it in the near future, I
>> probably won't be doing it vs. 2.4.x, and I won't have to if someone
>> else does it first.

On Thu, Jan 09, 2003 at 09:17:56PM -0600, Brian Tinsley wrote:
> Is that a hint to someone in particular?

Only you, if anyone. My intentions and patchwriting efforts on the 64GB
and highmem multiprogramming fronts are long since public, and publicly
stated to be targeted at 2.7. Since there isn't a 2.7 yet, 2.5-CURRENT
must suffice until there is.


Bill

^ permalink raw reply

* problem with ./runme in --batch mode. -- current p-o-m
From: Alistair Tonner @ 2003-01-10  3:24 UTC (permalink / raw)
  To: netfilter
In-Reply-To: <200301092118.21946.netfilter@newkirk.us>


	Hi folks:
	Looking to minimize my time and general frustration levels, I set about 
automating my kernel rebuild process ... including doing the *go get kernel*, 
go patch kernel, make dep, make modules, make bzimage.... its somewhat more 
complex than that but what I found is that there is a little hook in ./runme 
if one invokes ./runme with --batch one invokes a loop at line 749 as 
follows... 

# Check to see if there is excluded patches
EXCLUDED=
while [ "$1" = "--exclude" ]; do
    EXCLUDED="$EXCLUDED $2"
    shift
    shift
done


 --- Correct me if I'm utterly off base, but does that second shift not close 
the loop by making $1 != --exclude for a long list of excluded suite/patches?

I'm trying to run this with patches I know that work (and install well) with a 
particular kernel .... and my little scripty b0rks at this and misapplies 
patches that I most definately do not want on my system ... and several that 
don't apply ... 

    Alistair Tonner
	Alistair@nerdnet.ca


^ permalink raw reply

* Re: ISO-9660 Rock Ridge gives different links different inums
From: Peter Chubb @ 2003-01-10  3:34 UTC (permalink / raw)
  To: Andrew McGregor; +Cc: Peter Chubb, eric, linux-kernel
In-Reply-To: <1345590000.1042169011@localhost.localdomain>

>>>>> "Andrew" == Andrew McGregor <andrew@indranet.co.nz> writes:

Andrew> --On Friday, January 10, 2003 14:08:59 +1100 Peter Chubb
Andrew> <peter@chubb.wattle.id.au> wrote:

>> In linux 2.5.54, multiple links to the same file on a rock-ridge CD
>> have different inode numbers.  This confuses cpio, tar and cp -ra
>> because the multiple links are each copied separately as a single
>> file.
>> 
>> It'll probably also confuse NFS, but I haven't tried that.

Andrew> Shouldn't do, but it will probably make the buffer cache on
Andrew> the server less effective.

>> Currently the inode number appears to be the offset in bytes from
>> the start of the file system to the iso directory entry.  Files
>> with multiple directory entries (i.e., links) therefore have
>> different inums.
>> 
>> I don't know enough about the ISO9660 standard to be sure what's
>> best to do about this.

Andrew> Change it to be the offset to the data area, which should be
Andrew> the same for all of them?

I thought about that, but I'm unsure if there's any way to get from
that offset to the directory information.  As far as I can tell,
there's no concept of an inode separate from directory entry on iso9660
--- the directory entry/entries all contain all the information that
describes a file.  Which means that the inumber has to point to some
directory node.

Preferably, all the inumbers for the same file would point to the same
directory entry; but I can see no easy way to do that.  Keeping an
in-memory table for files with multiple links might be the best way,
as there aren't that many on a typical filesystem.

--
Dr Peter Chubb				    peterc@gelato.unsw.edu.au
You are lost in a maze of BitKeeper repositories, all almost the same.

^ 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.