* Re: [PATCH] oprofile per-cpu buffer overrun
From: John Levon @ 2004-01-26 10:32 UTC (permalink / raw)
To: Andrew Morton; +Cc: Philippe Elie, linux-kernel
In-Reply-To: <20040125200701.3c7b769a.akpm@osdl.org>
On Sun, Jan 25, 2004 at 08:07:01PM -0800, Andrew Morton wrote:
> When implementing a circular buffer it is better to not constrain the head
> and tail indices - just let them grow and wrap without bound. You only need
> to bring them in-bounds when you actually use them to index the buffer.
I'm not sure why that's better.
> - head-tail is always the amount of used space, no need to futz around
> handling the case where one has wrapped and the other hasn't.
I admit I have a hangover, but it seems to me it would actually be more
complicated to make damn sure that the integer overflow case is
definitely handled properly.
I clearly can't write functioning ring buffers :), so I'd prefer it to
stay as simple as possible.
regards,
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
^ permalink raw reply
* Re: clipper f/r locking failure
From: Mgr. Peter Tuharsky @ 2004-01-26 10:31 UTC (permalink / raw)
To: Yassen Damyanov, linux-msdos
In-Reply-To: <40151A6D.8070301@troyer.co.at>
And also, try running it under stable 1.2.0 DOSEMU and the beta9 version
of FREEDOS (avaiable near binaries download). I know that with older
versions of FREEDOS it didn't work.
Peter
Yassen Damyanov wrote:
> hi all,
>
> I've been trying for quite some time to run a clipper accounting
> application within DOSEMU/FreeDOS (also within DOSEMU/MS-DOS 7). The
> thing runs just fine until time comes to do the clipper file and
> record locking (flock, rlock). In this case, when running two DOSEMU
> instances on one and the same machine, and files are shared via
> lredir, one of two clients hangs. (If you wonder how two clients
> operate on one machine at the same time, they are remote X terminals).
>
> DOSEMU leaves a message like this after terminating the hang client:
>
> "ERROR: SS selector invalid: 0x6A22, type=0 np=1"
>
> The linux version is 2.4.20; the DOSEMU is 1.1.99. I tried with the
> FreeDOS shipped together with the binary distro of DOSEMU; also with
> MS-DOS 7 as I said already (which shows me that the problem, ot at
> leats part of it, is not in the DOS but in the emulator). The clipper
> version is 5.3b and uses standard clipper locking functions (flock,
> rlock). If any other information is needed, just let me know.
>
> Please help me somehow to solve this. I was fighting quite a long time
> with this sole trouble. If I succeed, a well known accounting software
> in my country will get a reliable and legal open source platform to
> run on! Would be REALLY GREAT! Many people know of the experiment and
> often ask me how are things going on... I would like DOSEMU to win
> this case :-) Hope it will.
>
> --
>
> What I intend to try last (after trying so many options, like sharing
> a disk image or a real vfat partion (yes, bad ideas, but I tried these
> to see what happens), is to activate networking on each DOSEMU session
> and try to mount to a samba share somewhere on the local net.
>
> Any comments and suggestions are more than welcome.
> I would appreciate any help -- thanks in advance!
>
> Regards,
> Yassen
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" 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
* Re: MPC823E SMC/I2C/SPI micropatch
From: Jan Damborsky @ 2004-01-26 10:29 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc-dev
In-Reply-To: <20040126093345.5EC57C108D@atlas.denx.de>
Wolfgang Denk wrote:
> In message <4014DD1D.8070704@devcom.cz> you wrote:
>
>>I think I have selected the __correct__ one.
>>Situated in ./arch/ppc/8xx_io/micropatch_850.c file.
>
>
> No!!! The micropatch_850.c is ONLY for MPC850, and NOT for MPC823(E).
OK, so I will try and use micropatch_8xx.c instead.
>
>
>>- it is determined for 850 and 823E processors (I hope).
>
>
> Wrong.
But I really do not uderstand, why there is following
sentence in micropatch_850.c file:
The patch applicable to the 850 and 823E processors.
And in micropatch_8xx.c:
The patch applicable to all 8xx family except 850 and 823E.
I think it is rather misleading, is'nt it ?
Sincerely, Jan Damborsky
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: clipper f/r locking failure
From: Mgr. Peter Tuharsky @ 2004-01-26 10:27 UTC (permalink / raw)
To: Yassen Damyanov, linux-msdos
In-Reply-To: <40151A6D.8070301@troyer.co.at>
Hi!
I run a clipper app by two users simultaneously on a machine, using
LTSP thin client for one of them. I don't use lredir; both users have
their own dosemu installations, only the Clipper program directory is
physically only at one place, and for the second user is accessed by
using standard directory symlink placed inside of his DOSEMU structure.
It works nice for me, on standard local Linux filesystem Ext3 under
Linux 2.6. Just the access privilegues are to be set correctly in Linux;
both users in the same group with rw access to all files, try running
chgrp -R <groupname> *
chmod -R 770 *
for the Clipper program directory
and place the
umask 007
command somewhere near beginning of dosemu starting script (in both
user's installations).
Does it help?
Yassen Damyanov wrote:
> hi all,
>
> I've been trying for quite some time to run a clipper accounting
> application within DOSEMU/FreeDOS (also within DOSEMU/MS-DOS 7). The
> thing runs just fine until time comes to do the clipper file and
> record locking (flock, rlock). In this case, when running two DOSEMU
> instances on one and the same machine, and files are shared via
> lredir, one of two clients hangs. (If you wonder how two clients
> operate on one machine at the same time, they are remote X terminals).
>
> DOSEMU leaves a message like this after terminating the hang client:
>
> "ERROR: SS selector invalid: 0x6A22, type=0 np=1"
>
> The linux version is 2.4.20; the DOSEMU is 1.1.99. I tried with the
> FreeDOS shipped together with the binary distro of DOSEMU; also with
> MS-DOS 7 as I said already (which shows me that the problem, ot at
> leats part of it, is not in the DOS but in the emulator). The clipper
> version is 5.3b and uses standard clipper locking functions (flock,
> rlock). If any other information is needed, just let me know.
>
> Please help me somehow to solve this. I was fighting quite a long time
> with this sole trouble. If I succeed, a well known accounting software
> in my country will get a reliable and legal open source platform to
> run on! Would be REALLY GREAT! Many people know of the experiment and
> often ask me how are things going on... I would like DOSEMU to win
> this case :-) Hope it will.
>
> --
>
> What I intend to try last (after trying so many options, like sharing
> a disk image or a real vfat partion (yes, bad ideas, but I tried these
> to see what happens), is to activate networking on each DOSEMU session
> and try to mount to a samba share somewhere on the local net.
>
> Any comments and suggestions are more than welcome.
> I would appreciate any help -- thanks in advance!
>
> Regards,
> Yassen
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-msdos" 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
* Bluetooth USB oopses on unplug (2.6.1)
From: Pavel Machek @ 2004-01-26 10:20 UTC (permalink / raw)
To: kernel list, maxk
Hi!
In 2.6.1, bluetooth-over-usb (hci_usb) works very well... As long as I
do not unplug it. When I do, it oopses. Is there newer version of
bluetooth that I should try?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply
* Re: usx2y dependencies
From: Takashi Iwai @ 2004-01-26 10:20 UTC (permalink / raw)
To: Martin Langer; +Cc: alsa-devel, annabellesgarden
In-Reply-To: <20040124002328.GA1946@tuba.home>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
At Sat, 24 Jan 2004 01:23:28 +0100,
Martin Langer wrote:
>
>
> Hi,
>
> usx2y build by "./configure --with-cards=usb-usx2y" has a dependency problem:
>
> depmod: *** Unresolved symbols in
> /lib/modules/2.4.23/kernel/sound/usb/usx2y/snd-usb-usx2y.o
> depmod: snd_usbmidi_disconnect_Rc1a56322
> depmod: snd_hack_usb_set_interface_R5b6905b8
> depmod: snd_usb_create_midi_interface_R5a5eff3a
>
> ./configure --with-cards=usb-usx2y,usb-audio fix this problem, but OTOH it
> looks fine in /alsa-driver/utils/Modules.dep -- usx2y depends there on
> snd-usb-audio and that seems to be ok.
>
> Any hints?
try the attached patch.
Takashi
[-- Attachment #2: Type: text/plain, Size: 554 bytes --]
Index: alsa-driver/usb/Makefile
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-driver/usb/Makefile,v
retrieving revision 1.13
diff -u -r1.13 Makefile
--- alsa-driver/usb/Makefile 25 Nov 2003 11:13:35 -0000 1.13
+++ alsa-driver/usb/Makefile 26 Jan 2004 10:19:35 -0000
@@ -10,6 +10,9 @@
# for compatibility
extra-snd-usb-audio-objs := usbcompat.o
+# usx2y depends on usb-audio
+obj-$(CONFIG_SND_USB_USX2Y) += snd-usb-audio.o
+
obj-$(CONFIG_SND) += usx2y/
export-objs := usbaudio.o usbmidi.o
^ permalink raw reply
* Re: Status of ADI AD1888
From: Takashi Iwai @ 2004-01-26 10:17 UTC (permalink / raw)
To: Carlos Fernandez Sanz; +Cc: David Lloyd, alsa-devel
In-Reply-To: <008c01c3e1ea$2b754b50$1530a8c0@HUSH>
At Fri, 23 Jan 2004 20:50:36 +0100,
Carlos Fernandez Sanz wrote:
>
> David,
>
> Apparently not. I've been doing some research and while the driver loads,
> etc, I get no sound (everything to the max in the mixer, speakers plugged,
> etc :-)). If I hadn't find anyone else with the exact same problem I would
> just assume I'm plain stupid (or add item to the list proving it)...
AD1888 is an ac97 codec, so definitely intel8x0 is the right driver.
show /etc/asound.state (after running "alsactl store") and
/proc/asound/card0/codec97#0/* files for debugging.
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)
From: Lutz Vieweg @ 2004-01-26 10:16 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: Linux Kernel Mailinglist, adilger
In-Reply-To: <1075058769.1756.8.camel@teapot.felipe-alfaro.com>
Felipe Alfaro Solana wrote:
> On Sun, 2004-01-25 at 19:29, Lutz Vieweg wrote:
>
>>I run a server that usually doesn't have to do anything on the local filesystems,
>>it just needs to answer some requests and perform some computations in RAM.
>>
>>So I use the "hdparm -S 123" parameter setting to keep the (IDE) system disk from
>>spinning unneccessarily.
>>
>>Alas, since an upgrade to kernel 2.6 and ext3 filesystem, I cannot find a way to
>>let the harddisk spin down - I found out that "kjournald" writes a few blocks every
>>few seconds.
>>
>>As I wouldn't like to downgrade to ext2: Is there any way to keep the 2.6 kjournald
>>from writing to idle disks?
>>
>>I cannot see a good reason why kjournald would write when there are no dirty buffers -
>>but still it does.
>
>
> Have you tried playing with the laptop-mode patch? It's already in the
> -mm kernel tree from Andrew Morton. I've been playing with it a little
> (just a few minutes) and seems keep the disks spun down for some time.
This "laptop-mode" patch would make things far worse than they're now: Spinning
up the disk about every 10min would reduce their lifetime significantly instead
of extending it.
It's not a laptop, but a server with an ordinary 3.5" harddisk I'm speaking about,
my goal is not saving power, but spinning down a harddisk that does not need to
spin up the whole day long.
What I'm questioning is whether there's a need to write to idle disks at all -
does anybody know why kjournald writes data even if there is nothing to commit at all?
Regards,
Lutz Vieweg
^ permalink raw reply
* Re: [uml-devel] Draft docs for port console channel
From: Dan Shearer @ 2004-01-24 8:20 UTC (permalink / raw)
To: Jeff Dike; +Cc: user-mode-linux-devel
In-Reply-To: <20040123144320.GB6768@ccure.user-mode-linux.org>
On Fri, Jan 23, 2004 at 09:43:20AM -0500, Jeff Dike wrote:
> > The login program, which is receiving data from the master side of
> > the pty that telnetd opened, sends the data back through this pipe
>
> And no. port_helper passes the actual file descriptor back to UML through
> the unix socket on fd 3. Then, UML receives characters directly from telnetd
> without port_helper having to relay them.
Got it now. Here is a patch to port-helper that might help others.
> Otherwise, this is pretty good.
You mean apart from the fact that I missed the point entirely.
Another fumbling newbie question: why can't we just have the fd for the
unix socket for xterm connected before xterm is exec'd? Then there would
be no need for open_socket in port-helper. I'm sure there's an obvious
reason.
--
Dan Shearer
dan@shearer.org
--- port-helper.c.orig
+++ port-helper.c
@@ -1,3 +1,15 @@
+/* port-helper
+
+Used by the port and xterm console channels for User Mode Linux.
+
+Tells UML "here is a file descriptor for my stdin as given to me by
+xterm or telnetd". Once UML has that (with os_rcv_fd()) UML opens it
+for read and write, and the console is functional.
+
+(c) Jeff Dike 2002-2004
+
+*/
+
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>
@@ -8,8 +20,17 @@
#include <sys/un.h>
#include <sys/uio.h>
+/* pass the fd over an fd that is already connected to a socket */
static void send_fd(int fd, int target)
{
+
+ /* File descriptors are specific to a process and normally only
+ sharable with another process by inheritence with fork(). The
+ alternative is to use sendmsg with a special flag that says
+ "I'm knowingly giving another process information from my private
+ file descriptor table" (SCM_RIGHTS)
+ */
+
char anc[CMSG_SPACE(sizeof(fd))];
struct msghdr msg;
struct cmsghdr *cmsg;
@@ -42,6 +63,8 @@
}
}
+/* for xterm we don't have an open socket, we only have the name
+ of a file used as a Unix socket by UML. So we need to open it. */
static int open_socket(char *name)
{
struct sockaddr_un sock;
@@ -74,12 +97,17 @@
{
int fd;
- if((argc > 1) && !strcmp(argv[1], "-uml-socket")) fd = open_socket(argv[2]);
- else fd = 3;
+ if((argc > 1) && !strcmp(argv[1], "-uml-socket")) {
+ /* inherited a filename not an open fd */
+ fd = open_socket(argv[2]);
+ } else {
+ /* inherited fd of the listening TCP socket */
+ fd = 3;
+ }
signal(SIGHUP, SIG_IGN);
if(ioctl(0, TIOCNOTTY, 0) < 0)
- perror("TIOCNOTTY failed");
+ perror("TIOCNOTTY failed in port-helper, check UML's exec call for xterm or telnetd");
send_fd(0, fd);
pause();
return(0);
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: cfi_cmdset_0002 -- erase suspends broken.
From: David Vrabel @ 2004-01-26 10:12 UTC (permalink / raw)
To: Linux MTD List
In-Reply-To: <3FDDD939.8030302@arcom.com>
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
David Vrabel wrote:
>
> The problem with the occasional bit errors appears to only occur when
> the erase is suspended for a write so I've temporarily disabled that.
Seems I left the patch off that does this.
David Vrabel
--
David Vrabel, Design Engineer
Arcom, Clifton Road Tel: +44 (0)1223 411200 ext. 3233
Cambridge CB1 7EA, UK Web: http://www.arcom.com/
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the addressee only and should not be disclosed to any other party. Unauthorised recipients are requested to preserve this confidentiality. Please advise the sender if the addressee is not resident at the receiving end. Email to and from Arcom is automatically monitored for operational and lawful business reasons.
This message has been checked for all viruses by MessageLabs Virus Control Centre.
[-- Attachment #2: mtd-cfi_cmdset_0002.c-erase-suspend-fix.patch --]
[-- Type: text/plain, Size: 3378 bytes --]
%patch
Index: linux-2.4.21/drivers/mtd/chips/cfi_cmdset_0002.c
===================================================================
--- linux-2.4.21.orig/drivers/mtd/chips/cfi_cmdset_0002.c 2003-12-11 15:03:06.000000000 +0000
+++ linux-2.4.21/drivers/mtd/chips/cfi_cmdset_0002.c 2003-12-15 15:34:01.000000000 +0000
@@ -500,27 +500,37 @@
return 0;
case FL_ERASING:
+ if (mode == FL_WRITING) /* FIXME: Erase-suspend-program appears broken. */
+ goto sleep;
+
if (!(mode == FL_READY || mode == FL_POINT
|| (mode == FL_WRITING && (cfip->EraseSuspend & 0x2))
|| (mode == FL_WRITING && (cfip->EraseSuspend & 0x1))))
goto sleep;
+ oldstatus = cfi_read(map, adr);
+ status = cfi_read(map, adr);
+ if ((oldstatus ^ status) & dq2) {
+ printk(KERN_ERR "Can't suspend erase -- block in progress\n");
+ goto sleep;
+ }
+
/* Erase suspend */
/* FIXME - is there a way to verify suspend? */
- cfi_write(map, CMD(0xB0), adr);
+ cfi_write(map, CMD(0xB0), chip->in_progress_block_addr);
chip->oldstate = FL_ERASING;
chip->state = FL_ERASE_SUSPENDING;
chip->erase_suspended = 1;
for (;;) {
- oldstatus = cfi_read(map, adr);
- status = cfi_read(map, adr);
- if (((oldstatus ^ status) & dq2) == dq2)
+ oldstatus = cfi_read(map, chip->in_progress_block_addr);
+ status = cfi_read(map, chip->in_progress_block_addr);
+ if (((oldstatus ^ status) & dq6) == 0)
break;
if (time_after(jiffies, timeo)) {
/* Urgh. Resume and pretend we weren't here. */
/* FIXME - is there a way to verify resume? */
- cfi_write(map, CMD(0x30), adr);
+ cfi_write(map, CMD(0x30), chip->in_progress_block_addr);
chip->state = FL_ERASING;
chip->oldstate = FL_READY;
printk(KERN_ERR "Chip not ready after erase "
@@ -534,7 +544,7 @@
/* Nobody will touch it while it's in state FL_ERASE_SUSPENDING.
So we can just loop here. */
}
- chip->state = FL_STATUS;
+ chip->state = FL_READY;
return 0;
case FL_POINT:
@@ -562,7 +572,7 @@
switch(chip->oldstate) {
case FL_ERASING:
chip->state = chip->oldstate;
- cfi_write(map, CMD(0x30), adr);
+ cfi_write(map, CMD(0x30), chip->in_progress_block_addr);
chip->oldstate = FL_READY;
chip->state = FL_ERASING;
break;
@@ -1507,7 +1517,8 @@
chip->state = FL_ERASING;
chip->erase_suspended = 0;
-
+ chip->in_progress_block_addr = adr;
+
cfi_spin_unlock(chip->mutex);
set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout((chip->erase_time*HZ)/(2*1000));
@@ -1739,6 +1750,7 @@
chip->state = FL_ERASING;
chip->erase_suspended = 0;
+ chip->in_progress_block_addr = adr;
cfi_spin_unlock(chip->mutex);
set_current_state(TASK_UNINTERRUPTIBLE);
Index: linux-2.4.21/include/linux/mtd/flashchip.h
===================================================================
--- linux-2.4.21.orig/include/linux/mtd/flashchip.h 2003-12-11 11:19:59.000000000 +0000
+++ linux-2.4.21/include/linux/mtd/flashchip.h 2003-12-11 15:09:22.000000000 +0000
@@ -61,6 +61,7 @@
int write_suspended:1;
int erase_suspended:1;
+ unsigned long in_progress_block_addr;
spinlock_t *mutex;
spinlock_t _spinlock; /* We do it like this because sometimes they'll be shared. */
^ permalink raw reply
* [linux-lvm] LVM2 + Linux 2.6.1 questions
From: Dale Gallagher @ 2004-01-26 10:06 UTC (permalink / raw)
To: linux-lvm
Hi there
I've successfully setup LVM2.2.00.08 and
device-mapper.1.00.07 on a Slackware 9.1 host with Linux
2.6.1. I have a question or two:
1) Would a shutdown error something like the following, be
attributed to LVM and/or device-mapper?
/proc/devices: fopen failed - no such file or directory
2) Why do I see, for example, a /dev/mapper/v01-home entry,
instead of /dev/v01/home, when running 'df' and 'mount'? I
see that /dev/mapper/v01/home symlinks to
/dev/mapper/v01-home, which must account for this, though I
thought that because I'd specified /dev/v01/home, that it'd
appear as such? Not that this really matters I suppose ;-)
$ df -h | grep v01
/dev/mapper/v01-home 2.9G 444M 2.4G 16% /home
/dev/mapper/v01-usr 2.0G 1.1G 760M 60% /usr
/dev/mapper/v01-var 985M 30M 906M 4% /var
$ mount | grep v01
/dev/mapper/v01-home on /home type ext3 (rw)
/dev/mapper/v01-usr on /usr type ext3 (rw)
/dev/mapper/v01-var on /var type ext3 (rw)
3) Does anyone know when LVM2 specific docs, such as a
HOWTO and FAQ will be available?
Thanks
Dale
^ permalink raw reply
* vga16fb mode change.
From: Dave Jones @ 2004-01-23 15:33 UTC (permalink / raw)
To: linux-fbdev-devel
Guys,
How come the 2.6 vga16fb driver doesn't change the display
to the framebuffer when it's modprobe'd any more like the 2.4
used to ?
Is this an intentional change, or a regression?
Dave
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Port Amit's kgdb to netpoll
From: Pavel Machek @ 2004-01-26 9:57 UTC (permalink / raw)
To: Amit S. Kale, kernel list, mason
Hi!
This is "port Amit's kgdb to netpoll code" patch. It maskes kgdb_eth.c
quite a lot cleaner.
But, at this point only compiled it, and it probably will not
work. If someone wants to pick it up, feel free...
Pavel
--- tmp/linux/drivers/net/kgdb_eth.c 2004-01-26 10:18:45.000000000 +0100
+++ linux/drivers/net/kgdb_eth.c 2004-01-24 19:02:28.000000000 +0100
@@ -14,6 +14,9 @@
* Reveral changes to make it free of device driver changes.
* Added internal buffers for this interface.
* by Amit S. Kale <amitkale@emsyssoft.com>
+ *
+ * Refactored for netpoll API by Matt Mackall <mpm@selenic.com>
+ *
* Some cleanups by Pavel Machek <pavel@suse.cz>
*/
@@ -37,6 +40,8 @@
#include <linux/irq.h>
#include <linux/inet.h>
#include <linux/notifier.h>
+#include <linux/netpoll.h>
+
#include <net/tcp.h>
#include <net/udp.h>
@@ -47,656 +52,121 @@
#include <asm/system.h>
#include <asm/atomic.h>
-#define GDB_BUF_SIZE 512 /* power of 2, please */
-
-#define CHUNKSIZE 30
-#define MAXINCHUNK (CHUNKSIZE + 8)
-
-static char kgdb_buf[GDB_BUF_SIZE];
-static int kgdb_buf_in_inx;
-static atomic_t kgdb_buf_in_cnt;
-static int kgdb_buf_out_inx;
-
-static unsigned int kgdb_remoteip = 0;
-static unsigned short kgdb_listenport = 6443;
-static unsigned short kgdb_sendport= 6442;
-static int kgdb_eth = -1; /* Default tty mode */
-static unsigned char kgdb_remotemac[6] = {0xff,0xff,0xff,0xff,0xff,0xff};
-static unsigned char kgdb_localmac[6] = {0xff,0xff,0xff,0xff,0xff,0xff};
-
-static char kgdbeth_sendbuf[MAXINCHUNK];
-static int kgdbeth_sendbufchars;
-static irqreturn_t (*kgdbeth_irqhandler)(int, void *, struct pt_regs *) = NULL;
-
-struct net_device *kgdb_netdevice = NULL;
-
-/* Indicates dept of recursion for xmitlock hold */
-static int xlock_hold_count = 0;
-
-/* kgdb ethernet ring buffers. Increase the space if you get panics in
- * kgdbeth_alloc_skb.
- * Status of send_skbs can be known from the field users.
- * If it's 1 the buffer is free.
- * If the count 2 or more, the buffer is in use.
- * Keeping 1 as the initial count prevents kfree_skb from freeing it. */
-#define SEND_BUFLEN 1024
-#define NUM_SENDBUF 128
-static char *send_bufs[NUM_SENDBUF];
-static struct sk_buff *send_skbs[NUM_SENDBUF];
-static struct sk_buff *send_skb;
-static int bufnum;
-
-static char kgdb_netdev_name[16];
-
-#ifdef CONFIG_KGDB_CONSOLE
-#error kgdb over ethernet is not yet ready for console messages.
-#endif
-
-/*
- * Returns next skb from kgdb skbs.
- * Initializes users field of the skb to 2 so that kfree_skb doesn't attempt
- * freeing it.
- * Always call after holding xmitlock of the ethernet device.
- */
-
-struct sk_buff *kgdbeth_alloc_skb(int size)
-{
- struct sk_buff *skb;
- u8 *data;
- int i;
-
- i = bufnum;
-
- do {
- skb = send_skbs[i];
-
- if (atomic_read(&skb->users) == 1) {
- bufnum = i;
- i = -1;
- break;
- }
- i = (i + 1) % NUM_SENDBUF;
- } while (i != bufnum);
- if (i == bufnum) {
- panic("kgdb ethernet buffer overflow\n");
- }
- data = (u8 *)(send_bufs[bufnum]);
-
- size = SKB_DATA_ALIGN(size);
- if (size + sizeof(struct skb_shared_info) > SEND_BUFLEN)
- panic("kgdb ethernet buffer too short for this request");
-
- memset(skb, 0, offsetof(struct sk_buff, truesize));
- skb->truesize = size + sizeof(struct sk_buff);
- atomic_set(&skb->users, 2);
- skb->head = data;
- skb->data = data;
- skb->tail = data;
- skb->end = data + size;
-
- atomic_set(&(skb_shinfo(skb)->dataref), 1);
- skb_shinfo(skb)->nr_frags = 0;
- skb_shinfo(skb)->tso_size = 0;
- skb_shinfo(skb)->tso_segs = 0;
- skb_shinfo(skb)->frag_list = NULL;
-
- return skb;
-}
-
-/* Holds xmitlock of the ethernet device
- * Recursive calls allowed */
-static void kgdbeth_lock(void)
-{
- if (spin_is_locked(&kgdb_netdevice->xmit_lock)) {
- if (kgdb_netdevice->xmit_lock_owner == smp_processor_id()) {
- goto gotit;
- }
- }
- spin_lock(&kgdb_netdevice->xmit_lock);
- kgdb_netdevice->xmit_lock_owner = smp_processor_id();
-
-gotit:
- xlock_hold_count++;
-}
+#define IN_BUF_SIZE 512 /* power of 2, please */
+#define OUT_BUF_SIZE 256
-/* releases xmitlock of the ethernet device
- * Recursive calls allowed */
-static void kgdbeth_unlock(void)
-{
- if (--xlock_hold_count) {
- kgdb_netdevice->xmit_lock_owner = -1;
- spin_unlock(&kgdb_netdevice->xmit_lock);
- }
-}
-
-/*
- * Get a char if available, return -1 if nothing available.
- * Empty the receive buffer first, then look at the interface hardware.
- */
-static int
-read_char(void)
-{
- /* intr routine has queued chars */
- if (atomic_read(&kgdb_buf_in_cnt) != 0) {
- int chr;
-
- chr = kgdb_buf[kgdb_buf_out_inx++];
- kgdb_buf_out_inx &= (GDB_BUF_SIZE - 1);
- atomic_dec(&kgdb_buf_in_cnt);
- return chr;
- }
-
- return -1; /* no data */
-}
+static char in_buf[IN_BUF_SIZE], out_buf[OUT_BUF_SIZE];
+static int in_head, in_tail, out_count;
+static atomic_t in_count;
+int kgdboe = 0; /* Default to tty mode */
+
+extern void set_debug_traps(void);
+extern void breakpoint(void);
+static void rx_hook(struct netpoll *np, int port, char *msg, int len);
+
+static struct netpoll np = {
+ .name = "kgdboe",
+ .dev_name = "eth0",
+ .rx_hook = rx_hook,
+ .local_port = 6443,
+ .remote_port = 6442,
+ .remote_mac = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff},
+};
-/*
- * Wait until the interface can accept a char, then write it.
- */
-static void
-write_buffer(char *buf, int len)
+int eth_getDebugChar(void)
{
- int total_len, eth_len, ip_len, udp_len;
- struct in_device *in_dev;
- struct sk_buff *skb;
- struct udphdr *udph;
- struct iphdr *iph;
- struct ethhdr *eth;
-
- if (!(in_dev = (struct in_device *) kgdb_netdevice->ip_ptr)) {
- panic("No in_device available for interface!\n");
- }
-
- if (!(in_dev->ifa_list)) {
- panic("No interface address set for interface!\n");
- }
- kgdbeth_lock();
+ int chr;
- udp_len = len + sizeof(struct udphdr);
- ip_len = eth_len = udp_len + sizeof(struct iphdr);
- total_len = eth_len + ETH_HLEN;
-
- skb = kgdbeth_alloc_skb(total_len);
-
- skb_reserve(skb, total_len - 1);
-
- memcpy(skb->data, (unsigned char *) buf, len);
- skb->len += len;
-
- udph = (struct udphdr *) skb_push(skb, sizeof(*udph));
- udph->source = htons(kgdb_listenport);
- udph->dest = htons(kgdb_sendport);
- udph->len = htons(udp_len);
- udph->check = 0;
-
- iph = (struct iphdr *)skb_push(skb, sizeof(*iph));
- iph->version = 4;
- iph->ihl = 5;
- iph->tos = 0;
- iph->tot_len = htons(ip_len);
- iph->id = 0;
- iph->frag_off = 0;
- iph->ttl = 64;
- iph->protocol = IPPROTO_UDP;
- iph->check = 0;
- iph->saddr = in_dev->ifa_list->ifa_address;
- iph->daddr = kgdb_remoteip;
- iph->check = ip_fast_csum((unsigned char *)iph, iph->ihl);
-
- eth = (struct ethhdr *) skb_push(skb, ETH_HLEN);
- eth->h_proto = htons(ETH_P_IP);
- memcpy(eth->h_source, kgdb_localmac, kgdb_netdevice->addr_len);
- memcpy(eth->h_dest, kgdb_remotemac, kgdb_netdevice->addr_len);
-
- kgdb_netdevice->hard_start_xmit(skb, kgdb_netdevice);
- BUG_ON(atomic_read(&skb->users) != 1);
- kgdbeth_unlock();
-}
-
-static void kgdbeth_flush(void)
-{
- if (!kgdbeth_sendbufchars) {
- return;
- }
- write_buffer(kgdbeth_sendbuf, kgdbeth_sendbufchars);
- kgdbeth_sendbufchars = 0;
-}
+ while (atomic_read(&in_count) == 0)
+ netpoll_poll(&np);
-static void kgdbeth_write_char(int chr)
-{
- if (kgdbeth_sendbufchars == MAXINCHUNK) {
- kgdbeth_flush();
- }
- kgdbeth_sendbuf[kgdbeth_sendbufchars++] = chr;
+ chr = in_buf[in_tail++];
+ in_tail &= (IN_BUF_SIZE - 1);
+ atomic_dec(&in_count);
+ return chr;
}
-
-/*
- * In the interrupt state the target machine will not respond to any
- * arp requests, so handle them here.
- */
-
-static void
-kgdb_eth_reply_arp(void)
+void eth_flushDebugChar(void)
{
- if (send_skb) {
- kgdbeth_lock();
- kgdb_netdevice->hard_start_xmit(send_skb, kgdb_netdevice);
- send_skb = NULL;
- kgdbeth_unlock();
+ if(out_count && np.dev) {
+ netpoll_send_udp(&np, out_buf, out_count);
+ out_count = 0;
}
}
-static int
-make_arp_request(struct sk_buff *skb)
+void eth_putDebugChar(int chr)
{
- struct arphdr *arp;
- unsigned char *arp_ptr;
- int type = ARPOP_REPLY;
- int ptype = ETH_P_ARP;
- u32 sip, tip;
- unsigned char *sha, *tha;
- struct in_device *in_dev = (struct in_device *) kgdb_netdevice->ip_ptr;
-
- /* No arp on this interface */
-
- if (kgdb_netdevice->flags & IFF_NOARP) {
- return 0;
- }
-
- if (!pskb_may_pull(skb, (sizeof(struct arphdr) +
- (2 * kgdb_netdevice->addr_len) +
- (2 * sizeof(u32))))) {
- return 0;
- }
-
- skb->h.raw = skb->nh.raw = skb->data;
- arp = skb->nh.arph;
-
- if ((arp->ar_hrd != htons(ARPHRD_ETHER) &&
- arp->ar_hrd != htons(ARPHRD_IEEE802)) ||
- arp->ar_pro != htons(ETH_P_IP)) {
- return 0;
- }
-
- /* Understand only these message types */
-
- if (arp->ar_op != htons(ARPOP_REQUEST)) {
- return 0;
- }
-
- /* Extract fields */
-
- arp_ptr= (unsigned char *)(arp+1);
- sha = arp_ptr;
- arp_ptr += kgdb_netdevice->addr_len;
- memcpy(&sip, arp_ptr, 4);
- arp_ptr += 4;
- tha = arp_ptr;
- arp_ptr += kgdb_netdevice->addr_len;
- memcpy(&tip, arp_ptr, 4);
-
- if (tip != in_dev->ifa_list->ifa_address) {
- return 0;
- }
-
- if (kgdb_remoteip != sip) {
- return 0;
- }
-
- /*
- * Check for bad requests for 127.x.x.x and requests for multicast
- * addresses. If this is one such, delete it.
- */
-
- if (LOOPBACK(tip) || MULTICAST(tip)) {
- return 0;
- }
- /* reply to the ARP request */
-
- kgdbeth_lock();
- if (send_skb) {
- /* Get rid of any previous replies to ARP request. We hope
- * that regular reply to ARP by network layers would have gone
- * out by now. */
- kfree_skb(send_skb);
- }
- send_skb = kgdbeth_alloc_skb(sizeof(struct arphdr) +
- 2 * (kgdb_netdevice->addr_len + 4) +
- LL_RESERVED_SPACE(kgdb_netdevice));
- kgdbeth_unlock();
-
- skb_reserve(send_skb, LL_RESERVED_SPACE(kgdb_netdevice));
- send_skb->nh.raw = send_skb->data;
- arp = (struct arphdr *) skb_put(send_skb, sizeof(struct arphdr) + 2 * (kgdb_netdevice->addr_len + 4));
- send_skb->dev = kgdb_netdevice;
- send_skb->protocol = htons(ETH_P_ARP);
-
- /* Fill the device header for the ARP frame */
-
- if (kgdb_netdevice->hard_header &&
- kgdb_netdevice->hard_header(send_skb, kgdb_netdevice, ptype,
- kgdb_remotemac, kgdb_localmac,
- send_skb->len) < 0) {
- kfree_skb(send_skb);
- return 0;
- }
-
- /*
- * Fill out the arp protocol part.
- *
- * we only support ethernet device type,
- * which (according to RFC 1390) should always equal 1 (Ethernet).
- */
-
- arp->ar_hrd = htons(kgdb_netdevice->type);
- arp->ar_pro = htons(ETH_P_IP);
-
- arp->ar_hln = kgdb_netdevice->addr_len;
- arp->ar_pln = 4;
- arp->ar_op = htons(type);
-
- arp_ptr=(unsigned char *)(arp + 1);
-
- memcpy(arp_ptr, kgdb_netdevice->dev_addr, kgdb_netdevice->addr_len);
- arp_ptr += kgdb_netdevice->addr_len;
- memcpy(arp_ptr, &tip, 4);
- arp_ptr += 4;
- memcpy(arp_ptr, kgdb_localmac, kgdb_netdevice->addr_len);
- arp_ptr += kgdb_netdevice->addr_len;
- memcpy(arp_ptr, &sip, 4);
- return 0;
+ out_buf[out_count++] = chr;
+ if(out_count == OUT_BUF_SIZE)
+ eth_flushDebugChar();
}
-
-/*
- * Accept an skbuff from net_device layer and add the payload onto
- * kgdb buffer
- *
- * When the kgdb stub routine read_char() is called it draws characters
- * out of the buffer until it is empty and then polls the hardware.
- *
- * Return value of NET_RX_DROP means skb was used by this function.
- * NET_RX_SUCCESS indicates this function didn't use it.
-
- * Be prepared to respond to ARP requests. Let the caller also handle
- * them if debugger is not active. We'll respond to the ARP request when
- * a debugging session begins. It's necessary to respond to the request as the
- * debugging session may begin even before kernel has a chance finish the
- * response.
- */
-int
-kgdb_net_interrupt(struct sk_buff *skb)
+static void rx_hook(struct netpoll *np, int port, char *msg, int len)
{
- unsigned char chr;
- struct iphdr *iph = (struct iphdr*)skb->data;
- struct udphdr *udph= (struct udphdr*)(skb->data+(iph->ihl<<2));
- unsigned char *data = (unsigned char *) udph + sizeof(struct udphdr);
- int len;
- int i;
-
- if (!kgdb_initialized || !kgdb_netdevice) {
- goto out;
- }
- if (skb->protocol == __constant_htons(ETH_P_ARP) && !send_skb) {
- make_arp_request(skb);
- goto out;
- }
- if (iph->protocol != IPPROTO_UDP ||
- be16_to_cpu(udph->dest) != kgdb_listenport)
- goto out;
+ int i;
- kgdb_sendport = be16_to_cpu(udph->source);
+ np->remote_port = port;
- len = (be16_to_cpu(iph->tot_len) -
- (sizeof(struct udphdr) + sizeof(struct iphdr)));
+ /* Is this gdb trying to attach? */
+ if (!netpoll_trap() && len == 8 && !strncmp(msg, "$Hc-1#09", 8))
+ printk(KERN_CRIT "Someone is trying to attach\n");
+// kgdb_schedule_breakpoint();
for (i = 0; i < len; i++) {
- chr = *data++;
- if (chr == 3)
- {
- if (!atomic_read(&debugger_active)) {
- breakpoint();
- }
- continue;
- }
- if (atomic_read(&kgdb_buf_in_cnt) >= GDB_BUF_SIZE) {
- /* buffer overflow, clear it */
- kgdb_buf_in_inx = 0;
- atomic_set(&kgdb_buf_in_cnt, 0);
- kgdb_buf_out_inx = 0;
- break;
- }
- kgdb_buf[kgdb_buf_in_inx++] = chr;
- kgdb_buf_in_inx &= (GDB_BUF_SIZE - 1);
- atomic_inc(&kgdb_buf_in_cnt) ;
- }
- return NET_RX_DROP;
-
-out:
- if (atomic_read(&debugger_active))
- return NET_RX_DROP;
- return NET_RX_SUCCESS;
-}
+ if (msg[i] == 3) /* Check for ^C? */
+ printk(KERN_CRIT "Someone is trying to ^C?\n");
+// kgdb_schedule_breakpoint();
-/*
- * Initializes ethernet interface to kgdb.
- * Searches the device list and finds the device specified on kernel command
- * line.
- * Finds the irq handler for the device and saves its reference.
- * Initializes kgdbeth data structures.
- */
-
-int
-kgdbeth_hook(void)
-{
- extern void kgdb_respond_ok(void);
- struct irqaction *ia_ptr;
- int i;
-
- sprintf(kgdb_netdev_name, "eth%d", kgdb_eth);
-
- for (kgdb_netdevice = dev_base;
- kgdb_netdevice != NULL;
- kgdb_netdevice = kgdb_netdevice->next) {
- if (strncmp(kgdb_netdevice->name, kgdb_netdev_name, IFNAMSIZ) == 0) {
- break;
- }
- }
- if (!kgdb_netdevice) {
- printk("kgdbeth: Unable to find interface %s\n",
- kgdb_netdev_name);
- return -ENODEV;
- }
- if (!(kgdb_netdevice->flags & IFF_UP)) {
- return -EINVAL;
- }
- ia_ptr = irq_desc[kgdb_netdevice->irq].action;
- while (ia_ptr) {
- if (!strncmp(kgdb_netdev_name, ia_ptr->name, IFNAMSIZ)) {
- kgdbeth_irqhandler = ia_ptr->handler;
+ if (atomic_read(&in_count) >= IN_BUF_SIZE) {
+ /* buffer overflow, clear it */
+ in_head = in_tail = 0;
+ atomic_set(&in_count, 0);
break;
}
- ia_ptr = ia_ptr->next;
- }
- if (!kgdbeth_irqhandler) {
- printk("kgdbeth: Interface %s doesn't have an interrupt"
- " handler cannot use it\n", kgdb_netdev_name);
- return -EINVAL;
- }
- for (i = 0; i < NUM_SENDBUF; i++) {
- send_skbs[i] = kmalloc(sizeof (struct sk_buff), GFP_KERNEL);
- send_bufs[i] = kmalloc(SEND_BUFLEN, GFP_KERNEL);
- if (!send_skbs[i] || !send_bufs[i]) {
- printk("kgdbeth: not enough memory\n");
- return -ENOMEM;
- }
- atomic_set(&(send_skbs[i]->users), 1);
+ in_buf[in_head++] = msg[i];
+ in_head &= (IN_BUF_SIZE - 1);
+ atomic_inc(&in_count);
}
-
-
- return 0;
}
-/*
- * kgdbeth_read_char
- *
- * This is a GDB stub routine. It waits for a character from the
- * ethernet interface and then returns it.
- */
-static int
-kgdbeth_read_char(void)
+static int option_setup(char *opt)
{
- int chr;
-
- while ((chr = read_char()) < 0) {
- if (send_skb) {
- kgdb_eth_reply_arp();
- }
- (*kgdbeth_irqhandler)(kgdb_netdevice->irq,
- (void *)kgdb_netdevice, 0);
- }
- return chr;
+ return netpoll_parse_options(&np, opt);
}
-/*
- * Hold onto the xmitlock and keep holding till the session ends.
- * Disable device irq and keep it disabled till this session ends.
- * Respond to last arp request we have received. It may not not have be
- * responded yet.
- */
-static void kgdbeth_begin_session(void) {
- kgdbeth_lock();
- disable_irq(kgdb_netdevice->irq);
- kgdb_eth_reply_arp();
-}
+__setup("kgdboe=", option_setup);
-static void kgdbeth_end_session(void)
+static int init_kgdboe(void)
{
- enable_irq(kgdb_netdevice->irq);
- kgdbeth_unlock();
-}
-
-struct kgdb_serial kgdbeth_serial = {
- .chunksize = CHUNKSIZE,
- .read_char = kgdbeth_read_char,
- .write_char = kgdbeth_write_char,
- .hook = kgdbeth_hook,
- .flush = kgdbeth_flush,
- .begin_session = kgdbeth_begin_session,
- .end_session = kgdbeth_end_session,
-};
+#ifdef CONFIG_SMP
+ if (num_online_cpus() > CONFIG_NO_KGDB_CPUS) {
+ printk("kgdb: too manu cpus. Cannot enable debugger with more than %d cpus\n", CONFIG_NO_KGDB_CPUS);
+ return -1;
+ }
+#endif
+// set_debug_traps();
-static int __init parse_hw_addr(char **ptr, unsigned char *addr,
- unsigned char delimiter)
-{
- int i = 0;
+ if(!np.remote_ip || netpoll_setup(&np))
+ return 1;
- while(**ptr != delimiter)
- {
- unsigned int c;
+ kgdboe = 1;
+ printk(KERN_INFO "kgdb: debugging over ethernet enabled\n");
- if (sscanf(*ptr, "%x", &c) != 1) {
- return 1;
- }
- addr[i++] = c;
- do
- (*ptr)++;
- while((**ptr != delimiter) && (*(*ptr -1) != ':'));
- if (i > 6)
- return -EINVAL;
- }
- if (i != 6)
- return -EINVAL;
return 0;
}
-int kgdbeth_thread(void *data)
-{
- struct net_device *ndev = (struct net_device *)data;
- daemonize("kgdbeth");
- while (!ndev->ip_ptr) {
- schedule();
- }
- debugger_entry();
- return 0;
-}
+static int hook(void) { printk("Hook called\n"); return 0; }
+static int begin(void) { printk("Begin called\n"); return 0; }
+static int end(void) { printk("End called\n"); return 0; }
-int kgdbeth_event(struct notifier_block * self, unsigned long val, void * data)
-{
- if (strcmp(((struct net_device *)data)->name, kgdb_netdev_name)) {
- goto out;
- }
- if (val!= NETDEV_UP)
- goto out;
- kernel_thread(kgdbeth_thread, data, CLONE_KERNEL);
+module_init(init_kgdboe);
-out:
- return NOTIFY_DONE;
-}
-static struct notifier_block nb = {
- .notifier_call = kgdbeth_event,
+struct kgdb_serial kgdbeth_serial = {
+ .chunksize = 1,
+ .read_char = eth_getDebugChar,
+ .write_char = eth_putDebugChar,
+ .hook = hook,
+ .flush = eth_flushDebugChar,
+ .begin_session = begin,
+ .end_session = end,
};
-
-/*
- * Syntax for this cmdline option is
- * kgdbeth=interfacenum,localmac,listenport,remoteip,remotemac
- */
-
-static int __init kgdbeth_opt(char *str)
-{
- char ipaddrstr[16];
- char *ipaddrptr = ipaddrstr;
- extern int register_netdevice_notifier(struct notifier_block *nb);
-
-
- if (register_netdevice_notifier(&nb)) {
- printk("KGDB_ETH: couldn't register notifier\n");
- return 0;
- }
-
- /* interfacenum */
- if (*str < '0' || *str > '9')
- goto errout;
- kgdb_eth = *str - '0';
- str++;
- if (*str != ',')
- goto errout;
- str++;
-
- /* localmac */
- if (parse_hw_addr(&str, kgdb_localmac, ','))
- goto errout;
- str++;
-
- /* port */
- kgdb_listenport = simple_strtoul(str, &str, 10);
-
- if (*str != ',')
- goto errout;
- str++;
-
- /* remoteip */
- while (*str != ',') {
- if (!*str)
- goto errout;
- *ipaddrptr = *str;
- str++;
- ipaddrptr++;
- }
- str++;
- *ipaddrptr = '\0';
- kgdb_remoteip = in_aton(ipaddrstr);
-
- /* remotemac */
- if (parse_hw_addr(&str, kgdb_remotemac, '\0'))
- goto errout;
-
- kgdb_serial = &kgdbeth_serial;
- return 1;
-
-errout:
- printk("Invalid syntax for option kgdbeth=\n");
- return 0;
-}
-
-__setup("kgdbeth=", kgdbeth_opt);
--- tmp/linux/net/core/dev.c 2004-01-26 10:18:51.000000000 +0100
+++ linux/net/core/dev.c 2004-01-24 18:53:56.000000000 +0100
@@ -1428,15 +1428,6 @@
int this_cpu;
struct softnet_data *queue;
unsigned long flags;
- int ret;
- int kgdb_net_interrupt(struct sk_buff *skb);
-
-#ifdef CONFIG_KGDB_ETH
- /* See if kgdb_eth wants this packet */
- if ((ret = kgdb_net_interrupt(skb)) == NET_RX_DROP) {
- return ret;
- }
-#endif
#ifdef CONFIG_NETPOLL_RX
if (skb->dev->netpoll_rx && netpoll_rx(skb)) {
--- tmp/linux/net/core/skbuff.c 2004-01-26 10:18:45.000000000 +0100
+++ linux/net/core/skbuff.c 2004-01-24 18:58:44.000000000 +0100
@@ -127,11 +127,6 @@
{
struct sk_buff *skb;
u8 *data;
- struct sk_buff *kgdbeth_alloc_skb(int size);
-
- if (atomic_read(&debugger_active)) {
- return kgdbeth_alloc_skb(size);
- }
/* Get the HEAD */
skb = kmem_cache_alloc(skbuff_head_cache,
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply
* Re: Fried the onboard Broadcom 4401 network...
From: Vojtech Pavlik @ 2004-01-26 9:56 UTC (permalink / raw)
To: Tomas Ogren, linux-kernel
In-Reply-To: <20040126094815.GA2060@ing.umu.se>
On Mon, Jan 26, 2004 at 10:48:15AM +0100, Tomas Ogren wrote:
> On 26 January, 2004 - Pavel Machek sent me these 0,4K bytes:
>
> > Hi!
> >
> > > After that, I have not been able to get link (neither see it through
> > > Linux/WinXP or the physical LED). I have tried multiple cables and my
> > > laptop is perfectly happy with all of them, but the broadcom thingie
> > > seems not. The switch doesn't see link either.
> >
> > Try to physically unplug machine from AC for a while.
>
> Ah, thank you! Just turning the power switch off didn't help.. I suppose
> it's kept alive (for some values of alive ;) for WOL and such..
I think you meant undead in your case. ;)
> Now it's working again.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
^ permalink raw reply
* Re: Fried the onboard Broadcom 4401 network...
From: Tomas Ogren @ 2004-01-26 9:48 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040126090859.GB505@elf.ucw.cz>
On 26 January, 2004 - Pavel Machek sent me these 0,4K bytes:
> Hi!
>
> > After that, I have not been able to get link (neither see it through
> > Linux/WinXP or the physical LED). I have tried multiple cables and my
> > laptop is perfectly happy with all of them, but the broadcom thingie
> > seems not. The switch doesn't see link either.
>
> Try to physically unplug machine from AC for a while.
Ah, thank you! Just turning the power switch off didn't help.. I suppose
it's kept alive (for some values of alive ;) for WOL and such..
Now it's working again.
/Tomas
--
Tomas Ögren, stric@ing.umu.se, http://www.ing.umu.se/~stric/
|- Student at Computing Science, University of Umeå
`- Sysadmin at {cs,ing,acc}.umu.se
^ permalink raw reply
* Re: howto configuring kernel and modules.conf for automatic loading of ide-scsi
From: Agri @ 2004-01-26 9:46 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <Pine.LNX.4.58.0401252359410.9280@ppg_penguin>
Oh.... i did everything as you say many times before...
i get success only this time.
i have done a little investigation...
there is no need of
pre-install sg modprobe ide-scsi # load ide-scsi before sg
pre-install sr_mod modprobe ide-scsi
moreover these lines breaks loading after "rmmod -a"
lines from logs:
insmod: /lib/modules/2.4.23-rc1/kernel/drivers/cdrom/cdrom.o: pre-install sr_mod failed
insmod: /lib/modules/2.4.23-rc1/kernel/drivers/cdrom/cdrom.o: insmod block-major-11 failed
and line
pre-install ide-scsi modprobe scsi_mod
breaks everything cause:
modprobe: Can't locate module scsi_mod
now i'm more confused about modules, and about rmmod because it does not always
remove unused modules.....
thanx a lot for answer.
Agri
On Mon, 26 Jan 2004 00:08:29 +0000 (GMT)
Ken Moffat <ken@kenmoffat.uklinux.net> wrote:
> On Sun, 25 Jan 2004, Agri wrote:
>
> > thanks for answers, but....
> > the only thing i get: there is no way to configure loading of ide-scsi "ON DEMAND".
> > Am i right?
> >
>
> Following are from my modules.conf.
>
> First, make sure there is a path pointing to the directory where the
> actual modules are found (maybe not necessary), such as
>
> path[scsi]=/lib/modules/`uname -r`/kernel/drivers/scsi
>
> The following let me use /dev/scd0 to access the CD for reading, and sg
> (I guess) for writing from cdrecord:
>
> alias scsi_hostadapter ide-scsi
> alias scd0 sr_mod # load sr_mod upon access of scd0
> pre-install sg modprobe ide-scsi # load ide-scsi before sg
> pre-install sr_mod modprobe ide-scsi
> pre-install ide-scsi modprobe scsi_mod
>
> You'll probably need to rerun depmod after changing modules.conf.
> Of course, unless your distro runs a cron job to unload unused modules,
> once they've been loaded they stay loaded.
>
> HTH,
>
> Ken
> --
> This is a job for Riviera Kid!
> -
> To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.linux-learn.org/faqs
>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* [PATCH] AGPGART preliminary SiS648 support - fixed and shrunk
From: Heilmann, Oliver @ 2004-01-26 9:46 UTC (permalink / raw)
To: linux-kernel
* fixed a major bug where the request size had accidentally been take from the master's status reg instead of the target's.
* got rid of the extra file it's all in generic.c and sis-agp.c now
Any feedback is greatly appreciated.
patch is vs 2.6.1
Oliver
diff -urN -X dontdiff linux-2.6.1/drivers/char/agp/agp.h linux-2.6.1.agp648/drivers/char/agp/agp.h
--- linux-2.6.1/drivers/char/agp/agp.h 2004-01-09 06:59:26.000000000 +0000
+++ linux-2.6.1.agp648/drivers/char/agp/agp.h 2004-01-24 23:58:38.000000000 +0000
@@ -402,6 +402,16 @@
void get_agp_version(struct agp_bridge_data *bridge);
unsigned long agp_generic_mask_memory(unsigned long addr, int type);
+/* generic routines for agp>=3 */
+int agp3_generic_fetch_size(void);
+void agp3_generic_tlbflush(struct agp_memory *mem);
+int agp3_generic_configure(void);
+void agp3_generic_cleanup(void);
+
+/* aperture sizes have been standardised since v3 */
+#define AGP_GENERIC_SIZES_ENTRIES 11
+extern struct aper_size_info_16 agp3_generic_sizes[];
+
extern int agp_off;
extern int agp_try_unsupported_boot;
@@ -410,13 +420,17 @@
#define AGPCMD 0x8
#define AGPNISTAT 0xc
#define AGPCTRL 0x10
+#define AGPAPSIZE 0x14
#define AGPNEPG 0x16
+#define AGPGARTLO 0x18
+#define AGPGARTHI 0x1c
#define AGPNICMD 0x20
#define AGP_MAJOR_VERSION_SHIFT (20)
#define AGP_MINOR_VERSION_SHIFT (16)
#define AGPSTAT_RQ_DEPTH (0xff000000)
+#define AGPSTAT_RQ_DEPTH_SHIFT 24
#define AGPSTAT_CAL_MASK (1<<12|1<<11|1<<10)
#define AGPSTAT_ARQSZ (1<<15|1<<14|1<<13)
@@ -435,4 +449,7 @@
#define AGPSTAT3_8X (1<<1)
#define AGPSTAT3_4X (1)
+#define AGPCTRL_APERENB (1<<8)
+#define AGPCTRL_GTLBEN (1<<7)
+
#endif /* _AGP_BACKEND_PRIV_H */
diff -urN -X dontdiff linux-2.6.1/drivers/char/agp/generic.c linux-2.6.1.agp648/drivers/char/agp/generic.c
--- linux-2.6.1/drivers/char/agp/generic.c 2004-01-09 06:59:26.000000000 +0000
+++ linux-2.6.1.agp648/drivers/char/agp/generic.c 2004-01-24 23:02:37.000000000 +0000
@@ -956,3 +956,86 @@
}
EXPORT_SYMBOL(agp_generic_mask_memory);
+/*
+ * These functions are implemented according to the agpV3 spec,
+ * which covers implementation details that had previously been
+ * left open.
+ */
+
+int agp3_generic_fetch_size(void)
+{
+ u16 temp_size;
+ int i;
+ struct aper_size_info_16 *values;
+
+ pci_read_config_word(agp_bridge->dev, agp_bridge->capndx+AGPAPSIZE, &temp_size);
+ values = A_SIZE_16(agp_bridge->driver->aperture_sizes);
+
+ for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
+ if (temp_size == values[i].size_value) {
+ agp_bridge->previous_size =
+ agp_bridge->current_size = (void *) (values + i);
+
+ agp_bridge->aperture_size_idx = i;
+ return values[i].size;
+ }
+ }
+ return 0;
+}
+EXPORT_SYMBOL(agp3_generic_fetch_size);
+
+void agp3_generic_tlbflush(struct agp_memory *mem)
+{
+ u32 ctrl;
+ pci_read_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, &ctrl);
+ pci_write_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, ctrl & ~AGPCTRL_GTLBEN);
+ pci_write_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, ctrl);
+}
+EXPORT_SYMBOL(agp3_generic_tlbflush);
+
+int agp3_generic_configure(void)
+{
+ u32 temp;
+
+ struct aper_size_info_16 *current_size;
+ current_size = A_SIZE_16(agp_bridge->current_size);
+
+ pci_read_config_dword(agp_bridge->dev, AGP_APBASE, &temp);
+ agp_bridge->gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
+
+ // set aperture size
+ pci_write_config_word(agp_bridge->dev, agp_bridge->capndx+AGPAPSIZE, current_size->size_value);
+ // set gart pointer
+ pci_write_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPGARTLO, agp_bridge->gatt_bus_addr);
+
+ // enable aperture and GTLB
+ pci_read_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, &temp);
+ pci_write_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, temp | AGPCTRL_APERENB | AGPCTRL_GTLBEN);
+
+ return 0;
+}
+EXPORT_SYMBOL(agp3_generic_configure);
+
+void agp3_generic_cleanup(void)
+{
+ u32 ctrl;
+ pci_read_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, &ctrl);
+ pci_write_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCTRL, ctrl & ~AGPCTRL_APERENB);
+}
+EXPORT_SYMBOL(agp3_generic_cleanup);
+
+struct aper_size_info_16 agp3_generic_sizes[AGP_GENERIC_SIZES_ENTRIES]=
+{
+ {4096, 1048576, 10,0x000},
+ {2048, 524288, 9, 0x800},
+ {1024, 262144, 8, 0xc00},
+ { 512, 131072, 7, 0xe00},
+ { 256, 65536, 6, 0xf00},
+ { 128, 32768, 5, 0xf20},
+ { 64, 16384, 4, 0xf30},
+ { 32, 8192, 3, 0xf38},
+ { 16, 4096, 2, 0xf3c},
+ { 8, 2048, 1, 0xf3e},
+ { 4, 1024, 0, 0xf3f}
+};
+EXPORT_SYMBOL(agp3_generic_sizes);
diff -urN -X dontdiff linux-2.6.1/drivers/char/agp/sis-agp.c linux-2.6.1.agp648/drivers/char/agp/sis-agp.c
--- linux-2.6.1/drivers/char/agp/sis-agp.c 2004-01-09 06:59:06.000000000 +0000
+++ linux-2.6.1.agp648/drivers/char/agp/sis-agp.c 2004-01-25 17:26:15.000000000 +0000
@@ -95,6 +95,88 @@
.agp_destroy_page = agp_generic_destroy_page,
};
+// sis-648 specific routines + driver
+static void sis648_enable(u32 mode)
+{
+ // find the master, this needs to be better
+ struct pci_dev *master = NULL;
+ u8 mcapndx=0;
+
+ while ((master = pci_find_class(PCI_CLASS_DISPLAY_VGA<<8, master)) != NULL) {
+ mcapndx = pci_find_capability(master, PCI_CAP_ID_AGP);
+ printk (KERN_INFO PFX "Found AGP master. %x:%x \n", master->vendor, master->device);
+ break;
+ }
+ if(!mcapndx)
+ return;
+
+ u32 tStatus;
+ u32 mStatus;
+ pci_read_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPSTAT, &tStatus);
+ pci_read_config_dword(master, mcapndx+AGPSTAT, &mStatus);
+
+ printk(KERN_INFO PFX "target status %x\n", tStatus);
+ printk(KERN_INFO PFX "master status %x\n", mStatus);
+
+ int tcc=tStatus & AGPSTAT_CAL_MASK;
+ int mcc=mStatus & AGPSTAT_CAL_MASK;
+ int calcycl=(tcc<mcc) ? tcc : mcc;
+ int rate=(tStatus & tStatus & AGPSTAT3_8X) ? 2 : 1;
+
+ u32 tcmd=tStatus & mStatus & (AGPSTAT_SBA|AGPSTAT_FW);
+ u32 mcmd=tcmd;
+ tcmd|=calcycl|AGPSTAT_AGP_ENABLE|rate;
+ mcmd|=(tStatus & AGPSTAT_RQ_DEPTH)|(tStatus & AGPSTAT_ARQSZ)|AGPSTAT_AGP_ENABLE|rate;
+
+ printk(KERN_INFO PFX "tcmd=%x\n",tcmd);
+ printk(KERN_INFO PFX "mcmd=%x\n",mcmd);
+
+ // init target (bridge)
+ pci_write_config_dword(agp_bridge->dev, agp_bridge->capndx+AGPCMD, tcmd);
+
+ u8 mcaptest = pci_find_capability(master, PCI_CAP_ID_AGP);
+ if(mcaptest!=mcapndx)
+ {
+ printk(KERN_INFO PFX "master capndx screwed ... waiting 10ms\n");
+ // weird: on 648fx chipsets any rate change in the target command register
+ // triggers a 5ms screwup during which the master cannot be configured
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout (1+(HZ*10)/1000);
+ }
+ else
+ {
+ printk(KERN_INFO PFX "bridge is up and master seems okay");
+ }
+
+ // init master (card)
+ pci_write_config_dword(master, mcapndx+AGPCMD, mcmd);
+}
+
+struct agp_bridge_driver sis648_driver = {
+ .owner = THIS_MODULE,
+ .aperture_sizes = agp3_generic_sizes,
+ .size_type = U16_APER_SIZE,
+ .num_aperture_sizes = AGP_GENERIC_SIZES_ENTRIES,
+ .configure = agp3_generic_configure,
+ .fetch_size = agp3_generic_fetch_size,
+ .cleanup = agp3_generic_cleanup,
+ .tlb_flush = agp3_generic_tlbflush,
+ .mask_memory = agp_generic_mask_memory,
+ .masks = NULL,
+ .agp_enable = sis648_enable,
+ .cache_flush = global_cache_flush,
+ .create_gatt_table = agp_generic_create_gatt_table,
+ .free_gatt_table = agp_generic_free_gatt_table,
+ .insert_memory = agp_generic_insert_memory,
+ .remove_memory = agp_generic_remove_memory,
+ .alloc_by_type = agp_generic_alloc_by_type,
+ .free_by_type = agp_generic_free_by_type,
+ .agp_alloc_page = agp_generic_alloc_page,
+ .agp_destroy_page = agp_generic_destroy_page
+};
+// sis-648 end
+
+
static struct agp_device_ids sis_agp_device_ids[] __devinitdata =
{
{
@@ -206,7 +288,11 @@
if (!bridge)
return -ENOMEM;
- bridge->driver = &sis_driver;
+
+ if(pdev->device==PCI_DEVICE_ID_SI_648)
+ bridge->driver = &sis648_driver;
+ else
+ bridge->driver = &sis_driver;
bridge->dev = pdev;
bridge->capndx = cap_ptr;
--------------------------------------------------------------------------------
The information contained herein is confidential and is intended solely for the
addressee. Access by any other party is unauthorised without the express
written permission of the sender. If you are not the intended recipient, please
contact the sender either via the company switchboard on +44 (0)20 7623 8000, or
via e-mail return. If you have received this e-mail in error or wish to read our
e-mail disclaimer statement and monitoring policy, please refer to
http://www.drkw.com/disc/email/ or contact the sender.
--------------------------------------------------------------------------------
^ permalink raw reply
* Re: Test suite?
From: Yusuf Goolamabbas @ 2004-01-26 9:39 UTC (permalink / raw)
To: Nikita Danilov; +Cc: markw, john.l.villalovos, reiserfs-list
In-Reply-To: <16399.52970.948058.252595@laputa.namesys.com>
Could you also consider fstress which provides for a SPECsfs97 like
workload
http://www.cs.duke.edu/ari/fstress/
Regards, Yusuf
--
If you're not using Firebird, you're not surfing the web
you're suffering it
http://www.mozilla.org/products/firebird/why/
^ permalink raw reply
* Re: Q: Filesystem choice..
From: David Woodhouse @ 2004-01-26 9:31 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: linux-mtd
In-Reply-To: <m3brorf4hg.fsf@maxwell.lnxi.com>
On Mon, 2004-01-26 at 02:23 -0700, Eric W. Biederman wrote:
> Compression is an interesting question. Do you encode the uncompressed
> size of a block in bytes.
Yes.
> If so I don't think it would be too difficult to get your uncompressed
> block size > page size.
It wouldn't be difficult -- but that's not really at all relevant to the
above question. By 'uncompressed block size' here I'm assuming you're
talking of the amount of data payload we attach to any given node (log
entry). The rule is currently that it mustn't cross a page boundary --
and hence, by inference, obviously can't exceed a page in size.
That assumption did allow a little simplification of bits of the code,
but actually it turned out to be less useful than I originally thought,
so it might be worth ditching in order to let us get better compression
by compressing larger chunks at a time.
> With the page cache there is real reason a block size <= page size.
> You just need what amounts to scatter/gather support.
Yes. It's been done for zisofs -- if we have to decompress, for example,
16KiB to satisfy a single 4KiB readpage, we can prefetch the other data
which we had to decompress anyway.
Fix up some other assumptions about the first byte in any given page
also being the first byte in a node, and fix up the garbage-collection
which will need to have enough workspace to decompress and recompress
the largest block it may encounter, and it should work.
> My real question here is how difficult is it to disable compression?
> Or can compression be deliberately disabled on a per file basis?
It's not too hard. To disable it completely you just need to change a
few #defines in os-linux.h. The support for disabling it on a per-file
basis isn't complete, but there are flags allocated in the inode
structure to keep track of it.
> I have a truly perverse case I would like to ask your opinion about.
> A filesystem composed of 2 8K erase blocks? That is one of the
> weird special cases that flash chips often support. I could
> only store my parameter file in there but it would be interesting.
To be honest, at that size I'd just do it directly via /dev/mtd0. Put
the file directly on the flash with a checksum. Alternate between the
eraseblocks each time it changes, then erase the old copy.
> And a last question. jffs2 rounds all erase blocks up to a common size
> doesn't it?
Yes.
--
dwmw2
^ permalink raw reply
* Re: MPC823E SMC/I2C/SPI micropatch
From: Wolfgang Denk @ 2004-01-26 9:33 UTC (permalink / raw)
To: Jan Damborsky; +Cc: linuxppc-dev
In-Reply-To: <4014DD1D.8070704@devcom.cz>
In message <4014DD1D.8070704@devcom.cz> you wrote:
> I think I have selected the __correct__ one.
> Situated in ./arch/ppc/8xx_io/micropatch_850.c file.
No!!! The micropatch_850.c is ONLY for MPC850, and NOT for MPC823(E).
> - it is determined for 850 and 823E processors (I hope).
Wrong.
> And for now, I have SCC2,SCC3 ethernets
> and SMC1,SMC2 UARTs working altogether.
But you might get "strange" effects for example when trying to use SPI.
Best regards,
Wolfgang Denk
--
See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Bus error -- please leave by the rear door.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [RFC/PATCH] IMQ port to 2.6
From: Vladimir B. Savkin @ 2004-01-26 9:32 UTC (permalink / raw)
To: jamal; +Cc: linux-kernel, netdev
In-Reply-To: <1075086588.1732.221.camel@jzny.localdomain>
On Sun, Jan 25, 2004 at 10:09:48PM -0500, jamal wrote:
> On Sun, 2004-01-25 at 19:11, Vladimir B. Savkin wrote:
> > On Sun, Jan 25, 2004 at 06:45:16PM -0500, jamal wrote:
> [..]
> >
> > With typical internet traffic patterns, policing will drop many packets,
> > and shaping will not.
>
> What is typical internet traffic? I guess you mean TCP (thats what 90%
> of the traffic is)
> In that case, the effect of dropping or delaying on throughput is
> similar. Studies i have seen indicate that throughput is directly
> proportional to the square root of the drop probability
> (drop is what you get when you police).
> It is also influenced by the delay (which is what you introduce when you
> shape). I have not seen anything in favor of shaping; i could be wrong
> (so if you know of something or have experimented pass the data).
Yes, I have experimented. Shaping works much better:
much less packets dropped, much better donwload rates for clients.
> For detailed analysis at least fro RENO, this would be a good reference:
> http://citeseer.nj.nec.com/padhye98modeling.html
>
[snip]
> Maybe i am misunderstanding what you are after.
> couldnt you use -i ppp+ -j mark --set-mark x in the ingress/prerouting
> and use the fwmark to shape on the egress?
> Post your script examples.
>
I want to shape traffic that comes from upstream to clients connected
via PPTP.
Here is a part of my scripts:
DEVICE=imq0
/sbin/tc qidisc add dev $DEVICE root handle 10: htb r2q 1 default 100
/sbin/tc class add dev $DEVICE parent 10:0 classid 10:1 est 1sec 8sec htb \
rate 10Mbit burst 400k
/sbin/tc class add dev $DEVICE parent 10:1 classid 10:2 est 1sec 8sec htb \
rate 180kbps ceil 180kbps burst 3000
# default class for users
/sbin/tc class add dev $DEVICE parent 10:2 classid 10:101 est 1sec 8sec htb \
rate 20kbps burst 1k ceil 50kbps cburst 1k
/sbin/tc qdisc add dev $DEVICE parent 10:101 wrr \
dest ip 128 1 wmode1=1 wmode2=1
/sbin/tc filter add dev $DEVICE protocol ip parent 10:0 \
prio 100 handle 1 fw flowid 10:101
# more classes to follow ...
The limit 50kbps is artificial, so there's no bottleneck in
connection from upstream to this router. I cannot allocate all
the channel bandwidth to clients for some political reasons.
Then, I mark packets I want to go to this default user class with mark "1",
like this:
iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \
-j IMQ --todev 0 # traffic from internet to clients
iptables -t mangle -A FORWARD -i $UPLINK_DEV -d $CLIENTS_NET \
-j MARK --set-mark 1 # default class
# here I can change fwmark for packets that deserve
# some special treatment
So, I shape traffic destined to clients, and I use "wrr" to
divide bandwidth fairly. I cannot attach qdisc to an egress device
because there's no single one, each client has its own ppp interface.
Well, I could move this shaping upstream, but what if upstream router was
some dumb cisco with no "wrr" qdisc?
~
:wq
With best regards,
Vladimir Savkin.
^ permalink raw reply
* RE: Q: Filesystem choice..
From: Joakim Tjernlund @ 2004-01-26 9:28 UTC (permalink / raw)
To: 'David Woodhouse'; +Cc: linux-mtd, 'Eric W. Biederman'
In-Reply-To: <1075106302.19924.9.camel@imladris.demon.co.uk>
> On Mon, 2004-01-26 at 09:34 +0100, Joakim Tjernlund wrote:
> > size = 63*1024*1024/50 = 1321205
> > size += 252*100 += 25200= 1321457
> > size += 256*1024 -1 += 262143 = 1583600
> >
> > resv_blocks_write = 2 + 1583600/(256*1024) = 2 + 6 = 8
> > resv_blocks_gcmerge = 2+1 = 3
> >
> > So now I need 8(2 MB) reserved blocks instead of 5?
> > I never had any trouble with 5 reserved blocks, maybe one could do a
> > resv_blocks_write = MIN(5, resv_blocks_write) iff NOR flash?
>
> I'd be happier about reducing the 2% figure to 1% or 1.5%, maybe.
1% results in: resv_blocks_write = 2 + 3.7 = 5.
Much better.
Jocke
^ permalink raw reply
* Re: MPC823E SMC/I2C/SPI micropatch
From: Jan Damborsky @ 2004-01-26 9:25 UTC (permalink / raw)
To: Wolfgang Denk, linuxppc-dev
In-Reply-To: <20040126080100.26782C108D@atlas.denx.de>
I think I have selected the __correct__ one.
Situated in ./arch/ppc/8xx_io/micropatch_850.c file.
- relocates I2C, SPI, SMC parameter RAM.
- it is determined for 850 and 823E processors (I hope).
- I had to define USE_SMC_PATCH and write some
additional code for relocating SMC parameter RWM
in cpm_load_patch() function (./arch/ppc/8xx_io/micropatch.c)
as well as in SMC UART code (./arch/ppc/8xx_io/uart.c).
More additional hacks needed:
* original RPBASE set to 0x400 clashed with SMC micropatch
so I redefined it to 0x800
* when used ethernets on SCC2,SCC3 with CONFIG_ENET_BIG_BUFFERS
enabled, they need 2kB of DPRAM - it cannot fit together with
micropatch in first 4kB of DPRAM, so I redefined
CPM_DATAONLY_BASE to 0x1000 and CPM_DATAONLY_SIZE to 0x0c00
And for now, I have SCC2,SCC3 ethernets
and SMC1,SMC2 UARTs working altogether.
Sincerely, Jan Damborsky
Wolfgang Denk wrote:
> In message <4014C088.1020208@devcom.cz> you wrote:
>
>>I have found out that CPM micropatch
>>available in linux-2.4 from Wolfgang Denk
>>site (the kernel we use successfuly on our
>>custom boards at present) is applicable as well.
>
>
> You have to select the _correct_ uCode patch.
>
> There is one patch for the MPC850, and another one for all other 8xx
> processors. And there is the USB SOF potch for the MPC823.
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
> Another dream that failed. There's nothing sadder.
> -- Kirk, "This side of Paradise", stardate 3417.3
>
>
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Q: Filesystem choice..
From: Eric W. Biederman @ 2004-01-26 9:23 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd
In-Reply-To: <1075102799.17157.209.camel@lapdancer.baythorne.internal>
David Woodhouse <dwmw2@infradead.org> writes:
> On Mon, 2004-01-26 at 00:09 -0700, Eric W. Biederman wrote:
> > Has anyone gotten as far as a proof. Or are there some informal
> > things that almost make up a proof, so I could get a feel? Reserving
> > more than a single erase block is going to be hard to swallow for such
> > a small filesystem.
>
> You need to have enough space to let garbage collection make progress.
> Which means it has to be able to GC a whole erase block into space
> elsewhere, then erase it. That's basically one block you require.
>
> Except you have to account for write errors or power cycles during a GC
> write, wasting some of your free space. You have to account for the
> possibility that what started off as a single 4KiB node in the original
> block now hits the end of the new erase block and is split between that
> and the start of another, so effectively it grew because it has an extra
> node header now. And of course when you do that you get worse
> compression ratios too, since 2KiB blocks compress less effectively than
> 4KiB blocks do.
Compression is an interesting question. Do you encode the uncompressed
size of a block in bytes. If so I don't think it would be too difficult
to get your uncompressed block size > page size. With the page cache
there is real reason a block size <= page size. You just need what
amounts to scatter/gather support.
My real question here is how difficult is it to disable compression?
Or can compression be deliberately disabled on a per file basis?
For the two primary files I am thinking of using neither one would
need compression. A file of my BIOS settings is would be dense
and quite small (128 bytes on a big day). A kernel is already
compressed and carries it's own decompresser, and whole file compression
is more effective than compressing small blocks.
> When you get down to the kind of sizes you're talking about, I suspect
> we need to be thinking in bytes rather than blocks -- because there
> isn't just one threshold; there's many, of which three are particularly
> relevant:
That makes sense. This at least looks like a viable alternative for
the 1MB case.
[snip actual formulas]
> You want resv_blocks_write to be larger than resv_blocks_deletion, and I
> suspect you could get away with values of 2 and 1.5 respectively, if we
> were counting bytes rather than whole eraseblocks.
I have a truly perverse case I would like to ask your opinion about.
A filesystem composed of 2 8K erase blocks? That is one of the
weird special cases that flash chips often support. I could
only store my parameter file in there but it would be interesting.
I think if I counted bytes very carefully and never got above .5 of
a block full I suspect that it would work, and be useful. I'd just
have to make certain the degenerate case matched the original jffs.
And a last question. jffs2 rounds all erase blocks up to a common size
doesn't it?
Eric
^ permalink raw reply
* Re: [Qemu-devel] QEMU 0.5.2 testing
From: Sylvain OBEGI @ 2004-01-26 9:19 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <20040120040730.GA14683@gnu.org>
Le mar 20/01/2004 à 05:07, Lennert Buytenhek a écrit :
> Win98 second edition install CD. Spews a bunch of "FLOPPY ERROR: fd_seek:
> try to read 0 00 02 (max=1 00 01)" messages while starting up the setup.
> When copying files is complete, it says "Detection Manager failed to allocate
> memory for internal use." followed by "Error loading Explorer.exe. You must
> reinstall Windows." and the termination of the setup. If I then boot from
> hard disk (-boot c), Windows finishes the installation, but after reboot,
> I just get "While initializing device IOS: Windows protection error. You
> need to restart your computer."
I get the same things here with 0.5.2 final, except that it seems random
freezes during install causes some vxd errors, so I can't boot windows
at all.
--
Sylvain OBEGI
Email : katios@nolabel.net
ICQ : 661913
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.