* Re: TTY_FLIPBUF_SIZE
From: Stuart MacDonald @ 2002-12-17 16:13 UTC (permalink / raw)
To: Sriram Narasimhan, linux-serial
In-Reply-To: <3DFF0DFF.8030505@tataelxsi.co.in>
From: "Sriram Narasimhan" <nsri@tataelxsi.co.in>
> The TTY_FLIPBUF_SIZE is restricted to 2 * 512 bytes. Can this be
> increased to support synchronous serial lines without affecting other
> serial drivers which still stick to the TTY_FLIPBUF_SIZE limit ?
No. Check the code. struct tty_struct depends on being less than one
page (4 kb) in size, and making the flip bufs any much bigger will
break that.
..Stu
^ permalink raw reply
* Re: Domain transition -- enabling user_r in eklogin
From: Stephen D. Smalley @ 2002-12-17 16:14 UTC (permalink / raw)
To: russell, fw; +Cc: SELinux
> For which I've been having problems getting an appropriate transition working.
> (the following may have some typos I don't have either box running just now
> to refer to)
>
> The remote_login domain was clearly designed with telnet in mind, there is
> no transtion to user_u:user_r.
>
> Looking this over I moved login.krb5 into the same SID as /bin/login, using
> login.te as an example, however once the user's successfully authenticated
> the domain remains system_u:system_r and 'newrole(1)' is not available.
>
> I'm going somewhat from memory so there may be some missed details, however
> I've tried re-configuring several times without much luck.
>
> Also this test is being done on a slackware setup, because I was able to
> get telnetd working in a redhat system more easily there may be some system
> layout issues causing problems, not sure yet.
The example policy includes rules to transition from inetd_t or tcpd_t to
rlogind_t upon executing a file labeled with the rlogind_exec_t type (assigned
to in.rlogind and in.telnetd in the file contexts configuration), and to
transition from rlogind_t to remote_login_t upon executing a file labeled with
the login_exec_t type (assigned to login in the file contexts configuration).
The remote_login_t domain can then transition to user_t, at which point
the user can run newrole if the user has an entry in the policy/users
file and is authorized for any other roles. If the user lacks an entry in the
policy/users file and you retain the user_u entry in policy/users, then the user
will be mapped to the generic user_u identity for the SELinux security context
and will be limited to operating in user_r.
--
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: increase base memory
From: Stas Sergeev @ 2002-12-17 16:17 UTC (permalink / raw)
To: kandan bala; +Cc: linux-msdos
Hello.
kandan bala wrote:
Sorry that I am CC'ing the private
message to ML, but it seems that you
haven't received the message I've sent
you privately, so I'll repeat it here.
> Is any other solutions for memory management.
Do everything that you do in a real dos.
Use XM under dosemu for your memory
management just as you do that without
dosemu.
My previous message (that you obviously
didn't receive) was:
---
Hello.
kandan bala wrote:
> Yes, The cobol is Microfocus and using
> XM for dosextender in real DOS.
But then you are making the problems
where they don't actually exist, arent
you?
Just consider dosemu is a virtual DOS
box. You can't use video memory for
RAM in the real dos box (unless you
use vidram, which is weird), neither
you can do that under dosemu esp. if
you are going to display graphics.
I simply dont understand the problem
then, just use XM and you are fine?
---
^ permalink raw reply
* Re: Via 8233 flooding of errors [2.4-ac]
From: Nathaniel Russell @ 2002-12-17 16:27 UTC (permalink / raw)
To: alan; +Cc: alan, reddog83, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 220 bytes --]
Alan,
I have played 4 mp3's and switched to X and so far nothing.
I don't know here is my dmesg log. I don't know how i got the first
Assertion but I'll keep working with the driver and report back to you,
ok.
Nathaniel
[-- Attachment #2: Via 8233 --]
[-- Type: TEXT/PLAIN, Size: 10720 bytes --]
Linux version 2.4.20 (root@reddog) (gcc version 3.2.1) #1 Fri Dec 6 01:28:57 EST 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000007ff0000 (usable)
BIOS-e820: 0000000007ff0000 - 0000000007ff3000 (ACPI NVS)
BIOS-e820: 0000000007ff3000 - 0000000008000000 (ACPI data)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
127MB LOWMEM available.
On node 0 totalpages: 32752
zone(0): 4096 pages.
zone(1): 28656 pages.
zone(2): 0 pages.
Kernel command line: BOOT_IMAGE=linux ro root=301
Initializing CPU#0
Detected 650.128 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1297.61 BogoMIPS
Memory: 126332k/131008k available (1730k kernel code, 4288k reserved, 623k data, 104k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes)
Page-cache hash table entries: 32768 (order: 5, 131072 bytes)
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: After generic, caps: 008031b5 808030b5 00000000 00000000
CPU: Common caps: 008031b5 808030b5 00000000 00000000
CPU: Centaur VIA Samuel stepping 03
Checking 'hlt' instruction... OK.
Checking for popad bug... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au)
mtrr: detected mtrr type: Intel
PCI: PCI BIOS revision 2.10 entry at 0xfb460, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router VIA [1106/3074] at 00:11.0
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
VFS: Diskquotas version dquot_6.4.0 initialized
Journalled Block Device driver loaded
ACPI: Core Subsystem version [20011018]
ACPI: Subsystem enabled
ACPI: System firmware supports S0 S1 S4 S5
Processor[0]: C0 C1 C2, 2 throttling states
ACPI: Power Button (FF) found
ACPI: Multiple power buttons detected, ignoring fixed-feature
ACPI: Power Button (CM) found
ACPI: Sleep Button (CM) found
ACPI: Thermal Zone found
pty: 512 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with HUB-6 MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e
smapi::smapi_init, ERROR invalid usSmapiID
mwave: tp3780i::tp3780I_InitializeBoardData: Error: SMAPI is not available on this machine
mwave: mwavedd::mwave_init: Error: Failed to initialize board data
mwave: mwavedd::mwave_init: Error: Failed to initialize
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller on PCI bus 00 dev 89
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
hda: WDC WD400BB-53DEA0, ATA DISK drive
hdc: Pioneer DVD-ROM ATAPIModel DVD-106S 012, ATAPI CD/DVD-ROM drive
hdd: PCRW804, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
blk: queue c0396ea4, I/O limit 4095Mb (mask 0xffffffff)
hda: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=4865/255/63, UDMA(100)
ide-floppy driver 0.99.newide
Partition check:
hda: hda1 hda2 hda3 hda4
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 7777K size 1024 blocksize
loop: loaded (max 8 devices)
ide-floppy driver 0.99.newide
SCSI subsystem driver Revision: 1.00
scsi0 : SCSI host adapter emulation for IDE ATAPI devices
Vendor: PIONEER Model: DVD-ROM DVD-106 Rev: 1.22
Type: CD-ROM ANSI SCSI revision: 02
Vendor: PHILIPS Model: PCRW804 Rev: 2,1
Type: CD-ROM ANSI SCSI revision: 02
Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
Attached scsi CD-ROM sr1 at scsi0, channel 0, id 1, lun 0
sr0: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.12
sr1: scsi3-mmc drive: 32x/32x writer cd/rw xa/form2 cdda tray
md: linear personality registered as nr 1
md: raid0 personality registered as nr 2
md: raid1 personality registered as nr 3
md: raid5 personality registered as nr 4
raid5: measuring checksumming speed
8regs : 512.400 MB/sec
32regs : 286.400 MB/sec
pII_mmx : 558.800 MB/sec
p5_mmx : 596.400 MB/sec
raid5: using function: p5_mmx (596.400 MB/sec)
md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27
md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
LVM version 1.0.5+(22/07/2002)
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 104k freed
Adding Swap: 1714600k swap-space (priority -1)
EXT3 FS 2.4-0.9.19, 19 August 2002 on ide0(3,1), internal journal
reiserfs: checking transaction log (device 03:02) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
reiserfs: checking transaction log (device 03:04) ...
Using r5 hash to sort names
ReiserFS version 3.6.25
usb.c: registered new driver usbdevfs
usb.c: registered new driver hub
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:11.2
PCI: Sharing IRQ 11 with 00:09.2
PCI: Sharing IRQ 11 with 00:11.3
PCI: Sharing IRQ 11 with 00:11.4
uhci.c: USB UHCI at I/O 0xdc00, IRQ 11
usb.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 11 for device 00:11.3
PCI: Sharing IRQ 11 with 00:09.2
PCI: Sharing IRQ 11 with 00:11.2
PCI: Sharing IRQ 11 with 00:11.4
uhci.c: USB UHCI at I/O 0xe000, IRQ 11
usb.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found
hub.c: 2 ports detected
PCI: Found IRQ 11 for device 00:11.4
PCI: Sharing IRQ 11 with 00:09.2
PCI: Sharing IRQ 11 with 00:11.2
PCI: Sharing IRQ 11 with 00:11.3
uhci.c: USB UHCI at I/O 0xe400, IRQ 11
usb.c: new USB bus registered, assigned bus number 3
hub.c: USB hub found
hub.c: 2 ports detected
8139too Fast Ethernet driver 0.9.26
PCI: Found IRQ 11 for device 00:0a.0
PCI: Sharing IRQ 11 with 00:09.1
PCI: Sharing IRQ 11 with 00:11.5
eth0: D-Link DFE-538TX (RealTek RTL8139) at 0xc8a5d000, 00:50:ba:c8:1c:12, IRQ 11
eth0: Identified 8139 chip type 'RTL-8139C'
PCI: Found IRQ 11 for device 00:09.2
PCI: Sharing IRQ 11 with 00:11.2
PCI: Sharing IRQ 11 with 00:11.3
PCI: Sharing IRQ 11 with 00:11.4
hcd.c: ehci-hcd @ 00:09.2, NEC Corporation USB 2.0
hcd.c: irq 11, pci mem c8a64000
usb.c: new USB bus registered, assigned bus number 4
ehci-hcd.c: USB 2.0 support enabled, EHCI rev 0.95
hub.c: USB hub found
hub.c: 5 ports detected
PCI: Found IRQ 11 for device 00:09.0
usb-ohci.c: USB OHCI at membase 0xc8a6c000, IRQ 11
usb-ohci.c: usb-00:09.0, NEC Corporation USB
usb.c: new USB bus registered, assigned bus number 5
hub.c: USB hub found
hub.c: 3 ports detected
PCI: Found IRQ 11 for device 00:09.1
PCI: Sharing IRQ 11 with 00:0a.0
PCI: Sharing IRQ 11 with 00:11.5
usb-ohci.c: USB OHCI at membase 0xc8a6e000, IRQ 11
usb-ohci.c: usb-00:09.1, NEC Corporation USB (#2)
usb.c: new USB bus registered, assigned bus number 6
hub.c: USB hub found
hub.c: 2 ports detected
es1370: version v0.37 time 03:23:54 Dec 6 2002
PCI: Found IRQ 11 for device 00:08.0
es1370: found adapter at io 0xd000 irq 11
es1370: features: joystick off, line in, mic impedance 0
keyboard: unknown scancode e0 2e
keyboard: unknown scancode e0 2e
usb-uhci.c: $Revision: 1.275 $ time 03:27:43 Dec 6 2002
usb-uhci.c: High bandwidth mode enabled
usb-uhci.c: v1.275:USB Universal Host Controller Interface driver
eth0: Setting 100mbps full-duplex based on auto-negotiated partner ability 41e1.
nvidia: loading NVIDIA Linux x86 NVdriver Kernel Module 1.0-3123 Tue Aug 27 15:56:48 PDT 2002
keyboard: unknown scancode e0 6c
keyboard: unknown scancode e0 20
keyboard: unknown scancode e0 6c
keyboard: unknown scancode e0 20
es1370: unloading
Via 686a/8233/8235 audio driver 1.9.1-ac2
PCI: Found IRQ 11 for device 00:11.5
PCI: Sharing IRQ 11 with 00:09.1
PCI: Sharing IRQ 11 with 00:0a.0
via82cxxx: Six channel audio available
PCI: Setting latency timer of device 00:11.5 to 64
ac97_codec: AC97 Audio codec, id: ICE17(ICE1232)
via82cxxx: board #1 at 0xE800, IRQ 11
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 94M
agpgart: Detected Via Apollo Pro266 chipset
agpgart: AGP aperture is 64M @ 0xe0000000
NVRM: AGPGART: VIA chipset
NVRM: AGPGART: aperture: 64M @ 0xe0000000
NVRM: AGPGART: aperture mapped from 0xe0000000 to 0xc9bf0000
NVRM: AGPGART: mode 4x
NVRM: AGPGART: allocated 16 pages
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
NVRM: AGPGART: freed 16 pages
NVRM: AGPGART: backend released
NVRM: AGPGART: VIA chipset
NVRM: AGPGART: aperture: 64M @ 0xe0000000
NVRM: AGPGART: aperture mapped from 0xe0000000 to 0xc9bf0000
NVRM: AGPGART: mode 4x
NVRM: AGPGART: allocated 16 pages
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
NVRM: AGPGART: freed 16 pages
NVRM: AGPGART: backend released
NVRM: AGPGART: VIA chipset
NVRM: AGPGART: aperture: 64M @ 0xe0000000
NVRM: AGPGART: aperture mapped from 0xe0000000 to 0xc9bf0000
NVRM: AGPGART: mode 4x
NVRM: AGPGART: allocated 16 pages
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
via_audio: ignoring drain playback error -11
NVRM: AGPGART: freed 16 pages
NVRM: AGPGART: backend released
^ permalink raw reply
* Re: [PATCHSET] PC-9800 addtional for 2.5.50-ac1 (21/21)
From: Osamu Tomita @ 2002-12-17 16:25 UTC (permalink / raw)
To: Alan Cox
Cc: YOSHIFUJI Hideaki / 吉藤英明,
Linux Kernel Mailing List
In-Reply-To: <1040139409.20199.8.camel@irongate.swansea.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 667 bytes --]
Thanks for your advice.
Alan Cox wrote:
>
> Any chance of moving the EBDA to query to be something like
>
> unsigned long get_bios_ebda(void)
>
> and hiding it in the per platform includes (returning 0 for non I guess)
How about this patch? This is replace of previous smp.patch.
diffstat:
arch/i386/kernel/mpparse.c | 39 +++++++++++++++++++++++--------------
arch/i386/kernel/smpboot.c | 14 +++++++++++++
arch/i386/mach-defaults/smp_bios.h | 14 +++++++++++++
arch/i386/mach-pc9800/smp_bios.h | 7 ++++++
include/asm-i386/smpboot.h | 9 ++++++++
5 files changed, 69 insertions(+), 14 deletions(-)
Regards,
Osamu
[-- Attachment #2: smp.patch --]
[-- Type: text/plain, Size: 5587 bytes --]
diff -Nru linux/arch/i386/kernel/mpparse.c linux98/arch/i386/kernel/mpparse.c
--- linux/arch/i386/kernel/mpparse.c 2002-12-15 15:16:42.000000000 +0900
+++ linux98/arch/i386/kernel/mpparse.c 2002-12-18 01:07:27.000000000 +0900
@@ -31,9 +31,7 @@
#include <asm/pgalloc.h>
#include <asm/io_apic.h>
#include "mach_apic.h"
-
-/* Have we found an MP table */
-int smp_found_config;
+#include "smp_bios.h"
/*
* Various Linux-internal data structures created from the
@@ -676,11 +674,14 @@
printk(KERN_DEBUG "Default MP configuration #%d\n", mpf->mpf_feature1);
construct_default_ISA_mptable(mpf->mpf_feature1);
} else if (mpf->mpf_physptr) {
+ extern int pc98;
+
/*
* Read the physical hardware table. Anything here will
* override the defaults.
*/
- if (!smp_read_mpc((void *)mpf->mpf_physptr)) {
+ if (!smp_read_mpc(pc98 ? phys_to_virt(mpf->mpf_physptr)
+ : (void *)mpf->mpf_physptr)) {
smp_found_config = 0;
printk(KERN_ERR "BIOS bug, MP table errors detected!...\n");
printk(KERN_ERR "... disabling SMP support. (tell your hw vendor)\n");
@@ -734,8 +735,25 @@
Dprintk("found SMP MP-table at %08lx\n",
virt_to_phys(mpf));
reserve_bootmem(virt_to_phys(mpf), PAGE_SIZE);
- if (mpf->mpf_physptr)
- reserve_bootmem(mpf->mpf_physptr, PAGE_SIZE);
+ /*
+ * PC-9800's MPC table places on the very last of
+ * physical memory; so that simply reserving PAGE_SIZE
+ * from mpg->mpf_physptr yields BUG() in
+ * reserve_bootmem.
+ */
+ if (mpf->mpf_physptr) {
+ /*
+ * We cannot access to MPC table to compute
+ * table size yet, as only few megabytes from
+ * the bottom is mapped now.
+ */
+ unsigned long size = PAGE_SIZE;
+ unsigned long end = max_low_pfn * PAGE_SIZE;
+ if (mpf->mpf_physptr + size > end)
+ size = end - mpf->mpf_physptr;
+ reserve_bootmem(mpf->mpf_physptr, size);
+ }
+
mpf_found = mpf;
return 1;
}
@@ -747,8 +765,6 @@
void __init find_smp_config (void)
{
- unsigned int address;
-
/*
* FIXME: Linux assumes you have 640K of base ram..
* this continues the error...
@@ -778,12 +794,7 @@
* MP1.4 SPEC states to only scan first 1K of 4K EBDA.
*/
- address = *(unsigned short *)phys_to_virt(0x40E);
- address <<= 4;
- smp_scan_config(address, 0x400);
- /* This has been safe for ages */
- if (smp_found_config)
- Dprintk(KERN_WARNING "WARNING: MP table in the EBDA can be UNSAFE, contact linux-smp@vger.kernel.org if you experience SMP problems!\n");
+ get_bios_ebda();
}
diff -Nru linux/arch/i386/mach-defaults/smp_bios.h linux98/arch/i386/mach-defaults/smp_bios.h
--- linux/arch/i386/mach-defaults/smp_bios.h 1970-01-01 09:00:00.000000000 +0900
+++ linux98/arch/i386/mach-defaults/smp_bios.h 2002-12-18 00:53:48.000000000 +0900
@@ -0,0 +1,14 @@
+static int __init smp_scan_config (unsigned long base, unsigned long length);
+
+/* Have we found an MP table */
+int smp_found_config;
+
+static inline void get_bios_ebda(void)
+{
+ unsigned int address = *(unsigned short *)phys_to_virt(0x40E);
+ address <<= 4;
+ smp_scan_config(address, 0x400);
+ /* This has been safe for ages */
+ if (smp_found_config)
+ Dprintk(KERN_WARNING "WARNING: MP table in the EBDA can be UNSAFE, contact linux-smp@vger.kernel.org if you experience SMP problems!\n");
+}
diff -Nru linux/arch/i386/mach-pc9800/smp_bios.h linux98/arch/i386/mach-pc9800/smp_bios.h
--- linux/arch/i386/mach-pc9800/smp_bios.h 1970-01-01 09:00:00.000000000 +0900
+++ linux98/arch/i386/mach-pc9800/smp_bios.h 2002-12-18 00:49:50.000000000 +0900
@@ -0,0 +1,7 @@
+/* Have we found an MP table */
+int smp_found_config;
+
+static inline void get_bios_ebda(void)
+{
+ /* PC-9800 has no EBDA */
+}
diff -Nru linux/arch/i386/kernel/smpboot.c linux98/arch/i386/kernel/smpboot.c
--- linux/arch/i386/kernel/smpboot.c 2002-11-23 06:40:42.000000000 +0900
+++ linux98/arch/i386/kernel/smpboot.c 2002-11-25 11:14:21.000000000 +0900
@@ -823,13 +823,27 @@
nmi_low = *((volatile unsigned short *) TRAMPOLINE_LOW);
}
+#ifndef CONFIG_PC9800
CMOS_WRITE(0xa, 0xf);
+#else
+ /* reset code is stored in 8255 on PC-9800. */
+ outb(0x0e, 0x37); /* SHUT0 = 0 */
+#endif
local_flush_tlb();
Dprintk("1.\n");
*((volatile unsigned short *) TRAMPOLINE_HIGH) = start_eip >> 4;
Dprintk("2.\n");
*((volatile unsigned short *) TRAMPOLINE_LOW) = start_eip & 0xf;
Dprintk("3.\n");
+#ifdef CONFIG_PC9800
+ /*
+ * On PC-9800, continuation on warm reset is done by loading
+ * %ss:%sp from 0x0000:0404 and executing 'lret', so:
+ */
+ /* 0x3f0 is on unused interrupt vector and should be safe... */
+ *((volatile unsigned long *) phys_to_virt(0x404)) = 0x000003f0;
+ Dprintk("4.\n");
+#endif
/*
* Be paranoid about clearing APIC errors.
diff -Nru linux/include/asm-i386/smpboot.h linux98/include/asm-i386/smpboot.h
--- linux/include/asm-i386/smpboot.h 2002-10-12 13:22:19.000000000 +0900
+++ linux98/include/asm-i386/smpboot.h 2002-10-12 19:33:46.000000000 +0900
@@ -13,8 +13,17 @@
#define TRAMPOLINE_LOW phys_to_virt(0x8)
#define TRAMPOLINE_HIGH phys_to_virt(0xa)
#else /* !CONFIG_CLUSTERED_APIC */
+ #ifndef CONFIG_PC9800
#define TRAMPOLINE_LOW phys_to_virt(0x467)
#define TRAMPOLINE_HIGH phys_to_virt(0x469)
+ #else /* CONFIG_PC9800 */
+ /*
+ * On PC-9800, continuation on warm reset is done by loading
+ * %ss:%sp from 0x0000:0404 and executing 'lret', so:
+ */
+ #define TRAMPOLINE_LOW phys_to_virt(0x4fa)
+ #define TRAMPOLINE_HIGH phys_to_virt(0x4fc)
+ #endif /* !CONFIG_PC9800 */
#endif /* CONFIG_CLUSTERED_APIC */
#ifdef CONFIG_CLUSTERED_APIC
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Richard B. Johnson @ 2002-12-17 16:33 UTC (permalink / raw)
To: Hugh Dickins
Cc: Linus Torvalds, Dave Jones, Ingo Molnar, Ulrich Drepper,
linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212171556110.1460-100000@localhost.localdomain>
On Tue, 17 Dec 2002, Hugh Dickins wrote:
> On Mon, 16 Dec 2002, Linus Torvalds wrote:
> >
> > Ok, I did the vsyscall page too, and tried to make it do the right thing
> > (but I didn't bother to test it on a non-SEP machine).
> >
> > I'm pushing the changes out right now, but basically it boils down to the
> > fact that with these changes, user space can instead of doing an
> >
> > int $0x80
> >
> > instruction for a system call just do a
> >
> > call 0xfffff000
>
So you are going to do a system-call off a trap instead of an interrupt.
The difference in performance should be practically nothing. There is
also going to be additional overhead in returning from the trap since
the IP and caller's segment was not saved by the initial trap. I don't
see how you can possibly claim any improvement in performance. Further,
it doesn't make any sense. We don't call physical addresses from a
virtual address anyway, so there will be additional translation that
must take some time. With the current page-table translation you
would need to put your system-call entry point at 0xfffff000 - 0xc0000000
= 0x3ffff000 and there might not even be any RAM there. This guarantees
that you are going to have to set up a special PTE, resulting in
additional overhead.
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.
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Manfred Spraul @ 2002-12-17 16:32 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: linux-kernel
>
>
> pushl %ebp
> movl $0xfffff000, %ebp
> call *%ebp
> popl %ebp
>
>
You could avoid clobbering a register with something like
pushl $0xfffff000
call *(%esp)
addl %esp,4
--
Manfred
^ permalink raw reply
* [Linux-ia64] RTC support on ia64
From: Joel GUILLET @ 2002-12-17 16:26 UTC (permalink / raw)
To: linux-ia64
Hi,
Here is a patch to use the Real Time Clock (RTC) on ia64.
It works on a tiger. It doesn't on early lion machines. (Why ?)
I don't know about others ia64 machines. Please report me - if you test
it.
To see if it works, please check the /var/log/messages. The driver reports
sometimes that "rtc losts some interrupts..." It usually means that the
rtc doesn't work, and the interruptions that arrived were coming from a
software-timer (see the driver code).
This patch is very simple.
I changed the irq affected for the rtc as it is an "ex-i386" interruption.
(an Ox20 offset)
And copied some files from the asm-i386 to asm-ia64...
The duplication of these files is a waste of disk space, but it's coherent
with the way it has been made on i386.
You may want to try this patch and test it.
There is a program test included in the Documentation/rtc.txt of the
kernel tree.
The actual priority of the interruption is low but perhaps it might be
changed (Do anyone know how to make it ?) for some usages.
For the kernel releases after 2.5.45, I've seen that the Kconfig will be
modified so that the option will not be available (unless you activate it
manually).
This can be used for example to run scheduler latencies tests (a way of
using amlat) - I've got some more stuff for this, please mail me.
Here is the patch :
********************************************
diff -urN linux-2.5.45/arch/ia64/kernel/ia64_ksyms.c linux-2.5.45-clean/arch/ia64/kernel/ia64_ksyms.c
--- linux-2.5.45/arch/ia64/kernel/ia64_ksyms.c Thu Oct 31 01:42:54 2002
+++ linux-2.5.45-clean/arch/ia64/kernel/ia64_ksyms.c Tue Dec 17 15:08:19 2002
@@ -143,3 +143,5 @@
#endif
EXPORT_SYMBOL(machvec_noop);
+extern spinlock_t rtc_lock;
+EXPORT_SYMBOL(rtc_lock);
diff -urN linux-2.5.45/arch/ia64/kernel/time.c linux-2.5.45-clean/arch/ia64/kernel/time.c
--- linux-2.5.45/arch/ia64/kernel/time.c Thu Oct 31 01:42:20 2002
+++ linux-2.5.45-clean/arch/ia64/kernel/time.c Tue Dec 17 15:08:19 2002
@@ -27,6 +27,7 @@
extern rwlock_t xtime_lock;
extern unsigned long wall_jiffies;
extern unsigned long last_time_offset;
+spinlock_t rtc_lock = SPIN_LOCK_UNLOCKED;
u64 jiffies_64;
diff -urN linux-2.5.45/include/asm-ia64/mc146818rtc.h linux-2.5.45-clean/include/asm-ia64/mc146818rtc.h
--- linux-2.5.45/include/asm-ia64/mc146818rtc.h Thu Oct 31 01:43:38 2002
+++ linux-2.5.45-clean/include/asm-ia64/mc146818rtc.h Tue Dec 17 15:10:12 2002
@@ -1,10 +1,29 @@
+/*
+ * Machine dependent access functions for RTC registers.
+ */
#ifndef _ASM_IA64_MC146818RTC_H
#define _ASM_IA64_MC146818RTC_H
+#include <asm/io.h>
+
+#ifndef RTC_PORT
+#define RTC_PORT(x) (0x70 + (x))
+#define RTC_ALWAYS_BCD 1 /* RTC operates in binary mode */
+#endif
+
/*
- * Machine dependent access functions for RTC registers.
+ * The yet supported machines all access the RTC index register via
+ * an ISA port access but the way to access the date register differs ...
*/
+#define CMOS_READ(addr) ({ \
+outb_p((addr),RTC_PORT(0)); \
+inb_p(RTC_PORT(1)); \
+})
+#define CMOS_WRITE(val, addr) ({ \
+outb_p((addr),RTC_PORT(0)); \
+outb_p((val),RTC_PORT(1)); \
+})
-/* empty include file to satisfy the include in genrtc.c */
+#define RTC_IRQ 40 /* irq on a i386 + Ox20 */
#endif /* _ASM_IA64_MC146818RTC_H */
diff -urN linux-2.5.45/include/asm-ia64/rtc.h linux-2.5.45-clean/include/asm-ia64/rtc.h
--- linux-2.5.45/include/asm-ia64/rtc.h Thu Jan 1 01:00:00 1970
+++ linux-2.5.45-clean/include/asm-ia64/rtc.h Tue Dec 17 15:09:03 2002
@@ -0,0 +1,10 @@
+#ifndef _IA64_RTC_H
+#define _IA64_RTC_H
+
+/*
+ * ia64 uses the default access methods for the RTC.
+ */
+
+#include <asm-generic/rtc.h>
+
+#endif
**************************************************************
--------------
** Joel
^ permalink raw reply
* Re: Via 8233 flooding of errors [2.4-ac]
From: Alan Cox @ 2002-12-17 16:34 UTC (permalink / raw)
To: Nathaniel Russell; +Cc: alan, alan, reddog83, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212171108530.1415-200000@reddog.example.net>
> I have played 4 mp3's and switched to X and so far nothing.
> I don't know here is my dmesg log. I don't know how i got the first
> Assertion but I'll keep working with the driver and report back to you,
> ok.
If anything pops up let me know
^ permalink raw reply
* Re: [PATCHSET] PC-9800 addtional for 2.5.50-ac1 (21/21)
From: Alan Cox @ 2002-12-17 17:17 UTC (permalink / raw)
To: Osamu Tomita
Cc: YOSHIFUJI Hideaki / 吉藤英明,
Linux Kernel Mailing List
In-Reply-To: <3DFF4FF8.FA43A1A1@cinet.co.jp>
On Tue, 2002-12-17 at 16:25, Osamu Tomita wrote:
> Thanks for your advice.
Slight misunderstanding: I just meant put the
static inline int get_ebda(void)
{
unsigned int address = *(unsigned short *)phys_to_virt(0x40E);
address <<= 4;
return address; /* 0 means none */
}
then do
addr = get_ebda();
if(addr)
spm_scan_config(...)
Which actually fixes a bug too - the real PC can have no EBDA (EBDA
value of zero) and we shouldnt scan it if so
^ permalink raw reply
* [BUGlet] security/Kconfig
From: Philipp Matthias Hahn @ 2002-12-17 15:15 UTC (permalink / raw)
To: Greg Kroah-Hartman, Kernel Mailing List
Hi!
It was and is still strange when reading this, but
from linux/security/root_plug.c:
[...]
* Prevents any programs running with egid == 0 if a specific USB device
^^^^^^^^
* is not present in the system. Yes, it can be gotten around, but is a
^^^^^^^^^^^
from linux/security/Kconfig
[...]
This is a sample LSM module that should only be used as such.
It enables control over processes being created by root users
^^^^^^^
if a specific USB device is not present in the system.
^^^
I thinks, that "not" should not be in Kconfig.
BYtE
Philipp
--
/ / (_)__ __ ____ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ pmhahn@titan.lahn.de
^ permalink raw reply
* [Linux-ia64] Re: gas generates incorrect ia64 unwind rlen values
From: Patil, Harish @ 2002-12-17 16:33 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805569@msgid-missing>
>>>>> Mon, 16 Dec 2002 14:08:43 -0800, David Mosberger
<davidm@napali.hpl.hp.com> said:
> 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
David:
I have a RHAS kernel compiled with *gcc3.2*. Using a script based on
readelf/objdmp I found out that there are 7 instances in this kernel where
'rlen' may be wrong. The invariant the script is looking for is this:
Sum(rlen for various regions) = Number of slots in the code range.
The script found following violations of the invariant:
<ia64_trace_syscall>: [0xe00000000440e1a0-0xe00000000440e240), info at
+0x54cdd8
lo = 440E1A0 hi = 440E240
sum_rlen = 28 no_slots = 30
*******ERROR ***********
sum_rlen: 28 != no_slots:30
<ia64_ret_from_clone>: [0xe00000000440e240-0xe00000000440e270), info at
+0x54ce08
lo = 440E240 hi = 440E270
sum_rlen = 7 no_slots = 9
*******ERROR ***********
sum_rlen: 7 != no_slots:9
<ia64_prepare_handle_unaligned>: [0xe00000000440e7a0-0xe00000000440e800),
info at +0x54cf70
lo = 440E7A0 hi = 440E800
sum_rlen = 17 no_slots = 18
*******ERROR ***********
sum_rlen: 17 != no_slots:18
<ia32_ret_from_clone>: [0xe0000000044506a0-0xe0000000044506d0), info at
+0x54fd00
lo = 44506A0 hi = 44506D0
sum_rlen = 7 no_slots = 9
*******ERROR ***********
sum_rlen: 7 != no_slots:9
<memset>: [0xe0000000049338a0-0xe000000004933cc0), info at +0x5803d0
lo = 49338A0 hi = 4933CC0
sum_rlen = 195 no_slots = 198
*******ERROR ***********
sum_rlen: 195 != no_slots:198
<memcpy>: [0xe0000000049365a0-0xe000000004936a40), info at +0x580618
lo = 49365A0 hi = 4936A40
sum_rlen = 219 no_slots = 222
*******ERROR ***********
sum_rlen: 219 != no_slots:222
code_range= 0xe000000004b18000-0xe000000004b182b0
lo = 4B18000 hi = 4B182B0
sum_rlen = 130 no_slots = 129
*******ERROR ***********
sum_rlen: 130 != no_slots:129
-Harish
^ permalink raw reply
* Re: make module_install
From: Wolfgang Denk @ 2002-12-17 16:39 UTC (permalink / raw)
To: Ing.Gianfranco Morandi; +Cc: LinuxPPC
In-Reply-To: <000701c2a5e5$30b5a660$0700a8c0@pc005>
Dear Gianfranco,
in message <000701c2a5e5$30b5a660$0700a8c0@pc005> you wrote:
>
> I have implemented a loadable driver and I have compiled the source code
> with the command "make modules". When I try to run the install script with
OK so far.
> the command "make modules_install" it exits with the following message:
This is wrong; it will try to install the modules not on your target
filesystem, but on your development host, and (if you're running as
root and the copy actually succeeds - which is another mistake: never
do such things as root!) your development host's "depmod" will
complain.
You should pass a "INSTALL_MOD_PATH=<target_dir>" parameter to your
make command, something like
make modules_install INSTALL_MOD_PATH=/opt/eldk/ppc_8xx
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
There are three ways to get something done: do it yourself, hire
someone, or forbid your kids to do it.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 16:50 UTC (permalink / raw)
To: dean gaudet; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.50.0212162241150.26163-100000@twinlark.arctic.org>
On Mon, 16 Dec 2002, dean gaudet wrote:
>
> don't many of the multi-CPU problems with tsc go away because you've got a
> per-cpu physical page for the vsyscall?
No.
The per-cpu page is _inside_ the kernel, and is only pointed at by the
SYSENTER_EIP_MSR, and not accessible from user space. It's not virtually
mapped to the same address at all.
The userspace vsyscall page is shared on the whole system, and has to be
so, because anything else is a disaster from a TLB standpoint (two threads
running on different CPU's have the same page tables, so it's basically
impossible to sanely do per-cpu TLB mappings with a hw-filled TLB like the
x86).
Linus
^ permalink raw reply
* Re: kmalloc and startup process
From: Dan Malek @ 2002-12-17 16:44 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <3DFF1DF4.8010005@intracom.gr>
Pantelis Antoniou wrote:
> At what point in the startup process is it OK to call
> kmalloc?
Before you start hacking up things that are "broken", you
should probably take a moment to understand why they are
currently implemented the way they are.
The CPM support functions are called _very_ early in the
kernel to support such features as KGDB on the serial ports.
Currently, the host memory allocator uses bootmem pages
because they are only option for allocating memory that early.
There are three host memory allocators that are used to
support CPM functions. One is the 'cpm_hostalloc()' space,
which is available early and used for small objects like
uart fifos. Second is the consistent DMA functions which
are used in the places like the Ethernet driver. Third is
the kernel kmalloc() function which must be futher managed
with the cache coherency functions. They all have advantages
and features that meet various driver requirements. You may
need to use several layers of initialization to make this
happen, just like any other Linux driver. Some must be
done at kernel initialization, others can be postponed until
later. When you think driver support functions are "broken"
you may want to stop and consider that maybe your driver
writing techniques are broken and investigate how these
functions are working successfully for others.
I would strongly suggest that the only thing to "fix" is to
add a trivial space manager to some statically configurable
number of bootmem pages. The old UNIX resouce map allocator
would be a perfect algorithm to manage this space.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Hugh Dickins @ 2002-12-17 16:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dave Jones, Ingo Molnar, Ulrich Drepper, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212171556110.1460-100000@localhost.localdomain>
On Tue, 17 Dec 2002, Hugh Dickins wrote:
> whereas now I can read a 0 there (and perhaps you should be
> using get_zeroed_page rather than __get_free_page?).
Sorry, yes, you are using get_zeroed_page for the one that needs it.
Hugh
^ permalink raw reply
* Re: MSN helper module
From: Michael Richardson @ 2002-12-17 16:46 UTC (permalink / raw)
To: netfilter-devel
In-Reply-To: <20021217075448.GA24766@oknodo.bof.de>
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Patrick" == Patrick Schaaf <bof@bof.de> writes:
Patrick> On Tue, Dec 17, 2002 at 12:57:35AM +0100, Carlos Fernandez Sanz wrote:
>>
>> Is there a helper module for MSN? If not, is it being developed and can I
>> join the effort?
>>
>> If nothing is being done I'll just write the module myself before not having
>> full MSN support becomes a serious issue and starts going up...
Patrick> Ahem - what would such a helper module have to do? As far as I know,
Patrick> MSN is an Internet Service Provider, and there is no network protocol
Patrick> called MSN. Did that change? Do they do the AOL, 10 years later?
I don't know, cause I've never been there, but I think that he means the
MSN instant message protocol. There is even a possibility that this is just
IETF IMPP. (Embrace and extend...)
I didn't think it needed NAT support.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPf9U/YqHRg3pndX9AQE8oAQA6QLDohf/d+Fi86FPQ2ONrk8LiSqgKmwI
aiG+cL6pmH+R5lihxYBWMEJ/T+2MpMfeopP4Hc/mquzrkOpo6J64J8EmeqlcAm9c
7Rn/K/MvLK2VXFSkqzahZ7S2t5QmfeCQPtgp3QePKqy79AszWW+bxracQ9+ES7A6
BAzsdtHuPhs=
=v3E+
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [CryptoAPI-devel] Re: [RFC] Hardware support notes for the kernel crypto API (2.5+)
From: Jean-Luc Cooke @ 2002-12-17 16:54 UTC (permalink / raw)
To: Justin Clift
Cc: James Morris, Andrew McGregor, linux-kernel, David S. Miller,
cryptoapi-devel
In-Reply-To: <3DFC064F.10708@postgresql.org>
Looks good Justin,
I'd put in a bt more "we're doing your work for you" slant, or even a "open
new markets for your company" slant...but then again, they may get
suspisious.
JLC
On Sun, Dec 15, 2002 at 03:34:23PM +1100, Justin Clift wrote:
> Hello,
>
> Is Broadcom interested in having support for their encryption acceleration products (not just the one given in the
> product number above) officially added to Linux?
>
> The Linux "CryptoAPI" project is trying to find out the best person at Broadcom to contect, as we are adding support for
> encryption hardware to the Linux kernel and are wondering you guys would like your products included.
>
> :-)
>
> Regards and best wishes,
>
> Justin Clift
>
> ***********
>
> Reckon we should probably hear something back within 3-4 days. It's worded clearly enough for pretty much anyone there
> to understand, and gives them a solid "reason to contact us" back.
>
> :-)
>
> Does it sound ok?
--
http://www.certainkey.com
Suite 4560 CTTC
1125 Colonel By Dr.
Ottawa ON, K1S 5B6
C: 613.263.2983
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 16:57 UTC (permalink / raw)
To: Andi Kleen; +Cc: mingo, linux-kernel, davej
In-Reply-To: <p73smwxrpl7.fsf@oldwotan.suse.de>
On 17 Dec 2002, Andi Kleen wrote:
>
> Linus Torvalds <torvalds@transmeta.com> writes:
> >
> > That NMI problem is pretty fundamentally unfixable due to the stupid
> > sysenter semantics, but we could just make the NMI handlers be real
> > careful about it and fix it up if it happens.
>
> You just have to make the NMI a task gate with an own TSS, then the
> microcode will set up an own stack for you.
Actually, I came up with a much simpler solution (which I didn't yet
implement, but should be just a few lines).
The simpler solution is to just make the temporary ESP stack _look_ like
it's a real process - ie make it 8kB per CPU (instead of the current 4kB)
and put a fake "thread_info" at the bottom of it with the right CPU
number etc. That way if an NMI comes in (in the _extremely_ tiny window),
it will still see a sane picture of the system. It will basically think
that we had a micro-task-switch between two instructions.
It's also entirely possible that the NMI window may not actually even
exist, since I'm not even sure that Intel checks for pending interrupt
before the first instruction of a trap handler.
> Using a task gate would be a good idea for kernel stack faults and
> double faults too, then it would be at least possible to get an oops
> for them, not the usual double fault.
We can't get stack faults without degrading performance horribly (they
require you to set up the stack segment in magic ways that gcc doesn't
even support). For double-faults, yes, but quite frankly, if you ever get
a double fault things are _so_ screwed up that it's not very funny any
more.
> I cannot implement SYSENTER for x86-64/32bit emulation, but I think
> I can change the vsyscall code to use SYSCALL, not SYSENTER.
Right. The point of my patches is that user-level really _cannot_ use
sysenter directly, because the sysenter semantics are just not useful for
user land. So as far as user land is concerned, it really _is_ just a
"call 0xfffff000", and then the kernel can do whatever is appropriate for
that CPU.
Linus
^ permalink raw reply
* Shutdown(), TCP sockets, and select() discrepancy
From: Michael Kerrisk @ 2002-12-17 17:01 UTC (permalink / raw)
To: linux-kernel
After an offline discussion with Andi Kleen, I thought I'd bring this topic
here.
I have been experimenting with shutdown() and select() on TCP sockets and
noted a clear discrepancy from (seemingly all) other Unix flavours. On most
implementations, if we do a SHUT_WR or SHUT_RDWR, then the socket should test
as writable when we call select(), since a write() etc. will fail with a
SIGPIPE signal or an EPIPE error.
On Linux this doesn't happen - is there a reason why Linux differs in this
respect from other implementations? Given that FreeBSD, Solaris 8, HP/UX 11,
Irix 6.5, and OSF 5.1/a all do mark a socket as writable in this case, things
appear to be broken, de facto, on Linux.
At the foot of this mail is a test program I wrote which
demonstrates the disrepancy. When I run this on SuSE 8.0 (kernel 2.4.18)
and SuSE 7.2 (kernel 2.2.19) I see the following:
$ ./is_shutdown_select 1
Listening socket (fd=3) set up okay
Active socket (fd=4) set up okay
Connection established (fd=5)
shutdown(4, 1)
3:
4:
5: r w
$ ./is_shutdown_select 2
Listening socket (fd=3) set up okay
Active socket (fd=4) set up okay
Connection established (fd=5)
shutdown(4, 2)
3:
4: r
5: r w
But On FreeBSD 4.7 I see the following (which is what I expected to see on
Linux):
$ ./is_shutdown_select 1
Listening socket (fd=3) set up okay
Active socket (fd=4) set up okay
Connection established (fd=5)
shutdown(4, 1)
3:
4: w
5: r w
$ ./is_shutdown_select 2
Listening socket (fd=3) set up okay
Active socket (fd=4) set up okay
Connection established (fd=5)
shutdown(4, 2)
3:
4: r w
5: r w
Solaris 8, HP/UX 11, Irix 6.5, and OSF 5.1/a (I had to modify the header
files included slightly for the latter OSes) give the same results as FreeBSD
4.7.
Cheers
Michael
============================
/* is_shutdown_select.c
Experiment to determine behaviour of select() after a shutdown()
is performed on one or both ends of a TCP socket pair.
*/
#include <sys/types.h>
#include <netinet/in.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <sys/select.h>
#include <signal.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#define errExit(msg) { perror(msg); exit(EXIT_FAILURE); }
#define PORT_NUM 50000 /* Port number for server */
int
main(int argc, char *argv[])
{
struct sockaddr_in svaddr;
int fd[3], optval, j;
fd_set rfds, wfds;
int nfds;
struct timeval tmo = { 0, 0 }; /* For polling select() */
if (argc > 1 && strcmp(argv[1], "--help") == 0) {
fprintf(stderr, "%s active-how accept-how\n", argv[0]);
exit(EXIT_FAILURE);
} /* if */
fd[0] = socket(AF_INET, SOCK_STREAM, 0); /* Listening socket */
if (fd[0] == -1) errExit("socket");
optval = 1;
if (setsockopt(fd[0], SOL_SOCKET, SO_REUSEADDR, &optval,
sizeof(optval)) == -1) errExit("setsockopt");
/* Bind to wildcard host address + well-known port, and mark as
listening socket */
memset(&svaddr, 0, sizeof(svaddr));
svaddr.sin_family = AF_INET;
svaddr.sin_addr.s_addr = htonl(INADDR_ANY); /* Wildcard address */
svaddr.sin_port = htons(PORT_NUM); if (bind(fd[0], (struct sockaddr *)
&svaddr, sizeof(svaddr)) == -1)
errExit("bind");
if (listen(fd[0], 5) == -1) errExit("listen");
printf("Listening socket (fd=%d) set up okay\n", fd[0]);
/* Active sockets */
fd[1] = socket(AF_INET, SOCK_STREAM, 0);
if (fd[1] == -1) errExit("socket");
svaddr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
if (connect(fd[1], (struct sockaddr *) &svaddr, sizeof(svaddr)) == -1)
errExit("connect");
printf("Active socket (fd=%d) set up okay\n", fd[1]);
fd[2] = accept(fd[0], NULL, NULL);
if (fd[2] == -1) errExit("accept");
printf("Connection established (fd=%d)\n", fd[2]);
if (argc > 1) { /* Do a shutdown on active socket */
if (shutdown(fd[1], atoi(argv[1])) == -1)
errExit("shutdown (active socket)");
printf("shutdown(%d, %d)\n", fd[1], atoi(argv[1]));
} /* if */
if (argc > 2) { /* Do a shutdown on accepted socket */
if (shutdown(fd[2], atoi(argv[2])) == -1)
errExit("shutdown (accepted socket)");
printf("shutdown(%d, %d)\n", fd[2], atoi(argv[2]));
} /* if */
FD_ZERO(&rfds);
FD_ZERO(&wfds);
nfds = 0;
for (j = 0; j < 3; j++) {
FD_SET(fd[j], &rfds);
FD_SET(fd[j], &wfds);
if (fd[j] >= nfds)
nfds = fd[j] + 1;
} /* for */
if (select(nfds, &rfds, &wfds, NULL, &tmo) == -1) errExit("select");
for (j = 0; j < 3; j++) {
printf("%d: ", fd[j]);
if (FD_ISSET(fd[j], &rfds))
printf("r ");
if (FD_ISSET(fd[j], &wfds))
printf("w ");
printf("\n");
} /* for */
exit(EXIT_SUCCESS);
} /* main */
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
^ permalink raw reply
* [LARTC] ROUTING Problem
From: Andre Lorenz @ 2002-12-17 16:53 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101530055025659@msgid-missing>
hello,
(sorry for my bad english)
1,5 Mbit 2 Mbit
www www
| |
+---------------------------+
| LINUX Box |----- DMZ
+---------------------------+
|
LAN
most of clients in the lan are connectet to the 1,5 Mbit connection
and some are connectet to the 2 Mbit connection
the linux box has 4 network adapters
problem
the clients which are routet to the 2 Mbit couldn't acces the dmz
u will be able to connect the dmz from all other routes.
routes are following defined.
default --> 1,5 Mbit
table fast
default -> 2mbit
clientXX lookup table fast
dmz-Network lookup table fast
where I've done a mistake
I've tried to solve it with fw-mark but there is also the same problem
thanks for help
with friendly regards
Andre
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 17:06 UTC (permalink / raw)
To: Ulrich Drepper; +Cc: Dave Jones, Ingo Molnar, linux-kernel, hpa
In-Reply-To: <3DFF023E.6030401@redhat.com>
On Tue, 17 Dec 2002, Ulrich Drepper wrote:
>
> The problem with the current solution is the instruction set of the x86.
> In your test code you simply use call 0xfffff000 and it magically work.
> But this is only the case because your program is linked statically.
Yeah, it's not very convenient. I didn't find any real alternatives,
though, and you can always just put 0xfffff000 in memory or registers and
jump to that. In fact, I suspect that if you actually want to use it in
glibc, then at least in the short term that's what you need to do anyway,
sinc eyou probably don't want to have a glibc that only works with very
recent kernels.
So I was actually assuming that the glibc code would look more like
something like this:
old_fashioned:
int $0x80
ret
unsigned long system_call_ptr = old_fashioned;
/* .. startup .. */
if (kernel_version > xxx)
system_call_ptr = 0xfffff000;
/* ... usage ... */
call *system_call_ptr;
since you cannot depend on the 0xfffff000 on older kernels anyway..
> Instead I've changed the syscall handling to effectve do
>
> pushl %ebp
> movl $0xfffff000, %ebp
> call *%ebp
> popl %ebp
The above will work, but then you'd have limited yourself to a binary that
_only_ works on new kernels. So I'd suggest the memory indirection
instead.
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-17 17:07 UTC (permalink / raw)
To: Hugh Dickins; +Cc: Dave Jones, Ingo Molnar, Ulrich Drepper, linux-kernel, hpa
In-Reply-To: <Pine.LNX.4.44.0212171556110.1460-100000@localhost.localdomain>
On Tue, 17 Dec 2002, Hugh Dickins wrote:
>
> I thought that last page was intentionally left invalid?
It was. But I thought it made sense to use, as it's the only really
"special" page.
But yes, we should decide on this quickly - it's easy to change right now,
but..
Linus
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Richard B. Johnson @ 2002-12-17 17:13 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Ulrich Drepper, linux-kernel
In-Reply-To: <3DFF51A3.5010201@colorfullife.com>
On Tue, 17 Dec 2002, Manfred Spraul wrote:
> >
> >
> > pushl %ebp
> > movl $0xfffff000, %ebp
> > call *%ebp
> > popl %ebp
> >
> >
>
> You could avoid clobbering a register with something like
>
> pushl $0xfffff000
> call *(%esp)
> addl %esp,4
>
This is a near 'call'.
pushl $0xfffff000
ret
This is a 'far' 'call' that I think you will need to reload the segment
back to user-mode segments on the return.
pushl $KERNEL_CS
pushl $0xfffff000
lret
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.
^ permalink raw reply
* Re: 2.5.52-mm1 kernel BUG at mm/page_walk.c:430!
From: Andrew Morton @ 2002-12-17 17:10 UTC (permalink / raw)
To: Helge Hafting; +Cc: lkml
In-Reply-To: <3DFEDE0B.E0F692A4@aitel.hist.no>
Helge Hafting wrote:
>
> X suddenly died, and was restarted. I found this in dmesg:
>
> kernel BUG at mm/page_walk.c:430!
> invalid operand: 0000
> CPU: 0
> EIP: 0060:[<c013beeb>] Not tainted
> EFLAGS: 00013246
> EIP is at make_pages_present+0x77/0xbc
> eax: d0efa344 ebx: 6b6b6b6b ecx: 000000a0 edx: c1604954
> esi: 6b6b6b6b edi: 00009000 ebp: d0efa344 esp: de555ef8
> ds: 0068 es: 0068 ss: 0068
> Process XFree86 (pid: 246, threadinfo=de554000 task=dfc00d80)
> Stack: 00000000 de9c35cc 00000001 d0efa344 6b6b6b6b d0efa344 de555f00
> dfc00d80
> c1604954 00009000 c013be64 00000000 c0136d78 6b6b6b6b 6b6b6b6b
> d0efa344
> de554000 000a0000 00009000 d0efa344 00000000 d0efa344 c1604954
> d0efa344
> Call Trace:
> [<c013be64>] gup_mk_present+0x0/0x10
> [<c0136d78>] move_vma+0x3d4/0x404
> [<c01370c8>] do_mremap+0x320/0x34c
> [<c0137142>] sys_mremap+0x4e/0x6f
> [<c0108973>] syscall_call+0x7/0xb
>
Seems to be just a bogus assertion. A shrinking, relocating mremap
against a VMA which has !MREMAP_MAYMOVE will call make_pages_present()
for zero pages.
You can remove mm:page_walk.c:430.
Thanks.
^ 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.