* [LARTC] HTB and ARP
From: Eric Leblond @ 2003-01-10 14:48 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 404 bytes --]
Hi,
I discover recently that the arp traffic is managed like any other flow.
So you get hang after a moment if you don't use a default class.
Is the any means to avoid this ? Not to have a default class is a way to
filter traffic ...
One would be to managed to class ARP request with tc but I don't know if
it is possible.
Thanks in advance,
--
Éric Leblond
courriel : eric@regit.org
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch] R4000/R4400 64-bit errata handling
From: Ralf Baechle @ 2003-01-10 14:47 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips, Karsten Merker, Thiemo Seufer
In-Reply-To: <Pine.GSO.3.96.1030110150339.23678K-100000@delta.ds2.pg.gda.pl>
On Fri, Jan 10, 2003 at 03:32:34PM +0100, Maciej W. Rozycki wrote:
> As you might already know there are a few nasty errata in the R4000 and
> the early R4400 that hit 64-bit operation badly. Here is proposed code to
> detect them. If an erratum is found in the processor and no workaround is
> applied to a kernel executable, the kernel refuses to run. In all cases
> the result of the probes is output to the bootstrap log.
>
> The code has bits that make use of features of non-standard tools
> (binutils and gcc). But it doesn't depend on them -- when built with
> standard tools and run on an affected system, a kernel will simply fail,
> and on good systems it will run normally. Therefore it's safe to apply,
> and if the ultimate implementation in the tools differs, the code may get
> adjusted appropriately later.
>
> I'd like to apply this code as soon as possible as I consider it a
> prerequisite for integrating 64-bit support for the DECstation (to prevent
> people from running unreliable code), so please tell me if there are any
> doubts about it. Errata descriptions are available at the MIPS site --
> see: 'http://www.mips.com/publications/r400_r5000.html'. Unfortunately,
> despite several attempts to get a permission to duplicate them within
> Linux sources, I failed to get one.
>
> I'd like to express my gratitude to Karsten and Thiemo for testing the
> code with their hardware. Without their help, I wouldn't be able to
> prepare appropriate tests for errata my hardware doesn't suffer from.
> + __save_and_cli(flags);
> + __restore_flags(flags);
I suggest to replace these with local_irq_save and local_irq_restore.
They're already deprecated for 2.4 and completly gone in 2.5.
Looks ok to me otherwise.
Ralf
^ permalink raw reply
* Re: Are linux network drivers really affected by this?
From: andrea.glorioso @ 2003-01-10 14:53 UTC (permalink / raw)
To: vda; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <200301101211.h0ACBIs16337@Port.imtp.ilyichevsk.odessa.ua>
>>>>> "dv" == Denis Vlasenko <vda@port.imtp.ilyichevsk.odessa.ua> writes:
dv> Too much work for zero gain
`Too much work' refers to coding time or to kernel work?
bye,
andrea
--
Andrea Glorioso andrea.glorioso@binary-only.com
Binary Only http://www.binary-only.com/
Via A. Zanolini, 7/b Tel: +39-348.921.43.79
40126 Bologna Fax: +39-051-930.31.133
^ permalink raw reply
* Kernel hooks just to get rid of copy_[to/from]_user() and syscall overhead?
From: Mihnea Balta @ 2003-01-10 14:45 UTC (permalink / raw)
To: linux-kernel
Hi,
I have to implement a system which grabs udp packets off a gigabit connection,
take some basic action based on what they contain, repack their data with a
custom protocol header and send them through a gigabit ethernet interface on
broadcast.
I know how to do this in userspace, but I need to know if doing everyting in
the kernel would show a considerable speed improvement due to removing
syscall and memory copy overhead. The system will be quite stressed, having
to deal with around 15-20000 packets/second.
I didn't want to start this e-mail with an excuse, so I delayed it until here
:). I appologise if this isn't the right place to ask, it seemed that way to
me. I wasn't able to find sufficient and coherent information about this
issue on the internet or on this mailing list's archives, so I decided to ask
you people directly.
Thanks for your time,
Mihnea Balta
^ permalink raw reply
* [PATCH] ne.c 8139too.c to fix CERT VU#412115, 2.4.20
From: David McCullough @ 2003-01-10 14:52 UTC (permalink / raw)
To: linux-kernel; +Cc: becker, jgarzik
Hi all,
Here's a patch for the ne2000 driver (ne.c) and the RealTek driver
(8139too.c) in the 2.4.20 kernel to fix the CERT vulnerability VU#412115:
http://www.kb.cert.org/vuls/id/412115
For interest, the smc9194 and FEC ethernet drivers appear to be ok.
Please CC me on any replies,
Cheers,
Davidm
--- linux-2.4.20/drivers/net/ne.c.orig Sat Aug 3 10:39:44 2002
+++ linux-2.4.20/drivers/net/ne.c Sat Jan 11 00:29:36 2003
@@ -623,6 +623,7 @@
const unsigned char *buf, const int start_page)
{
int nic_base = NE_BASE;
+ int pad_count = count >= ETH_ZLEN ? count : ETH_ZLEN;
unsigned long dma_start;
#ifdef NE_SANITY_CHECK
int retries = 0;
@@ -669,16 +670,22 @@
outb_p(ENISR_RDC, nic_base + EN0_ISR);
/* Now the normal output. */
- outb_p(count & 0xff, nic_base + EN0_RCNTLO);
- outb_p(count >> 8, nic_base + EN0_RCNTHI);
+ outb_p(pad_count & 0xff, nic_base + EN0_RCNTLO);
+ outb_p(pad_count >> 8, nic_base + EN0_RCNTHI);
outb_p(0x00, nic_base + EN0_RSARLO);
outb_p(start_page, nic_base + EN0_RSARHI);
outb_p(E8390_RWRITE+E8390_START, nic_base + NE_CMD);
if (ei_status.word16) {
outsw(NE_BASE + NE_DATAPORT, buf, count>>1);
+ while (count < pad_count) {
+ outw_p(0x00, NE_BASE + NE_DATAPORT);
+ count += 2;
+ }
} else {
outsb(NE_BASE + NE_DATAPORT, buf, count);
+ while (count++ < pad_count)
+ outb_p(0x00, NE_BASE + NE_DATAPORT);
}
dma_start = jiffies;
--- linux-2.4.20/drivers/net/8139too.c.orig Fri Nov 29 09:53:13 2002
+++ linux-2.4.20/drivers/net/8139too.c Sat Jan 11 00:29:36 2003
@@ -1683,6 +1683,9 @@
if (likely(len < TX_BUF_SIZE)) {
skb_copy_and_csum_dev(skb, tp->tx_buf[entry]);
+ /* PAD the frame out with zeroes */
+ if (len < (unsigned int) ETH_ZLEN)
+ memset(tp->tx_buf[entry] + len, 0, ETH_ZLEN - len);
dev_kfree_skb(skb);
} else {
dev_kfree_skb(skb);
--
David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com
davidm@snapgear.com Fx: +61 7 3891 3630 Custom Embedded Solutions + Security
^ permalink raw reply
* Re: ksoftirqd_CPU0 causing severe latency
From: Jim Roland @ 2003-01-10 14:45 UTC (permalink / raw)
To: vda; +Cc: linux-kernel
In-Reply-To: <200301100916.h0A9Gus15400@Port.imtp.ilyichevsk.odessa.ua>
How do I profile and collect interrupt info? I have not tried to do this
w/o iptables, because iptables is required for this box to do what it does.
I'm not a programmer, so looking at eepro100's code will not do me much
good. :)
----- Original Message -----
From: "Denis Vlasenko" <vda@port.imtp.ilyichevsk.odessa.ua>
To: "Jim Roland" <jroland@roland.net>; <linux-kernel@vger.kernel.org>
Sent: Friday, January 10, 2003 3:16 AM
Subject: Re: ksoftirqd_CPU0 causing severe latency
> On 10 January 2003 08:41, Jim Roland wrote:
> > I am running a RH7.2 router with kernel 2.4.18-19.7.x and upgraded
> > from 2.4.18-17 in hopes this would fix the problem, but it hasn't.
> >
> > The problem I am experiencing is that after a while, the system
> > begins to lag badly, and running "ps -ax" writes to a SSH console
> > like a terminal running at 14.4kbps. This only seems to have
> > occurred after the box started procesing a network load.
> >
> > The box is a router, with a Supermicro (model=?) motherboard with
> > embedded Intel EEpro/100 NICs using the eepro100 module. This box is
> > also serving as an iptables filter for the network as well. It's
> > processing approximately 60Mbps sustained traffic outbound, and about
> > 10-15Mbps traffic inbound.
>
> That's not a small figure :)
>
> > The box also lags SEVERLY when I'm trying to use the state matching
> > in the kernel (as module), lagging badly when ip_conntrack is loaded.
> >
> > In contrast, I am running the same OS and kernel versions on another
> > box (same modules) and am not having the same problem (it is only
> > handling about 5Mbps sustained out, and 1Mbps sustained inbound).
> >
> > I need HELP!
>
> Profile your box. (We need to know where it spends most of CPU time).
> Send profile data to the list.
>
> Also collect interrupt rate info.
>
> You may also look into Intel EEpro/100 driver's interrupt handler code.
>
> Does is lag that bad without iptables?
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [Linux-fbdev-devel] [PATCH][FBDEV]: fb_putcs() and fb_setfont() methods
From: Antonino Daplas @ 2003-01-10 14:36 UTC (permalink / raw)
To: James Simmons
Cc: Geert Uytterhoeven, Petr Vandrovec, Linux Fbdev development list,
Linux Kernel List, davidm
In-Reply-To: <Pine.LNX.4.44.0301090034020.4976-100000@phoenix.infradead.org>
On Fri, 2003-01-10 at 02:09, James Simmons wrote:
> >
> > So maybe if we can rename fb_putcs() to fb_tileblit(), fb_setfont() to
> > fb_loadtiles(), struct fb_chars to struct fb_tilemap and struct
> > fb_fontdata to struct fb_tiledata, maybe it will be more acceptable?
> >
> > It can be even be expanded by including fb_tiledata.depth
> > fb_tiledata.cmap so we can support multi-colored tiled blitting.
>
> This I have no problem with. I'm willing to accept this. As long as data
> from the console layer is not touched. As for loadtiles one thing I like
> to address is memory allocation. It probable is good idea to do things
> like place the tile data in buffers allocated by pci_alloc_consistent.
> The other fear is it will only support so many tiles.
>
Hmm, so you're willing to accept this... okay, attached is another
patch, made it a bit cleaner so none of the console data will be ever
touched. Also expanded it so tile blitting has an equivalent
counterpart with classic blitting.
Thinking about it, I think tile blitting may one day become useful if
ever the console supports more than 16-colors. Imagine how expensive it
would be to draw 32-bit fonts using classic blitting.
Tried it with a few test hooks, works fine except for one thing: the
font is initially scrambled at boot, but became fixed later on. I don't
know how to fix that.
Tony
diff -Naur linux-2.5.54/drivers/video/console/fbcon.c linux/drivers/video/console/fbcon.c
--- linux-2.5.54/drivers/video/console/fbcon.c 2003-01-10 11:08:04.000000000 +0000
+++ linux/drivers/video/console/fbcon.c 2003-01-10 11:04:59.000000000 +0000
@@ -350,35 +350,91 @@
{
struct fb_info *info = p->fb_info;
struct vc_data *vc = p->conp;
- struct fb_copyarea area;
- area.sx = sx * vc->vc_font.width;
- area.sy = sy * vc->vc_font.height;
- area.dx = dx * vc->vc_font.width;
- area.dy = dy * vc->vc_font.height;
- area.height = height * vc->vc_font.height;
- area.width = width * vc->vc_font.width;
+ if (info->caps & FB_CAPS_TILEBLIT && info->tileops) {
+ struct fb_tilecopy tilerect;
- info->fbops->fb_copyarea(info, &area);
+ tilerect.sx = sx;
+ tilerect.sy = sy;
+ tilerect.dx = dx;
+ tilerect.dy = dy;
+ tilerect.width = width;
+ tilerect.height = height;
+
+ info->tileops->fb_tilecopy(info, &tilerect);
+ } else {
+ struct fb_copyarea area;
+
+ area.sx = sx * vc->vc_font.width;
+ area.sy = sy * vc->vc_font.height;
+ area.dx = dx * vc->vc_font.width;
+ area.dy = dy * vc->vc_font.height;
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+ }
}
void accel_clear(struct vc_data *vc, struct display *p, int sy,
int sx, int height, int width)
{
struct fb_info *info = p->fb_info;
- struct fb_fillrect region;
+ if (info->caps & FB_CAPS_TILEBLIT && info->tileops) {
+ struct fb_tilefill tilerect;
- region.color = attr_bgcol_ec(p, vc);
- region.dx = sx * vc->vc_font.width;
- region.dy = sy * vc->vc_font.height;
- region.width = width * vc->vc_font.width;
- region.height = height * vc->vc_font.height;
- region.rop = ROP_COPY;
+ tilerect.dx = sx;
+ tilerect.dy = sy;
+ tilerect.width = width;
+ tilerect.height = height;
+ tilerect.fg_color = attr_fgcol_ec(p, vc);
+ tilerect.bg_color = attr_bgcol_ec(p, vc);
+ tilerect.idx = vc->vc_video_erase_char & p->charmask;
+ tilerect.rop = ROP_COPY;
- info->fbops->fb_fillrect(info, ®ion);
-}
+ info->tileops->fb_tilefill(info, &tilerect);
+ } else {
+ struct fb_fillrect region;
+
+ region.color = attr_bgcol_ec(p, vc);
+ region.dx = sx * vc->vc_font.width;
+ region.dy = sy * vc->vc_font.height;
+ region.width = width * vc->vc_font.width;
+ region.height = height * vc->vc_font.height;
+ region.rop = ROP_COPY;
+
+ info->fbops->fb_fillrect(info, ®ion);
+ }
+}
#define FB_PIXMAPSIZE 8192
+static void tile_putcs(struct vc_data *vc, struct display *p, u32 *tilemap,
+ const unsigned short *s, int count, int yy, int xx)
+{
+ struct fb_info *info = p->fb_info;
+ struct fb_tileblit tilerect;
+ int maxcnt = FB_PIXMAPSIZE/4, i, cnt;
+ u16 c = scr_readw(s);
+
+ tilerect.dx = xx;
+ tilerect.dy = yy;
+ tilerect.height = 1;
+ tilerect.fg_color = attr_fgcol(p, c);
+ tilerect.bg_color = attr_bgcol(p, c);
+ tilerect.data = tilemap;
+
+ while (count) {
+ cnt = (count > maxcnt) ? maxcnt : count;
+ tilerect.width = cnt;
+ for (i = 0; i < cnt; i++)
+ tilemap[i] = (u32) (scr_readw(s++) & p->charmask);
+
+ info->tileops->fb_tileblit(info, &tilerect);
+ tilerect.dx += cnt;
+ count -= cnt;
+ }
+}
+
void accel_putcs(struct vc_data *vc, struct display *p,
const unsigned short *s, int count, int yy, int xx)
{
@@ -390,6 +446,11 @@
u16 c = scr_readw(s);
static u8 pixmap[FB_PIXMAPSIZE];
+ if (info->caps & FB_CAPS_TILEBLIT && info->tileops) {
+ tile_putcs(vc, p, (u32 *) pixmap, s, count, yy, xx);
+ return;
+ }
+
image.fg_color = attr_fgcol(p, c);
image.bg_color = attr_bgcol(p, c);
image.dx = xx * vc->vc_font.width;
@@ -452,6 +513,10 @@
unsigned int bs = info->var.yres - bh;
struct fb_fillrect region;
+ /* unneeded for tile blits */
+ if (info->caps && FB_CAPS_TILEBLIT && info->tileops)
+ return;
+
region.color = attr_bgcol_ec(p, vc);
region.rop = ROP_COPY;
@@ -1150,7 +1215,6 @@
struct fb_info *info = p->fb_info;
unsigned short charmask = p->charmask;
unsigned int width = ((vc->vc_font.width + 7) >> 3);
- struct fb_image image;
int redraw_cursor = 0;
if (!p->can_soft_blank && console_blanked)
@@ -1164,17 +1228,33 @@
redraw_cursor = 1;
}
- image.fg_color = attr_fgcol(p, c);
- image.bg_color = attr_bgcol(p, c);
- image.dx = xpos * vc->vc_font.width;
- image.dy = real_y(p, ypos) * vc->vc_font.height;
- image.width = vc->vc_font.width;
- image.height = vc->vc_font.height;
- image.depth = 1;
- image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
+ if (info->caps & FB_CAPS_TILEBLIT && info->tileops) {
+ struct fb_tileblit tilerect;
+
+ u32 font = c & charmask;
+ tilerect.dx = xpos;
+ tilerect.dy = real_y(p, ypos);
+ tilerect.width = 1;
+ tilerect.height = 1;
+ tilerect.fg_color = attr_fgcol(p, c);
+ tilerect.bg_color = attr_bgcol(p, c);
+ tilerect.data = &font;
+
+ info->tileops->fb_tileblit(info, &tilerect);
+ } else {
+ struct fb_image image;
- info->fbops->fb_imageblit(info, &image);
+ image.fg_color = attr_fgcol(p, c);
+ image.bg_color = attr_bgcol(p, c);
+ image.dx = xpos * vc->vc_font.width;
+ image.dy = real_y(p, ypos) * vc->vc_font.height;
+ image.width = vc->vc_font.width;
+ image.height = vc->vc_font.height;
+ image.depth = 1;
+ image.data = p->fontdata + (c & charmask) * vc->vc_font.height * width;
+ info->fbops->fb_imageblit(info, &image);
+ }
if (redraw_cursor)
vbl_cursor_cnt = CURSOR_DRAW_DELAY;
}
@@ -1935,6 +2015,31 @@
scrollback_max = 0;
scrollback_current = 0;
+ if (info->caps & FB_CAPS_TILEBLIT && info->tileops) {
+ struct fb_tiledata tile;
+ int err, cnt = FNTCHARCNT(p->fontdata);
+ int size = (vc->vc_font.height * vc->vc_font.width)/8 * cnt;
+ u8 *tiledata;
+
+ /*
+ * make sure we don't allow drivers to mangle
+ * console fontdata
+ */
+ tiledata = kmalloc(size, GFP_KERNEL);
+ if (tiledata == NULL)
+ return 0;
+ memcpy(tiledata, p->fontdata, size);
+ tile.tile.width = vc->vc_font.width;
+ tile.tile.height = vc->vc_font.height;
+ tile.tile.depth = 1;
+ tile.len = cnt;
+ tile.data = tiledata;
+ err = info->tileops->fb_loadtiles(info, &tile);
+ kfree(tiledata);
+
+ if (err) return 0;
+ }
+
info->currcon = unit;
fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
@@ -2152,6 +2257,27 @@
}
+ if (info->caps & FB_CAPS_TILEBLIT && info->tileops) {
+ struct fb_tiledata tile;
+ int size = (vc->vc_font.height * vc->vc_font.width)/8 * cnt;
+ int err;
+ u8 *tiledata;
+
+ tiledata = kmalloc(size, GFP_KERNEL);
+ if (tiledata == NULL)
+ return 1;
+ memcpy(tiledata, p->fontdata, size);
+ tile.tile.width = vc->vc_font.width;
+ tile.tile.height = vc->vc_font.height;
+ tile.tile.depth = 1;
+ tile.len = cnt;
+ tile.data = tiledata;
+
+ err = info->tileops->fb_loadtiles(info, &tile);
+ kfree(tiledata);
+ if (err) return err;
+ }
+
if (resize) {
/* reset wrap/pan */
info->var.xoffset = info->var.yoffset = p->yscroll = 0;
diff -Naur linux-2.5.54/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.54/include/linux/fb.h 2003-01-10 11:08:19.000000000 +0000
+++ linux/include/linux/fb.h 2003-01-10 11:21:27.000000000 +0000
@@ -173,6 +173,10 @@
#define FB_VMODE_SMOOTH_XPAN 512 /* smooth xpan possible (internally used) */
#define FB_VMODE_CONUPDATE 512 /* don't update x/yoffset */
+/* Driver Capability */
+#define FB_CAPS_CLIPPING 1 /* hardware can do clipping */
+#define FB_CAPS_TILEBLIT 2 /* hardware can do tileblits */
+
#define PICOS2KHZ(a) (1000000000UL/(a))
#define KHZ2PICOS(a) (1000000000UL/(a))
@@ -377,6 +381,77 @@
int (*fb_mmap)(struct fb_info *info, struct file *file, struct vm_area_struct *vma);
};
+/*
+ * Tile Blitting Support
+ *
+ * In Tile Blitting, the basic unit is a Tile which is a bitmap with
+ * a predefined width and height, and optionally, other properties
+ * such as color depth, spacing, transparency, etc. For now, we'll
+ * just support width, height, and color depth.
+ *
+ * All operations are analogous to classic blitting operations which
+ * use pixels as the basic unit. Instead of pixels, it will use tiles,
+ * instead of info->pseudo_palette, it will use tiledata, etc.
+ */
+
+struct fb_tile {
+ __u32 width; /* tile width in pixels */
+ __u32 height; /* tile height in scanlines */
+ __u32 depth; /* pixel depth */
+};
+
+struct fb_tiledata {
+ struct fb_tile tile; /* tile properties */
+ __u32 len; /* number of tiles in the map */
+ __u8 *data; /* packed tile data */
+};
+
+struct fb_tileblit {
+ __u32 dx; /* destination x origin, in tiles */
+ __u32 dy; /* destination y origin, in tiles */
+ __u32 width; /* destination window width, in tiles */
+ __u32 height; /* destination window height, in tiles */
+ __u32 fg_color; /* fg_color if monochrome */
+ __u32 bg_color; /* bg_color if monochrome */
+ __u32 *data; /* tile map - array of indices to tiledata */
+};
+
+struct fb_tilecopy {
+ __u32 dx; /* destination window origin... */
+ __u32 dy; /* in tiles */
+ __u32 width; /* destination width, in tiles */
+ __u32 height; /* destination height, in tiles */
+ __u32 sx; /* source window origin ... */
+ __u32 sy; /* in tiles */
+};
+
+struct fb_tilefill {
+ __u32 dx; /* destination window origin ... */
+ __u32 dy; /* in tiles */
+ __u32 width; /* destination width in tiles */
+ __u32 height; /* destination height in tiles */
+ __u32 fg_color; /* fg_color if monochrome */
+ __u32 bg_color; /* bg_color if monochrome */
+ __u32 rop; /* rop operation */
+ __u32 idx; /* index to current tiledata */
+};
+
+struct fb_tileops {
+ /* upload tile data to driver and make it current... the driver
+ * must copy the contents of tiledata.data, not just the pointer to it */
+ int (*fb_loadtiles)(struct fb_info *info,
+ const struct fb_tiledata *tile);
+ /* blit tiles to destination from a tilemap */
+ void (*fb_tileblit)(struct fb_info *info,
+ const struct fb_tileblit *tilemap);
+ /* copy tiles from one region of fb memory to another */
+ void (*fb_tilecopy)(struct fb_info *info, const struct fb_tilecopy *area);
+ /* fill a region of fb memory with a tile */
+ void (*fb_tilefill)(struct fb_info *info,
+ const struct fb_tilefill *region);
+ /* If driver is to support tile blitting, all hooks above are required */
+};
+
struct fb_info {
kdev_t node;
int flags;
@@ -388,6 +463,7 @@
struct fb_cursor cursor; /* Current cursor */
struct fb_cmap cmap; /* Current cmap */
struct fb_ops *fbops;
+ struct fb_tileops *tileops /* Tile blitting */
char *screen_base; /* Virtual address */
struct vc_data *display_fg; /* Console visible on this display */
int currcon; /* Current VC. */
^ permalink raw reply
* Re: SSH doesnt properly logout
From: Jamie Harris @ 2003-01-10 14:36 UTC (permalink / raw)
To: axel; +Cc: linux-admin
In-Reply-To: <20030110140855.GB2417@neon.pearbough.net>
I get the same behaviour. I've always assumed its sshd not completely
closing down due to child process still being alive. I can't say I've
really ever looked too closely into this as I don't end up with lots of
zombie sshd's lying around when I just kill the ssh client off.
cheers
Jamie...
> Hi linux admins,
>
> I'm observing some strange behaviour concerning ssh and logging out from
> a ssh connection when I put a process in background on the remote side.
> For instance I do the following:
>
> * I start a gcc compilation on the remote terminal
> make bootstrap >& build.log &
> Then it goes into background.
>
> * Now I "logout" but do not return to my local terminal, now there is
> only a
> blank screen with the cursor in the upper left side.
>
> Can somebody help me please in understand this behaviour or rather help
> me fix it?
>
>
> Best regards,
> Axel Siebenwirth
> -
> To unsubscribe from this list: send the line "unsubscribe linux-admin"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
** This message was transmitted on 100% recycled electrons **
^ permalink raw reply
* gpart-0.1g-reiserfs-3.6.diff
From: Yury Umanets @ 2003-01-10 14:34 UTC (permalink / raw)
To: stefan; +Cc: Reiserfs-List
[-- Attachment #1: Type: text/plain, Size: 137 bytes --]
Hello Stefan,
I've made a patch aginst gpart-0.1h for detecting reiserfs 3.6 partitions.
See attachment for details.
--
Yury Umanets
[-- Attachment #2: gpart-0.1h-reiserfs-3.6.diff --]
[-- Type: text/plain, Size: 14479 bytes --]
diff -rupN ./gpart-0.1h.orig/README ./gpart-0.1h/README
--- ./gpart-0.1h.orig/README Wed Feb 7 20:58:12 2001
+++ ./gpart-0.1h/README Fri Jan 10 16:29:43 2003
@@ -24,25 +24,25 @@
- Currently recognized partitions/filesystems types ---------------------
- Modname Typ Description
- fat 0x01 "Primary DOS with 12 bit FAT"
- 0x04 "Primary DOS with 16 bit FAT (<= 32MB)"
- 0x06 "Primary 'big' DOS (> 32MB)"
- 0x0B "DOS or Windows 95 with 32 bit FAT"
- 0x0C "DOS or Windows 95 with 32 bit FAT, LBA"
- ntfs 0x07 "OS/2 HPFS, NTFS, QNX or Advanced UNIX"
- hpfs 0x07 "OS/2 HPFS, NTFS, QNX or Advanced UNIX"
- ext2 0x83 "Linux ext2 filesystem"
- lswap 0x82 "Linux swap"
- bsddl 0xA5 "FreeBSD/NetBSD/386BSD"
- s86dl 0x82 "Solaris/x86 disklabel"
- minix 0x80 "Minix V1"
- 0x81 "Minix V2"
- rfs 0x83 "Reiser filesystem"
- hmlvm 0xFE "Linux LVM physical volumes"
- qnx4 0x4F "QNX 4.x"
- beos 0xEB "BeOS fs"
- xfs 0x83 "SGI XFS filesystem"
+ Modname Typ Description
+ fat 0x01 "Primary DOS with 12 bit FAT"
+ 0x04 "Primary DOS with 16 bit FAT (<= 32MB)"
+ 0x06 "Primary 'big' DOS (> 32MB)"
+ 0x0B "DOS or Windows 95 with 32 bit FAT"
+ 0x0C "DOS or Windows 95 with 32 bit FAT, LBA"
+ ntfs 0x07 "OS/2 HPFS, NTFS, QNX or Advanced UNIX"
+ hpfs 0x07 "OS/2 HPFS, NTFS, QNX or Advanced UNIX"
+ ext2 0x83 "Linux ext2 filesystem"
+ lswap 0x82 "Linux swap"
+ bsddl 0xA5 "FreeBSD/NetBSD/386BSD"
+ s86dl 0x82 "Solaris/x86 disklabel"
+ minix 0x80 "Minix V1"
+ 0x81 "Minix V2"
+ reiserfs 0x83 "ReiserFS filesystem"
+ hmlvm 0xFE "Linux LVM physical volumes"
+ qnx4 0x4F "QNX 4.x"
+ beos 0xEB "BeOS fs"
+ xfs 0x83 "SGI XFS filesystem"
diff -rupN ./gpart-0.1h.orig/man/gpart.man ./gpart-0.1h/man/gpart.man
--- ./gpart-0.1h.orig/man/gpart.man Wed Feb 7 20:54:18 2001
+++ ./gpart-0.1h/man/gpart.man Fri Jan 10 16:31:52 2003
@@ -63,8 +63,8 @@ MS Windows NT/2000 filesystem.
.I qnx4
QNX 4.x filesystem.
.TP
-.I rfs
-The Reiser filesystem (version 3.5.X, X > 11).
+.I reiserfs
+The Reiser filesystem (version 3.5.X, X > 11, 3.6.X).
.TP
.I s86dl
Sun Solaris on Intel platforms uses a sub-partitioning
diff -rupN ./gpart-0.1h.orig/src/Makefile ./gpart-0.1h/src/Makefile
--- ./gpart-0.1h.orig/src/Makefile Tue Jan 30 20:01:08 2001
+++ ./gpart-0.1h/src/Makefile Fri Jan 10 16:32:24 2003
@@ -19,7 +19,7 @@ CFLAGS+=-DGPART_LANG=\'$(GPART_LANG)\'
endif
-mod=ext2 lswap fat bsddl ntfs hpfs s86dl minix rfs hmlvm qnx4 beos xfs
+mod=ext2 lswap fat bsddl ntfs hpfs s86dl minix reiserfs hmlvm qnx4 beos xfs
modobj=$(foreach m,$(mod),gm_$(m).o)
obj=gpart.o gmodules.o disku.o l64seek.o $(modobj)
src=$(obj:.o=.c)
diff -rupN ./gpart-0.1h.orig/src/gm_reiserfs.c ./gpart-0.1h/src/gm_reiserfs.c
--- ./gpart-0.1h.orig/src/gm_reiserfs.c Thu Jan 1 03:00:00 1970
+++ ./gpart-0.1h/src/gm_reiserfs.c Fri Jan 10 17:25:30 2003
@@ -0,0 +1,91 @@
+/*
+ * gm_reiserfs.c -- gpart ReiserFS guessing module
+ *
+ * gpart (c) 1999-2001 Michail Brzitwa <mb@ichabod.han.de>
+ * Guess PC-type hard disk partitions.
+ *
+ * gpart is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2, or (at your
+ * option) any later version.
+ *
+ * Created: 21.01.1999 <mb@ichabod.han.de>
+ * Modified: 26.12.2000 Francis Devereux <francis@devereux.tc>
+ * Added reiserfs 3.5.28 support.
+ * Modified: 10.01.2003 yury Umanets <umka@namesys.com>
+ * Added reiserfs 3.6.x support.
+ *
+ */
+
+#include <string.h>
+#include <errno.h>
+#include "gpart.h"
+#include "gm_reiserfs.h"
+
+static const char rcsid[] = "$Id: gm_reiserfs.c,v 1.5 2003/01/10 16:38:08 mb Exp mb $";
+
+
+int reiserfs_init(disk_desc *d,g_module *m)
+{
+ if ((d == 0) || (m == 0))
+ return (0);
+
+ m->m_desc = "ReiserFS filesystem";
+ return (REISERFS_FIRST_BLOCK * 1024 + SB_V35_SIZE);
+}
+
+
+
+int reiserfs_term(disk_desc *d)
+{
+ return (1);
+}
+
+
+
+int reiserfs_gfun(disk_desc *d,g_module *m)
+{
+ struct reiserfs_super_block_v35 *sb;
+ dos_part_entry *pt = &m->m_part;
+ s64_t size;
+
+ m->m_guess = GM_NO;
+ sb = (struct reiserfs_super_blockv35 *)(d->d_sbuf + REISERFS_FIRST_BLOCK * 1024);
+ if (strncmp(sb->s_magic,REISERFS_SUPER_V35_MAGIC,12) == 0 ||
+ strncmp(sb->s_magic,REISERFS_SUPER_V36_MAGIC,12) == 0)
+ {
+ /*
+ * sanity checks.
+ */
+
+ if (sb->s_block_count < sb->s_free_blocks)
+ return (1);
+
+ if (sb->s_block_count < REISERFS_MIN_BLOCK_AMOUNT)
+ return (1);
+
+ if ((sb->s_state != REISERFS_VALID_FS) &&
+ (sb->s_state != REISERFS_ERROR_FS))
+ return (1);
+
+ if (sb->s_oid_maxsize % 2) /* must be even */
+ return (1);
+
+ if (sb->s_oid_maxsize < sb->s_oid_cursize)
+ return (1);
+
+ if ((sb->s_blocksize != 4096) && (sb->s_blocksize != 8192))
+ return (1);
+
+ /*
+ * ok.
+ */
+
+ m->m_guess = GM_YES;
+ pt->p_start = d->d_nsb;
+ size = sb->s_block_count; size *= sb->s_blocksize; size /= d->d_ssize;
+ pt->p_size = (unsigned long)size;
+ pt->p_typ = 0x83;
+ }
+ return (1);
+}
diff -rupN ./gpart-0.1h.orig/src/gm_reiserfs.h ./gpart-0.1h/src/gm_reiserfs.h
--- ./gpart-0.1h.orig/src/gm_reiserfs.h Thu Jan 1 03:00:00 1970
+++ ./gpart-0.1h/src/gm_reiserfs.h Fri Jan 10 17:25:55 2003
@@ -0,0 +1,82 @@
+/*
+ * gm_reiserfs.h -- gpart ReiserFS guessing module header
+ *
+ * gpart (c) 1999-2001 Michail Brzitwa <mb@ichabod.han.de>
+ * Guess PC-type hard disk partitions.
+ *
+ * gpart is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2, or (at your
+ * option) any later version.
+ *
+ * Created: 21.01.1999 <mb@ichabod.han.de>
+ * Modified: 26.12.2000 Francis Devereux <francis@devereux.tc>
+ * Update support reiserfs version 3.5.28
+ * Modified: 10.01.2003 yury Umanets <umka@namesys.com>
+ * Added reiserfs 3.6.x support.
+ *
+ */
+
+#ifndef _GM_reiserfs_H
+#define _GM_reiserfs_H
+
+/* imported from asm/types.h */
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+/*
+ * taken from ReiserFS v3.5.28, v3.6.x. Reiserfs Copyright 1996-2000 Hans Reiser
+ */
+
+#define REISERFS_SUPER_V35_MAGIC "ReIsErFs"
+#define REISERFS_SUPER_V36_MAGIC "ReIsEr2Fs"
+
+#define REISERFS_FIRST_BLOCK 64
+#define REISERFS_VALID_FS 1
+#define REISERFS_ERROR_FS 2
+#define REISERFS_MIN_BLOCK_AMOUNT 100
+
+struct reiserfs_super_block_v35
+{
+ __u32 s_block_count; /* blocks count */
+ __u32 s_free_blocks; /* free blocks count */
+ __u32 s_root_block; /* root block number */
+ __u32 s_journal_block; /* journal block number */
+ __u32 s_journal_dev; /* journal device number */
+ __u32 s_orig_journal_size; /* size of the journal on FS creation. used to make sure they don't overflow it */
+ __u32 s_journal_trans_max; /* max number of blocks in a transaction. */
+ __u32 s_journal_block_count; /* total size of the journal. can change over time */
+ __u32 s_journal_max_batch; /* max number of blocks to batch into a trans */
+ __u32 s_journal_max_commit_age; /* in seconds, how old can an async commit be */
+ __u32 s_journal_max_trans_age; /* in seconds, how old can a transaction be */
+ __u16 s_blocksize; /* block size */
+ __u16 s_oid_maxsize; /* max size of object id array, see get_objectid() commentary */
+ __u16 s_oid_cursize; /* current size of object id array */
+ __u16 s_state; /* valid or error */
+ char s_magic[12]; /* reiserfs magic string indicates that file system is reiserfs */
+ __u32 s_hash_function_code; /* indicate, what hash fuction is being use to sort names in a directory*/
+ __u16 s_tree_height; /* height of disk tree */
+ __u16 s_bmap_nr; /* amount of bitmap blocks needed to address each block of file system */
+ __u16 s_reserved;
+};
+
+#define SB_V35_SIZE (sizeof(struct reiserfs_super_block_v35))
+
+struct reiserfs_super_block_v36 {
+ struct reiserfs_super_block_v35 s_v35;
+ __u32 s_inode_generation;
+ __u32 s_flags;
+ char s_uuid[16];
+ char s_label[16];
+ char s_unused[88];
+};
+
+#define SB_V36_SIZE (sizeof(struct reiserfs_super_block_v36))
+
+#endif /* _GM_REISERFS_H */
diff -rupN ./gpart-0.1h.orig/src/gm_rfs.c ./gpart-0.1h/src/gm_rfs.c
--- ./gpart-0.1h.orig/src/gm_rfs.c Wed Feb 7 21:08:08 2001
+++ ./gpart-0.1h/src/gm_rfs.c Thu Jan 1 03:00:00 1970
@@ -1,88 +0,0 @@
-/*
- * gm_rfs.c -- gpart ReiserFS guessing module
- *
- * gpart (c) 1999-2001 Michail Brzitwa <mb@ichabod.han.de>
- * Guess PC-type hard disk partitions.
- *
- * gpart is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published
- * by the Free Software Foundation; either version 2, or (at your
- * option) any later version.
- *
- * Created: 21.01.1999 <mb@ichabod.han.de>
- * Modified: 26.12.2000 Francis Devereux <francis@devereux.tc>
- * Added reiserfs 3.5.28 support.
- *
- */
-
-#include <string.h>
-#include <errno.h>
-#include "gpart.h"
-#include "gm_rfs.h"
-
-static const char rcsid[] = "$Id: gm_rfs.c,v 1.5 2001/02/07 18:08:08 mb Exp mb $";
-
-
-int rfs_init(disk_desc *d,g_module *m)
-{
- if ((d == 0) || (m == 0))
- return (0);
-
- m->m_desc = "Reiser filesystem";
- return (REISERFS_FIRST_BLOCK * 1024 + SB_SIZE);
-}
-
-
-
-int rfs_term(disk_desc *d)
-{
- return (1);
-}
-
-
-
-int rfs_gfun(disk_desc *d,g_module *m)
-{
- struct reiserfs_super_block *sb;
- dos_part_entry *pt = &m->m_part;
- s64_t size;
-
- m->m_guess = GM_NO;
- sb = (struct reiserfs_super_block *)(d->d_sbuf + REISERFS_FIRST_BLOCK * 1024);
- if (strncmp(sb->s_magic,REISERFS_SUPER_MAGIC,12) == 0)
- {
- /*
- * sanity checks.
- */
-
- if (sb->s_block_count < sb->s_free_blocks)
- return (1);
-
- if (sb->s_block_count < REISERFS_MIN_BLOCK_AMOUNT)
- return (1);
-
- if ((sb->s_state != REISERFS_VALID_FS) &&
- (sb->s_state != REISERFS_ERROR_FS))
- return (1);
-
- if (sb->s_oid_maxsize % 2) /* must be even */
- return (1);
-
- if (sb->s_oid_maxsize < sb->s_oid_cursize)
- return (1);
-
- if ((sb->s_blocksize != 4096) && (sb->s_blocksize != 8192))
- return (1);
-
- /*
- * ok.
- */
-
- m->m_guess = GM_YES;
- pt->p_start = d->d_nsb;
- size = sb->s_block_count; size *= sb->s_blocksize; size /= d->d_ssize;
- pt->p_size = (unsigned long)size;
- pt->p_typ = 0x83;
- }
- return (1);
-}
diff -rupN ./gpart-0.1h.orig/src/gm_rfs.h ./gpart-0.1h/src/gm_rfs.h
--- ./gpart-0.1h.orig/src/gm_rfs.h Mon Jan 29 16:34:35 2001
+++ ./gpart-0.1h/src/gm_rfs.h Thu Jan 1 03:00:00 1970
@@ -1,68 +0,0 @@
-/*
- * gm_rfs.h -- gpart ReiserFS guessing module header
- *
- * gpart (c) 1999-2001 Michail Brzitwa <mb@ichabod.han.de>
- * Guess PC-type hard disk partitions.
- *
- * gpart is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published
- * by the Free Software Foundation; either version 2, or (at your
- * option) any later version.
- *
- * Created: 21.01.1999 <mb@ichabod.han.de>
- * Modified: 26.12.2000 Francis Devereux <francis@devereux.tc>
- * Update support reiserfs version 3.5.28
- *
- */
-
-#ifndef _GM_RFS_H
-#define _GM_RFS_H
-
-/* imported from asm/types.h */
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
-
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
-
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-/*
- * taken from ReiserFS v3.5.28. Reiserfs Copyright 1996-2000 Hans Reiser
- */
-
-#define REISERFS_SUPER_MAGIC "ReIsErFs"
-#define REISERFS_FIRST_BLOCK 64
-#define REISERFS_VALID_FS 1
-#define REISERFS_ERROR_FS 2
-#define REISERFS_MIN_BLOCK_AMOUNT 100
-
-struct reiserfs_super_block
-{
- __u32 s_block_count; /* blocks count */
- __u32 s_free_blocks; /* free blocks count */
- __u32 s_root_block; /* root block number */
- __u32 s_journal_block; /* journal block number */
- __u32 s_journal_dev; /* journal device number */
- __u32 s_orig_journal_size; /* size of the journal on FS creation. used to make sure they don't overflow it */
- __u32 s_journal_trans_max; /* max number of blocks in a transaction. */
- __u32 s_journal_block_count; /* total size of the journal. can change over time */
- __u32 s_journal_max_batch; /* max number of blocks to batch into a trans */
- __u32 s_journal_max_commit_age; /* in seconds, how old can an async commit be */
- __u32 s_journal_max_trans_age; /* in seconds, how old can a transaction be */
- __u16 s_blocksize; /* block size */
- __u16 s_oid_maxsize; /* max size of object id array, see get_objectid() commentary */
- __u16 s_oid_cursize; /* current size of object id array */
- __u16 s_state; /* valid or error */
- char s_magic[12]; /* reiserfs magic string indicates that file system is reiserfs */
- __u32 s_hash_function_code; /* indicate, what hash fuction is being use to sort names in a directory*/
- __u16 s_tree_height; /* height of disk tree */
- __u16 s_bmap_nr; /* amount of bitmap blocks needed to address each block of file system */
- __u16 s_reserved;
-};
-
-#define SB_SIZE (sizeof(struct reiserfs_super_block))
-
-
-#endif /* _GM_RFS_H */
diff -rupN ./gpart-0.1h.orig/src/gmodules.c ./gpart-0.1h/src/gmodules.c
--- ./gpart-0.1h.orig/src/gmodules.c Tue Jan 30 20:01:00 2001
+++ ./gpart-0.1h/src/gmodules.c Fri Jan 10 16:31:28 2003
@@ -154,7 +154,7 @@ void g_mod_addinternals()
GMODINS(bsddl);
GMODINS(lswap);
GMODINS(qnx4);
- GMODINS(rfs);
+ GMODINS(reiserfs);
GMODINS(ntfs);
GMODINS(hpfs);
GMODINS(minix);
diff -rupN ./gpart-0.1h.orig/src/gmodules.h ./gpart-0.1h/src/gmodules.h
--- ./gpart-0.1h.orig/src/gmodules.h Tue Jan 30 20:00:47 2001
+++ ./gpart-0.1h/src/gmodules.h Fri Jan 10 16:31:23 2003
@@ -63,7 +63,7 @@ g_module *g_mod_setweight(char *,float);
GMODDECL(bsddl); GMODDECL(ext2); GMODDECL(fat);
GMODDECL(hpfs); GMODDECL(lswap); GMODDECL(ntfs);
-GMODDECL(s86dl); GMODDECL(minix); GMODDECL(rfs);
+GMODDECL(s86dl); GMODDECL(minix); GMODDECL(reiserfs);
GMODDECL(hmlvm); GMODDECL(qnx4); GMODDECL(beos);
GMODDECL(xfs);
^ permalink raw reply
* Re: fs errors on thinkpad R31
From: Oleg Drokin @ 2003-01-10 14:32 UTC (permalink / raw)
To: Bernd Schubert; +Cc: ReiserFS
In-Reply-To: <200301092320.48501.bernd-schubert@web.de>
Hello!
On Thu, Jan 09, 2003 at 11:20:48PM +0100, Bernd Schubert wrote:
> this is the second time within 14 days after which I had to run reiserfsck on
> my IBM Thinkpad R31.
> This time I lost a directory with 49 files (it seems it were only kernel
> modules, so probably not so important data).
> I have attached the error messages from the /var/log/messages file.
Hm. Looks like some blocks have unexpected contents.
Do you often uncleanly turn-off/run out of battaries prior to
corruption?
Try to disable write caching in your harddrive then. (hdparm -W0 /dev/hda)
Bye,
Oleg
^ permalink raw reply
* [patch] R4000/R4400 64-bit errata handling
From: Maciej W. Rozycki @ 2003-01-10 14:32 UTC (permalink / raw)
To: Ralf Baechle, linux-mips; +Cc: Karsten Merker, Thiemo Seufer
Hello,
As you might already know there are a few nasty errata in the R4000 and
the early R4400 that hit 64-bit operation badly. Here is proposed code to
detect them. If an erratum is found in the processor and no workaround is
applied to a kernel executable, the kernel refuses to run. In all cases
the result of the probes is output to the bootstrap log.
The code has bits that make use of features of non-standard tools
(binutils and gcc). But it doesn't depend on them -- when built with
standard tools and run on an affected system, a kernel will simply fail,
and on good systems it will run normally. Therefore it's safe to apply,
and if the ultimate implementation in the tools differs, the code may get
adjusted appropriately later.
I'd like to apply this code as soon as possible as I consider it a
prerequisite for integrating 64-bit support for the DECstation (to prevent
people from running unreliable code), so please tell me if there are any
doubts about it. Errata descriptions are available at the MIPS site --
see: 'http://www.mips.com/publications/r400_r5000.html'. Unfortunately,
despite several attempts to get a permission to duplicate them within
Linux sources, I failed to get one.
I'd like to express my gratitude to Karsten and Thiemo for testing the
code with their hardware. Without their help, I wouldn't be able to
prepare appropriate tests for errata my hardware doesn't suffer from.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
patch-mips-2.4.20-pre6-20021212-mips-bugs-20
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/Makefile linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/Makefile
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/Makefile 2002-12-04 03:56:39.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/Makefile 2003-01-09 19:04:31.000000000 +0000
@@ -32,6 +32,7 @@ ifndef CONFIG_MAPPED_PCI_IO
obj-y += pci-dma.o
endif
-AFLAGS_r4k_genex.o := -P
+CFLAGS_cpu-probe.o = $(shell if $(CC) $(CFLAGS) -Wa,-mdaddi -c -o /dev/null -xc /dev/null >/dev/null 2>&1; then echo "-DHAVE_AS_SET_DADDI"; fi)
+AFLAGS_r4k_genex.o = -P
include $(TOPDIR)/Rules.make
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/cpu-probe.c linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/cpu-probe.c
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/cpu-probe.c 2002-12-04 03:56:39.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/cpu-probe.c 2003-01-09 20:19:32.000000000 +0000
@@ -1,10 +1,27 @@
+/*
+ * arch/mips64/kernel/cpu-probe.c
+ *
+ * Processor capabilities determination functions.
+ *
+ * Copyright (C) xxxx the Anonymous
+ * Copyright (C) 2003 Maciej W. Rozycki
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
#include <linux/init.h>
#include <linux/kernel.h>
+#include <linux/ptrace.h>
#include <linux/stddef.h>
+
#include <asm/bugs.h>
#include <asm/cpu.h>
#include <asm/fpu.h>
#include <asm/mipsregs.h>
+#include <asm/system.h>
/*
* Not all of the MIPS CPUs have the "wait" instruction available. Moreover,
@@ -90,9 +107,229 @@ static inline void check_wait(void)
}
}
+static inline void check_mult_sh(void)
+{
+ unsigned long flags;
+ int m1, m2;
+ long p, s, v;
+
+ printk("Checking for the multiply/shift bug... ");
+
+ __save_and_cli(flags);
+ /*
+ * The following code leads to a wrong result of dsll32 when
+ * executed on R4000 rev. 2.2 or 3.0.
+ *
+ * See "MIPS R4000PC/SC Errata, Processor Revision 2.2 and
+ * 3.0" by MIPS Technologies, Inc., errata #16 and #28 for
+ * details. I got no permission to duplicate them here,
+ * sigh... --macro
+ */
+ asm volatile(
+ ".set push\n\t"
+ ".set noat\n\t"
+ ".set noreorder\n\t"
+ ".set nomacro\n\t"
+ "mult %1, %2\n\t"
+ "dsll32 %0, %3, %4\n\t"
+ "mflo $0\n\t"
+ ".set pop"
+ : "=r" (v)
+ : "r" (5), "r" (8), "r" (5), "I" (0)
+ : "hi", "lo", "accum");
+ __restore_flags(flags);
+
+ if (v == 5L << 32) {
+ printk("no.\n");
+ return;
+ }
+
+ printk("yes, workaround... ");
+ __save_and_cli(flags);
+ /*
+ * We want the multiply and the shift to be isolated from the
+ * rest of the code to disable gcc optimizations. Hence the
+ * asm statements that execute nothing, but make gcc not know
+ * what the values of m1, m2 and s are and what v and p are
+ * used for.
+ *
+ * We have to use single integers for m1 and m2 and a double
+ * one for p to be sure the mulsidi3 gcc's RTL multiplication
+ * instruction has the workaround applied. Older versions of
+ * gcc have correct mulsi3, but other multiplication variants
+ * lack the workaround.
+ */
+ asm volatile(
+ ""
+ : "=r" (m1), "=r" (m2), "=r" (s)
+ : "0" (5), "1" (8), "2" (5));
+ p = m1 * m2;
+ v = s << 32;
+ asm volatile(
+ ""
+ : "=r" (v)
+ : "0" (v), "r" (p));
+ __restore_flags(flags);
+
+ if (v == 5L << 32) {
+ printk("yes.\n");
+ return;
+ }
+
+ printk("no.\n");
+ panic("Reliable operation impossible!\n"
+#ifndef CONFIG_CPU_R4000
+ "Configure for R4000 to enable the workaround."
+#else
+ "Please report to <linux-mips@linux-mips.org>."
+#endif
+ );
+}
+
+static volatile int daddi_ov __initdata = 0;
+
+asmlinkage void __init do_daddi_ov(struct pt_regs *regs)
+{
+ daddi_ov = 1;
+ regs->cp0_epc += 4;
+}
+
+static inline void check_daddi(void)
+{
+ extern asmlinkage void handle_daddi_ov(void);
+ unsigned long flags;
+ void *handler;
+ long v;
+
+ printk("Checking for the daddi bug... ");
+
+ __save_and_cli(flags);
+ handler = set_except_vector(12, handle_daddi_ov);
+ /*
+ * The following code fails to trigger an overflow exception
+ * when executed on R4000 rev. 2.2 or 3.0.
+ *
+ * See "MIPS R4000PC/SC Errata, Processor Revision 2.2 and
+ * 3.0" by MIPS Technologies, Inc., erratum #23 for details.
+ * I got no permission to duplicate it here, sigh... --macro
+ */
+ asm volatile(
+ ".set push\n\t"
+ ".set noat\n\t"
+ ".set noreorder\n\t"
+ ".set nomacro\n\t"
+#ifdef HAVE_AS_SET_DADDI
+ ".set daddi\n\t"
+#endif
+ "daddi %0, %1, %2\n\t"
+ ".set pop"
+ : "=r" (v)
+ : "r" (0x7fffffffffffedcd), "I" (0x1234));
+ set_except_vector(12, handler);
+ __restore_flags(flags);
+
+ if (daddi_ov) {
+ printk("no.\n");
+ return;
+ }
+
+ printk("yes, workaround... ");
+
+ __save_and_cli(flags);
+ handler = set_except_vector(12, handle_daddi_ov);
+ asm volatile(
+ "daddi %0, %1, %2"
+ : "=r" (v)
+ : "r" (0x7fffffffffffedcd), "I" (0x1234));
+ set_except_vector(12, handler);
+ __restore_flags(flags);
+
+ if (daddi_ov) {
+ printk("yes.\n");
+ return;
+ }
+
+ printk("no.\n");
+ panic("Reliable operation impossible!\n"
+#if !defined(CONFIG_CPU_R4000) && !defined(CONFIG_CPU_R4400)
+ "Configure for R4000 or R4400 to enable the workaround."
+#else
+ "Please report to <linux-mips@linux-mips.org>."
+#endif
+ );
+}
+
+static inline void check_daddiu(void)
+{
+ long v, w;
+
+ printk("Checking for the daddiu bug... ");
+
+ /*
+ * The following code leads to a wrong result of daddiu when
+ * executed on R4400 rev. 1.0.
+ *
+ * See "MIPS R4400PC/SC Errata, Processor Revision 1.0" by
+ * MIPS Technologies, Inc., erratum #7 for details.
+ *
+ * According to "MIPS R4000PC/SC Errata, Processor Revision
+ * 2.2 and 3.0" by MIPS Technologies, Inc., erratum #41 this
+ * problem affects R4000 rev. 2.2 and 3.0, too. Testing
+ * failed to trigger it so far.
+ *
+ * I got no permission to duplicate the errata here, sigh...
+ * --macro
+ */
+ asm volatile(
+ ".set push\n\t"
+ ".set noat\n\t"
+ ".set noreorder\n\t"
+ ".set nomacro\n\t"
+#ifdef HAVE_AS_SET_DADDI
+ ".set daddi\n\t"
+#endif
+ "daddiu %0, %2, %3\n\t"
+ "addiu %1, $0, %3\n\t"
+ "daddu %1, %2\n\t"
+ ".set pop"
+ : "=&r" (v), "=&r" (w)
+ : "r" (0x7fffffffffffedcd), "I" (0x1234));
+
+ if (v == w) {
+ printk("no.\n");
+ return;
+ }
+
+ printk("yes, workaround... ");
+
+ asm volatile(
+ "daddiu %0, %2, %3\n\t"
+ "addiu %1, $0, %3\n\t"
+ "daddu %1, %2"
+ : "=&r" (v), "=&r" (w)
+ : "r" (0x7fffffffffffedcd), "I" (0x1234));
+
+ if (v == w) {
+ printk("yes.\n");
+ return;
+ }
+
+ printk("no.\n");
+ panic("Reliable operation impossible!\n"
+#if !defined(CONFIG_CPU_R4000) && !defined(CONFIG_CPU_R4400)
+ "Configure for R4000 or R4400 to enable the workaround."
+#else
+ "Please report to <linux-mips@linux-mips.org>."
+#endif
+ );
+}
+
void __init check_bugs(void)
{
check_wait();
+ check_mult_sh();
+ check_daddi();
+ check_daddiu();
}
/*
diff -up --recursive --new-file linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/r4k_genex.S linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/r4k_genex.S
--- linux-mips-2.4.20-pre6-20021212.macro/arch/mips64/kernel/r4k_genex.S 2002-10-02 17:22:18.000000000 +0000
+++ linux-mips-2.4.20-pre6-20021212/arch/mips64/kernel/r4k_genex.S 2002-10-22 21:44:51.000000000 +0000
@@ -35,6 +35,11 @@
__INIT
+/* A temporary overflow handler used by check_daddi(). */
+
+ BUILD_HANDLER daddi_ov daddi_ov none silent /* #12 */
+
+
/* General exception handler for CPUs with virtual coherency exception.
*
* Be careful when changing this, it has to be at most 256 (as a special
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Adrian Bunk @ 2003-01-10 14:38 UTC (permalink / raw)
To: Alan Cox, Joachim Martillo; +Cc: linux-kernel
In-Reply-To: <200301090139.h091d9G26412@devserv.devel.redhat.com>
On Wed, Jan 08, 2003 at 08:39:09PM -0500, Alan Cox wrote:
>...
> Linux 2.4.21pre3-ac2
>...
> o Driver for Aurora Sio16 PCI adapter series (Joachim Martillo)
> (SIO8000P, 16000P, and CPCI)
> | Initial merge
>...
siolx_cleanup in drivers/char/cd1865/cd1865.c is __exit but called from
the __init function siolx_init causing a .text.exit error when compiling
this driver statically into the kernel. The following patch that removes
the __exit fixes it:
--- linux-2.4.20-ac/drivers/char/cd1865/cd1865.c.old 2003-01-10 15:31:41.000000000 +0100
+++ linux-2.4.20-ac/drivers/char/cd1865/cd1865.c 2003-01-10 15:32:26.000000000 +0100
@@ -2630,7 +2630,7 @@
}
-static void __exit siolx_cleanup(void)
+static void siolx_cleanup(void)
{
siolx_release_drivers();
siolx_release_memory();
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: Pushing a stray sk_buff to the NIC
From: Rui Sousa @ 2003-01-10 14:34 UTC (permalink / raw)
To: Joshua Stewart; +Cc: Linux Kernel Mailing List, Linux network development
In-Reply-To: <1042161058.6107.18.camel@localhost.localdomain>
On Thu, 9 Jan 2003, Joshua Stewart wrote:
Hi,
> I'm trying to take "hand-built" sk_buffs with little more than some data
> and a dev member and push them to the NIC for transmission. I would
> like to simply give them to dev_queue_xmit. Does anybody know what
> state I should have them in before handing them to dev_queue_xmit?
In a driver I wrote I setup (for a newly allocated skb and a 2.4 kernel):
some_header = (struct some_header *) skb_push(skb, sizeof(struct some_header));
skb->nh.raw = (unsigned char *) some_header;
this_eth_hdr = (struct ethhdr *) skb_push(skb, ETH_HLEN);
this_eth_hdr->h_proto = __constant_htons(ETH_P_SOME_HEADER);
memcpy(this_eth_hdr->h_source, dev->dev_addr, ETH_ALEN);
skb->dev = dev;
skb->protocol = __constant_htons(ETH_P_CSM_ENCAPS);
dev_queue_xmit(skb);
where some_header for you is probably an IP header and dev is the "struct
net_device" of the device you are using to send the packet out on the
wire.
> Should skb->data point to the start of a MAC header or an IP header?
MAC
> Also, given an IP address in skb->nh.iph->daddr, what's the easiest way
> to get the appropriate MAC address?
First you need to get the device, then the MAC address is easy. This
should be what normal IP routing code does...
> J
>
>
Rui
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* RE: Reg iptables Connection tracking
From: Amit Kumar Gupta @ 2003-01-10 14:25 UTC (permalink / raw)
To: Athan; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]
Hi,
But As I have told previously, (in my previous mails), I don't have
/proc file system. So it is taking the default value of 1016.
Even I changed the kernel code also by hardcoding this value in
init_conntrack function to 4096 but it didn't has any effect.
Still it keeps dumping kernel messages.
Regards,
Amit
-----Original Message-----
From: Athan [mailto:netfilter@miggy.org]
Sent: Friday, January 10, 2003 7:33 PM
To: Amit Kumar Gupta
Cc: netfilter@lists.netfilter.org
Subject: Re: Reg iptables Connection tracking
On Fri, Jan 10, 2003 at 10:33:48AM +0530, Amit Kumar Gupta wrote:
> As soon as somebody pings to my m/c , that fellow doesn't get the
reply
> and on my m/c , kernel keeps dumping certain messages which are like
> this :-
>
> Ip_contrack: maximum limit of 1016 entries exceeded.
echo 32760 > /proc/sys/net/ipv4/ip_conntrack_max
Works to increase the size of the table. I had a problem with a default
of ~4092 for this when I was copying LOTS of files between machines
using "get -R directory" in ncftp. The above cured it.
HTH,
-Ath
--
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
Finger athan(at)fysh.org for PGP key
"And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 514 bytes --]
**************************Disclaimer************************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************************
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Alan Cox @ 2003-01-10 15:17 UTC (permalink / raw)
To: Ralf Hildebrandt; +Cc: Linux Kernel Mailing List
In-Reply-To: <20030110141729.GA31123@charite.de>
On Fri, 2003-01-10 at 14:17, Ralf Hildebrandt wrote:
> * Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
>
> > Backing out of mm/shmem.c makess thee bug disappear.
>
> Not really. I rebooted and then the ac2 crashed DURING a fsck that was
> caused by reaching the maximum mount count.
> I'm outta here and back to 2.4.21pre3 :)
Curious indeed. I guess we'll find the problem when I submit the
troublesome change to Marcelo 8). I'll look at that keyboard
fix, that seems a fairly sane workaround. Next stop is zapping
the other bits of journal related stuff and checking network
card fixup corner cases - what ethernet do you have btw ?
Alan
^ permalink raw reply
* Re: small migration thread fix
From: Erich Focht @ 2003-01-10 14:29 UTC (permalink / raw)
To: William Lee Irwin III
Cc: Ingo Molnar, Linus Torvalds, linux-kernel, Robert Love
In-Reply-To: <20030110131100.GS23814@holomorphy.com>
On Friday 10 January 2003 14:11, William Lee Irwin III wrote:
> I'm not mingo, but I can say this looks sane. My only question is
> whether there are more codepaths that need this kind of check, for
> instance, what happens if someone does set_cpus_allowed() to a cpumask
> with !(task->cpumask & cpu_online_map) ?
The piece of code below was intended for that. I agree with Rusty's
comment, BUG() is too strong for that case.
#if 0 /* FIXME: Grab cpu_lock, return error on this case. --RR */
new_mask &= cpu_online_map;
if (!new_mask)
BUG();
#endif
Anyhow, changing the new_mask in this way is BAD, because the masks
are inherited. So when more CPUs come online, they remain excluded
from the mask of the process and it's children.
The fix suggested in the comments still has to be done...
Regards,
Erich
^ permalink raw reply
* Re: 2.5.55: static compilation of mxser.c doesn't work
From: Alan Cox @ 2003-01-10 15:12 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Arnaldo Carvalho de Melo, Linux Kernel Mailing List, support
In-Reply-To: <20030110140313.GL6626@fs.tum.de>
On Fri, 2003-01-10 at 14:03, Adrian Bunk wrote:
> Hi Arnaldo,
>
> the 2.5 Linux kernel contains your patch
>
> o mxser: add module_exit/module_init
> This fixes the compilation problem in 2.5
>
> This patch renames mxser_init to mxser_module_init causing a compile
> error when trying to compile this driver statically into the kernel
> since mxser_init is still called from drivers/char/tty_io.c.
You should be able to kill the call from tty_io.c
^ permalink raw reply
* Re: [2.4.20] e1000 as module gives unresolved symbol _mmx_memcpy
From: Alan Cox @ 2003-01-10 15:14 UTC (permalink / raw)
To: Jurgen Kramer; +Cc: Linux Kernel Mailing List
In-Reply-To: <1042206299.1694.12.camel@paragon.slim>
On Fri, 2003-01-10 at 13:45, Jurgen Kramer wrote:
> Hi,
>
> While trying to use the e1000 as a module with kernel 2.4.20 it gives
> me a unresolved symbol while trying to insmod the module. The offending
> symbol is _mmx_memcpy. When the driver is compiled into the kernel
> there's no problem.
>
> I am running the kernel on a VIA Eden with 800MHz C3. Does this have
> something to do with the fact that kernels for the VIA C3 are now
> compiled with i486 optimisations (so maybe no MMX support?)?
Make sure you build from distclean if you've built for other cpu options
before. (cp .config ..; make distclean; cp ../.config .config; make oldconfig..
^ permalink raw reply
* Re: KERNEL BUG: assertion failure in reiserfs code
From: Oleg Drokin @ 2003-01-10 14:26 UTC (permalink / raw)
To: Pascal Junod; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0301101340520.1906-100000@lasecpc10.epfl.ch>
Hello!
On Fri, Jan 10, 2003 at 01:49:37PM +0100, Pascal Junod wrote:
> My /tmp partition is using reiserfs and I get following message when
> copying a large file on it (there is enough room, and fsck.reiserfs says
> everything is ok...). Is this issue known ? My kernel version is the
> linux-2.4.19-gentoo-r10 one.
This is issue is not know, but on the way to 2.4.20 the block allocator in
reiserfs was replaced with another one.
> Jan 10 13:38:34 lasecpc29 kernel: vs-4010: is_reusable: block number is out of range 248999 (248999)
Hm... Very strange. I cannot think off hand have that might happen.
Can you reproduce it somehow?
Thanks for the report
Bye,
Oleg
^ permalink raw reply
* Re: Severe reiserfs problems
From: Oleg Drokin @ 2003-01-10 14:21 UTC (permalink / raw)
To: Robert Szentmihalyi; +Cc: Linux Kernel Mailing List
In-Reply-To: <200301101332.50873.robert.szentmihalyi@entracom.de>
Hello!
On Fri, Jan 10, 2003 at 01:32:50PM +0100, Robert Szentmihalyi wrote:
> I have severe file system problems on a reiserfs partition.
> When I try copy files to another filesystem, the kernel panics at certain
> files.
Can you tell us what the panics were?
What was the kernel version?
> reiserfsck --fix-fixable says that I need to run
> reiserfsck --rebuild-tree to fix the errors, but when I do this,
> reiserfsck hangs after a few secounds.
What's the reiserfsck version you have?
What do you mean by hangs? Does it eats cpu time or something?
> Is there a way to rescue at least some of the data on the partition?
There is not enough info yet to know the answer.
Bye,
Oleg
^ permalink raw reply
* Re: aal_assert()
From: Yury Umanets @ 2003-01-10 14:12 UTC (permalink / raw)
To: Andrew Clausen; +Cc: reiserfs-list
In-Reply-To: <20030110133657.GE1056@gnu.org>
Andrew Clausen wrote:
>On Fri, Jan 10, 2003 at 10:22:43AM +0300, Yura Umanets wrote:
>
>
>>Actually there was the code earlier like you have proposed. And it was
>>changed to the current state due to the following reasons:
>>
>>* there are two developers working on reiser4progs currentry (Vitaly
>>Fertman and Yury Umanets). And our parts is much different. So, each of
>>us should work on own code.
>>* there is not neccessary an assertion is corect and only the author can
>>decide is it correct.
>>
>>
>
>Well, that decision is made by the developers, not the users.
>
Decision is made by developers in debug and test stage.
>Presumebly, you know who wrote what code. If an assertion is
>contentious (and 99.9% of them aren't), you should document *why*,
>anyway.
>
I should document why an assert is contentious? I think there should not
exist contentious assersions. Assertion is correct or not.
>
>
>
>>* NAMESYS has some development policies. And hints is the one of them.
>>
>>
>
>Why?
>
I don't know :)) Probably Nikita will tell you better. Hi is the old
resident of NAMESYS.
>
>Cheers,
>Andrew
>
>
>
>
>
--
Yury Umanets
^ permalink raw reply
* Re: clipping
From: Geert Uytterhoeven @ 2003-01-10 10:49 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Geert Uytterhoeven
In-Reply-To: <1042172278.933.145.camel@localhost.localdomain>
On 10 Jan 2003, Antonino Daplas wrote:
> For putcs and putc, I just made it mandatory that when one character is
> to be out of bounds, it just won't get drawn. A cleaner implementation
> is, of course, to clip the destination window + the passed bitmap.
Except for the geek value, why would it be cleaner to draw half of a character
near the border?
> Do we need to clip the fb_set_logo() too?
I don't think so. The current code already draws only the number of logos that
really fit on the screen. Unless you want to see half penguins as well :-)
> The patch may be a bit difficult to swallow because it is pretty much
> invasive and not so clean :-(, so it's okay if you don't take it.
> But it has the advantage of clipping the coordinates for hardware that
> does not support clipping (like the i810fb). For hardware that does
> support clipping, or wants to implement its own clipping code, we require
> a 'caps' (capabilities) field in fb_info or fb_fix_screeninfo. This is
> checked first and if set, the default clipping code is bypassed.
I prefer fb_info, since user space doesn't need to know.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Ping a DNS???
From: Hal MacArgle @ 2003-01-10 14:09 UTC (permalink / raw)
To: linux-newbie
Greetings: Contemplating an ISP change I thought I'd ping the present
thence the proposed DNS's to evaluate the round trip time..
The present, 204.97.4.2, returned it's RTT to be expected.. The
proposed, 65.196.16.3, returned "100% packet loss" - not expected.
Both addresses are in /etc/resolv.conf, but that shouldn't make a
difference here - IMHO. <grin> Also; since I'm connected to the INet
via the present ISP my ping testing idea might be a dumb one.
Invoking 'dig' for both addresses I find a difference in the report:
"ANSWER" is set = 1, on the working site and = 0 on the non-working.
This is obvious, to me, what's happening but I can't help but
wonder if that might mean I wont be able to use that site? /Or/ why
would a SysAdm set his/her site to not support ping? I'm confused.
TIA and thanks,
Hal - in Terra Alta, WV - Slackware GNU/Linux 8.0 (2.4.13)
haltec@iceweb.net | w8mch@iceweb.net
Proprietary Formats Unacceptable
.
-
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
* SSH doesnt properly logout
From: axel @ 2003-01-10 14:08 UTC (permalink / raw)
To: linux-admin
Hi linux admins,
I'm observing some strange behaviour concerning ssh and logging out from a
ssh connection when I put a process in background on the remote side.
For instance I do the following:
* I start a gcc compilation on the remote terminal
make bootstrap >& build.log &
Then it goes into background.
* Now I "logout" but do not return to my local terminal, now there is only a
blank screen with the cursor in the upper left side.
Can somebody help me please in understand this behaviour or rather help me
fix it?
Best regards,
Axel Siebenwirth
^ permalink raw reply
* Re: Linux 2.4.21pre3-ac2
From: Ralf Hildebrandt @ 2003-01-10 14:17 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <20030110133028.GB12071@charite.de>
* Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
> Backing out of mm/shmem.c makess thee bug disappear.
Not really. I rebooted and then the ac2 crashed DURING a fsck that was
caused by reaching the maximum mount count.
I'm outta here and back to 2.4.21pre3 :)
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
^ 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.