* Re: New changes
From: Alan Cox @ 2002-10-26 14:49 UTC (permalink / raw)
To: Harry Kalogirou; +Cc: Linux-8086
In-Reply-To: <1035641027.5491.23.camel@cool>
On Sat, 2002-10-26 at 15:03, Harry Kalogirou wrote:
>
> Hi all,
> after a long time there are some new changes in the CVS! Any happy beta
> testers out there?
Oh for a time machine
^ permalink raw reply
* Re: Wide negotiation fails with 80->68 LVD adapter?
From: Alexy Khrabrov @ 2002-10-26 14:53 UTC (permalink / raw)
To: Alexy Khrabrov; +Cc: linux-scsi
In-Reply-To: <20021022221958.GA17112@angle.setup.org>
OK, I've got the CSC (Corpsys) "sca2lvd" adapters and tried them
with my Barracuda ST150176LC's. The adapters look much more solid
than the anonymous Taiwan-made "v1.1" ones. The CSC adapters have
two ig red LEDs onboard, the inner part of the circuit board
has a cover, etc.
However, they too failed to spin my drives at 160, only at 80.
I went back and enabled Wide Negotiation, then trying
to set speed at 160 caused Adaptec 7899 to recognize
the drives as ASYN, hangup, decreasing it to 80 led to their
recognition as 80 and working fine.
I went back and tried the "v1.1" adapters in that setting,
Wide Negotiation enabled, 80 sync speed, and they worked
at the same speed (as measured by copying a 5 GB from
the 160 drive). Doh.
So I reread the drive manual, which says that
Barracuda 50 drives support ANSI SCSI, SCSI-2 and SCSI-3
(Fast-20 and Fast-40), which it says are the same
as Ultra-1 and Ultra-2 for Fast-20/40, respectively.
Mysteriously, Ultra2 is referred to as Ultra80 elsewhere,
so looks like Fast-40 _is_ 80? If SCSI veterans could
clarify this, I'd see how 40=80... Especially, given
aic7xxx says something about 80 (40 MHz) in parentheses...
In all cases, seems that it's really the drive, Barracuda 50
family is Ultra2 <=> Ultra80 (right?) but I was able to
enable Wide Negotiation and set speed to 80, and aic7xxx v6.2.8
showed them registered at 80. I'm just curious if I still could
kinda spin them up to 160 anyways... :-)
Hence, so far, both SCA<->68 LVD adapters worked as advertised.
I'm going to get a real 160 SCA drive and test it further.
In the same vein, if I do end up getting an Ultra 320 card,
and I will get an Adaptec one, what should I look for in the
drive to see if it's capable of supporting 320? I'm interested
in Ultra160 drives, usually SCA ones I can get at closeouts,
but I heard (in the Ultra320 thread) that they can spin at 320
in case they support "HBA" -- can someone please elaborate?
Many thanks, I'll put together a SCA<->68 mini-HOWTO based
on this.
--
Cheers,
Alexy Khrabrov :: www.setup.org :: Age Quod Agis
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Martin J. Bligh @ 2002-10-26 15:00 UTC (permalink / raw)
To: Alan Cox, Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <200210261357.g9QDvgl13774@devserv.devel.redhat.com>
>> Isn't this always the case on x86 ?
>> /me waits to hear gory details of some IBM monster.
>
> It isnt. The boot CPU may be any number. In addition you can strap dual
> pentium boxes to arbitrate for who is boot cpu (this is used for fault
> tolerance).
Eh? I don't understand this, and I think Dave is right for all the
IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
numbers are dynamically assigned as we boot, so the boot CPU will
always get 0, surely?
M.
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Martin J. Bligh @ 2002-10-26 15:03 UTC (permalink / raw)
To: Alan Cox, Dave Jones; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <3007712682.1035619204@[10.10.2.3]>
>>> Isn't this always the case on x86 ?
>>> /me waits to hear gory details of some IBM monster.
>>
>> It isnt. The boot CPU may be any number. In addition you can strap dual
>> pentium boxes to arbitrate for who is boot cpu (this is used for fault
>> tolerance).
>
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?
Indeed cscope indicates these are acutally hardcoded into the calls:
1 smpboot.c smp_callin 418 smp_store_cpu_info(cpuid);
2 smpboot.c smp_boot_cpus 989 smp_store_cpu_info(0);
The only thing that does smp_callin is a secondary ... so the boot
CPU has this hardcoded to 0 ... I think Dave's fine.
M.
^ permalink raw reply
* Re: The return of the return of crunch time (2.5 merge candidate list 1.6)
From: Eric W. Biederman @ 2002-10-26 15:09 UTC (permalink / raw)
To: landley; +Cc: linux-kernel
In-Reply-To: <200210251557.55202.landley@trommello.org>
Rob Landley <landley@trommello.org> writes:
> I'm also looking for other things that can similarly be removed from
> this list and pushed for integration during the next stable series.
> Criteria for this: no API changes, and no impact on people who don't
> actually try to use the thing.
>
> If people familiar with these features can suggest stuff that's
> deferrable, please let me know. I've been trying very hard not to make
> judgement calls on these patches (not my job), but I'm certainly open
> to advice.
> 11) Kexec, luanch new linux kernel from Linux (Eric W. Biederman)
>
> Announcement with links:
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html
>
> And this thread is just too brazen not to include:
> http://lists.insecure.org/lists/linux-kernel/2002/Oct/7952.html
sys_kexec introduces no new APIs to the rest of the kernel and is
fairly self contained. Making it non intrusive enough that by that
criterion it may be deferred.
Currently the device driver support is lacking. sys_kexec calls the
reboot notifier call chain, and device_shutdown to shut devices down
cleanly. Due to a bug fix/cleanup that went into of 2.5.44
device_shutdown is neutered, and does nothing.
So far with all of the review sys_kexec has gotten not one bug has
been found in it's core. However actually using it is problematic.
In the 2.5.44 kexec to 2.5.44 case quite a few devices cannot
reinitialize when the new kernel comes up.
The proof of concept of what sys_kexec can do is etherboot.
http://www.etherboot.org. Etherboot contains real hardware drivers often
adapted from the linux kernel drivers. It is quite possible to boot
DOS from etherboot, and I can quite definitely run all of setup.S.
However when I attempt this from sys_kexec in a number of significant
cases I cannot even reliably execute the BIOS calls in setup.S after
the kernel has run. Though most of them can reliably be executed.
So the remaining work with sys_kexec is to track down why it is less
reliable than etherboot. A few cases like being loaded from loadlin
and the BIOS interrupt table has hooks to code that is not longer
running is quite explainable. The rest of the failures need more
investigation.
All of the hardware driver stabilization work for sys_kexec can be
postponed until after the feature freeze. And on that note I plan
on removing the few driver fixes in my current patch and posting a
stripped down version later today.
Having sys_kexec in the kernel makes what I am doing more explainable,
and makes people think a little differently about device_shutdown, and
the reboot notifier call chain. And with sys_kexec in the kernel
people mutating the internal kernel interfaces will be encouraged to
take sys_kexec into account.
My point is that while the sys_kexec patch is not especially intrusive
in and of itself, I am fairly certain usage of it can be stabilized
easier in the kernel than outside of it.
Unless something comes up the plan for today is to incorporate the
very minor changes that have been suggested (Makefile, Config.in,
Config.help type), to split out the driver fixes I currently have
into separate patches, and post just a bare bones sys_kexec patch,
ready for inclusion in 2.5.
After the feature freeze I have on the todo list to look at porting
sys_kexec to the Itanium and Hammer. As well as building debugging
tools, and in general debugging sys_kexec so it is generally useful.
Eric
^ permalink raw reply
* Swap doesn't work
From: Vladimír Třebický @ 2002-10-26 15:14 UTC (permalink / raw)
To: linux-kernel
Hi,
I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
swap, turned it on but it doesn't work. It seems it does but when there's
not enough memory, the system crashes. Either it kills the application
desiring more memory (gcc or something) or crashes the kernel with memory
dump. Neither the 2.4.20-pre5-ac3 helped.
Thank you for your help,
Vladimir Trebicky
--
Vladimir Trebicky
guru@cimice.yo.cz
^ permalink raw reply
* Re: Swap doesn't work
From: Alan Cox @ 2002-10-26 15:44 UTC (permalink / raw)
To: Vladimír T Tý; +Cc: Linux Kernel Mailing List
In-Reply-To: <001001c27d02$6297fe50$4500a8c0@cybernet.cz>
On Sat, 2002-10-26 at 16:14, Vladimír Třebický wrote:
> Hi,
>
> I've made my linux-from-scratch with latest stable (2.4.19) kernel, made
> swap, turned it on but it doesn't work. It seems it does but when there's
> not enough memory, the system crashes. Either it kills the application
> desiring more memory (gcc or something) or crashes the kernel with memory
> dump. Neither the 2.4.20-pre5-ac3 helped.
Does this occur if you take a kernel build on a standard distribution
and boot it on your box rather than one generated by a hand built tool
chain ?
^ permalink raw reply
* Re: [PATCH] Double x86 initialise fix.
From: Alan Cox @ 2002-10-26 15:46 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Alan Cox, Dave Jones, Linux Kernel Mailing List
In-Reply-To: <3007712682.1035619204@[10.10.2.3]>
On Sat, 2002-10-26 at 16:00, Martin J. Bligh wrote:
> >> Isn't this always the case on x86 ?
> >> /me waits to hear gory details of some IBM monster.
> >
> > It isnt. The boot CPU may be any number. In addition you can strap dual
> > pentium boxes to arbitrate for who is boot cpu (this is used for fault
> > tolerance).
>
> Eh? I don't understand this, and I think Dave is right for all the
> IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU
> numbers are dynamically assigned as we boot, so the boot CPU will
> always get 0, surely?
Ok its a logical ID - so yes
^ permalink raw reply
* KT333, IO-APIC, Promise Fasttrak, Initrd [UPDATE]
From: freaky @ 2002-10-26 15:37 UTC (permalink / raw)
To: linux-kernel
Hey there,
in addition to my previous posts with this topic I would like to post the
kernel output.
Additional info:
kernel 2.4.20-pre11
gcc version 2.95.3 20010315 (release)
Kernel config: http://freaky.bananateam.nl/config
BIOS-e820:
#Stripped insignificant zeros
0-9FC00 (usable)
9FC00-A0000 (reserved)
F0000-100000 (reserved)
100000-1fff0000 (usable)
1FFF0000-1FFF8000 (ACPI DATA)
1FFF8000-20000000 (ACPI NVS)
FEC00000-FEC01000 (reserved)
FEE00000-FEE01000 (reserved)
FFF800000-100000000 (reserved)
511MB LOWMEM available
found SMP MP-table at 000FB940 # Is the uniprocessor IO-APIC causing this?
AFAIK I didn't include SMP....
hm, page 000FB000 reserved twice
hm, page 000FC000 reserved twice
hm, page 000F6000 reserved twice
hm, page 000F7000 reserved twice
On node 0 totalpages: 131056
zone(0): 4096 pages.
zone(1): 126960 pages.
zone(2): 0 pages.
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: VIA Product ID: VT5440B APIC at: 0xFEE00000
Processor #0 Pentium(tm) Pro APIC version 17
I/O APIC #2 Version 3 at 0xFEC00000.
Processors: 1
Kernel command line: vmlinuz ramdisk_size=7000 root=/dev/fd0u1440 vga=normal
rw SLACK_KERNEL=new.i BOOT_IMAGE=vmlinuz root=/dev/fd0
Initializing CPU#0
Detected 1666.740 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 3322.67 BogoMIPS
Memory: 516472k/524224k available (1041k kernel code, 7364k reserved, 311k
data, 100k init, 0k highmem)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode cache hash table entries: 32768 (order: 6, 262144 bytes)
Mount-cache hash table entries: 8192 (order: 4, 65536 bytes)
Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes)
Page-cache hash table entries: 131072 (order: 7, 524288 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: Common caps: 0383fbff c1c3fbff 00000000 00000000
CPU: AMD Athlon(tm) XP 2000+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
enabled ExtINT on CPU#0
ESR value before enabling vector: 00000080
ESR value after enabling vector: 00000000
ENABLING IO-APIC IRQs
Setting 2 in the phys_id_present_map
...changing IO-APIC physical APIC ID to 2 ... ok.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-17, 2-18, 2-20, 2-21, 2-23 not
connected.
..TIMER: vector=0x31 pin1=2 pin2=0
number of MP IRQ sources: 18.
number of IO-APIC #2 registers: 24.
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02000000
....... : physical APIC id: 02
.... register #01: 00178003
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0003
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 001 01 0 0 0 0 0 1 1 39
02 001 01 0 0 0 0 0 1 1 31
03 001 01 0 0 0 0 0 1 1 41
04 001 01 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 001 01 0 0 0 0 0 1 1 51
07 001 01 0 0 0 0 0 1 1 59
08 001 01 0 0 0 0 0 1 1 61
09 001 01 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 001 01 0 0 0 0 0 1 1 71
0d 001 01 0 0 0 0 0 1 1 79
0e 001 01 0 0 0 0 0 1 1 81
0f 001 01 0 0 0 0 0 1 1 89
10 001 01 1 1 0 1 0 1 1 91
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 001 01 1 1 0 1 0 1 1 99
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 001 01 1 1 0 1 0 1 1 A1
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ19 -> 0:19
IRQ22 -> 0:22
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 1666.7379 MHz.
..... host bus clock speed is 266.6780 MHz.
cpu: 0, clocks: 2666780, slice: 1333390
CPU0<T0:2666768,T1:1333376,D:2,S:1333390,C:2666780>
PCI: PCI BIOS revision 2.10 entry at 0xfdaf1, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Using IRQ router default [1106/3177] at 00:11.0
PCI->APIC IRQ transform: (B0,I8,P0) -> 19
PCI->APIC IRQ transform: (B0,I12,P0) -> 19
PCI->APIC IRQ transform: (B0,I17,P0) -> 16
PCI->APIC IRQ transform: (B0,I17,P2) -> 22
PCI->APIC IRQ transform: (B1,I0,P0) -> 16
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ
SERIAL_PCI enabled
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20276: IDE controller on PCI bus 00 dev 60
PDC20276: chipset revision 1
PDC20276: not 100% native mode: will probe irqs later
ide2: BM-DMA at 0xdc00-0xdc07, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0xdc08-0xdc0f, BIOS settings: hdg:pio, hdh:pio
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
VP_IDE: Unknown VIA SouthBridge, contact Vojtech Pavlik <vojtech@ucw.cz>
hda: Pioneer DVD-ROM ATAPIModel DVD-105S 013, ATAPI CD/DVD-ROM drive
hdc: LITE-ON LTR-12101B, ATAPI CD/DVD-ROM drive
hde: QUANTUM FIREBALLP AS30.0, ATA DISK drive
hdf: ST340810A, ATA DISK drive
hdg: IBM-DTLA-307020, ATA DISK drive
hdh: Maxtor 91741U4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide0: probed IRQ 14 failed, using default.
ide1 at 0x170-0x177,0x376 on irq 15
ide1: probed IRQ 15 failed, using default.
ide2 at 0xec00-0xec07,0xe802 on irq 19
ide3 at 0xe400-0xe407,0xe002 on irq 19
hde: 58633344 sectors (30020 MB) w/1902KiB Cache, CHS=58168/16/63
hdf: 78165360 sectors (40021 MB) w/2048KiB Cache, CHS=77545/16/63
hdg: 40188960 sectors (20577 MB) w/1916KiB Cache, CHS=39870/16/63
hdh: 34004880 sectors (17410 MB) w/512KiB Cache, CHS=33735/16/63
hda: ATAPI 40X DVD-ROM drive, 512kB Cache
Uniform CD-ROM driver Revision: 3.12
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache
Partition check:
hde: [PTBL] [3649/255/63] hde1 hde2 < hde5 >
hdf: [PTBL] [4865/255/63] hdf1
hdg: [PTBL] [2501/255/63] hdg1
hdh: [PTBL] [2116/255/63] hdh1 hdh2 hdh3 hdh4 < hdh5 hdh6 >
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 7000K size 1024 blocksize
loop: loaded (max 8 devices)
8139too Fast Ethernet driver 0.9.26
eth0: RealTek RTL8139 Fast Ethernet at 0xe0800f00, 00:40:f4:55:38:a7, IRQ 19
eth0: Identified 8139 chip type 'RTL-8139C'
ataraid/d0: ataraid/d0p1 ataraid/d0p2 < ataraid/d0p5 >
Drive 0 is 28629 Mb (33 / 0)
Raid0 array consists of 1 drives.
ataraid/d1: ataraid/d1p1
Drive 0 is 38166 Mb (33 / 64)
Raid0 array consists of 1 drives.
ataraid/d2: ataraid/d2p1
Drive 0 is 19623 Mb (34 / 0)
Raid0 array consists of 1 drives.
ataraid/d3: ataraid/d3p1 ataraid/d3p2 ataraid/d3p3 ataraid/d3p4 <
ataraid/d3p5 ataraid/d3p6 >
Drive 0 is 16603 Mb (34 / 64)
Raid0 array consists of 1 drives.
Promise Fasttrak(tm) Softwareraid driver for linux version 0.03beta
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
VFS: Insert root floppy disk to be loaded into RAM disk and press ENTER
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 100k freed
That was the rescuedisk (compressed 1 disk image)
with the 5 install disks (wget
ftp://ftp.slackware.org/slackware/slackware-current/rootdisks/install.[1-5])
It gives:
RAMDISK: ext2 fs found at block 0
Loading 6464 blocks [5 disks] into ram disk
VFS: Insert disk #2 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
VFS: Insert disk #3 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
VFS: Insert disk #4 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
VFS: Insert disk #5 and press ENTER # It reads this disk in 0.5 secs or so?
Loading disk #2...
Then it boots and comes up with ext2 filesystem errors on directory #41.
Sometimes it starts actually reading at disk 3 or 4, but it never actually
reads disk 2... Most of the time it doesn't actually read any disk but 1
though (the floppy read LED does go on tho'). Since disk 2 is never loaded
it always comes up with the directory #41 ext2 fs errors.
^ permalink raw reply
* Re: Pinging a IP , how to stop it bringing diald live
From: Mark Frey @ 2002-10-26 15:31 UTC (permalink / raw)
To: Sean Rima; +Cc: linux-diald
In-Reply-To: <MSGID_2=3a263=2f950=40fidonet_3db16275@fidonet.org>
Hi Sean,
Try putting this near the top of your standard.filter file, or the file
where you're defining your rules:
ignore icmp ip.daddr=ip.address.to.ignore
Mark.
Sean Rima wrote:
> Originally to: All
>
> Hi Folks,
>
> I am trying to get a BBS package working, it checks that the inet is
> live by
> pinging the net. Is there any way to tell diald not to dial if it
> receives a
> ping for a certain ip?
>
> Sean
>
>
> Gtx, Sean Rima
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-diald" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] hyper-threading information in /proc/cpuinfo
From: Eric W. Biederman @ 2002-10-26 15:45 UTC (permalink / raw)
To: Alan Cox
Cc: Nakajima, Jun, Robert Love, 'Dave Jones',
'akpm@digeo.com', 'linux-kernel@vger.kernel.org',
'chrisl@vmware.com', 'Martin J. Bligh'
In-Reply-To: <1035584076.13032.96.camel@irongate.swansea.linux.org.uk>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> On Fri, 2002-10-25 at 22:50, Nakajima, Jun wrote:
> > Sorry,
> >
> > Can you please change "siblings\t" to "threads\t\t". SuSE 8.1, for example,
> > is already doing it:
>
> Could do
> >
> > +#ifdef CONFIG_SMP
> > + if (cpu_has_ht) {
> > + seq_printf(m, "physical id\t: %d\n", phys_proc_id[n]);
> > + seq_printf(m, "threads\t\t: %d\n", smp_num_siblings);
> > + }
> > +#endif
>
>
> Im just wondering what we would then use to describe a true multiple cpu
> on a die x86. Im curious what the powerpc people think since they have
> this kind of stuff - is there a generic terminology they prefer ?
How about using "SMT width" for the P4 case?
And if we needed to break it down per package for a Power4 and the
like we could talk about CMP something, or other.
Only SMT and CMP seem to be unambiguous prefixes. Though for CMP
we probably do not need to do anything because it really is 2 cpus, and we
only need to worry about locatity in the cache hierarchy not the fact that
if we schedule a cpu intensive job on 1 ``cpu'' the others are useless.
Eric
^ permalink raw reply
* Re: [PATCH 2/2] High-res-timers part 2 (x86 platform code) take 6
From: george anzinger @ 2002-10-26 15:47 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <20021023093815.GB3416@elf.ucw.cz>
Pavel Machek wrote:
>
> Hi!
>
> > This patch, in conjunction with the "core" high-res-timers
> > patch implements high resolution timers on the i386
> > platforms. The high-res-timers use the periodic interrupt
> > to "remind" the system to look at the clock. The clock
>
> This scares me:
>
> +#define fail_message \
> +"High-res-timers:
> >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"\
> +"High-res-timers: >Failed to find the ACPI pm timer
> <\n"\
> +"High-res-timers: >-<--><-->-<-->-<-->-<-->Boot will fail in
> Calibrate Delay <\n"\
> +"High-res-timers: >Supply a valid default pm timer address
> <\n"\
> +"High-res-timers: >or get your BIOS to turn on ACPI support.
> <\n"\
> +"High-res-timers: >See CONFIGURE help for more information.
> <\n"\
> +"High-res-timers:
> >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"
>
> Does that mean our boot has now so much junk in it that we start
> adding ascii art for "important" messages?
Well, Yes! It does. However, the problem here is that this
is detected prior to enabling the console so, unless the
boot can limp along until that happens, this message will
not be seen. I have seen both conditions...
I am open to suggestions...
Thanks for looking.
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: [long]2.5.44-mm3 UP went into unexpected trashing
From: Dipankar Sarma @ 2002-10-26 15:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: Rusty Russell, maneesh, linux-kernel
In-Reply-To: <20021025235222.A25786@in.ibm.com>
Well, my earlier find_first_bit() implementation was completely bogus.
My sanity has now returned and I coded this patch below that fixes
find_find_bit() to return "size" if all bits are zero. I have tested it
extensively in userspace and it boots 2.5.44-mm5 which crashed with the earlier
version of the bitops_fix patch. I have coded the assembly routine
as optimal as I could think of and without introducing any new
branches or memory loads.
Along with this patch, I applied the larger_cpu_mask patch to -mm5
and sanity tested both UP and SMP kernels for dcache leaks in a 4CPU P3 box.
An ls -lR and subsequent unmounting of that filesystems showed that
the dentries were correctly getting returned the dcache slab and
that indicates that the larger_cpu_mask patch no longer breaks RCU.
I will do some more testing with this combination later with
rcu_stats applied on this tree (just to be sure), but so far it looks good.
Thanks
--
Dipankar Sarma <dipankar@in.ibm.com> http://lse.sourceforge.net
Linux Technology Center, IBM Software Lab, Bangalore, India.
bitops_fix.patch
-----------------
diff -urN linux-2.5.44-mm5/include/asm-i386/bitops.h linux-2.5.44-mm5-fix/include/asm-i386/bitops.h
--- linux-2.5.44-mm5/include/asm-i386/bitops.h Sat Oct 19 09:32:01 2002
+++ linux-2.5.44-mm5-fix/include/asm-i386/bitops.h Sat Oct 26 17:52:09 2002
@@ -311,12 +311,13 @@
"repe; scasl\n\t"
"jz 1f\n\t"
"leal -4(%%edi),%%edi\n\t"
- "bsfl (%%edi),%%eax\n"
- "1:\tsubl %%ebx,%%edi\n\t"
+ "bsfl (%%edi),%%edx\n"
+ "subl %%ebx,%%edi\n\t"
"shll $3,%%edi\n\t"
- "addl %%edi,%%eax"
+ "addl %%edi,%%edx\n\t"
+ "1:\tmovl %%edx,%%eax\n\t"
:"=a" (res), "=&c" (d0), "=&D" (d1)
- :"1" ((size + 31) >> 5), "2" (addr), "b" (addr));
+ :"1" ((size + 31) >> 5), "2" (addr), "b" (addr), "d" (size));
return res;
}
^ permalink raw reply
* Re: how do plugins work?
From: Hans Reiser @ 2002-10-26 15:46 UTC (permalink / raw)
To: Edward Shishkin; +Cc: gregor, reiserfs mailing list
In-Reply-To: <3DBAA71B.667E2EE8@namesys.com>
Edward Shishkin wrote:
>Hans Reiser wrote:
>
>
>>Edward Shishkin wrote:
>>
>>
>>
>>>Hans Reiser wrote:
>>>
>>>
>>>
>>>
>>>>Edward Shishkin wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Gregor Zeitlinger wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm new to this list. I'm wondering how the file plugins work. Are they
>>>>>>just a means of accessing the file contents or are they also designed to
>>>>>>save the file differently.
>>>>>>
>>>>>>For example, could you create a plugin that automatically zips each
>>>>>>text/plain file, which is totally transparent to the user?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>Yeah, we could. Although transparentness means a bit worse compression..
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>?
>>>>
>>>>You mean because of choosing to use compression atoms
>>>>
>>>>
>>>>
>>>>
>>>Yes, but it is not the only reason.
>>>
>>>
>>>
>>>
>>>
>>>>that are node sized?
>>>>
>>>>
>>>>
>>>>
>>>No, compression atoms are limited by common sense ;)
>>>Obviously, it doesn't make sense to choose it less then node size, if you
>>>want to compress a file presented by tails. On the other hand, I am not
>>>sure if you will be delighted from transparent compression supported by 256K
>>>clusters even for larger files.
>>>
>>>
>>>
>>>
>>>
>>>>Maybe it might be more precise to say that efficient random
>>>>access motivates small compression atoms which are less efficient?
>>>>(Assuming that I understood you.)
>>>>
>>>>
>>>>
>>>>
>>>There is one more obscured reason that makes transparent compression worser.
>>>I have to remind that its primary assignment is the same: to provide more
>>>efficient disk space usage. Let's take a look how transparent compression
>>>and the package using the same compression algorithm will provide it:
>>>Suppose we want to compress a 8S-byte file, and both transparent compression
>>>and package is supported by 4-blocks clusters, S - block size.
>>>
>>>File system:
>>>divides the file into 2 clusters, suppose each cluster was compressed up to
>>>(2S+1) bytes, so compressed file occupies 6 blocks.
>>>Package:
>>>makes compressed file which occupies 2*(2S+1) = 4S+2 bytes and passes it
>>>to the file system, which places it (aieee!) into 5 blocks..
>>>
>>> So we do have the actual compression ratio produced by the file system is
>>>6/8 = 25% against actual ones (5/8 = 37,5%) produced by the package. The user
>>>can observe this effect only by using "du" (when he does "df", he see that
>>>file system and package produce the same compression ratio 37,5%).
>>>This is another effect caused by the specific of packing policy (for the
>>>ext2 files, reiserfs files presented by indirect items, etc..) Obviously
>>>we can avoid this by using bigger cluster (8 blocks).
>>>
>>>Edward.
>>>
>>>
>>>
>>>
>>>
>>>
>>Or by not block aligning the clusters, which might be the right
>>solution,
>>
>>
>
>It is impossible for the files presented by indirect items, since
>it means you'll place dead space in memory per file.
>
We don't use indirect items. It is not impossible in any event, the
problem is with being efficient in reads while also ensuring that we
read whole compression atoms at a time.
>
>
>
>>and might allow for compression atoms larger than nodes.
>> Please consider that approach.
>>
>>Hans
>>
>>
>
>
>
>
^ permalink raw reply
* Re: Wide negotiation fails with 80->68 LVD adapter?
From: Doug Ledford @ 2002-10-26 16:00 UTC (permalink / raw)
To: Alexy Khrabrov; +Cc: linux-scsi
In-Reply-To: <20021026145309.GA7695@angle.setup.org>
On Sat, Oct 26, 2002 at 10:53:09AM -0400, Alexy Khrabrov wrote:
>
> So I reread the drive manual, which says that
> Barracuda 50 drives support ANSI SCSI, SCSI-2 and SCSI-3
> (Fast-20 and Fast-40), which it says are the same
> as Ultra-1 and Ultra-2 for Fast-20/40, respectively.
> Mysteriously, Ultra2 is referred to as Ultra80 elsewhere,
> so looks like Fast-40 _is_ 80? If SCSI veterans could
> clarify this, I'd see how 40=80... Especially, given
> aic7xxx says something about 80 (40 MHz) in parentheses...
You aren't paying attention to the units of measure. The 40 in
Ultra2/Fast40 is 40MHz (aka, 40 million cycles per second). The SCSI bus
itself is either narrow (8 bits) or wide (16 bits). The speed rating you
are referring to is in Mega*BYTES* per second. So, to get the total
speed, you multiply the frequency of data transfer (the MHz part) times
how many bytes are transferred in each data transfer operation (aka, there
are 8 bits per byte, so a narrow bus transfers exactly one byte of
information in each transfer cycle, while a wide bus transfers 2 bytes of
information in each cycle). So, a Wide (16 bit, 2 byte) bus operating at
40MHz transfer frequency is actually transferring data at a rate of 80
MegaBytes of data per second.
> In all cases, seems that it's really the drive, Barracuda 50
> family is Ultra2 <=> Ultra80 (right?) but I was able to
> enable Wide Negotiation and set speed to 80, and aic7xxx v6.2.8
> showed them registered at 80. I'm just curious if I still could
> kinda spin them up to 160 anyways... :-)
No. A drive will *only* do what it is capable of doing, there is no
margin there for overclocking (and in fact the negotiation protocol won't
allow it, on most 80MByte/s drives if you set the Adaptec BIOS to
160MByte/s, the card and drive will still end up at 80MByte/s anyway
because the drive firmware and the controller driver have a message
protocol that they follow to negotiate the best possible speed that both
of them support and obviously if the drive only supports 80MByte/s
transfers, then that's the best that both of them support, but in your
case the drive appears to be locking up during the transfer speed
negotiation phase which could be the fault of the linux scsi driver you
are using or the fault of the drive firmware).
> Hence, so far, both SCA<->68 LVD adapters worked as advertised.
> I'm going to get a real 160 SCA drive and test it further.
> In the same vein, if I do end up getting an Ultra 320 card,
> and I will get an Adaptec one, what should I look for in the
> drive to see if it's capable of supporting 320?
The card and the drive *both* have to support 320 speeds, and you have to
have a driver for the 320 card. Justin Gibbs has a driver for the adaptec
320 cards, but it isn't in all the stock linux kernels yet (I think it's
in 2.4.19 and later, and should be in the 2.5 kernel series pretty soon).
--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606
^ permalink raw reply
* [PATCH] IPv6: Fix for Refine IPv6 Address Validation Timer
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2002-10-26 16:10 UTC (permalink / raw)
To: linux-kernel, netdev; +Cc: usagi
Hi,
We sent a patch to refine timing of IPv6 address validation timer.
However, timer was not recalculated on receipt of RA.
This patch fixes this bug.
Patch is for 2.4.20-pre11.
Thanks.
Index: net/ipv6/addrconf.c
===================================================================
RCS file: /cvsroot/usagi/usagi-backport/linux24/net/ipv6/addrconf.c,v
retrieving revision 1.1.1.2
retrieving revision 1.1.1.2.26.1
diff -u -r1.1.1.2 -r1.1.1.2.26.1
--- net/ipv6/addrconf.c 9 Oct 2002 01:35:53 -0000 1.1.1.2
+++ net/ipv6/addrconf.c 26 Oct 2002 15:55:14 -0000 1.1.1.2.26.1
@@ -947,6 +947,7 @@
ipv6_ifa_notify((flags&IFA_F_DEPRECATED) ?
0 : RTM_NEWADDR, ifp);
in6_ifa_put(ifp);
+ addrconf_verify(0);
}
}
in6_dev_put(in6_dev);
--
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
^ permalink raw reply
* Re: [LARTC] Problem with fw filters
From: Martin Josefsson @ 2002-10-26 16:06 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103563976509242@msgid-missing>
On Sat, 2002-10-26 at 15:44, Aigars Mahinovs wrote:
> Hi all,
>
> I am trying to priorityse outgoing traffic basing on UID of the sender.
> Script follows:
>
> # First mark packets with their respective priority
>
> iptables -t mangle -F OUTPUT
>
> iptables -t mangle -A OUTPUT -m owner --uid-owner root -j MARK
> --set-mark 1
> iptables -t mangle -A OUTPUT -m owner --uid-owner aigarius -j MARK
> --set-mark 2
> iptables -t mangle -A OUTPUT -m owner --uid-owner bind -j MARK
> --set-mark 3
> iptables -t mangle -A OUTPUT -m owner --uid-owner proxy -j MARK
> --set-mark 4
> iptables -t mangle -A OUTPUT -m owner --uid-owner nobody -j MARK
> --set-mark 5
> iptables -t mangle -A OUTPUT -m owner --uid-owner www-data -j MARK
> --set-mark 6
> iptables -t mangle -A OUTPUT -m owner --uid-owner ftp -j MARK --set-mark
> 7
> iptables -t mangle -A OUTPUT -m owner --uid-owner ivarix -j MARK
> --set-mark 8
> iptables -t mangle -A OUTPUT -m owner --uid-owner blacky -j MARK
> --set-mark 9
> iptables -t mangle -A OUTPUT -j MARK --set-mark 666
This won't work the way you want it to.
MARK doesn't terminate the rule-traversal... so all packets will be
marked as 666 in the end.
--
/Martin
Never argue with an idiot. They drag you down to their level, then beat
you with experience.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* [PATCH]: linux-2.5.44uc1 (MMU-less support)
From: Greg Ungerer @ 2002-10-26 16:19 UTC (permalink / raw)
To: linux-kernel
Hi All,
An updated uClinux patch is available at:
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1.patch.gz
Changelog (alot :-)
1. v850 updates (Miles Bader)
2. mm cleanups (Christoph Hellwig)
3. cleanup of arch/m68knommu (me)
- common files moved to ~/arch/m68knomu/kernel
- arch Makefiles rewritten
- 68360 drivers moved to drivers directory
- lots of other miscelleneous changes
Smaller specific patches:
. FEC ColdFire 5272 and 68360 ethernet drivers
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-fec.patch.gz
. m68k/ColdFire/v850 serial drivers
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-serial.patch.gz
. 68328 frame buffer
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-fb.patch.gz
. binfmt_flat loader
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-binflat.patch.gz
. m68knommu architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-m68knommu.patch.gz
. v850 architecture
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-v850.patch.gz
. mm (MMU-less) only patch
http://www.uclinux.org/pub/uClinux/uClinux-2.5.x/linux-2.5.44uc1-mm.patch.gz
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Wizard EMAIL: gerg@snapgear.com
Snapgear Pty Ltd PHONE: +61 7 3279 1822
825 Stanley St, FAX: +61 7 3279 1820
Woolloongabba, QLD, 4102, Australia WEB: www.SnapGear.com
^ permalink raw reply
* Re: [PATCH 2/2] High-res-timers part 2 (x86 platform code) take 6
From: george anzinger @ 2002-10-26 16:19 UTC (permalink / raw)
To: Pavel Machek, Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <3DBAB90F.CEF29920@mvista.com>
george anzinger wrote:
>
> Pavel Machek wrote:
> >
> > Hi!
> >
> > > This patch, in conjunction with the "core" high-res-timers
> > > patch implements high resolution timers on the i386
> > > platforms. The high-res-timers use the periodic interrupt
> > > to "remind" the system to look at the clock. The clock
> >
> > This scares me:
> >
> > +#define fail_message \
> > +"High-res-timers:
> > >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"\
> > +"High-res-timers: >Failed to find the ACPI pm timer
> > <\n"\
> > +"High-res-timers: >-<--><-->-<-->-<-->-<-->Boot will fail in
> > Calibrate Delay <\n"\
> > +"High-res-timers: >Supply a valid default pm timer address
> > <\n"\
> > +"High-res-timers: >or get your BIOS to turn on ACPI support.
> > <\n"\
> > +"High-res-timers: >See CONFIGURE help for more information.
> > <\n"\
> > +"High-res-timers:
> > >-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"
> >
> > Does that mean our boot has now so much junk in it that we start
> > adding ascii art for "important" messages?
>
> Well, Yes! It does. However, the problem here is that this
> is detected prior to enabling the console so, unless the
> boot can limp along until that happens, this message will
> not be seen. I have seen both conditions...
This, of course is the problem, the message appears buried
in the noise prior to the actual boot failure (assuming it
is printed at all).
>
> I am open to suggestions...
>
> Thanks for looking.
>
--
George Anzinger george@mvista.com
High-res-timers:
http://sourceforge.net/projects/high-res-timers/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml
^ permalink raw reply
* Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
From: Joel Soete @ 2002-10-26 17:39 UTC (permalink / raw)
To: jsoe0708; +Cc: Randolph Chung, Stefan Pfetzing, parisc-linux
In-Reply-To: <3DB5776100000C32@ocpmta8.be.tiscali.com>
Hmm question about "default:" uaccess.h implementation on different
platform:
i386 declare: "extern void __get_user_bad(void);"
ia64: "extern void __get_user_unknown (void);"
mips: "extern void __get_user_unknown(void);"
...
but not define elsewhere? (is it there so that the build of the kernel
failed if that case was requested to run properly?)
Thanks in advance for attention,
Joel
PS: afaik on i386 only put_user_u64 is define why not pending get_user?
jsoe0708@tiscali.be wrote:
> too bad:
>
> man ioctl advise that it would return -1 (not ENOTSUP which would be assign
> to errno) I will try to see how?
>
> Sorry to annoy,
> Joel
>
>
>>-- Original Message --
>>From: jsoe0708@tiscali.be
>>Subject: Re: [parisc-linux] Re: mkfs.xfs (xfsprogs-2.3.5) failled
>>To: "Randolph Chung" <randolph@tausq.org>,
>> "Stefan Pfetzing" <dreamind@dreamind.de>
>>Cc: parisc-linux@lists.parisc-linux.org
>>Date: Fri, 25 Oct 2002 14:58:42 +0200
>>
>>
>>Hi Randolph,
>>
>>It sure I found a bug in the two parts kernel and xfs.
>>
>>A. The kernel hppa: put_user and get_user does just a printk for BUG messages
>>but don't return error code as ENOTSUP (or what else) (what I assume the
>>other platforms does when they do not yet support BLKGETSIZE64?)
>>
>>Here is a small patch I suggest:
>>(I do not reach to implement an operational support of BLKGETSIZE64 [for
>>32bits kernel]; I do not find a easy way to manage code failure :-( )
>>
>>--- uaccess.h.orig 2002-10-22 15:14:54.000000000 +0200
>>+++ uaccess.h 2002-10-23 13:46:48.000000000 +0200
>>@@ -35,10 +35,10 @@
>>#define get_user __get_user
>>
>>#if BITS_PER_LONG == 32
>>-#define LDD_KERNEL(ptr) BUG()
>>-#define LDD_USER(ptr) BUG()
>>-#define STD_KERNEL(x, ptr) BUG()
>>-#define STD_USER(x, ptr) BUG()
>>+#define LDD_KERNEL(ptr) BUG(); __gu_err=ENOTSUP;
>>+#define LDD_USER(ptr) BUG(); __gu_err=ENOTSUP;
>>+#define STD_KERNEL(x, ptr) BUG(); __pu_err=ENOTSUP;
>>+#define STD_USER(x, ptr) BUG(); __pu_err=ENOTSUP;
>>#else
>>#define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>>#define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>>@@ -75,7 +75,7 @@
>> case 2: __get_kernel_asm("ldh",ptr); break; \
>> case 4: __get_kernel_asm("ldw",ptr); break; \
>> case 8: LDD_KERNEL(ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __gu_err=ENOTSUP; break; \
>> } \
>> } \
>> else { \
>>@@ -84,7 +84,7 @@
>> case 2: __get_user_asm("ldh",ptr); break; \
>> case 4: __get_user_asm("ldw",ptr); break; \
>> case 8: LDD_USER(ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __gu_err=ENOTSUP; break; \
>> } \
>> } \
>> \
>>@@ -144,7 +144,7 @@
>> case 2: __put_kernel_asm("sth",x,ptr); break; \
>> case 4: __put_kernel_asm("stw",x,ptr); break; \
>> case 8: STD_KERNEL(x,ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __pu_err=ENOTSUP; break; \
>> } \
>> } \
>> else { \
>>@@ -153,7 +153,7 @@
>> case 2: __put_user_asm("sth",x,ptr); break; \
>> case 4: __put_user_asm("stw",x,ptr); break; \
>> case 8: STD_USER(x,ptr); break; \
>>- default: BUG(); break; \
>>+ default: BUG(); __pu_err=ENOTSUP; break; \
>> } \
>> } \
>> \
>>
>>If all agreed, (awaiting better :?) can somebody ci it?
>>
>>
>>Thanks in advance for attention,
>> Joel
>>
>>PS:
>>B. in xfs:
>>
>> error = ioctl(fd, BLKGETSIZE64, &size);
>>- if (error >= 0) {
>>+ if (!error) {
>> /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>>
>>AFAIK ioctl should return error=0 if success and error <>0 (>0?)
>>
>>here is the full patch I will suggest:
>>
>>--- cmd/xfsprogs/libxfs/init.c.orig 2002-10-25 12:12:29.000000000 +0200
>>+++ cmd/xfsprogs/libxfs/init.c 2002-10-25 14:22:34.000000000 +0200
>>@@ -155,11 +155,14 @@
>> progname, path, strerror(errno));
>> exit(1);
>> }
>>+#if !defined(__hppa__) || defined(__LP64__)
>> error = ioctl(fd, BLKGETSIZE64, &size);
>>- if (error >= 0) {
>>+ if (!error) {
>> /* BLKGETSIZE64 returns size in bytes not 512-byte blocks */
>> size = size >> 9;
>>- } else {
>>+ } else
>>+#endif
>>+ {
>> /* If BLKGETSIZE64 fails, try BLKGETSIZE */
>> unsigned long tmpsize;
>> error = ioctl(fd, BLKGETSIZE, &tmpsize);
>>
>>_______________________________________________
>>parisc-linux mailing list
>>parisc-linux@lists.parisc-linux.org
>>http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
^ permalink raw reply
* Re: [LARTC] can anyone help me to solve this problem?
From: Werner Almesberger @ 2002-10-26 16:37 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103555834517971@msgid-missing>
Folke Aeon wrote:
> can IMQ classify packets based on their RATE and BURST ?
> if it cannot , then it wouldn't do any help to me . :(
I haven't used IMQ myself, but I'd expect it to work with
policing, etc., like everywhere else, yes.
>>(Well, or fix MPLS to preserve skb->tc_index.)
>
> to be frank i am not quite familiar with this stuff.
> i just do everything according to the installation guide
> shipped with the mpls-patch downloaded at sf.net/mpls-linux/ :(
I suppose, on
http://lists.sourceforge.net/lists/listinfo/mpls-linux-general
they could help you, if you described the problem.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: 2.5.44: Still has KVM + Mouse issues
From: Jon Grimm @ 2002-10-26 16:44 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-kernel
In-Reply-To: <p738z0lu2dl.fsf@oldwotan.suse.de>
Thanks Andi,
The workaround sounds reasonable.
-jon
Andi Kleen wrote:
> Boot with psmouse_noext, that should fix it. It runs the intellimouse as a
> plain PS/2 mouse. You lose the additional mouse buttons and the scroll wheel,
> but they never worked through that KVM anyways.
>
> -Andi
>
^ permalink raw reply
* [parisc-linux] SQUID failled :(
From: Joel Soete @ 2002-10-26 17:50 UTC (permalink / raw)
To: parisc-linux
Hi all,
Is somebody reach to make squid running on a woody pa-box?
I install it (to replace a old pentium 100Mhz box).
Well it start some second(s) then stop without any message anywhere
(even if I start it with -X)?
The check of the config file is ok!
Thanks in advance for all adivise,
Joel
PS: the running kernel is the last 2.4.19-pa22 32bits dpkg released (for
the rest all is woody)
^ permalink raw reply
* Re: [LARTC] Problem with fw filters
From: Aigars Mahinovs @ 2002-10-26 16:44 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-103563976509242@msgid-missing>
[-- Attachment #1: Type: text/plain, Size: 710 bytes --]
Hello,
On 26 Oct 2002 18:06:17 +0200, Martin Josefsson <gandalf@wlug.westbo.se>
wrote:
> > iptables -t mangle -A OUTPUT -j MARK --set-mark 666
>
> This won't work the way you want it to.
> MARK doesn't terminate the rule-traversal... so all packets will be
> marked as 666 in the end.
Thanks, that worked.
--
Best regards,
Aigars Mahinovs mailto:aigarius@debian.org
#--------------------------------------------------#
| .''`. |
| : :' : Debian GNU/Linux |
| `. `' http://www.debian.org |
| `- |
#--------------------------------------------------#
[-- Attachment #2: Type: application/pgp-signature, Size: 831 bytes --]
^ permalink raw reply
* [PATCH] use 64 bit jiffies for exported values
From: Tim Schmielau @ 2002-10-26 16:51 UTC (permalink / raw)
To: lkml; +Cc: Dave Jones
Now that we have HZ=1000 even on 32bit platforms, we really should
use the 64 bit jiffies value for exported interfaces like uptime, process
start time etc. Otherwise innocent users might get quite surprised
when ps output goes berzerk after 49.5 days.
Note that the appended patch does not change any of the exported
interfaces, it just avoids internal overflows.
This patch has been in -dj (modulo the HZ=1000 change) since 2.5.20-dj3.
I just forward ported it from 2.5.39-dj1 to 2.5.44, and renamed
jiffies_64_to_clock_t() to jiffies_64_to_user_HZ().
A version that additionally bumps up kstat.per_cpu_... counters to 64 bit
can be found at
http://www.physik3.uni-rostock.de/tim/kernel/2.5/jiffies64-27.patch.gz
I believe this counts as a bugfix (it fixes a regression from 2.4), but
still I wanted to put it out before the feature freeze deadline.
Tim
--- linux-2.5.44/kernel/timer.c Sat Oct 19 06:01:19 2002
+++ linux-2.5.44-j64/kernel/timer.c Sat Oct 26 13:21:02 2002
@@ -24,8 +24,10 @@
#include <linux/percpu.h>
#include <linux/init.h>
#include <linux/mm.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
+#include <asm/div64.h>
/*
* per-CPU timer vector definitions:
@@ -1001,13 +1003,16 @@
asmlinkage long sys_sysinfo(struct sysinfo *info)
{
struct sysinfo val;
+ u64 uptime;
unsigned long mem_total, sav_total;
unsigned int mem_unit, bitcount;
memset((char *)&val, 0, sizeof(struct sysinfo));
read_lock_irq(&xtime_lock);
- val.uptime = jiffies / HZ;
+ uptime = jiffies_64;
+ do_div(uptime, HZ);
+ val.uptime = (unsigned long) uptime;
val.loads[0] = avenrun[0] << (SI_LOAD_SHIFT - FSHIFT);
val.loads[1] = avenrun[1] << (SI_LOAD_SHIFT - FSHIFT);
--- linux-2.5.44/include/linux/jiffies.h Sat Oct 19 06:01:08 2002
+++ linux-2.5.44-j64/include/linux/jiffies.h Sat Oct 26 13:00:11 2002
@@ -2,14 +2,34 @@
#define _LINUX_JIFFIES_H
#include <linux/types.h>
+#include <linux/spinlock.h>
+#include <asm/system.h>
#include <asm/param.h> /* for HZ */
/*
* The 64-bit value is not volatile - you MUST NOT read it
- * without holding read_lock_irq(&xtime_lock)
+ * without holding read_lock_irq(&xtime_lock).
+ * get_jiffies_64() will do this for you as appropriate.
*/
extern u64 jiffies_64;
extern unsigned long volatile jiffies;
+
+static inline u64 get_jiffies_64(void)
+{
+#if BITS_PER_LONG < 64
+ extern rwlock_t xtime_lock;
+ unsigned long flags;
+ u64 tmp;
+
+ read_lock_irqsave(&xtime_lock, flags);
+ tmp = jiffies_64;
+ read_unlock_irqrestore(&xtime_lock, flags);
+ return tmp;
+#else
+ return (u64)jiffies;
+#endif
+}
+
/*
* These inlines deal with timer wrapping correctly. You are
--- linux-2.5.44/fs/proc/array.c Sat Oct 19 06:01:59 2002
+++ linux-2.5.44-j64/fs/proc/array.c Sat Oct 26 13:00:11 2002
@@ -344,7 +344,7 @@
ppid = task->pid ? task->real_parent->pid : 0;
read_unlock(&tasklist_lock);
res = sprintf(buffer,"%d (%s) %c %d %d %d %d %d %lu %lu \
-%lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %lu %lu %ld %lu %lu %lu %lu %lu \
+%lu %lu %lu %lu %lu %ld %ld %ld %ld %ld %ld %llu %lu %ld %lu %lu %lu %lu %lu \
%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu %lu\n",
task->pid,
task->comm,
@@ -367,7 +367,7 @@
nice,
0UL /* removed */,
jiffies_to_clock_t(task->it_real_value),
- jiffies_to_clock_t(task->start_time),
+ (unsigned long long) jiffies_64_to_user_HZ(task->start_time),
vsize,
mm ? mm->rss : 0, /* you might want to shift this left 3 */
task->rlim[RLIMIT_RSS].rlim_cur,
--- linux-2.5.44/fs/proc/proc_misc.c Sat Oct 19 06:01:14 2002
+++ linux-2.5.44-j64/fs/proc/proc_misc.c Sat Oct 26 13:16:34 2002
@@ -39,12 +39,14 @@
#include <linux/seq_file.h>
#include <linux/times.h>
#include <linux/profile.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
#include <asm/pgtable.h>
#include <asm/io.h>
#include <asm/pgalloc.h>
#include <asm/tlb.h>
+#include <asm/div64.h>
#define LOAD_INT(x) ((x) >> FSHIFT)
#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
@@ -97,34 +99,36 @@
static int uptime_read_proc(char *page, char **start, off_t off,
int count, int *eof, void *data)
{
- unsigned long uptime;
- unsigned long idle;
+ u64 uptime;
+ unsigned long uptime_remainder;
int len;
- uptime = jiffies;
- idle = init_task.utime + init_task.stime;
+ uptime = get_jiffies_64();
+ uptime_remainder = (unsigned long) do_div(uptime, HZ);
- /* The formula for the fraction parts really is ((t * 100) / HZ) % 100, but
- that would overflow about every five days at HZ == 100.
- Therefore the identity a = (a / b) * b + a % b is used so that it is
- calculated as (((t / HZ) * 100) + ((t % HZ) * 100) / HZ) % 100.
- The part in front of the '+' always evaluates as 0 (mod 100). All divisions
- in the above formulas are truncating. For HZ being a power of 10, the
- calculations simplify to the version in the #else part (if the printf
- format is adapted to the same number of digits as zeroes in HZ.
- */
#if HZ!=100
- len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
- uptime / HZ,
- (((uptime % HZ) * 100) / HZ) % 100,
- idle / HZ,
- (((idle % HZ) * 100) / HZ) % 100);
+ {
+ u64 idle = init_task.utime + init_task.stime;
+ unsigned long idle_remainder;
+
+ idle_remainder = (unsigned long) do_div(idle, HZ);
+ len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
+ (unsigned long) uptime,
+ (uptime_remainder * 100) / HZ,
+ (unsigned long) idle,
+ (idle_remainder * 100) / HZ);
+ }
#else
- len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
- uptime / HZ,
- uptime % HZ,
- idle / HZ,
- idle % HZ);
+ {
+ unsigned long idle = init_task.times.tms_utime
+ + init_task.times.tms_stime;
+
+ len = sprintf(page,"%lu.%02lu %lu.%02lu\n",
+ (unsigned long) uptime,
+ uptime_remainder,
+ idle / HZ,
+ idle % HZ);
+ }
#endif
return proc_calc_metrics(page, start, off, count, eof, len);
}
@@ -320,6 +324,8 @@
};
#endif
+extern rwlock_t xtime_lock;
+
extern struct seq_operations slabinfo_op;
extern ssize_t slabinfo_write(struct file *, const char *, size_t, loff_t *);
static int slabinfo_open(struct inode *inode, struct file *file)
@@ -339,8 +345,9 @@
{
int i, len;
extern unsigned long total_forks;
- unsigned long jif = jiffies;
- unsigned int sum = 0, user = 0, nice = 0, system = 0, idle = 0, iowait = 0;
+ u64 jif = get_jiffies_64();
+ unsigned int sum = 0;
+ unsigned long user = 0, nice = 0, system = 0, idle = 0, iowait = 0;
int major, disk;
for (i = 0 ; i < NR_CPUS; i++) {
@@ -358,7 +365,7 @@
#endif
}
- len = sprintf(page, "cpu %u %u %u %u %u\n",
+ len = sprintf(page, "cpu %lu %lu %lu %lu %lu\n",
jiffies_to_clock_t(user),
jiffies_to_clock_t(nice),
jiffies_to_clock_t(system),
@@ -366,7 +373,7 @@
jiffies_to_clock_t(iowait));
for (i = 0 ; i < NR_CPUS; i++){
if (!cpu_online(i)) continue;
- len += sprintf(page + len, "cpu%d %u %u %u %u %u\n",
+ len += sprintf(page + len, "cpu%d %lu %lu %lu %lu %lu\n",
i,
jiffies_to_clock_t(kstat.per_cpu_user[i]),
jiffies_to_clock_t(kstat.per_cpu_nice[i]),
@@ -401,12 +408,13 @@
}
}
+ do_div(jif, HZ);
len += sprintf(page + len,
"\nctxt %lu\n"
"btime %lu\n"
"processes %lu\n",
nr_context_switches(),
- xtime.tv_sec - jif / HZ,
+ xtime.tv_sec - (unsigned long) jif,
total_forks);
return proc_calc_metrics(page, start, off, count, eof, len);
--- linux-2.5.44/include/linux/kernel_stat.h Sat Oct 19 06:01:50 2002
+++ linux-2.5.44-j64/include/linux/kernel_stat.h Sat Oct 26 13:19:09 2002
@@ -16,11 +16,11 @@
#define DK_MAX_DISK 16
struct kernel_stat {
- unsigned int per_cpu_user[NR_CPUS],
- per_cpu_nice[NR_CPUS],
- per_cpu_system[NR_CPUS],
- per_cpu_idle[NR_CPUS],
- per_cpu_iowait[NR_CPUS];
+ unsigned long per_cpu_user[NR_CPUS],
+ per_cpu_nice[NR_CPUS],
+ per_cpu_system[NR_CPUS],
+ per_cpu_idle[NR_CPUS],
+ per_cpu_iowait[NR_CPUS];
unsigned int dk_drive[DK_MAX_MAJOR][DK_MAX_DISK];
unsigned int dk_drive_rio[DK_MAX_MAJOR][DK_MAX_DISK];
unsigned int dk_drive_wio[DK_MAX_MAJOR][DK_MAX_DISK];
--- linux-2.5.44/include/linux/sched.h Sat Oct 19 06:01:11 2002
+++ linux-2.5.44-j64/include/linux/sched.h Sat Oct 26 13:00:11 2002
@@ -334,7 +334,7 @@
unsigned long it_real_incr, it_prof_incr, it_virt_incr;
struct timer_list real_timer;
unsigned long utime, stime, cutime, cstime;
- unsigned long start_time;
+ u64 start_time;
long per_cpu_utime[NR_CPUS], per_cpu_stime[NR_CPUS];
/* mm fault and swap info: this can arguably be seen as either mm-specific or thread-specific */
unsigned long min_flt, maj_flt, nswap, cmin_flt, cmaj_flt, cnswap;
--- linux-2.5.44/include/linux/times.h Sat Oct 19 06:01:09 2002
+++ linux-2.5.44-j64/include/linux/times.h Sat Oct 26 13:00:11 2002
@@ -2,7 +2,16 @@
#define _LINUX_TIMES_H
#ifdef __KERNEL__
+#include <asm/div64.h>
+#include <asm/types.h>
+
# define jiffies_to_clock_t(x) ((x) / (HZ / USER_HZ))
+
+static inline u64 jiffies_64_to_user_HZ(u64 x)
+{
+ do_div(x, HZ / USER_HZ);
+ return x;
+}
#endif
struct tms {
--- linux-2.5.44/kernel/acct.c Sat Oct 19 06:01:56 2002
+++ linux-2.5.44-j64/kernel/acct.c Sat Oct 26 13:00:11 2002
@@ -49,7 +49,9 @@
#include <linux/acct.h>
#include <linux/file.h>
#include <linux/tty.h>
+#include <linux/jiffies.h>
#include <asm/uaccess.h>
+#include <asm/div64.h>
/*
* These constants control the amount of freespace that suspend and
@@ -304,6 +306,7 @@
mm_segment_t fs;
unsigned long vsize;
unsigned long flim;
+ u64 elapsed;
/*
* First check to see if there is enough free_space to continue
@@ -321,9 +324,11 @@
strncpy(ac.ac_comm, current->comm, ACCT_COMM);
ac.ac_comm[ACCT_COMM - 1] = '\0';
- ac.ac_btime = CT_TO_SECS(current->start_time) +
- (xtime.tv_sec - (jiffies / HZ));
- ac.ac_etime = encode_comp_t(jiffies - current->start_time);
+ elapsed = get_jiffies_64() - current->start_time;
+ ac.ac_etime = encode_comp_t(elapsed < (unsigned long) -1l ?
+ (unsigned long) elapsed : (unsigned long) -1l);
+ do_div(elapsed, HZ);
+ ac.ac_btime = xtime.tv_sec - elapsed;
ac.ac_utime = encode_comp_t(current->utime);
ac.ac_stime = encode_comp_t(current->stime);
ac.ac_uid = current->uid;
--- linux-2.5.44/kernel/fork.c Sat Oct 19 06:01:11 2002
+++ linux-2.5.44-j64/kernel/fork.c Sat Oct 26 13:00:11 2002
@@ -26,6 +26,7 @@
#include <linux/mman.h>
#include <linux/fs.h>
#include <linux/security.h>
+#include <linux/jiffies.h>
#include <linux/futex.h>
#include <linux/ptrace.h>
@@ -766,7 +767,7 @@
#endif
p->array = NULL;
p->lock_depth = -1; /* -1 = no lock */
- p->start_time = jiffies;
+ p->start_time = get_jiffies_64();
p->security = NULL;
INIT_LIST_HEAD(&p->local_pages);
--- linux-2.5.44/mm/oom_kill.c Sat Oct 19 06:01:56 2002
+++ linux-2.5.44-j64/mm/oom_kill.c Sat Oct 26 13:00:11 2002
@@ -19,6 +19,7 @@
#include <linux/sched.h>
#include <linux/swap.h>
#include <linux/timex.h>
+#include <linux/jiffies.h>
/* #define DEBUG */
@@ -68,11 +69,10 @@
/*
* CPU time is in seconds and run time is in minutes. There is no
* particular reason for this other than that it turned out to work
- * very well in practice. This is not safe against jiffie wraps
- * but we don't care _that_ much...
+ * very well in practice.
*/
cpu_time = (p->utime + p->stime) >> (SHIFT_HZ + 3);
- run_time = (jiffies - p->start_time) >> (SHIFT_HZ + 10);
+ run_time = (get_jiffies_64() - p->start_time) >> (SHIFT_HZ + 10);
points /= int_sqrt(cpu_time);
points /= int_sqrt(int_sqrt(run_time));
^ 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.