All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] RE: packet marking: only a ratio, not all
From: pfer @ 2006-04-10 13:48 UTC (permalink / raw)
  To: lartc

Hi Andy!

I haven't checked the iproute sources for that,
but maybe I was not clear:

What I need is not having ALL packets re-marked when
they are overlimit, or sent to any class, etc..

I want them to be remarked at a ratio. (eg. 2%)

And granularity is important, if I have to re-mark
with
a 20% ratio, I wish to remark every 5th, and not mark
20 continously at not mark other 80 continously.

(
Why I need this:
A protocol (RMD-QoS-NSLP) I want to implement has this
syntax to signal if a link is congested to some edge
nodes at the border of a domain.
)

Do you have a solution for this? I believe what you
suggested is not this, is it?

And I already found a 'somewhat' solution: 

filter actions

See my mail with subject: 
"action pass random determ/netrand reclassify
-value-": granularity problems

With:

tc filter add dev eth0 parent X protocol ip prio Y u32
match ip src 0/0 flowid Z action continue random
determ pass 5

I believe I am able to send every 5th package to class
Z (for remarking with dsmark) and the other 4/5 to the
next filter (with continue), which can send the packet
to the link.

This results in marking 20% of all the packets this
interface gets (via u32 match ip src 0/0).

Do you think this works? I still have not tried.
I believe "continue" gives the packet to the next
filter (order determined by filter command sequence)
and "pass" gives it to the "flowid Z".

Or, does "pass" actually sends the packet to the wire?


Thanks for the info,

Ferenc

--- Andy Furniss <andy.furniss@dsl.pipex.com> wrote:

> pfer wrote:
> > Hi all!
> >  
> >  In short: 
> >  
> >  Anybody wrote a patch for DSMARK to make it
> capable of marking
> >  only a ratio (a given arg to the tc command) of
> the packets it gets?
> >  Say, 20%? Or, do I have to hack into the source?
> Alternatives,
> >  like a filter spitting packets to 2 different
> DSMARK based on this ratio?
> >  
> >  In long:
> >  
> >  I'm a hungarian univ student involved in a
> project (RMD-QoS stuff)
> >  which needs the following:
> >  
> >   \                    This node has 3 ingress and
> 1 egress link, all have for ex. 10 Mbit
> >     \                  limit to their traffic.
> >       \
> >    ---  node -----  Suppose ingress traffic is: 8
> + 3 +5 = 16 while the egress
> >      /                 link will be congested with
> 10. Because this node is a simple,
> >    /                   intradomain router, we
> would like to notify the downstream 
> >  /                    edge node about this
> congestion, to tear down some of the flows
> >                       causing it. (Congestion
> occured via for. ex. a net failure)
> >  
> >  What the protocol (draft) says, is that the edge
> will be notified of the level of the congestion,
> which will be calculated by this proportional data
> packet marking method, to avoid additional
> signaling.
> >  Say, if 16 would go on a link with 10 capacity,
> congested core-node will mark
> >  60% of the packets it sends to the output of the
> link to another DSCP.
> >  
> >  I thought about DSMARK first, but that is
> incapable of doing this stuff.
> >  (or I think so :)
> >  Ideas?
> >  
> >  PS: I did not check the archives rigorously, so
> sorry if I am asking trivial things.
> >  
> >  PS2: Since I checked not to get mails from this
> list, please send your answer
> >  to forgamedev@yahoo.com.
> 
> I am not sure I get the logic of what you are trying
> to do for this 
> paticular setup, but there are examples of using
> policers with meters 
> shared across ingress links to dsmark overlimits
> packets in the iproute2 
> sources.
> 
> Andy.
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply

* Re: [RFC/PATCH] remove unneeded check in bcm43xx
From: John W. Linville @ 2006-04-10 13:46 UTC (permalink / raw)
  To: Michael Buesch; +Cc: Benoit Boissinot, netdev, bcm43xx-dev, linux-kernel, benh
In-Reply-To: <200604100628.01483.mb@bu3sch.de>

On Mon, Apr 10, 2006 at 06:28:00AM +0200, Michael Buesch wrote:

> To summerize: I actually added these messages, because people were
> hitting "this does not work with >1G" issues and did not get an error message.
> So I decided to insert warnings until the issue is fixed inside the arch code.
> I will remove them once the issue is fixed.

This sounds like the same sort of problems w/ the b44 driver.
I surmise that both use the same (broken) DMA engine from Broadcom.

Unfortunately, I don't know of any good solution to this.  There are
a few hacks in b44 that deal with the issue.  I don't like them,
although I am the perpetrator of at least one of them.  It might be
worth looking at what was done there?

YMMV...

John
-- 
John W. Linville
linville@tuxdriver.com

^ permalink raw reply

* Re: [PATCH] fix de_thread() vs do_coredump() deadlock
From: Oleg Nesterov @ 2006-04-10 17:43 UTC (permalink / raw)
  To: Roland McGrath
  Cc: linux-kernel, Ingo Molnar, Michael Kerrisk, Linus Torvalds,
	Andrew Morton
In-Reply-To: <20060410013651.4D1791809D1@magilla.sf.frob.com>

On 04/09, Roland McGrath wrote:
>
> [PATCH] Fix race between exec and fatal signals

I'll try to study this patch carefully tomorrow, but now I have
the feeling it is not right (probably my misunderstanding after
the quick reading).

> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -606,15 +606,16 @@ static int de_thread(struct task_struct 
>
> ... [snip] ...
>
> -	zap_other_threads(current);
> +	zap_other_threads(current, SIGNAL_GROUP_EXEC);
>
> ... [snip] ...
>
> -void zap_other_threads(struct task_struct *p)
> +void zap_other_threads(struct task_struct *p, int flag)
>  {
>  	struct task_struct *t;
>
> -	p->signal->flags = SIGNAL_GROUP_EXIT;
> +	if (unlikely(p->signal->flags & SIGNAL_GROUP_EXEC)) {
> +		/*
> +		 * We are cancelling an exec that is in progress, to let
> +		 * the thread group die instead.  We need to wake the
> +		 * exec'ing thread up from uninterruptible wait.
> +		 */
> +		BUG_ON(flag != SIGNAL_GROUP_EXIT);
> +		t = p->signal->group_exit_task;
> +		p->signal->group_exit_task = NULL;
> +		p->signal->notify_count = 0;
> +		wake_up_process(t);
> +	}
> +
> +	p->signal->flags = flag;
>  	p->signal->group_stop_count = 0;

So, de_thread() sets SIGNAL_GROUP_EXEC and sends SIGKILL to other thereads.

Sub-thread receives the signal, and calls get_signal_to_deliver->do_group_exit.
do_group_exit() calls zap_other_threads(SIGNAL_GROUP_EXIT) because there is no
SIGNAL_GROUP_EXIT set. zap_other_threads() notices SIGNAL_GROUP_EXEC, wakes up
execer, and changes ->signal->flags to SIGNAL_GROUP_EXIT.

de_thread() re-locks sighand, sees !SIGNAL_GROUP_EXEC and goes to 'dying:'.

No?

Another problem. de_thread() sets '->group_exit_task = current' _only_ if
'atomic_read(&sig->count) > count', so wake_up_process(->group_exit_task)
in zap_other_threads() is unsafe.

Oleg.


^ permalink raw reply

* Re: [PATCH 2/4] tickless idle cpu: Skip ticks when CPU is idle
From: Srivatsa Vaddagiri @ 2006-04-10 12:23 UTC (permalink / raw)
  To: Kumar Gala; +Cc: sri_vatsa_v, paulus, linuxppc-dev
In-Reply-To: <981C3B4E-7336-403D-AF58-3B36AA071866@kernel.crashing.org>

On Fri, Apr 07, 2006 at 09:16:58AM -0500, Kumar Gala wrote:
> >+config NO_IDLE_HZ
> >+	depends on EXPERIMENTAL && (PPC_PSERIES || PPC_PMAC || PPC_MAPLE)
> >+	bool "Switch off timer ticks on idle CPUs"
> >+	help
> >+	  Switches the HZ timer interrupts off when a CPU is idle.
> >+
> 
> any reason not to provide this for all 6xx class processors?

I think the same patch would work mostly for 6xx cpus as well. I however
dont think have any hardware to test it. If I am not mistaken, to
support 6xx CPUs, only ppc6xx_idle needs to be modified to call stop_hz_timer 
before going into power-save mode?


-- 
Regards,
vatsa

^ permalink raw reply

* Is it possible to use NFS with built-in kernel on 5912 OSK?
From: Sergey Vointsev @ 2006-04-10 13:43 UTC (permalink / raw)
  To: Linux-omap-open-source

Hello, everybody!

I try to mount folder of host PC via NFS. From other PC it works
perfect. But from OMAP5912 OSK I have the following situation:

# insmod /lib/modules/2.4.20_mvl31-omap5912_osk/kernel/fs/nfsd/nfsd.o
# mkdir /tmp/nfs
# mount 192.168.0.16:/nfs /tmp/nfs
mount: 192.168.0.16:/nfs failed, reason given by server: Permission denied
mount: nfsmount failed: Bad file descriptor
NFS: mount program didn't pass remote address!
mount: Mounting 192.168.0.16:/nfs on /tmp/nfs failed: Invalid argument

What's wrong? I use standard kernel and rootfs shipped with the board.
By the way, why OMAP5912 OSK has 32M of flash onboard, but the size of
default rootfs is only 16M?

Thanks. Sergey.

^ permalink raw reply

* [LARTC] Re: Trying to do some very simple ingress limiting,
From: richard lucassen @ 2006-04-10 13:41 UTC (permalink / raw)
  To: lartc

On Mon, 10 Apr 2006 14:38:10 +0200
Erik Slagter <erik@slagter.name> wrote:

> > I didn't know there is a problrm with IMQ + netfilter.
> 
> You just told me ;-)
> 
> The IMQ handling is done before the netfilter handling...
 
That's IFB, not IMQ. IFB is an intermediate functional block that
appeared in kernel 2.6.16. IFB is a device, IMQ is a iptables target
(and a device)

And IMQ is a kernel patch (and iptables has to be patched as well) while
IFB is in the mainstream kernel.

-- 
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht                                        |
| Public key and email address:                                    |
| http://www.lucassen.org/mail-pubkey.html                         |
+------------------------------------------------------------------+
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply

* Re: pchdtv 3000 cx88 audio very very low level
From: Andreas Mohr @ 2006-04-10 13:38 UTC (permalink / raw)
  To: Greg Stark; +Cc: linux-kernel
In-Reply-To: <87d5ftmt5p.fsf@stark.xeocode.com>

Hi,

On Fri, Apr 07, 2006 at 09:06:42AM -0400, Greg Stark wrote:
> Andreas Mohr <andi@rhlx01.fht-esslingen.de> writes:
> 
> > IOW, you need to examine the driver sources of cx88xx, cx8800, cx88_alsa,
> > btcx_risc, tveeprom (?) for some multiplexer bit mask and tweak/twiddle that
> > for your tuner until you manage to hear something properly.
> 
> Hm. Except nobody else seems to have this problem with the pchdtv 3000 card.
> And there are plenty of HOWTOs and FAQs online for it. Perhaps nobody else is
> trying to use the NTSC tuner on it though.

A distant possibility might be that your card is a very specific rare revision
of that thing and thus doesn't have a proper card type entry for it due to
almost nobody else having that card.
In the TV card area (just as in the WLAN card area) there are quite some cards
sold under the *very same* name but wildly (or not so wildly but sufficiently)
differing hardware (those manufacturer b****rds burn in hell please, thanks).

> I'm assuming that if cx88_alsa found any audio devices on the card then it
> would create a card1 listed in /proc/asound/cards ? It isn't doing that
> currently. Apparently not all cx88 cards provide a mixer interface.

I'm not that familiar with ALSA user-space interface specifics (rather than
kernel-level), sorry.

Andreas Mohr

^ permalink raw reply

* [PATCH] tools/python pciif: fix some python format string operators
From: Ryan @ 2006-04-10 13:37 UTC (permalink / raw)
  To: xen-devel

I used the wrong operator in a couple places for putting together some
error messages out of format strings. This patch corrects those
operators and fixes the strings.

Signed-off-by: Ryan Wilson <hap9@epoch.ncsc.mil>

---

diff -r 1c03c45d0c06 tools/python/xen/xend/server/pciif.py
--- a/tools/python/xen/xend/server/pciif.py	Mon Apr 10 09:57:38 2006
+++ b/tools/python/xen/xend/server/pciif.py	Mon Apr 10 09:07:59 2006
@@ -115,7 +115,7 @@
             dev = PciDevice(domain, bus, slot, func)
         except Exception, e:
             raise VmError("pci: failed to locate device and "+
-                    "parse it's resources - %s"+str(e))
+                    "parse it's resources - "+str(e))
 
         if dev.driver!='pciback':
             raise VmError(("pci: PCI Backend does not own device "+ \
@@ -131,7 +131,7 @@
                     nr_ports = size, allow_access = True)
             if rc<0:
                 raise VmError(('pci: failed to configure I/O ports on device '+
-                            '%s - errno=%d')&(dev.name,rc))
+                            '%s - errno=%d')%(dev.name,rc))
             
         for (start, size) in dev.iomem:
             # Convert start/size from bytes to page frame sizes
@@ -147,7 +147,7 @@
                     allow_access = True)
             if rc<0:
                 raise VmError(('pci: failed to configure I/O memory on device '+
-                            '%s - errno=%d')&(dev.name,rc))
+                            '%s - errno=%d')%(dev.name,rc))
 
         if dev.irq>0:
             log.debug('pci: enabling irq %d'%dev.irq)
@@ -155,7 +155,7 @@
                     allow_access = True)
             if rc<0:
                 raise VmError(('pci: failed to configure irq on device '+
-                            '%s - errno=%d')&(dev.name,rc))
+                            '%s - errno=%d')%(dev.name,rc))
 
     def waitForBackend(self,devid):
         return (0, "ok - no hotplug")

^ permalink raw reply

* [PATCH -rt] Buggy uart (for 2.6.16)
From: Steven Rostedt @ 2006-04-10 13:37 UTC (permalink / raw)
  To: Ingo Molnar; +Cc: LKML

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

Ingo,

I've noticed that you dropped my "buggy uart" patch.  Probably because
the 2.6.14 version would cause a deadlock on 2.6.16.  I've sent you a
new update, but it must have been lost in all the noise.  Here's the
patch again.  If you don't think this is a bug, try running the attached
program on the machine that deadlocked (it is the one with the buggy
uart). Without the patch, the serial_test will miss a wake up, and then
be stuck in the sleeping TASK_INTERRUPTIBLE state (at least you can
still kill it).  With the patch, it runs fine.

I ran the program with the following parameters:

# ./serial_test /dev/ttyS0 115200 8 0 0 4

(Disclaimer: I did not write this serial_test.  It was hacked up by my
customer to show me that this bug exists).

This may also be a bug with the vanilla kernel, since I don't see why it
is not. I'll run more tests on the vanilla kernel, and if it too misses
a wake up, I'll submit this to vanilla as well.


Some 8250 uarts don't zero out the NO_INTERRUPT bit of the IIR register
on transmit empty interrupts. If this happens, then the interrupt handler
won't process any transmits that are waiting, and we can have processes
stuck waiting to transmit over the serial.

This patch has the interrupt process the transmits regardless if 
the interrupt handler didn't already handle the transmits, and
the uart was previously (on setup) detected to be buggy.

-- Steve

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

Index: linux-2.6.16-rt14/drivers/serial/8250.c
===================================================================
--- linux-2.6.16-rt14.orig/drivers/serial/8250.c	2006-03-20 00:53:29.000000000 -0500
+++ linux-2.6.16-rt14/drivers/serial/8250.c	2006-04-10 09:14:38.000000000 -0400
@@ -1336,6 +1336,14 @@
 				"irq%d\n", irq);
 			break;
 		}
+		/*
+		 * If we have a buggy TX line, that doesn't
+		 * notify us via iir that we need to transmit
+		 * then force the call.
+		 */
+		if (!handled && (up->bugs & UART_BUG_TXEN))
+			serial8250_handle_port(up, regs);
+
 	} while (l != end);
 
 	spin_unlock(&i->lock);


[-- Attachment #2: serial_test.c --]
[-- Type: text/x-csrc, Size: 11678 bytes --]

#include <termios.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <sys/signal.h>
#include <sys/types.h>

#define BAUDRATE B38400
#define MODEMDEVICE "/dev/ttyS1"
#define _POSIX_SOURCE 1         //POSIX compliant source
#define FALSE 0
#define TRUE 1

volatile int STOP=FALSE;

void signal_handler_IO (int status);    //definition of signal handler
int wait_flag=TRUE;                     //TRUE while no signal received
char devicename[80];
long Baud_Rate = 38400;         // default Baud Rate (110 through 38400)
long BAUD;                      // derived baud rate from command line
long DATABITS;
long STOPBITS;
long PARITYON;
long PARITY;
int Data_Bits = 8;              // Number of data bits
int Stop_Bits = 1;              // Number of stop bits
int Parity = 0;                 // Parity as follows:
                  // 00 = NONE, 01 = Odd, 02 = Even, 03 = Mark, 04 = Space
int Format = 4;
FILE *input;
FILE *output;
int status;

int main(int Parm_Count, char *Parms[])
{
	char version[80] = "       POSIX compliant Communications test program version 1.00 4-25-1999\r\n";
	char version1[80] = "          Copyright(C) Mark Zehner/Peter Baumann 1999\r\n";
	char version2[80] = " This code is based on a DOS based test program by Mark Zehner and a Serial\r\n";
	char version3[80] = " Programming POSIX howto by Peter Baumann, integrated by Mark Zehner\r\n";  
	char version4[80] = " This program allows you to send characters out the specified port by typing\r\n";
	char version5[80] = " on the keyboard.  Characters typed will be echoed to the console, and \r\n";
	char version6[80] = " characters received will be echoed to the console.\r\n";
	char version7[80] = " The setup parameters for the device name, receive data format, baud rate\r\n";
	char version8[80] = " and other serial port parameters must be entered on the command line \r\n";
	char version9[80] = " To see how to do this, just type the name of this program. \r\n";
	char version10[80] = " This program is free software; you can redistribute it and/or modify it\r\n";
	char version11[80] = " under the terms of the GNU General Public License as published by the \r\n";
	char version12[80] = " Free Software Foundation, version 2.\r\n";
	char version13[80] = " This program comes with ABSOLUTELY NO WARRANTY.\r\n";
	char instr[100] ="\r\nOn the command you must include six items in the following order, they are:\r\n";
	char instr1[80] ="   1.  The device name      Ex: ttyS0 for com1, ttyS1 for com2, etc\r\n";
	char instr2[80] ="   2.  Baud Rate            Ex: 38400 \r\n";
	char instr3[80] ="   3.  Number of Data Bits  Ex: 8 \r\n";
	char instr4[80] ="   4.  Number of Stop Bits  Ex: 0 or 1\r\n";
	char instr5[80] ="   5.  Parity               Ex: 0=none, 1=odd, 2=even\r\n";
	char instr6[80] ="   6.  Format of data received:  1=hex, 2=dec, 3=hex/asc, 4=dec/asc, 5=asc\r\n";
	char instr7[80] =" Example command line:  com ttyS0 38400 8 0 0 4 \r\n";
	char Param_strings[7][80];
	char message[90];
	char cntmessage[90];

	int fd, tty, res, i, error, cnt = 1;
	char In1;
	char Keys[] = "jfdslgjdlskfgklsdfjgkdlfsklsjgfdgsdfjglkdsf";
	struct termios oldtio, newtio;       //place for old and new port settings for serial port
	struct termios oldkey, newkey;       //place tor old and new port settings for keyboard teletype
	struct sigaction saio;               //definition of signal action
	char buf[255];                       //buffer for where data is put
   
	input = fopen("/dev/tty", "r");      //open the terminal keyboard
	output = fopen("/dev/tty", "w");     //open the terminal screen

	if (!input || !output){
		fprintf(stderr, "Unable to open /dev/tty\n");
		exit(1);
	}

	error=0;
	fputs(version,output);               //display the program introduction
	fputs(version1,output);
	fputs(version2,output);
	fputs(version3,output);
	fputs(version4,output);
	fputs(version5,output);
	fputs(version6,output);
	fputs(version7,output);
	fputs(version8,output);
	fputs(version9,output);
	fputs(version10,output);
	fputs(version11,output); 
	fputs(version12,output);
	fputs(version13,output);
	//read the parameters from the command line
	if (Parm_Count==7){  //if there are the right number of parameters on the command line
		for (i=1; i < Parm_Count; i++)  // for all wild search parameters
			strcpy(Param_strings[i-1],Parms[i]);
		i=sscanf(Param_strings[0],"%s",devicename);
		if (i != 1)
			error=1;
		i=sscanf(Param_strings[1],"%li",&Baud_Rate);
		if (i != 1)
			error=1;
		i=sscanf(Param_strings[2],"%i",&Data_Bits);
		if (i != 1)
			error=1;
		i=sscanf(Param_strings[3],"%i",&Stop_Bits);
		if (i != 1)
			error=1;
		i=sscanf(Param_strings[4],"%i",&Parity);
		if (i != 1)
			error=1;
		i=sscanf(Param_strings[5],"%i",&Format);
		if (i != 1)
			error=1;
		sprintf(message,"Device=%s, Baud=%li\r\n",devicename, Baud_Rate); //output the received setup parameters
		fputs(message,output);
		sprintf(message,"Data Bits=%i  Stop Bits=%i  Parity=%i  Format=%i\r\n",Data_Bits, Stop_Bits, Parity, Format);
		fputs(message,output);
	}  //end of if param_count==7
  
	if ((Parm_Count==7) && (error==0)){  //if the command line entries were correct
	                                    //run the program
		tty = open("/dev/tty", O_RDWR | O_NOCTTY | O_NONBLOCK); //set the user console port up
		tcgetattr(tty,&oldkey); // save current port settings   //so commands are interpreted right for this program
		// set new port settings for non-canonical input processing  //must be NOCTTY
		newkey.c_cflag = BAUDRATE | CRTSCTS | CS8 | CLOCAL | CREAD;
		newkey.c_iflag = IGNPAR;
		newkey.c_oflag = 0;
		newkey.c_lflag = 0;       //ICANON;
		newkey.c_cc[VMIN]=1;
		newkey.c_cc[VTIME]=0;
		tcflush(tty, TCIFLUSH);
		tcsetattr(tty,TCSANOW,&newkey);

		switch (Baud_Rate){
			case 38400:
			default:
				BAUD = B38400;
				break;
			case 19200:
				BAUD  = B19200;
				break;
			case 9600:
				BAUD  = B9600;
				break;
			case 4800:
				BAUD  = B4800;
				break;
			case 2400:
				BAUD  = B2400;
				break;
			case 1800:
				BAUD  = B1800;
				break;
			case 1200:
				BAUD  = B1200;
				break;
			case 600:
				BAUD  = B600;
				break;
			case 300:
				BAUD  = B300;
				break;
			case 200:
				BAUD  = B200;
				break;
			case 150:
				BAUD  = B150;
				break;
			case 134:
				BAUD  = B134;
				break;
			case 110:
				BAUD  = B110;
				break;
			case 75:
				BAUD  = B75;
				break;
			case 50:
				BAUD  = B50;
				break;
		}  //end of switch baud_rate

		switch (Data_Bits){
			case 8:
			default:
				DATABITS = CS8;
				break;
			case 7:
				DATABITS = CS7;
				break;
			case 6:
				DATABITS = CS6;
				break;
			case 5:
				DATABITS = CS5;
				break;
		}  //end of switch data_bits

		switch (Stop_Bits){
			case 1:
			default:
				STOPBITS = 0;
				break;
			case 2:
				STOPBITS = CSTOPB;
				break;
		}  //end of switch stop bits

		switch (Parity){
			case 0:
			default:                       //none
				PARITYON = 0;
				PARITY = 0;
				break;
			case 1:                        //odd
				PARITYON = PARENB;
				PARITY = PARODD;
				break;
			case 2:                        //even
				PARITYON = PARENB;
				PARITY = 0;
				break;
		}  //end of switch parity
       
		//install the serial handler before making the device asynchronous
		saio.sa_handler = signal_handler_IO;
		sigemptyset(&saio.sa_mask);   //saio.sa_mask = 0;
		saio.sa_flags = 0;
		saio.sa_restorer = NULL;
		sigaction(SIGIO,&saio,NULL);

		// loop while waiting for input. normally we would do something useful here
		while (STOP==FALSE){
			//open the device(com port) to be non-blocking (read will return immediately)
			sprintf(cntmessage,"============== %d =============\r\n", cnt);
			fputs(cntmessage, output);
			fputs("Trying to open device\r\n", output);
			fd = open(devicename, O_RDWR | O_NOCTTY | O_NONBLOCK);
			if (fd < 0){
				perror(devicename);
				exit(-1);
			}
			fputs("Opened device\r\n", output);

			// allow the process to receive SIGIO
			fcntl(fd, F_SETOWN, getpid());
			// Make the file descriptor asynchronous (the manual page says only
			// O_APPEND and O_NONBLOCK, will work with F_SETFL...)
			fcntl(fd, F_SETFL, FASYNC);

			tcgetattr(fd,&oldtio); // save current port settings 
			// set new port settings for canonical input processing 
			newtio.c_cflag = BAUD | /* CRTSCTS | */ DATABITS | STOPBITS | PARITYON | PARITY | CLOCAL | CREAD;
			newtio.c_iflag = IGNPAR;
			newtio.c_oflag = 0;
			newtio.c_lflag = 0;       //ICANON;
			newtio.c_cc[VMIN]=1;
			newtio.c_cc[VTIME]=0;
			tcflush(fd, TCIFLUSH);
			fputs("Trying to set attributes\r\n", output);
			tcsetattr(fd,TCSANOW,&newtio);
			fputs("Set attributes\r\n", output);
			
//			status = fread(&Key,1,1,input);
//			if (status==1){  //if a key was hit
//         			switch (Key){ /* branch to appropiate key handler */
//					case 0x1b: /* Esc */
//						STOP=TRUE;
//						break;
//					default:
//						fputc((int) Key,output);
						//sprintf(message,"%x ",Key);  //debug
						//fputs(message,output);
						write(fd,Keys,sizeof(Keys));          //write 1 byte to the port
						ioctl(fd, TCSBRK, NULL);
//						break;
//				}  //end of switch key
//			}  //end if a key was hit
			// after receiving SIGIO, wait_flag = FALSE, input is available and can be read
			if (wait_flag==FALSE){  //if input is available
				res = read(fd,buf,255);
				if (res){
					for (i=0; i<res; i++){  //for all chars in string
						In1 = buf[i];
						switch (Format){
							case 1:         //hex
								sprintf(message,"%x ",In1);
								fputs(message,output);
								break;
							case 2:         //decimal
								sprintf(message,"%d ",In1);
								fputs(message,output);
								break;
							case 3:         //hex and asc
								if ((In1) || (In1)){
									sprintf(message,"%x",In1);
									fputs(message,output);
								} else
									fputc ((int) In1, output);
								break;
							case 4:         //decimal and asc
							default:
								if ((In1) || (In1)){
									sprintf(message,"%d",In1);
									fputs(message,output);
								} else
									fputc ((int) In1, output);
								break;
							case 5:         //asc
								fputc ((int) In1, output);
								break;
						}  //end of switch format
					}  //end of for all chars in string
				}  //end if res?
				//buf[res]=0;
				//printf(":%s:%d\n", buf, res);
				//if (res==1) STOP=TRUE; /* stop loop if only a CR was input */
				wait_flag = TRUE;      /* wait for new input */
			}  //end if wait flag == FALSE
			fputs("Trying to reset attributes\r\n", output);
			tcsetattr(fd,TCSANOW,&oldtio);
			fputs("Reset attributes\r\n", output);
			fputs("Trying to close device\r\n", output);
			close(fd);        //close the com port
			fputs("Closed device\r\n", output);
			cnt++;
			usleep(500000);
		}  //while stop==FALSE

		// restore old port settings
		
		tcsetattr(tty,TCSANOW,&oldkey);
		close(tty);

	} else { //end if command line entrys were correct
		//give instructions on how to use the command line
		fputs(instr,output);
		fputs(instr1,output);
		fputs(instr2,output);
		fputs(instr3,output);
		fputs(instr4,output);
		fputs(instr5,output);
		fputs(instr6,output);
		fputs(instr7,output);
	}
	fclose(input);
	fclose(output);
	return 0;
}  //end of main

/***************************************************************************
* signal handler. sets wait_flag to FALSE, to indicate above loop that     *
* characters have been received.                                           *
***************************************************************************/

void signal_handler_IO (int status){
	//printf("received SIGIO signal.\n");
	wait_flag = FALSE;
}

^ permalink raw reply

* Re: Communicating FileSystem Structures b/w Two Machines
From: Matthew Wilcox @ 2006-04-10 13:32 UTC (permalink / raw)
  To: UZAIR LAKHANI; +Cc: linux-fsdevel
In-Reply-To: <20060410061146.89260.qmail@web37915.mail.mud.yahoo.com>

On Sun, Apr 09, 2006 at 11:11:46PM -0700, UZAIR LAKHANI wrote:
> I am in the process of making a filesystem in a
> client/server environment where there is a single
> server having a storage attached and 2 to 3 clients
> accessing that storage through a communication
> mechanism. The client and server are using a
> buffer(unsigned char array) to communicate.
> 
> In order for client and server to communicate, they
> have to exchange different structures like
> super-block, inode, dentry, vfsmount etc.

Why on earth do you think that?  Certainly you have to communicate
file data and metadata, but why on earth would you ship dentries from
one machine to another?  This will never work.

You should probably look at how other network filesystems are designed,
starting with NFS: http://www.faqs.org/rfcs/rfc1094.html

What are your research goals for this new filesystem?  Why will it be
any better than OCFS2, NFS (v2 or v4), SMBFS/CIFS, NCPFS, Coda or AFS?
Why don't you start by taking one of these filesystems and modify or
extend it to suit your needs rather than starting from scratch?

^ permalink raw reply

* Re: [PATCH 11/19] kconfig: move .kernelrelease
From: Roman Zippel @ 2006-04-10 13:29 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Sam Ravnborg, linux-kernel
In-Reply-To: <20060410025851.641022a0.akpm@osdl.org>

Hi,

On Mon, 10 Apr 2006, Andrew Morton wrote:

> hm, it takes nearly five seconds, but it wasn't that - something actually
> broke.  But I forget what it was.  I'll put it back and will wait for it
> to reoccur.

The patch below should speed this up. You know that you have to update 
this file explicitly?

bye, Roman

---

 Makefile |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Index: linux-2.6-git/Makefile
===================================================================
--- linux-2.6-git.orig/Makefile
+++ linux-2.6-git/Makefile
@@ -366,7 +366,8 @@ outputmakefile:
 # of make so .config is not included in this case either (for *config).
 
 no-dot-config-targets := clean mrproper distclean \
-			 cscope TAGS tags help %docs check%
+			 cscope TAGS tags help %docs check% \
+			 kernelrelease kernelversion
 
 config-targets := 0
 mixed-targets  := 0
@@ -1251,7 +1252,7 @@ namespacecheck:
 endif #ifeq ($(config-targets),1)
 endif #ifeq ($(mixed-targets),1)
 
-PHONY += checkstack
+PHONY += checkstack kernelrelease kernelversion
 checkstack:
 	$(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
 	$(PERL) $(src)/scripts/checkstack.pl $(ARCH)

^ permalink raw reply

* Re: [Xenomai-core] [BUG?] stalled xeno domain
From: Philippe Gerum @ 2006-04-10 13:28 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <443A56E2.1010204@domain.hid>

Jan Kiszka wrote:
>>>
>>>Philippe, do you see any remaining issues, e.g. that the leak survived
>>>the task termination? Does this have any meaning for correct driver and
>>>skin code?
>>>
>>
>>The only way I could see this leakage survive a switch transition would
>>require it to happen over the root context, not over a primary context.
>>Was it the case?
>>
> 
> 
> The task had to leave from primary mode. If I forced it to secondary
> before terminating, the problem did not show up.
> 

But does the code causing the leakage could have been run by different 
contexts in sequence, including the root one?

-- 

Philippe.


^ permalink raw reply

* Re: The assemble file under the driver folder can not be recognized when the driver is built as module
From: Aubrey @ 2006-04-10 13:27 UTC (permalink / raw)
  To: Erik Mouw; +Cc: linux-kernel
In-Reply-To: <20060410112817.GE12896@harddisk-recovery.com>

On 4/10/06, Erik Mouw <erik@harddisk-recovery.com> wrote:
> On Mon, Apr 10, 2006 at 06:16:56PM +0800, Aubrey wrote:
> Why would you write a driver in assembly in the first place? That makes
> it highly unportable, I bet you can't compile your driver for x86 and
> ARM from the same source. There are only four drivers in the whole
> kernel tree that have an assembly part, but those are so tied to their
> platform (Acorn, Amiga) that they aren't portable anyway.

Yes, the driver isn't portable. I'm working on the blackfin linux
system. The driver is written mostly by c except one codec. You know,
blackfin has DSP instruction set, so I write the codec in assembly to
improve my driver's performance.
>
> I haven't seen your Makefile so I can't see what's wrong, but see
> drivers/scsi/arm/Makefile for an example.
>
Makefile is simple.
===============================
----snip----
obj-$(CONFIG_FB_BFIN_7171)	  += bfin_ad7171fb.o rgb2ycbcr.o
----snip----
===============================
There are two files, bfin_ad7171fb.c and rgb2ycbcr.S under the folder
" ./drivers/video".
It should be OK because the driver can pass the compilation when
select it as built-in.
It just failed when select it as module.

Thanks your any hints.


Regards,
-Aubrey

^ permalink raw reply

* [LARTC] Re: EF & AF filters with HTB
From: pfer @ 2006-04-10 13:26 UTC (permalink / raw)
  To: lartc

Hi Robert!

If I get you right, you wish to use HTB at a node
for doing some QoS for packets based the DSCP they
already have, and NOT marking them to have that AF,
etc.

(
have you checked
http://www.opalsoft.net/qos/DS-310.htm?
he has some nice scripts
)

Why not simply use an u32 match on the TOS field for
filtering under your main htb? Why do you need DSMARK?
(haven't tried, but should work fine)

For ex. having htb main shaper at 1:0 gives

tc filter add dev eth0 parent 1:0 protocol ip prio 2
u32 match ip tos 0xb8 0xff flowid 1:10
(the EF htb branch is at 1:10)

tc filter add dev eth0 parent 1:0 protocol ip prio 3
u32 match ip tos 0x28 0xff flowid 1:20
(the AF11 htb branch is at 1:20)

At for bulk, create the htb main with: "default 30",
and add an 1:30 class with needed rate + burst and
red/sfq/etc.
U won't need any filter for this, anything
unclassified
(anything other than EF or AF11) will get there.

If I get you wrong, and you wish to re-mark those
packets, I have some scripts for that, too.

Contact me at forgamedev@yahoo.com, and I will send
them to you.

PS: 
since I also have some scripts to test, and they 
resemble yours, can you tell me whether they are
correct?

First I wish to re-mark packets based on u32 ip src
match, with:

tc qdisc add dev eth0 handle 1:0 root dsmark indices 4

tc class change dev eth0 classid 1:1 dsmark mask 0x3
value 0xb8

..some filters under 1:0 to send packets to 1:1 to
remark them...

and then comes a htb at 2:0 having 1:0 (the dsmark
qdisc) as parent with few branches.

Can I expect that htb qdisc at 2:0 will already have
the effects of dsmark at 1:0 (remarked packets)?

Thanks,

Ferenc

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply

* RE: aaccli - adding a disk to an existing container...
From: Toby Moxham @ 2006-04-10 13:26 UTC (permalink / raw)
  To: Salyzyn, Mark, linux-scsi
In-Reply-To: <547AF3BD0F3F0B4CBDC379BAC7E4189F0255FB76@otce2k03.adaptec.com>

Hi Mark,

Thanks for the responce, i will wait for the process to finish (which looks
as thought it make take a day or two!) and see what it reports then. I have
looked throught the adaptec documentation and this is very little concerning
expansion.

Thanks for the help!

Toby

-----Original Message-----
From: Salyzyn, Mark [mailto:mark_salyzyn@adaptec.com]
Sent: 10 April 2006 14:13
To: toby@digitalmischief.co.uk; linux-scsi@vger.kernel.org
Subject: RE: aaccli - adding a disk to an existing container...


You need to contact Adaptec Technical Support, or read the Adaptec
Documentation regarding array expansion. Please note that aaccli is no
longer supported and has been replaced by arcconf.

The array size for a RAID-5 is (n-1)*slice size. The new size is not
available until the build has completed, during that time it appears
that aaccli is reporting what it can to justify the older size with the
newer physical components while in this transitional state. I am unsure
of the operation of the /extend_fs switch for aaccli, I believe it is
only for the windoze file system; the actions you take under Linux will
be incantations around fdisk(8).

If I were you, I'd wait for the build to complete before worrying, it
has already started and any other actions you take until it is completed
could affect the integrity of the data. If the data is unimportant, just
build a fresh 4 drive RAID-5 and you can use the disk space immediately
;->

Sincerely -- Mark Salyzyn


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Toby Moxham
> Sent: Monday, April 10, 2006 8:15 AM
> To: linux-scsi@vger.kernel.org
> Subject: aaccli - adding a disk to an existing container...
>
>
>
>
>
> Hi,
>
> I have an Adaptec 2610SA sata raid card I inititally
> configured it with 3x
> 300gb drives in a Raid 5 configuration. I now have added another 300gb
> drive.
>
> Using AAC CLI in Slackware linux... i have issued the command
> container
> reconfigure 0 (0,3,0) to add the fourth disk to the array, It
> is currently
> in progress in doing this .
>
> however when i now do container list i get this :-
>
> Executing: container list
> Num          Total  Oth Chunk          Scsi   Partition
> Label Type   Size   Ctr Size   Usage   B:ID:L Offset:Size
> ----- ------ ------ --- ------ ------- ------ -------------
>  0    Reconf  558GB            Open
>  /dev/sda             RAID_ARRAY
> 62    RAID-5  558GB       64KB None    0:00:0 64.0KB: 186GB
>                                                0:01:0 64.0KB: 186GB
>                                                0:02:0 64.0KB: 186GB
>                                                0:03:0 64.0KB: 186GB
>
> I assume that what has happened is that the 558GB array is
> being distributed
> across the four disks. (or is it because the task is still in
> progress?)
>
> However i also want to grow the size of the array to max of
> the four disks.
> (rather than leaving free space on each disk)
>
> Do i need to use /extend_fs switch (looks as thought this is only for
> windows) or do i need to use the partition resize.
>
> Any help would be appreciated.
>
> Thanks
> Toby Moxham
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.0/306 - Release
> Date: 09/04/2006
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.0/306 - Release
> Date: 09/04/2006
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.0/306 - Release Date: 09/04/2006

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.0/306 - Release Date: 09/04/2006


^ permalink raw reply

* Re: mkpatches: against ref-linux or pristine? (Was: Error compiling with CONFIG_PROFILING (xenoprof))
From: Keir Fraser @ 2006-04-10 13:24 UTC (permalink / raw)
  To: Michael Paesold; +Cc: Xen Devel
In-Reply-To: <015a01c65c9f$15ca4210$d801a8c0@zaphod>


On 10 Apr 2006, at 14:02, Michael Paesold wrote:

> You are right, I also see no real value in having one xen patch + 
> several extra patches to apply. It rather makes the process of 
> patching more complicated. Although rpm helps me with the patching, I 
> still have to manually review changes in patches/ everytime I rebase 
> our own RPMs... resulting in this very thread. :-)
>
> Does anyone see a use-case for not creating an all-in-one patch? On a 
> second thought, a separate "make mkpatch" (or a more explicit target 
> name) could provide an all-in-one patch without introducing 
> transitioning problems for users of mkpatches.
>
> Should I create a patch to implement that? (Seems rather trivial and 
> suitable for my limited Makefile fu.)

Actually I just fixed it already. :-)  I think there will be no 
complaints and, if that's the case, we can also backport to 3.0.2 
series.

  -- Keir

^ permalink raw reply

* Re: [PATCH] sparse: gcc 4.1 warnings
From: Morten Welinder @ 2006-04-10 13:21 UTC (permalink / raw)
  To: jeff; +Cc: linux-sparse
In-Reply-To: <20060408041419.GA8943@havoc.gtf.org>


This doesn't look quite right.

So it looks like gcc 4.1 complains over non-used values that are the
result of a cast.  That feels obnoxious, but in this case maybe you
could try just casting to void in add_ptr_list -- is the value ever
used?

Morten

^ permalink raw reply

* patch-o-matic ROUTE
From: Ian stuart Turnbull @ 2006-04-10 13:19 UTC (permalink / raw)
  To: netfilter

Hi folks,
can I request some help please. I would like to know if the patch-o-matic 
ROUTE -tee function works and if so could someone please tell me how/when I 
apply the patch. I mean how does one tell the Kernel make to include just 
this one extra patch?
Sorry if this has been explained earlier. I attempted to search the mailing 
list archives but couldn't find a search capability.
Thanks,
Ian t

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://join.msn.com/messenger/overview



^ permalink raw reply

* Re: [Qemu-devel] SPARC iommu mapping
From: Joerg Platte @ 2006-04-10 13:18 UTC (permalink / raw)
  To: qemu-devel
In-Reply-To: <BAY104-F117C8B7ECF3ED07C6591A9FFC90@phx.gbl>

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

Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl:
Hi!

The attached patch is an updated version of my previous patch. Now it applies 
cleanly to cvs head and the read and write performance is increased.

regards,
Jörg

[-- Attachment #2: qemu-write2.patch --]
[-- Type: text/x-diff, Size: 5691 bytes --]

--- esp.c	2006-04-10 14:51:37.000000000 +0200
+++ esp.c.new	2006-04-10 14:54:44.000000000 +0200
@@ -63,6 +63,8 @@
     ESPDMAFunc *dma_cb;
     int64_t offset, len;
     int target;
+    int blocksize;
+    int ti_bufstart;
 };
 
 #define STAT_DO 0x00
@@ -229,12 +231,12 @@
                             target_phys_addr_t phys_addr, 
                             int transfer_size1)
 {
+    int len = transfer_size1/s->blocksize;
     DPRINTF("Write callback (offset %lld len %lld size %d trans_size %d)\n",
             s->offset, s->len, s->ti_size, transfer_size1);
-    bdrv_write(s->bd[s->target], s->offset, s->ti_buf, s->len);
-    s->offset = 0;
-    s->len = 0;
-    s->target = 0;
+
+    bdrv_write(s->bd[s->target], s->offset, s->ti_buf+s->ti_bufstart, len);
+    s->offset+=len;
     return 0;
 }
 
@@ -265,6 +267,7 @@
     s->ti_size = 0;
     s->ti_rptr = 0;
     s->ti_wptr = 0;
+    s->ti_bufstart = 0;
 
     if (target >= 4 || !s->bd[target]) { // No such drive
 	s->rregs[4] = STAT_IN;
@@ -293,6 +296,7 @@
 	s->ti_buf[3] = 2;
 	s->ti_buf[4] = 32;
 	s->ti_dir = 1;
+	s->ti_bufstart = 0;
 	s->ti_size = 36;
 	break;
     case 0x1a:
@@ -314,6 +318,7 @@
 	    s->ti_buf[6] = 2; // sector size 512
 	s->ti_buf[7] = 0;
 	s->ti_dir = 1;
+	s->ti_bufstart = 0;
 	s->ti_size = 8;
 	break;
     case 0x28:
@@ -336,6 +341,7 @@
 	    bdrv_read(s->bd[target], offset, s->ti_buf, len);
 	    // XXX error handling
 	    s->ti_dir = 1;
+	    s->ti_bufstart = 0;
 	    break;
 	}
     case 0x2a:
@@ -346,10 +352,12 @@
 		offset = ((buf[3] << 24) | (buf[4] << 16) | (buf[5] << 8) | buf[6]) * 4;
 		len = ((buf[8] << 8) | buf[9]) * 4;
 		s->ti_size = len * 2048;
+		s->blocksize=2048;
 	    } else {
 		offset = (buf[3] << 24) | (buf[4] << 16) | (buf[5] << 8) | buf[6];
 		len = (buf[8] << 8) | buf[9];
 		s->ti_size = len * 512;
+		s->blocksize=512;
 	    }
 	    DPRINTF("Write (10) (offset %lld len %lld)\n", offset, len);
             if (s->ti_size > TI_BUFSZ) {
@@ -359,6 +367,7 @@
             s->offset = offset;
             s->len = len;
             s->target = target;
+            s->ti_bufstart = 0;
 	    // XXX error handling
 	    s->ti_dir = 0;
 	    break;
@@ -400,6 +409,7 @@
                 break;
             }
 	    s->ti_dir = 1;
+	    s->ti_bufstart = 0;
             break;
         }
     default:
@@ -415,10 +425,9 @@
 
 static void dma_write(ESPState *s, const uint8_t *buf, uint32_t len)
 {
-    uint32_t dmaptr, dmalen;
+    uint32_t dmaptr;
 
-    dmalen = s->wregs[0] | (s->wregs[1] << 8);
-    DPRINTF("Transfer status len %d\n", dmalen);
+    DPRINTF("Transfer status len %d\n", len);
     if (s->dma) {
 	dmaptr = iommu_translate(s->espdmaregs[1]);
 	DPRINTF("DMA Direction: %c\n", s->espdmaregs[0] & 0x100? 'w': 'r');
@@ -428,10 +437,10 @@
 	s->rregs[6] = SEQ_CD;
     } else {
 	memcpy(s->ti_buf, buf, len);
-	s->ti_size = dmalen;
+	s->ti_size = len;
 	s->ti_rptr = 0;
 	s->ti_wptr = 0;
-	s->rregs[7] = dmalen;
+	s->rregs[7] = len;
     }
     s->espdmaregs[0] |= DMA_INTR;
     pic_set_irq(s->irq, 1);
@@ -442,34 +451,58 @@
 
 static void handle_ti(ESPState *s)
 {
-    uint32_t dmaptr, dmalen;
+    uint32_t dmaptr, dmalen, minlen, len, from, to;
     unsigned int i;
 
     dmalen = s->wregs[0] | (s->wregs[1] << 8);
-    DPRINTF("Transfer Information len %d\n", dmalen);
+    if (dmalen==0) {
+      dmalen=0x10000;
+    }
+
+    minlen = (dmalen < s->ti_size) ? dmalen : s->ti_size;
+    DPRINTF("Transfer Information len %d\n", minlen);
     if (s->dma) {
 	dmaptr = iommu_translate(s->espdmaregs[1]);
-	DPRINTF("DMA Direction: %c, addr 0x%8.8x\n", s->espdmaregs[0] & 0x100? 'w': 'r', dmaptr);
-	for (i = 0; i < s->ti_size; i++) {
+	DPRINTF("DMA Direction: %c, addr 0x%8.8x %08x %d %d\n", s->espdmaregs[0] & 0x100? 'w': 'r', dmaptr, s->ti_size, s->ti_bufstart, s->ti_dir);
+	from=s->espdmaregs[1];
+	to=from+minlen;
+	for (i = 0; i < minlen; i+=len, from+=len) {
 	    dmaptr = iommu_translate(s->espdmaregs[1] + i);
+	    if ((from&TARGET_PAGE_MASK)!=(to&TARGET_PAGE_MASK)) {
+               len=TARGET_PAGE_SIZE-(from&~TARGET_PAGE_MASK);
+            } else {
+	       len=to-from;
+            }
+            DPRINTF("DMA address p %08x v %08x len %08x, from %08x, to %08x\n", dmaptr, s->espdmaregs[1] + i, len, from, to);
 	    if (s->ti_dir)
-		cpu_physical_memory_write(dmaptr, &s->ti_buf[i], 1);
+		cpu_physical_memory_write(dmaptr, &s->ti_buf[s->ti_bufstart+i], len);
 	    else
-		cpu_physical_memory_read(dmaptr, &s->ti_buf[i], 1);
+		cpu_physical_memory_read(dmaptr, &s->ti_buf[s->ti_bufstart+i], len);
 	}
         if (s->dma_cb) {
-            s->dma_cb(s, s->espdmaregs[1], dmalen);
+            s->dma_cb(s, s->espdmaregs[1], minlen);
+        }
+        if (minlen<s->ti_size) {
+	    s->rregs[4] = STAT_IN | STAT_TC | (s->ti_dir?STAT_DO:STAT_DI);
+	    s->ti_size-=minlen;
+	    s->ti_bufstart+=minlen;
+        } else {
+	    s->rregs[4] = STAT_IN | STAT_TC | STAT_ST;
             s->dma_cb = NULL;
+            s->offset = 0;
+            s->len = 0;
+            s->target = 0;
+            s->ti_bufstart = 0;
         }
-	s->rregs[4] = STAT_IN | STAT_TC | STAT_ST;
-	s->rregs[5] = INTR_BS;
+        s->rregs[5] = INTR_BS;
 	s->rregs[6] = 0;
+	s->rregs[7] = 0;
 	s->espdmaregs[0] |= DMA_INTR;
     } else {
-	s->ti_size = dmalen;
+	s->ti_size = minlen;
 	s->ti_rptr = 0;
 	s->ti_wptr = 0;
-	s->rregs[7] = dmalen;
+	s->rregs[7] = minlen;
     }	
     pic_set_irq(s->irq, 1);
 }
@@ -485,8 +518,10 @@
     s->ti_rptr = 0;
     s->ti_wptr = 0;
     s->ti_dir = 0;
+    s->ti_bufstart = 0;
     s->dma = 0;
     s->dma_cb = NULL;
+    s->blocksize = 0;
 }
 
 static uint32_t esp_mem_readb(void *opaque, target_phys_addr_t addr)

^ permalink raw reply

* RE: aaccli - adding a disk to an existing container...
From: Salyzyn, Mark @ 2006-04-10 13:13 UTC (permalink / raw)
  To: toby, linux-scsi

You need to contact Adaptec Technical Support, or read the Adaptec
Documentation regarding array expansion. Please note that aaccli is no
longer supported and has been replaced by arcconf.

The array size for a RAID-5 is (n-1)*slice size. The new size is not
available until the build has completed, during that time it appears
that aaccli is reporting what it can to justify the older size with the
newer physical components while in this transitional state. I am unsure
of the operation of the /extend_fs switch for aaccli, I believe it is
only for the windoze file system; the actions you take under Linux will
be incantations around fdisk(8).

If I were you, I'd wait for the build to complete before worrying, it
has already started and any other actions you take until it is completed
could affect the integrity of the data. If the data is unimportant, just
build a fresh 4 drive RAID-5 and you can use the disk space immediately
;->

Sincerely -- Mark Salyzyn


> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org 
> [mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Toby Moxham
> Sent: Monday, April 10, 2006 8:15 AM
> To: linux-scsi@vger.kernel.org
> Subject: aaccli - adding a disk to an existing container...
> 
> 
> 
> 
> 
> Hi,
> 
> I have an Adaptec 2610SA sata raid card I inititally 
> configured it with 3x
> 300gb drives in a Raid 5 configuration. I now have added another 300gb
> drive.
> 
> Using AAC CLI in Slackware linux... i have issued the command 
> container
> reconfigure 0 (0,3,0) to add the fourth disk to the array, It 
> is currently
> in progress in doing this .
> 
> however when i now do container list i get this :-
> 
> Executing: container list
> Num          Total  Oth Chunk          Scsi   Partition
> Label Type   Size   Ctr Size   Usage   B:ID:L Offset:Size
> ----- ------ ------ --- ------ ------- ------ -------------
>  0    Reconf  558GB            Open
>  /dev/sda             RAID_ARRAY
> 62    RAID-5  558GB       64KB None    0:00:0 64.0KB: 186GB
>                                                0:01:0 64.0KB: 186GB
>                                                0:02:0 64.0KB: 186GB
>                                                0:03:0 64.0KB: 186GB
> 
> I assume that what has happened is that the 558GB array is 
> being distributed
> across the four disks. (or is it because the task is still in 
> progress?)
> 
> However i also want to grow the size of the array to max of 
> the four disks.
> (rather than leaving free space on each disk)
> 
> Do i need to use /extend_fs switch (looks as thought this is only for
> windows) or do i need to use the partition resize.
> 
> Any help would be appreciated.
> 
> Thanks
> Toby Moxham
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.0/306 - Release 
> Date: 09/04/2006
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.0/306 - Release 
> Date: 09/04/2006
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

^ permalink raw reply

* problem in iptables!!!
From: varun @ 2006-04-10 13:09 UTC (permalink / raw)
  To: netfilter-devel

Hi all,

             I have a small problem with iptables. Iam trying to use 
iptables in an Cyberton Board (ARM). I compiled it with ucLibc. and i 
also put the images on the board. Then when board comes up i manually 
insmoded the following modules.

ip_conntrack.ko    ipt_REJECT.ko      ipt_state.ko
ip_tables.ko       ipt_conntrack.ko   iptable_filter.ko

Then i tried to add a policy
                      iptables -t filter -A OUTPUT -j REJECT
 This works well in my PC with the 2.6 kernel but gives this error on 
the same kernel arm compiled.
                      The error i get is
                      iptables v1.2.11: Couldn't find target `REJECT'

                       Try `iptables -h' or 'iptables --help' for more 
information.

Can someone tell me what is wrong?

Varun

^ permalink raw reply

* [Bug 6367] New: acpi-cpufreq: fancy CPUfreq values - can't load p4-clockmod anymore
From: bugme-daemon @ 2006-04-10 13:06 UTC (permalink / raw)
  To: cpufreq

http://bugzilla.kernel.org/show_bug.cgi?id=6367

           Summary: acpi-cpufreq: fancy CPUfreq values - can't load p4-
                    clockmod anymore
    Kernel Version: 2.6.16.1 + suspend2-2.2.4
            Status: NEW
          Severity: blocking
             Owner: cpufreq@www.linux.org.uk
         Submitter: oopla@users.sf.net


[P: blockng for me at least, as it prevents me to upgrade the kernel and benefit
 from certain fixes]

Most recent kernel where this bug did not occur: 2.6.15.5, Debian's 2.6.15-1.686
Distribution: Debian Sarge, official + custom/vanilla kernel

Hardware Environment:
# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Celeron(R) CPU 2.70GHz
stepping        : 9
cpu MHz         : 336.750
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr
bogomips        : 5389.63

# lspci
0000:00:00.0 Host bridge: Intel Corp. 82852/855GM Host Bridge (rev 02)
0000:00:00.1 System peripheral: Intel Corp. 855GM/GME GMCH Memory I/O Control
Registers (rev 02)
0000:00:00.3 System peripheral: Intel Corp. 855GM/GME GMCH Configuration Process
Registers (rev 02)
0000:00:02.0 VGA compatible controller: Intel Corp. 82852/855GM Integrated
Graphics Device (rev 02)
0000:00:02.1 Display controller: Intel Corp. 82852/855GM Integrated Graphics
Device (rev 02)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #1 (rev 03)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M)
USB UHCI Controller #2 (rev 03)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI
Controller (rev 03)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 83)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DBM LPC Interface Controller (rev 03)
0000:00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4) Ultra ATA Storage
Controller (rev 03)
0000:00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus
Controller (rev 03)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem
Controller (rev 03)
0000:01:05.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg
NIC (rev 01)
0000:01:08.0 Ethernet controller: Intel Corp. 82801BD PRO/100 VE (MOB) Ethernet
Controller (rev 83)
0000:01:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus
Bridge with ZV Support (rev 33)

Software Environment:
Problem Description:
I've got a P4-celeron Toshiba notebook which used to work ok with the
cpufreq driver p4-clockmod, but that drivers doesn't load anymore in
2.6.16.1, while the acpi-cpufreq does, but offers wrong numbers:

#----OLD----#
# uname -r
2.6.14.7-se-ss2.2-rc15-p4.1
[ss2 stands for suspend2 patch]

with p4-clockmod:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
337500 675000 1012500 1350000 1687500 2025000 2362500 2700000
# lsmod|grep cpu
cpufreq_userspace       5340  0
cpufreq_stats           6020  0
cpufreq_ondemand        6556  0
cpufreq_conservative     7460  0
freq_table              5636  2 cpufreq_stats,p4_clockmod
cpufreq_powersave       2176  0

and works ok.

#----NEW----#
$ uname -r
2.6.16.1-se-ss2.2.2-p4.1
p4-clockmod doesn't load anymore.

with acpi-cpufreq I get fancy CPUfreqs:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2700000 65535000 65535000 65535000 65535000 65535000 65535000 65535000 65535000
+65535000 65535000 65535000 65535000 65535000 65535000

$ lsmod|grep cpu
acpi_cpufreq            7688  1
cpufreq_stats           5508  0
cpufreq_powersave       2304  0
cpufreq_userspace       4884  1
cpufreq_conservative     6820  0
cpufreq_ondemand        6044  0
cpuid                   3460  0
processor              38208  2 acpi_cpufreq,thermal
freq_table              5380  2 acpi_cpufreq,cpufreq_stats

also, cpufreq_stats won't unload anymore and suspend2 gets stuck there.

modprobe p4-clockmod results simply in: 'no such device' and nothing appears in
dmesg.

Steps to reproduce:

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

^ permalink raw reply

* mkpatches: against ref-linux or pristine? (Was: Error compiling with CONFIG_PROFILING (xenoprof))
From: Michael Paesold @ 2006-04-10 13:02 UTC (permalink / raw)
  To: Keir Fraser; +Cc: Xen Devel
In-Reply-To: <7c24dec9d3c0a25c92442001bd623b45@cl.cam.ac.uk>

Keir Fraser wrote:
> On 10 Apr 2006, at 12:28, Michael Paesold wrote:
>
>> "make mkpatches" creates diffs between vanilla+patches/linux-2.6.16 and 
>> xenified+patches/linux-2.6.16).
>
> I would have thought it would make more sense for it to diff against 
> vanilla/linux-2.6.16 (i.e., the pristine tree rather than the ref tree). 
> Most people are going to want an all-in-one patch to apply to a vanilla 
> kernel tree.

You are right, I also see no real value in having one xen patch + several 
extra patches to apply. It rather makes the process of patching more 
complicated. Although rpm helps me with the patching, I still have to 
manually review changes in patches/ everytime I rebase our own RPMs... 
resulting in this very thread. :-)

Does anyone see a use-case for not creating an all-in-one patch? On a second 
thought, a separate "make mkpatch" (or a more explicit target name) could 
provide an all-in-one patch without introducing transitioning problems for 
users of mkpatches.

Should I create a patch to implement that? (Seems rather trivial and 
suitable for my limited Makefile fu.)

Best Regards,
Michael Paesold 

^ permalink raw reply

* [U-Boot-Users] BDI vs. Lauterbach
From: Woodruff, Richard @ 2006-04-10 13:02 UTC (permalink / raw)
  To: u-boot

At the U-boot level I don't know that their should be a huge
differentiator.  When you get to the OS level depending on the type of
work you are doing having a bit tighter integration with the Linux
kernel probably can be more help (context switch awareness and symbol
context switching being something very useful).

I generally use a Lauterbach when I can as I'm familiar with it and it
has been stable and highly useful faster than alternatives.  Also as it
matures many if not all of the internal registers get mapped into the
debugger. I find ETB/ETM to be very useful in debugging low level code.
Being able to step bi-directionally in C or ASM at an exception point
makes things much easier.

LB does have an OS aware layer which I use at times.  It can give you ps
in various formats and access the /proc structure.  More things then
I'll enumerate here.

Regards,
Richard W.

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net [mailto:u-boot-users-
> admin at lists.sourceforge.net] On Behalf Of David Snowdon
> Sent: Monday, April 10, 2006 7:38 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: [U-Boot-Users] BDI vs. Lauterbach
> 
> G'Day,
> 
> I've been looking at a few of the posts regarding debugging tools,
> and the standard answer on this list appears to be "Get a BDI2000".
> I'm presently looking at getting a debugger to use to bring up a new
> board, get U-Boot going, and eventually do a lot of OS work (a new OS
> that we're developing - see http://www.ertos.nicta.com.au -- sorry,
> shameless plug).
> 
> Some people that we are working with use the Lauterbach Trace32 tools
> extensively, and we've had some good experiences with them. I was
> wondering if anyone on this list had used both (particularly while
> developing U-Boot), and how the BDI-2000 stacks up against the
> Lauterbach equivalent. (Apart from being significantly cheaper).
> 
> Any insights much appreciated.
> 
> Many thanks,
> 
> David Snowdon,
> Research Engineer,
> National ICT Australia,
> http://www.ertos.nicta.com.au
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding
> territory!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users

^ permalink raw reply

* Re: fs/binfmt_elf.c:maydump()
From: Daniel Jacobowitz @ 2006-04-10 13:01 UTC (permalink / raw)
  To: David S. Miller; +Cc: linux-kernel
In-Reply-To: <20060407.132753.50049697.davem@davemloft.net>

On Fri, Apr 07, 2006 at 01:27:53PM -0700, David S. Miller wrote:
> Yes, and it would also dump text segments that get written
> by the dynamic linker such as the .plt, which we definitely
> do want.
> 
> It would also dump impure text segment cases as well.

Well, I'm OK with this, upon reflection.  Might as well merge it and
see if anyone else is appalled :-)

-- 
Daniel Jacobowitz
CodeSourcery

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