* Re: [Linux-ia64] gas generates incorrect ia64 unwind rlen values
From: David Mosberger @ 2002-12-16 22:08 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805566@msgid-missing>
>>>>> On Mon, 16 Dec 2002 12:24:03 +1100, Keith Owens <kaos@sgi.com> said:
Keith> Using binutils-2.11.90.0.8-12 (old I know, but it is the only version
Keith> supported on Redhat ia64), the rlen field in the body part of the
Keith> unwind descriptors is incorrect, it is short of the real body size.
There have been many unwind-related bug fixes to the toolchain. It's
one reason why 2.9x is hopelessly obsolete. Distros should really
switch to gcc-3.2.
--david
^ permalink raw reply
* Re: Domain transition
From: Russell Coker @ 2002-12-16 22:07 UTC (permalink / raw)
To: Stephen D. Smalley, SELinux, rmayo
In-Reply-To: <200212162125.QAA00730@moss-shockers.ncsc.mil>
On Mon, 16 Dec 2002 22:25, Stephen D. Smalley wrote:
> What's the point of limiting the user to a single role at login time if he
> can change it subsequently via newrole? Of course, you could limit login
> to transition to a single user domain if you want to force all users to
> initially login with a certain role/domain.
We currently have the default policy for sshd not allowing it to transition to
sysadm_t to limit the damage from sshd being cracked.
I guess there's potential for a very paranoid (*) person to want to do the
same with login.
(*) /bin/login has had a good history in terms of security for almost 10
years now, unlike sshd. Also /bin/login can't be accessed anywhere nearly as
easily as sshd. Of course I'm sure there are some very paranoid people
here... ;)
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: counting shell args
From: johnjulian1 @ 2002-12-16 22:04 UTC (permalink / raw)
To: Mike Dresser, Scott Taylor; +Cc: linux-admin
Just a note responding to your comment about this being for backing up windows boxes. I back up ours with a script that does it in steps testing for errors along the way.
ping winbox
mount winbox /mnt/winbox
rsync /mnt/winbox user@remotebox
this doesn't compress but does give me a lot of error checking. The remote box in my case is a Solaris box with a big raid and tape jukebox.
If you're interested I'll email you the script.
Mike Dresser <mdresser_l@windsormachine.com> wrote:
>On Mon, 16 Dec 2002, Scott Taylor wrote:
>
>> That should be very useful to know. :)
>>
>> Now you have me curious (grr...I just got over that) why do you care if
>> there are more than 25 blocks in your zipped file?
>
>If it dumps out a zero byte file, as part of the pipe gzip will go gzip
>it, and it ends up being 20 bytes. As far as smbtar is concerned,
>that's a valid output, and returns 0 error code. It was easier to put
>down 25 than figure out if that's 25 bytes or 25 kilobytes.
>
>If it's a zero return code, AND the file is over 25(k), then the script
>rotates the backups, otherwise reports via email that there was a backup
>failure on that particular machine. Once in awhile I'll get one of those
>partial backups, and that's what the previous full daily backups are for.
>
>If i get two or so in a row, I go hunting down why the machine is
>failing(is it just turned off, is the ethernet unplugged AGAIN, did the
>hard drive die last Friday and the user hasn't called me after 4 days to
>tell me their computer is broken?)
>
>Are we still on topic? :D
>
>Mike
>
>-
>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
>
__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp
Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
^ permalink raw reply
* RE: writing new BBRAM driver
From: Alex Pavloff @ 2002-12-16 22:33 UTC (permalink / raw)
To: 'Tobias Otto-Adamczak', linux-mtd; +Cc: Alex Pavloff
> That depends on your hardware and your applications needs.
> You may want to try minix. How much (KB) is your BBRAM, anyway ? Maybe you
> need no FS at all ?
Alright, I've got most of that stuff done, and the device is there. It just
reboots when I mount the bbram. :-) Got some work to do.
I want to use a file system to provide the abstraction layer so that I can
go to a hard drive if needed. Makes my life easier too, especially on
testing. My previous product had a 128KB BBRAM that was mapped to a DOS
floppy drive by the bios and formatted with FAT12, and that worked well.
Does the minix fs have a small overhead like FAT12? Could I use FAT12 if I
was willing to stick with 8.3? (Which wouldn't be a bad idea anyway, for
other reasons in my project).
Alright, one more question: What should the erasesize be for BBRAM?
Obviously I'm not worried about wear, so should it be zero or one or
something else?
Thanks!
Alex Pavloff - apavloff@eason.com
Eason Technology -- www.eason.com
^ permalink raw reply
* [RFC] linux-2.4.21-pre1_lost-tick_A0
From: john stultz @ 2002-12-16 22:09 UTC (permalink / raw)
To: lkml
In-Reply-To: <1040076206.1583.14.camel@w-jstultz2.beaverton.ibm.com>
All,
On the x440, we occasionally (or not so occasionally) get SMIs that
take longer then a few ticks. This can cause brief inconsistencies in
gettimeofday values, as well as clock drift. This patch is my first
patch at compensating for the lost ticks. This applies on top of the
cyclone-timer_B3 patch.
Comments, feedback, and flames requested.
thanks
-john
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Mon Dec 16 13:57:55 2002
+++ b/arch/i386/kernel/time.c Mon Dec 16 13:57:55 2002
@@ -279,6 +279,7 @@
static inline void mark_timeoffset_cyclone(void)
{
int count;
+ unsigned long delta = last_cyclone_timer;
spin_lock(&i8253_lock);
/* quickly read the cyclone timer */
if(cyclone_timer)
@@ -291,6 +292,13 @@
count |= inb(0x40) << 8;
spin_unlock(&i8253_lock);
+ /*lost tick compensation*/
+ delta = last_cyclone_timer - delta;
+ if(delta > loops_per_jiffy+2000){
+ delta = (delta/loops_per_jiffy)-1;
+ jiffies += delta;
+ }
+
count = ((LATCH-1) - count) * TICK_SIZE;
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
^ permalink raw reply
* Re: 2.5.51: sleep broken
From: P. Christeas @ 2002-12-16 21:59 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021216203016.GF16669-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
>
> .org 0x800
> wakup_stack:
> .org 0x900
> ENTRY(wakup_end)
> .org 0x1000
>
...correction: not OK!
that's "stack", not "start" !
.org 0x2000
wakeup_stack:
^^^^^^^^^^
.org 0x3000
ENTRY(wakeup_end)
I found "start" in the begining of the assembly.
Did you write the code in the first place?
One more thing, the resume OOPS did happen again, w. 2.5.52. I couldn't grab
it..
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* NAT helper module for MSN
From: Carlos Fernandez Sanz @ 2002-12-16 22:07 UTC (permalink / raw)
To: linux-kernel
Is there a help module to help MSN work through a NAT'ed connection?
If there isn't one, is there an ongoing project to write one I can join?
^ permalink raw reply
* [PATCH] linux-2.4.21-pre1_cyclone-timer_B3
From: john stultz @ 2002-12-16 22:03 UTC (permalink / raw)
To: marcelo; +Cc: lkml
Marcelo, All,
This patch fixes gettimeofday for multi-node Summit based systems (IBM
x440, etc). These systems suffer from TSC skew, and thus require an
alternate high res time source. This patch allows do_gettimeofday to
access a register on the cyclone chip found on these systems, which
functions as a global time source.
Please consider for acceptance.
thanks
-john
diff -Nru a/arch/i386/config.in b/arch/i386/config.in
--- a/arch/i386/config.in Mon Dec 16 13:56:13 2002
+++ b/arch/i386/config.in Mon Dec 16 13:56:13 2002
@@ -231,9 +231,11 @@
fi
fi
-bool 'Unsynced TSC support' CONFIG_X86_TSC_DISABLE
-if [ "$CONFIG_X86_TSC_DISABLE" != "y" -a "$CONFIG_X86_HAS_TSC" = "y" ]; then
- define_bool CONFIG_X86_TSC y
+if [ "$CONFIG_X86_NUMA" != "y" ]; then
+ bool 'Unsynced TSC support' CONFIG_X86_TSC_DISABLE
+ if [ "$CONFIG_X86_TSC_DISABLE" != "y" -a "$CONFIG_X86_HAS_TSC" = "y" ]; then
+ define_bool CONFIG_X86_TSC y
+ fi
fi
if [ "$CONFIG_SMP" = "y" -a "$CONFIG_X86_CMPXCHG" = "y" ]; then
diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c Mon Dec 16 13:56:13 2002
+++ b/arch/i386/kernel/time.c Mon Dec 16 13:56:13 2002
@@ -256,12 +256,177 @@
static unsigned long (*do_gettimeoffset)(void) = do_slow_gettimeoffset;
+
+/* IBM Summit (EXA) Cyclone Timer code*/
+#ifdef CONFIG_X86_SUMMIT
+
+#define CYCLONE_CBAR_ADDR 0xFEB00CD0
+#define CYCLONE_PMCC_OFFSET 0x51A0
+#define CYCLONE_MPMC_OFFSET 0x51D0
+#define CYCLONE_MPCS_OFFSET 0x51A8
+#define CYCLONE_TIMER_FREQ 100000000
+
+int use_cyclone = 0;
+int __init cyclone_setup(char *str)
+{
+ use_cyclone = 1;
+ return 1;
+}
+
+static u32* volatile cyclone_timer; /* Cyclone MPMC0 register */
+static u32 last_cyclone_timer;
+
+static inline void mark_timeoffset_cyclone(void)
+{
+ int count;
+ spin_lock(&i8253_lock);
+ /* quickly read the cyclone timer */
+ if(cyclone_timer)
+ last_cyclone_timer = cyclone_timer[0];
+
+ /* calculate delay_at_last_interrupt */
+ outb_p(0x00, 0x43); /* latch the count ASAP */
+
+ count = inb_p(0x40); /* read the latched count */
+ count |= inb(0x40) << 8;
+ spin_unlock(&i8253_lock);
+
+ count = ((LATCH-1) - count) * TICK_SIZE;
+ delay_at_last_interrupt = (count + LATCH/2) / LATCH;
+}
+
+static unsigned long do_gettimeoffset_cyclone(void)
+{
+ u32 offset;
+
+ if(!cyclone_timer)
+ return delay_at_last_interrupt;
+
+ /* Read the cyclone timer */
+ offset = cyclone_timer[0];
+
+ /* .. relative to previous jiffy */
+ offset = offset - last_cyclone_timer;
+
+ /* convert cyclone ticks to microseconds */
+ /* XXX slow, can we speed this up? */
+ offset = offset/(CYCLONE_TIMER_FREQ/1000000);
+
+ /* our adjusted time offset in microseconds */
+ return delay_at_last_interrupt + offset;
+}
+
+static void __init init_cyclone_clock(void)
+{
+ u32* reg;
+ u32 base; /* saved cyclone base address */
+ u32 pageaddr; /* page that contains cyclone_timer register */
+ u32 offset; /* offset from pageaddr to cyclone_timer register */
+ int i;
+
+ printk(KERN_INFO "Summit chipset: Starting Cyclone Counter.\n");
+
+ /* find base address */
+ pageaddr = (CYCLONE_CBAR_ADDR)&PAGE_MASK;
+ offset = (CYCLONE_CBAR_ADDR)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ reg = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!reg){
+ printk(KERN_ERR "Summit chipset: Could not find valid CBAR register.\n");
+ use_cyclone = 0;
+ return;
+ }
+ base = *reg;
+ if(!base){
+ printk(KERN_ERR "Summit chipset: Could not find valid CBAR value.\n");
+ use_cyclone = 0;
+ return;
+ }
+
+ /* setup PMCC */
+ pageaddr = (base + CYCLONE_PMCC_OFFSET)&PAGE_MASK;
+ offset = (base + CYCLONE_PMCC_OFFSET)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ reg = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!reg){
+ printk(KERN_ERR "Summit chipset: Could not find valid PMCC register.\n");
+ use_cyclone = 0;
+ return;
+ }
+ reg[0] = 0x00000001;
+
+ /* setup MPCS */
+ pageaddr = (base + CYCLONE_MPCS_OFFSET)&PAGE_MASK;
+ offset = (base + CYCLONE_MPCS_OFFSET)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ reg = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!reg){
+ printk(KERN_ERR "Summit chipset: Could not find valid MPCS register.\n");
+ use_cyclone = 0;
+ return;
+ }
+ reg[0] = 0x00000001;
+
+ /* map in cyclone_timer */
+ pageaddr = (base + CYCLONE_MPMC_OFFSET)&PAGE_MASK;
+ offset = (base + CYCLONE_MPMC_OFFSET)&(~PAGE_MASK);
+ set_fixmap_nocache(FIX_CYCLONE_TIMER, pageaddr);
+ cyclone_timer = (u32*)(fix_to_virt(FIX_CYCLONE_TIMER) + offset);
+ if(!cyclone_timer){
+ printk(KERN_ERR "Summit chipset: Could not find valid MPMC register.\n");
+ use_cyclone = 0;
+ return;
+ }
+
+ /*quick test to make sure its ticking*/
+ for(i=0; i<3; i++){
+ u32 old = cyclone_timer[0];
+ int stall = 100;
+ while(stall--) barrier();
+ if(cyclone_timer[0] == old){
+ printk(KERN_ERR "Summit chipset: Counter not counting! DISABLED\n");
+ cyclone_timer = 0;
+ use_cyclone = 0;
+ return;
+ }
+ }
+ /* Everything looks good, so set do_gettimeoffset */
+ do_gettimeoffset = do_gettimeoffset_cyclone;
+}
+void __cyclone_delay(unsigned long loops)
+{
+ unsigned long bclock, now;
+ if(!cyclone_timer)
+ return;
+ bclock = cyclone_timer[0];
+ do {
+ rep_nop();
+ now = cyclone_timer[0];
+ } while ((now-bclock) < loops);
+}
+#endif /* CONFIG_X86_SUMMIT */
+
#else
#define do_gettimeoffset() do_fast_gettimeoffset()
#endif
+/* No-cyclone stubs */
+#ifndef CONFIG_X86_SUMMIT
+int __init cyclone_setup(char *str)
+{
+ printk(KERN_ERR "cyclone: Kernel not compiled with CONFIG_X86_SUMMIT, cannot use the cyclone-timer.\n");
+ return 1;
+}
+
+const int use_cyclone = 0;
+static void mark_timeoffset_cyclone(void) {}
+static unsigned long do_gettimeoffset_cyclone(void) {return 0;}
+static void init_cyclone_clock(void) {}
+void __cyclone_delay(unsigned long loops) {}
+#endif /* CONFIG_X86_SUMMIT */
+
/*
* This version of gettimeofday has microsecond resolution
* and better than microsecond precision on fast x86 machines with TSC.
@@ -481,8 +646,9 @@
*/
write_lock(&xtime_lock);
- if (use_tsc)
- {
+ if(use_cyclone)
+ mark_timeoffset_cyclone();
+ else if (use_tsc) {
/*
* It is important that these two operations happen almost at
* the same time. We do the RDTSC stuff first, since it's
@@ -531,7 +697,7 @@
count = ((LATCH-1) - count) * TICK_SIZE;
delay_at_last_interrupt = (count + LATCH/2) / LATCH;
}
-
+
do_timer_interrupt(irq, NULL, regs);
write_unlock(&xtime_lock);
@@ -692,21 +858,30 @@
*/
dodgy_tsc();
-
+
+ if(use_cyclone)
+ init_cyclone_clock();
+
if (cpu_has_tsc) {
unsigned long tsc_quotient = calibrate_tsc();
if (tsc_quotient) {
fast_gettimeoffset_quotient = tsc_quotient;
- use_tsc = 1;
- /*
- * We could be more selective here I suspect
- * and just enable this for the next intel chips ?
+ /* XXX: This is messy
+ * However, we want to allow for the cyclone timer
+ * to work w/ or w/o the TSCs being avaliable
+ * -johnstul@us.ibm.com
*/
- x86_udelay_tsc = 1;
+ if(!use_cyclone){
+ /*
+ * We could be more selective here I suspect
+ * and just enable this for the next intel chips ?
+ */
+ use_tsc = 1;
+ x86_udelay_tsc = 1;
#ifndef do_gettimeoffset
- do_gettimeoffset = do_fast_gettimeoffset;
+ do_gettimeoffset = do_fast_gettimeoffset;
#endif
-
+ }
/* report CPU clock rate in Hz.
* The formula is (10^6 * 2^32) / (2^32 * 1 / (clocks/us)) =
* clock/second. Our precision is about 100 ppm.
@@ -720,6 +895,7 @@
}
}
}
+
#ifdef CONFIG_VISWS
printk("Starting Cobalt Timer system clock\n");
diff -Nru a/arch/i386/lib/delay.c b/arch/i386/lib/delay.c
--- a/arch/i386/lib/delay.c Mon Dec 16 13:56:13 2002
+++ b/arch/i386/lib/delay.c Mon Dec 16 13:56:13 2002
@@ -56,10 +56,13 @@
:"=&a" (d0)
:"0" (loops));
}
-
+extern __cyclone_delay(unsigned long loops);
+extern int use_cyclone;
void __delay(unsigned long loops)
{
- if (x86_udelay_tsc)
+ if (use_cyclone)
+ __cyclone_delay(loops);
+ else if (x86_udelay_tsc)
__rdtsc_delay(loops);
else
__loop_delay(loops);
diff -Nru a/include/asm-i386/fixmap.h b/include/asm-i386/fixmap.h
--- a/include/asm-i386/fixmap.h Mon Dec 16 13:56:13 2002
+++ b/include/asm-i386/fixmap.h Mon Dec 16 13:56:13 2002
@@ -64,6 +64,9 @@
#ifndef CONFIG_X86_F00F_WORKS_OK
FIX_F00F,
#endif
+#ifdef CONFIG_X86_SUMMIT
+ FIX_CYCLONE_TIMER, /*cyclone timer register*/
+#endif
#ifdef CONFIG_HIGHMEM
FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
diff -Nru a/include/asm-i386/smpboot.h b/include/asm-i386/smpboot.h
--- a/include/asm-i386/smpboot.h Mon Dec 16 13:56:13 2002
+++ b/include/asm-i386/smpboot.h Mon Dec 16 13:56:13 2002
@@ -14,6 +14,8 @@
extern unsigned char esr_disable;
extern unsigned char int_delivery_mode;
extern unsigned int int_dest_addr_mode;
+extern int cyclone_setup(char*);
+
static inline void detect_clustered_apic(char* oem, char* prod)
{
/*
@@ -25,6 +27,8 @@
int_dest_addr_mode = APIC_DEST_PHYSICAL;
int_delivery_mode = dest_Fixed;
esr_disable = 1;
+ /*Start cyclone clock*/
+ cyclone_setup(0);
}
else if (!strncmp(oem, "IBM NUMA", 8)){
clustered_apic_mode = CLUSTERED_APIC_NUMAQ;
^ permalink raw reply
* Re: 2.5.51: sleep broken
From: P. Christeas @ 2002-12-16 21:51 UTC (permalink / raw)
To: Ducrot Bruno; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20021216203016.GF16669-j6u/t2rXLliUoIHC/UFpr9i2O/JbrIOy@public.gmane.org>
> Search for wakeup_stack under acpi_wakeup.S
> I have modified that and it look something like that for me now:
>
> .org 0x800
> wakup_stack:
> .org 0x900
> ENTRY(wakup_end)
> .org 0x1000
>
> (hint given by Pavel)
Looks already OK. Shouldn't the comments reflect that behaviour?
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Machine Check Exception
From: Felipe W Damasio @ 2002-12-16 19:55 UTC (permalink / raw)
To: Felix von Leitner; +Cc: linux-kernel
In-Reply-To: <20021215202227.GA7375@codeblau.de>
Felix von Leitner wrote:
> As soon as I start oggenc on my 2.5 kernel, I get this message:
>
> CPU 0: Machine Check Exception: 0000000000000004
> Bank 0: f60600000000135 at 000000001ea46db0
> Kernel panic: CPU context corrupt
>
> This vc then hangs, but I could log in and write down the message on
> another vc. Is this a hardware error? Should I replace my CPU? My
> memory? Is my machine overheating? I have had several strange and
> unexplained segfaults and reboots under 2.4 recently.
Looks like a instruction fetch error from the level 1 cache.
Your CPU may be overheating, yes. Or it could even be a faulty processor.
Could you please check your cooler? What's the average CPU temp.?
Felipe
^ permalink raw reply
* Re: counting shell args
From: Mike Dresser @ 2002-12-16 21:49 UTC (permalink / raw)
To: Scott Taylor; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20021216132151.01c70450@mustang>
On Mon, 16 Dec 2002, Scott Taylor wrote:
> That should be very useful to know. :)
>
> Now you have me curious (grr...I just got over that) why do you care if
> there are more than 25 blocks in your zipped file?
If it dumps out a zero byte file, as part of the pipe gzip will go gzip
it, and it ends up being 20 bytes. As far as smbtar is concerned,
that's a valid output, and returns 0 error code. It was easier to put
down 25 than figure out if that's 25 bytes or 25 kilobytes.
If it's a zero return code, AND the file is over 25(k), then the script
rotates the backups, otherwise reports via email that there was a backup
failure on that particular machine. Once in awhile I'll get one of those
partial backups, and that's what the previous full daily backups are for.
If i get two or so in a row, I go hunting down why the machine is
failing(is it just turned off, is the ethernet unplugged AGAIN, did the
hard drive die last Friday and the user hasn't called me after 4 days to
tell me their computer is broken?)
Are we still on topic? :D
Mike
^ permalink raw reply
* Re: Modem Identification - Thanks
From: whitnl73 @ 2002-12-16 21:47 UTC (permalink / raw)
To: sotl155360; +Cc: linux-newbie
In-Reply-To: <200212151455.13854.sotl155360@earthlink.net>
On Sun, 15 Dec 2002, Frank Roberts - SOTL wrote:
> Hi All
>
...
>
> The only major outstanding item required for this box is minicom or its
> replacement. Hopefully the latter as I find minicom a trite stuffy but
> usable.
I like cu - it is part of the uucp package, and a nice crude terminal
emulator.
cu -l <device name>
FI /dev/ttyS1
or if you have devfs, /dev/tts/1.
>
> Thanks again for all the great help.
>
> Frank
Lawson
--
---oops---
________________________________________________________________
Sign Up for Juno Platinum Internet Access Today
Only $9.95 per month!
Visit www.juno.com
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: dosemu 1.1.3.9 user report
From: Jan Willem Stumpel @ 2002-12-16 21:41 UTC (permalink / raw)
To: linux-msdos
In-Reply-To: <3DFE2840.3040103@yahoo.com>
Stas Sergeev wrote:
> Hello.
And hello to you too!
> Jan Willem Stumpel wrote:
>> According to "top", 1.1.3.9 takes up 99 % CPU even when just
>> displaying the C:> prompt.
> Sure with such a hogthreshold value. Since 1.1.3.8 you don't
> need to set most of the options manually, so just delete the
> $_hogthreshold from your dosemu.conf and you're fine.
OK.. used the new dosemu.conf (everything commented out), set
hdimage to "dos" to make it boot on my system, then only changed
hogthreshold. Tried it (1.1.3.9) with
hogthreshold = 0 --- 99 % CPU
hogthreshold = 1 --- quiet behaviour
hogthreshold = 800 --- 99 % CPU
hogthreshold commented out altogether --- quiet behaviour
Mmm.. not very intuitive, this. Somewhere in the DOC's it
says that hogthreshold should be related to the clock speed, and
the higher hogthreshold, the quieter dosemu gets. Anyway, you know
what I think about the dosemu doc's.
With all these values of hogthreshold Wolfenstein 3D hangs (it
keeps saying "one moment" forever). This is with everything
commented out apart from hdimage and hogthreshold.
Now I uncomment sound, and set it to 0. Now it works with
hogthreshold values 0, 1, 800, and commented out altogether.
This suggests that sound (on) is the default (as you surely
intended). OK, now trying Nukem 3D (*everything* commented out now
apart from hdimage). Use Duke3d "setup" program (in dosemu) to
select the Sound Blaster card for sound, nothing for music. Run
duke3d. Result: sound, demo visible and audible, when I want to
play it hangs when I choose the difficulty level.
> So you have applied some patches, havent you?
Well of course I did. The patch set posted yesterday by Bart
Oldeman. Or isn't that what you mean? Anyway I get a boot-up
message which begins
Linux DOS emulator 1.1.3.9 $Date: 2002/12/15 $
Extra info: I use ms-dos 6.00. Maybe that's relevant.
Regards, Jan
^ permalink raw reply
* Re: counting shell args
From: Scott Taylor @ 2002-12-16 21:38 UTC (permalink / raw)
To: linux-admin
In-Reply-To: <Pine.LNX.4.33.0212161607130.25857-100000@router.windsormac hine.com>
At 01:12 PM 12/16/02, Mike Dresser wrote:
>On Mon, 16 Dec 2002, Scott Taylor wrote:
>
>The worst part about writing this backup script of mine was finding the
>return status from the previous pipe in the script.
>
>smbtar -s $pcname -x $share -p $password -u $username -t - -X /win95
>/win98 | gzip -1 > $filename.tar.gz
> if [ $PIPESTATUS -eq 0 ] && [ `ls -s $filename.tar.gz | awk
> '{print $1}'` -gt 25 ]; then
>
>$PIPESTATUS was hard to find.
That should be very useful to know. :)
Now you have me curious (grr...I just got over that) why do you care if
there are more than 25 blocks in your zipped file?
>All that because smbtar doesn't properly report errors, you have to
>check that it did in fact report a zero error return, AND verify it
>didn't just dump a 0 byte file cause the machine was unreachable.
quite painful.
>Even
>so, if the Windows PC crashes in the middle of the backup(happens enough
>to be annoying!), it'll still think the backup ran just fine, and dump a 0
>status back at you, making the backup incomplete.
Even better if the WinThing crashes on a Windows user that uses file names
like:
"This is my file that has numbers in it from last year end" on a set of
subdirectories that make the filename over 250 chars long.
Yes, I've seen that! LMAO Just try to recover that from your tar file. Ugly!
>Most odd. :D
Yes, the SMB/CIFS world is not a perfect world, but just look at what they
are trying to perfect. ;0)
Scott.
^ permalink raw reply
* Re: subscription for dosemu?
From: Stas Sergeev @ 2002-12-16 21:35 UTC (permalink / raw)
To: linux-msdos
Hello.
Peter Jay Salzman wrote:
> would the transgaming business model work with dosemu?
Probably not. The gamers are generally
willing to pay, but not for dos games,
but rather for the Windows ones:)
> but i think something like that would make the users very happy
Maybe it is just too late and I personally
doubt people would be willing to pay for
the DOS progs support.
> i'd certainly be willing to pay 1) for support
But then I guess you are a little too
late: sound support is already there
since very recently.
> 2) to help the dosemu
> project along to encourage more development.
This may work, but probably it will not:(
This was already tried, see this:
http://marc.theaimsgroup.com/?l=linux-msdos&m=91084242329044&w=2
and that didn't work...
I am really curious *why* is this failed?
Noone wanted 500$? But it seems like that:)
^ permalink raw reply
* Re: i810 sound starts and stops for 2.4.XX and i845PE chipset
From: Alan Cox @ 2002-12-16 22:21 UTC (permalink / raw)
To: edward.kuns; +Cc: Linux Kernel Mailing List
In-Reply-To: <OFEC2D1079.106A6C04-ON86256C91.00739206-86256C91.0073544D@rockwellfirstpoin t.com>
On Mon, 2002-12-16 at 21:03, edward.kuns@rockwellfirstpoint.com wrote:
> Please CC me at edward.kuns at rockwellfirstpoint.com in your responses.
>
> I have a Gigabyte GA-8PE667 Ultra motherboard (aka P4 Titan 667 Ultra) with
> the i845PE chipset. According to the motherboard manual, it uses the
> Realtek ALC650 CODEC.
At a first guess it may be IRQ routing. If you build a kernel with
apic/local apic support does that work any better ?
^ permalink raw reply
* Re: GFP_DMA Janitation
From: Matt Domsch @ 2002-12-16 21:33 UTC (permalink / raw)
To: Matthew Wilcox; +Cc: linux-scsi, Janitors
In-Reply-To: <20021214053518.K10991@parcelfarce.linux.theplanet.co.uk>
> I know there's a lot of clean-up and janitorial work going on at the
> moment, so maybe someone already fixed the bogus uses of GFP_DMA in
> drivers/scsi?
> drivers/scsi/megaraid.c:5020: _tv = (void *)__get_free_pages(GFP_DMA, order);
The megaraid 2.00.2 driver (2.00.1 is in -ac right now) gets this right
(in fact, there are no GFP_DMA allocations ever, it uses the PCI DMA API
properly).
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
^ permalink raw reply
* Re: RAM and swap partition
From: Chuck Gelm @ 2002-12-16 21:33 UTC (permalink / raw)
To: Heimo Claasen; +Cc: linux-newbie
In-Reply-To: <200212160834.gBG8Yuq14788@ev6.be.wanadoo.com>
Heimo Claasen wrote:
>
> Chuck - that swapfile: has it to be created anew just before any
> prog/app is run ? Or could I just leave it "on" ?
A swap file, once created, can be left.
However, you will need to restart swap upon each boot.
Perhaps a rc.local script command will do.
> Well, and then - can I conclude from this that a swap _partition_ is
> basically used like a file ?
Well, maybe a swap file is used more like a partition. :-|
> (Or else: would programs which need swap create their _specific_ files
> in a swap partition ?)
A swap file and a swap partition behave as virtual memory,
not as a file. So let us not try to assign file attributes
to virtual memory (swap) or file attributes to virtual
memory (ramdisk). User applications do not create swap
or ramdisk. User applications request memory or create
scratch pad files. ;-)
I think.
HTH, Chuck
>
> -heimo
> -
> 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
* Re: [BUG] module-init-tools 0.9.3, rmmod modules with '-'
From: Rusty Russell @ 2002-12-16 21:36 UTC (permalink / raw)
To: vamsi; +Cc: lkml
In-Reply-To: <20021216163634.A29099@in.ibm.com>
In message <20021216163634.A29099@in.ibm.com> you write:
> Hi Rusty,
>
> It seems we cannot unload modules if they have a '-' in their name.
> filename2modname() in rmmod.c converts a '-' in the filename
> to '_'. Why? Are dashes not allowed as part of module names?
How did you get a module which has - in its name? The build system
*should* turn them into _'s.
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: FYI
From: Eli Carter @ 2002-12-16 21:38 UTC (permalink / raw)
To: Eli Carter; +Cc: root, Linux kernel
In-Reply-To: <3DFE4636.7090701@inet.com>
Eli Carter wrote:
> Richard B. Johnson wrote:
>
>> Small Linux Christmas Poem.
>> Cheers,
>> Dick Johnson
>> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
>> Why is the government concerned about the lunatic fringe? Think about it.
>>
>
> _That_ is going on my wall. :D
>
> (Do we have permission to forward that on to friends, or not? I didn't
> see anything about copyright on it, so by default, I think not. IANAL)
Erm, but it was posted to a public mailing list...
Oh nevermind, forget I asked.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: [TRIVIAL] aic7xxx_Makefile fix
From: Kai Germaschewski @ 2002-12-16 21:30 UTC (permalink / raw)
To: Rusty Trivial Russell; +Cc: linux-scsi
In-Reply-To: <20021216210038.2142D2C273@lists.samba.org>
On Mon, 16 Dec 2002, Rusty Trivial Russell wrote:
> From: junio@siamese.dyndns.org
>
> Patch against 2.4.19. If you are in a (good) habit of making
> all the upstream sources read-only before starting your build,
> generation of the firmware code fails because it tries to write
> into read-only files. This bites only in configurations where
> CONFIG_AIC7XXX_BUILD_FIRMWARE is set to 'y'.
>
>
> --- trivial-2.4.21-pre1/drivers/scsi/aic7xxx/Makefile.orig 2002-12-16 17:22:40.000000000 +1100
> +++ trivial-2.4.21-pre1/drivers/scsi/aic7xxx/Makefile 2002-12-16 17:22:40.000000000 +1100
> @@ -39,6 +39,7 @@
> $(obj-aic7xxx): aic7xxx_reg.h
>
> aic7xxx_seq.h aic7xxx_reg.h: aic7xxx.seq aic7xxx.reg aicasm/aicasm
> + rm -f aic7xxx_seq.h aic7xxx_reg.h
> aicasm/aicasm -I. -r aic7xxx_reg.h -o aic7xxx_seq.h aic7xxx.seq
> endif
This is 2.4, so I don't feel authorative for that ;) Anyhow, this is not a
right fix (it's fixed properly in 2.5). Overwriting shipped files should
never happen, the "rm" may fix the symptoms for some cases, but SCS as
e.g. bitkeeper will generally not be happy with that kind of behavior.
--Kai
^ permalink raw reply
* Re: Domain transition
From: Stephen D. Smalley @ 2002-12-16 21:25 UTC (permalink / raw)
To: SELinux, rmayo
> 1) What is "domain transition"? I've configured my system such that it
> doesn't happen, but I'm wondering if it's the best way to go.
Read the Configuring the SELinux Policy report, available in the
distribution (selinux/doc/policy) or from the NSA SELinux web site.
You might also want to read a background paper on Type Enforcement (TE).
A domain is a security attribute associated with a process. Processes with the
same domain have the same set of permissions to the same set of objects. A
domain transition occurs when a process changes its domain, conventionally by
executing a program with a particular entrypoint type. Domain transitions
provide a controlled mechanism for changes in permissions, whether to gain
permissions, shed permissions, or switch to a completely orthogonal set of
permissions. I doubt that you really configured away domain transitions. If you
did, you might as well not use SELinux.
> 2) Is there a text file on my system with the list of user roles or is
> that information stored some other way?
In the source distribution's selinux tree, the policy/users file specifies the
set of roles authorized for each user. Obtaining the full set of defined roles
is not entirely straightforward because role declarations are now distributed
among the domain .te files. Roles for user processes are typically defined
in policy/domains/user.te or policy/domains/admin.te. You may want to look at
the Tresys policy tools as a way of more easily viewing the policy or managing
users.
In an installed form, the policy sources are typically placed into
/etc/security/selinux/src/policy.
> 3) Can I configure the operating system NOT to ask for a user role on
> login? I would much prefer to have user role determined BY the login.
The user will be limited to the roles authorized for that user in
policy/users. If you authorize the user for multiple roles, then he
can choose one of those roles at login time or subsequently via newrole.
What's the point of limiting the user to a single role at login time if he can
change it subsequently via newrole? Of course, you could limit login
to transition to a single user domain if you want to force all users to
initially login with a certain role/domain.
--
Stephen Smalley, NSA
sds@epoch.ncsc.mil
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: [Linux-ia64] gas generates incorrect ia64 unwind rlen values
From: Jim Wilson @ 2002-12-16 21:25 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805566@msgid-missing>
>RH 7.2-ia64, Dec 15 2001.
The tools for this release were based on Summer 2000 FSF sources with patches.
So they are about 2.5 years old now.
>As I mentioned in the previous mail, I could not find any mail, bug
>reports or changelog entries that mentioned ia64 unwind or rlen being
>wrong. Which makes me think that the bug exists in current binutils,
>however I cannot test that at the moment.
There have been a number of fixes in this area in the last 2.5 years.
Are you sure this is an assembler problem? If the compiler is emitting bad
unwind directives, then it could be a compiler problem. You didn't mention
anything about looking at assembly code.
There was a compiler problem with block reordering (-freorder-blocks) that
could cause the epilogue to appear in the middle of the function, and then
we emitted bad unwind info that made half the function look like epilogue code.
This was fixed in March 2001. This patch may not be in your compiler sources.
There was an assembler problem where it calculated rlen wrong when a function
spanned multiple frags. This was fixed in November 2000. This patch should
be in your assembler sources, but it is possible it got left out accidentally.
There were also other various bug fixes over the last few years that might
be related.
I will try looking at this, but since it requires kernel, compiler, and
assembler sources that I don't happen to have it may take me some time to
figure anything out. If you could give a better bug report that would help.
For instance, an assembly source example that when assembled results in
incorrect unwind info. At the moment, I am skeptical that anything is broken
in current binutils sources. No proof of this has been presented yet.
Jim
^ permalink raw reply
* Re: FYI
From: Eli Carter @ 2002-12-16 21:31 UTC (permalink / raw)
To: root; +Cc: Linux kernel
In-Reply-To: <Pine.LNX.3.95.1021216161441.19614A-101000@chaos.analogic.com>
Richard B. Johnson wrote:
> Small Linux Christmas Poem.
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
> Why is the government concerned about the lunatic fringe? Think about it.
>
_That_ is going on my wall. :D
(Do we have permission to forward that on to friends, or not? I didn't
see anything about copyright on it, so by default, I think not. IANAL)
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: problem with UN-DNAT, source is same machine
From: Joel Newkirk @ 2002-12-16 21:22 UTC (permalink / raw)
To: Frank Wallingford, netfilter
In-Reply-To: <3DF2E9D3.6010006@technologist.com>
On Sunday 08 December 2002 01:42 am, Frank Wallingford wrote:
> Here's one I can't quite wrap my head around.
> iptables -t nat -A OUTPUT -d 192.168.0.100 --dport 22 \
> -j DNAT --to 192.168.0.200
>
> Now, I'm only trying to get this one case working:
>
> (from machine 192.168.0.100:) ssh 192.168.0.100
>
> and I'd like it to connect to 192.168.0.200. I'm not sure why it
> isn't.
> From what I understand, this should be the case:
> (1) The packet starts as
> SOURCE: 192.168.0.100:port_a (some random port)
> DEST: 192.168.0.100:22
> (2) While traversing the OUTPUT chain in the NAT table, it's changed:
> SOURCE: 192.168.0.100:port_a
> DEST: 192.168.0.200:22
> (3) The packet is sent out
> (4) Host 192.168.0.200 sees it and sends the reply
> SOURCE: 192.168.0.200:22
> DEST: 192.168.0.100:port_a
> (5) The packet arrives, and is un-snat'd:
> SOURCE: 192.168.0.100:22
> DEST: 192.168.0.100:port_a
> (6) The local process sees a reply from the local machine, and accepts
> it.
>
> What's actually happening is that it's getting as far as (4), and the
> reply comes in, but the local process doesn't accept it. I'm guessing
> this is because it wasn't un-snat'd correctly, or I'm doing something
> wrong.
Are you sure you are allowing it through the INPUT chain? You can
confirm whether or not it is reaching that point with two log rules, one
as first in PREROUTING, one as first in INPUT. If it hits both, then it
is likely being dropped in INPUT, but is getting unDNATted properly. If
it gets here, check the info on the packet logged at the INPUT chain and
make sure that you have a rule to allow it through.
j
^ 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.