* Re: [Linux-ia64] disabling nics in efi.
From: Joseph V Moss @ 2003-01-08 21:50 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805644@msgid-missing>
Have you tried just using the 'ksdevice=eth2' option to tell anaconda to
use eth2 for the kickstart install?
> I have a bunch of HP rx2600 that have two internal nics (10/100Mbit and 1Gbit)
> and one external nic (1Gbit). Is it possible to disable the two internal
> ones in efi so linux won't see them? I tried to use the disconnect command
> in the efi shell, but they still keep showing up when I boot up linux.
> I used
> disconnect 4C
> disconnect 49
> and they report successful operation. Am I missing the point completely?
>
> I also tried the reserve= boot option to avoid linux to probe them, but that
> didn't work either. I probably computed the iobase and extents wrong. Do
> anyone know how to determine the correct parameters?
>
> The reason for wanting to disable the internal nics is that the redhat
> installer insists on fetching the kickstart file over eth0 when doing
> installations over the network and the external nic that I want to use
> becomes eth2.
>
> Any hints is greatly appreciated.
>
> Best regards,
> Roy.
> --
>
> The Computer Center, University of Tromsø, N-9037 TROMSØ, Norway.
> phone:+47 77 64 41 07, fax:+47 77 64 41 00
> Roy Dragseth, High Performance Computing System Administrator
> Direct call: +47 77 64 62 56. email: royd@cc.uit.no
>
>
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
^ permalink raw reply
* [Linux-ia64] Re: disabling nics in efi.
From: Bill Nottingham @ 2003-01-08 21:49 UTC (permalink / raw)
To: linux-ia64
Roy Dragseth (royd@cc.uit.no) said:
> The reason for wanting to disable the internal nics is that the redhat
> installer insists on fetching the kickstart file over eth0 when doing
> installations over the network and the external nic that I want to use
> becomes eth2.
>
> Any hints is greatly appreciated.
linux ksdevice=eth2
Bill
^ permalink raw reply
* Re: Status of linuxppc_2.5
From: Benjamin Herrenschmidt @ 2003-01-08 21:46 UTC (permalink / raw)
To: mlan; +Cc: panto, linuxppc-dev
In-Reply-To: <E18WOU9-00009Z-00@piglet.grunz.lu>
On Wed, 2003-01-08 at 23:15, Michel Lanners wrote:
> On 8 Jan, this message from Pantelis Antoniou echoed through cyberspace:
> > I'm trying to compile linuxppc_2.5
> > and the following patch is needed to
> > make it compile.
>
> Tried to compile my standard kernel compile a while back, and found the
> following things broken (didn't have time to try fixing yet...):
>
> - 53c94 Mac SCSI
> - Matroxfb
>
> I also didn't try very hard to compile in face of these problems; there
> may be others still.
>
> Sorry I can't provide more info, but maybe this discussion makes ore
> people interested in 2.5 status, where I think a number of PPC-related
> things need to be seriously looked at, hopefully before it is declared
> 2.6...
Yup, mostly drivers though. Part of this is me lacking time or beeing
too lazy (pick your preferred one) as I want to rework most of the pmac
drivers to better fit in the new model. Some of it is in progress
locally though, hopefully I'll push something a couple of weeks from
now.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Randy.Dunlap @ 2003-01-08 21:51 UTC (permalink / raw)
To: John Bradford; +Cc: Valdis.Kletnieks, linux-kernel
In-Reply-To: <200301082147.h08Llfpp003623@darkstar.example.net>
On Wed, 8 Jan 2003, John Bradford wrote:
| > > What I was thinking of was a virtual device that allocated a new
| > > sector whenever an old one was overwritten - kind of like a journaled
| > > filesystem, but without the filesystem, (I.E. just the journal) :-).
| >
| > $ DIR FOO.TXT;*
| > FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
| >
| > VMS-style file versioning, anybody? ;)
|
| Brilliant!
re-read the archives from 6-8 months ago.
--
~Randy
^ permalink raw reply
* Net modules fail on compile with 2.5.52 and up kernel
From: Rowan Reid @ 2003-01-08 21:46 UTC (permalink / raw)
To: netfilter
Anyone who has been keeping up with my post probale is aware of my
plight trying to set up a VPN. Initially I had an IPTables firewall and
tried to allow PPTP traffic through with unsatisfying results. Then I
scrapt the idea to use IPSec I passed over freeswan and tried to use the
2.5.50 Kernel level IPSEC implimentation. My problem is the 2.5.50
version has problems booting to a resierfs using initrd so I decided to
use 2.5.52, then 2.5.54 both of which crap out while compiling the net
modules. Eg below
I keep getting errors simular to that listed below when I run make
modules_install. This happens for 2.5.52, and 2.5.54.
depmod: *** Unresolved symbols in
/lib/modules/2.5.54/kernel/net/netlink/netlink_dev.ko
Rowan Reid
Job Captain,
Systems Administrator
STUDIO 3 ARCHITECTS
909 982 1717
^ permalink raw reply
* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: Maciej W. Rozycki @ 2003-01-08 21:53 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: H. Peter Anvin, linux-kernel
In-Reply-To: <CAD6B2D09F9@vcnet.vc.cvut.cz>
On Wed, 8 Jan 2003, Petr Vandrovec wrote:
> > Fortunately that's not true. Grab the relevant docs from:
> > 'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
> > 0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
> > explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
> > config space using conf2 accesses.
>
> Thanks, page 34 of 290479.pdf is exactly what I was looking for
> (i.e. write 1 to 0xCFB to get PCI conf1, write 0 to get PCI conf2).
> Next time I'll complain immediately instead of spending time with
> browsing Intel website and google.
Well, the download.intel.com docs are sometimes hard to get by. There
are a few EISA and basic peripheral specs nearby, too.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: XFree86 vs. 2.5.54 - reboot
From: Andrew Morton @ 2003-01-08 21:52 UTC (permalink / raw)
To: Bob_Tracy(0000); +Cc: linux-kernel
In-Reply-To: <20030108213517.7F32F4EE7@gherkin.frus.com>
"Bob_Tracy(0000)" wrote:
>
> Andrew Morton wrote:
> > "Bob_Tracy(0000)" wrote:
> > > AMD K6-III 450 running a 2.4.19 kernel with vesafb, XFree86 4.1.0, and
> > > a USB mouse works fine. Same setup with a 2.5.54 kernel does a cold
> > > reboot when I type "startx".
> >
> > I saw exactly the same. In my case it appears to be due to miscompilation
> > of a particular sysenter patch which went into 2.5.53. If you're using
> > gcc-2.91.66 (aka `kgcc') then try 2.95.x instead.
>
> I'm running gcc-2.95.3 here. Is that a "sufficiently correct" version
> to avoid the miscompilation problem?
>
Yup. It must be something else then. Perhaps you should try disabling
various DRM/AGP type things in config, see if that helps. If not, it would
help if you could identify the kernel version at which the failure started
to occur.
^ permalink raw reply
* Etherleak
From: Dee @ 2003-01-08 21:47 UTC (permalink / raw)
To: linux-kernel
Forward:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
@stake, Inc.
www.atstake.com
Security Advisory
Advisory Name: Etherleak: Ethernet frame padding information leakage
Release Date: 01/06/2003
Application: Ethernet device driver software
Platform: Multiple
Severity: Information disclosure
Authors: Ofir Arkin <ofir@sys-security.com>
Josh Anderson
Vendor Status: Multiple vendors alerted via CERT Coordination Center
CVE Candidate: CAN-2003-0001
Reference: www.atstake.com/research/advisories/2003/a010603-1.txt
Overview:
Multiple platform ethernet Network Interface Card (NIC) device
drivers incorrectly handle frame padding, allowing an attacker to
view slices of previously transmitted packets or portions of kernel
memory. This vulnerability is the result of incorrect implementations
of RFC requirements and poor programming practices, the combination
of which results in several variations of this information leakage
vulnerability.
The simplest attack using this vulnerability would be to send ICMP
echo messages to a machine with a vulnerable ethernet driver.
Portions of kernel memory will be returned to the attacker in the
padding of the reply messages. During testing we have found that
the portions returned are typically snippets of network traffic
that the vulnerable machine is handling. This attack can allow
an attacker to see portions of the traffic that a router or firewall
is handling on network segments the attacker has no direct access
too. It is important to note that the attacker must be on the
same ethernet network as the vulnerable machine to receive the
ethernet frames.
Details:
@stake has prepared a detailed report on this issue. The
vulnerability is explored in its various manifestations through
code examples and packet captures.
Report available at:
www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf
Vendor Response:
Multiple platform and hardware vendors were contacted via the CERT
Coordination Center on 06/25/02. Detailed vendor response
information is available in CERT vulnerability note VU#412115.
http://www.kb.cert.org/vuls/id/412115
Recommendation:
Contact the vendor of your ethernet device drivers or your hardware
vendor for a patch.
End to end encryption technologies such as SSL, IPSEC, and SSH
should be used when transmitting sensitive data over a network. Using
encryption will help protect against this issue partly. It is not a
complete solution because the kernel data leaked in the ethernet
frame padding is not always the IP packet data portion of a
previous frame. Sometimes it is unencrypted IP header information or
other kernel memory.
Common Vulnerabilities and Exposures (CVE) Information:
The Common Vulnerabilities and Exposures (CVE) project has assigned
the following names to these issues. These are candidates for
inclusion in the CVE list (http://cve.mitre.org), which standardizes
names for security problems.
CAN-2003-0001 Ethernet frame padding information leakage
@stake Vulnerability Reporting Policy:
http://www.atstake.com/research/policy/
@stake Advisory Archive: http://www.atstake.com/research/advisories/
PGP Key:
http://www.atstake.com/research/pgp_key.asc
Copyright 2003 @stake, Inc. All rights reserved.
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0
iQA/AwUBPhmc+Ee9kNIfAm4yEQKyjACgnvi0ZuRUb94nfcG0zMHPzl6XdZQAn1tG
TXcUNSc0uLgCvhUp0vQAu7+J
=3Dtx
-----END PGP SIGNATURE-----
Was wondering if anyone had patchs for listed drivers?
^ permalink raw reply
* [Linux-ia64] disabling nics in efi.
From: Roy Dragseth @ 2003-01-08 21:39 UTC (permalink / raw)
To: linux-ia64
I have a bunch of HP rx2600 that have two internal nics (10/100Mbit and 1Gbit)
and one external nic (1Gbit). Is it possible to disable the two internal
ones in efi so linux won't see them? I tried to use the disconnect command
in the efi shell, but they still keep showing up when I boot up linux.
I used
disconnect 4C
disconnect 49
and they report successful operation. Am I missing the point completely?
I also tried the reserve= boot option to avoid linux to probe them, but that
didn't work either. I probably computed the iobase and extents wrong. Do
anyone know how to determine the correct parameters?
The reason for wanting to disable the internal nics is that the redhat
installer insists on fetching the kickstart file over eth0 when doing
installations over the network and the external nic that I want to use
becomes eth2.
Any hints is greatly appreciated.
Best regards,
Roy.
--
The Computer Center, University of Tromsø, N-9037 TROMSØ, Norway.
phone:+47 77 64 41 07, fax:+47 77 64 41 00
Roy Dragseth, High Performance Computing System Administrator
Direct call: +47 77 64 62 56. email: royd@cc.uit.no
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: John Bradford @ 2003-01-08 21:47 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel
In-Reply-To: <200301082133.h08LXlRA014406@turing-police.cc.vt.edu>
> > What I was thinking of was a virtual device that allocated a new
> > sector whenever an old one was overwritten - kind of like a journaled
> > filesystem, but without the filesystem, (I.E. just the journal) :-).
>
> $ DIR FOO.TXT;*
> FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
>
> VMS-style file versioning, anybody? ;)
Brilliant!
John.
^ permalink raw reply
* Re: CRAMFS on MTD/NAND Issue
From: Thomas Gleixner @ 2003-01-08 22:04 UTC (permalink / raw)
To: Henrik Nordstrom; +Cc: Russ Dill, Srinivasu.Vaduguri, linux-mtd
In-Reply-To: <Pine.LNX.4.44.0301082150360.9902-100000@filer.marasystems.com>
On Wednesday 08 January 2003 21:51, Henrik Nordstrom wrote:
> On Wed, 8 Jan 2003, Thomas Gleixner wrote:
> > > roll your own: Please, make a static compressed filesystem (like
> > > cramfs) that incorporates extra blocks, so that when the checksum is
> > > bad while initially writing the filesystem, or reading the file system
> > > (in the case where ecc can save the data), it rewrites this block to a
> > > free sector). It would seem like a simple modification to cramfs to me.
> >
> > Don't reinvent the wheel! :)
>
> Having a image based filesystem which cannot be written to has it's
> beauty..
Mount your rootfs _readonly_ and you have the _same_ including bad block
handling.
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
^ permalink raw reply
* Dosemu Fonts
From: Rodrigo de Bastidas @ 2003-01-08 21:34 UTC (permalink / raw)
To: linux-msdos
Hi! I use dosemu in enviroment production is working really good
with my freedos But I like know if you have a vga fonts different.
"vga11x19 in resolution 800x600 is not very good" Please Do you
have a vga fonts for 800 x 600? the vga fonts "vga" working very
good in 640 x 480 I like a vga font like that but for 800 x 600
Thanks!
Gustavo Adolfo Olarte Buelvas
Barranquilla, Colombia!
pd: excuse me for my bad english
_________________________________________________________________
MSN. Más Útil Cada Día http://www.msn.es/intmap/
^ permalink raw reply
* Re: 16 NANDS
From: Thomas Gleixner @ 2003-01-08 22:03 UTC (permalink / raw)
To: m.neiger, manningc2, 'linux-mtd@lists.infradead.org'
In-Reply-To: <515CABE7496FD111AA3300201829FCBE3552E0@archie.gsi.synergie-inf.com>
On Wednesday 08 January 2003 22:23, Marc Neiger wrote:
> Hi Thomas,
>
> > I have the framework ready to support different buswidths.
>
> It's dangerous talking to you, guys, one gets easily caught in the
> maelstrom ;-)
>
> I'll gladly put my share back into the GPLd world, however my timeframe for
> the current project is very tight; everything, board, embedded linux and
> application should be working in less than 2 months.....
> Moreover, although I, and my colleagues, are experienced programmers, both
> in embedded and win32, I booted my first Linux about 6 weeks ago....
>
> The project shall be using a customly developped board using AMD Alchemy
> AU1000 (MIPS4Kc) processor. The board is planned to support both 8 and
> 16bits NAND flash, an EPLD shall, among other task, take care of data bus
> bits reordering (8 and 16 bits NANDS are pin out compatible except for the
> bit order). After reading some msg on this list, we already doubt about the
> ease of mounting a root JFFS2 filesystem.
It's really no big deal to mount a root fs with JFFS2 on NAND FLASH (8 bit
buswidth). It works right out of the box, if you take the preliminaries into
concern (see http://www.linux-mtd.infradead.org/tech/nand.html)
It is used in production systems.
> I'll have a look at the framework, then if I have some "time" and I feel
> comfortable with your code, I'll try to finish it, and we'll test it on our
> first board version. Otherwise, and it seems more likely, after the project
> is delivered and we have some experience on Linux, including kernel
> development since we are to write a driver for this very specific hardware,
> I'll get more seriously hands on the code but without having a very short
> deadline in front of me.
If your deadline is so tight and your capacities are so restricted, you could
consider to sponsor one of the volunteer experts. This would speed up
development rapidly. :)
> I already do much non computer related volunteer work and can not afford to
> take on my "free" time anymore.
See above. :)
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
^ permalink raw reply
* Re: [Pcihpd-discuss] Re:[BUG] cpci patch for kernel 2.4.19 bug
From: Rusty Lynch @ 2003-01-08 20:59 UTC (permalink / raw)
To: Rusty Lynch, Scott Murray; +Cc: greg, harold.yang, linux-kernel, pcihpd-discuss
In-Reply-To: <005f01c2b756$b42a59a0$79d40a0a@amr.corp.intel.com>
[-- Attachment #1: Type: text/plain, Size: 3850 bytes --]
Just realized that the data I attached was for a 2.5.54
kernel with my patch to register both cpci buses. Here
is the same output for a normal 2.5.54 kernel.
I also added my dmesg.
--rustyl
From: "Rusty Lynch" <rusty@linux.co.intel.com>
> From: "Scott Murray" <scottm@somanetworks.com>
> > On Wed, 8 Jan 2003, Rusty Lynch wrote:
> >
> > > From: "Yang, Harold" <harold.yang@intel.com>
> > > >
> > > > Hi, Scott & Greg:
> > > >
> > > > I have applied the cpci patch for kernel 2.4.19, and test it
> > > > thoroughly on ZT5084 platform. Two bugs are found:
> > > >
> > > > 1. In my ZT5084, the driver can't correctly detect the cPCI
> > > > Hot Swap bridge device. Two DEC21154 exist on ZT5084,
> > > > however, only one is the right bridge. The driver can't
> > > > distinguish them correctly.
> > >
> > > I just got a couple of ZT5541 peripheral master boards
> > > and can finally see what happens when an enumerable board
> > > is plugged into a ZT5084 chassis using a ZT5550 system master
> > > board.
> > >
> > > As of yet I have only tried a 2.5.54 kernel, but I see the
> > > same problems along with some other wacky behavior that I
> > > am trying to isolate.
> > >
> > > Now about the multiple DEC21154 devices ==> on my ZT5550 that
> > > is in system master mode, the first DEC21154 device is a bridge
> > > for the slots to the left of the system slots, and the second
> > > DEC21154 is a bridge for the right of the system slots.
> >
> > Okay, that's what I originally wanted to determine from the lspci
> > output I requested when Harold mentioned this problem at the end
> > of November.
> >
>
> I am attaching output for:
> 1. lspci -vvv
> 2. cat /proc/ioports
> 3. cat /proc/iomem
>
> For a ZT5550 running as system master in the second system slot
> of a ZT5084 chassis that has two ZT5541 (peripherial master) boards
> plugged in (one to the left of the sytem slots and the other to
> the right of the system slots.)
>
> > > So if I boot the system master (I'll talk about problems with
> > > hotswaping in another email) with a peripheral board plugged
> > > into one of the slots on the right of the master using the
> > > current 2.5.54 kernel then I run into problems the first time
> > > cpci_hotplug_core.c::check_slots() runs because it only looks
> > > at the first bus when trying to find the card that caused the
> > > #ENUM.
> >
> > I assume by problems you mean that the cPCI event thread gets
> > shut down (which is what I'd expect), or do you mean something more
> > severe?
> >
>
> The event thread shutsdown with the
> "cannot find ENUM# source, shutting down" error message. That's all.
>
> > > The following patch will register each of the cpci busses instead
> > > of just the first one detected.
> >
> > Your patch is better than Harold's hack, but I'm probably going to
> > try and think of some other alternative, as the while loop idea
> > doesn't handle the possibility of someone having a 21154 bridge
> > on a PMC card or actually as a bridge on a cPCI card. The original
> > code doesn't really handle that possiblity either, so I'll need to
> > cook up something better anyway.
> >
> > > NOTE: I'm a little worried that the right way to do this is to
> > > properly initialize the RSS bits, or at least see how the
> > > chassis is configured via the RSS bits to determine which
> > > cpci bus to register. The ZT5084 doesn't have near as many
> > > configurations as newer designs like the ZT5088.
> > [snip]
> >
> > I will investigate reading the active bus(es) out of the HC, as I've
> > gotten the documentation for the HC from Performance Tech, I was just
> > too busy before Christmas to dig into it then. I'll try and have
> > something that attempts to handle your ZT5084 chassis done in a few
> > days.
> >
> > Scott
>
[-- Attachment #2: dmesg.log --]
[-- Type: application/octet-stream, Size: 7423 bytes --]
Linux version 2.5.54 (rusty@cpci-b) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #2 SMP Wed Jan 8 12:46:53 PST 2003
Video mode to be used for restore is ffff
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e7400 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
256MB LOWMEM available.
On node 0 totalpages: 65536
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61440 pages, LIFO batch:15
HighMem zone: 0 pages, LIFO batch:1
ACPI: Unable to locate RSDP
Building zonelist for node : 0
Kernel command line: auto BOOT_IMAGE=hack2 ro BOOT_FILE=/boot/hack2 debug=1
Local APIC disabled by BIOS -- reenabling.
Could not enable APIC!
Initializing CPU#0
PID hash table entries: 2048 (order 11: 16384 bytes)
Detected 498.539 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 985.08 BogoMIPS
Memory: 255512k/262144k available (2038k kernel code, 5892k reserved, 808k data, 120k init, 0k highmem)
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel Pentium III (Coppermine) stepping 03
per-CPU timeslice cutoff: 730.93 usecs.
task migration cache decay timeout: 1 msecs.
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Starting migration thread for cpu 0
CPUS done 2
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
device class 'cpu': registering
device class cpu: adding driver system:cpu
PCI: PCI BIOS revision 2.10 entry at 0xfd89e, last bus=3
PCI: Using configuration type 1
device class cpu: adding device CPU 0
interfaces: adding device CPU 0
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec pool[0]: 1 bvecs: 256 entries (12 bytes)
biovec pool[1]: 4 bvecs: 256 entries (48 bytes)
biovec pool[2]: 16 bvecs: 256 entries (192 bytes)
biovec pool[3]: 64 bvecs: 256 entries (768 bytes)
biovec pool[4]: 128 bvecs: 256 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 256 entries (3072 bytes)
ACPI: Subsystem revision 20021217
ACPI: System description tables not found
ACPI-0065: *** Error: acpi_load_tables: Could not get RSDP, AE_NOT_FOUND
ACPI-0115: *** Error: acpi_load_tables: Could not load tables: AE_NOT_FOUND
ACPI: Unable to load the System Description Tables
Linux Plug and Play Support v0.93 (c) Adam Belay
block request queues:
128 requests per read queue
128 requests per write queue
8 requests per batch
enter congestion at 31
exit congestion at 33
ACPI: ACPI tables contain no PCI IRQ routing entries
PCI: Invalid ACPI-PCI IRQ routing table
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router PIIX [8086/7110] at 00:07.0
PCI: Cannot allocate resource region 4 of device 00:07.1
IA-32 Microcode Update Driver: v1.11 <tigran@veritas.com>
Enabling SEP on CPU 0
aio_setup: sizeof(struct page) = 40
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Limiting direct PCI/PCI transfers.
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
device class 'tty': registering
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.11
Non-volatile memory driver v1.2
Linux agpgart interface v0.100 (c) Dave Jones
[drm] Initialized r128 2.3.0 20021029 on minor 0
Linux Tulip driver version 1.1.13 (May 11, 2002)
PCI: Found IRQ 11 for device 00:05.0
PCI: Sharing IRQ 11 with 02:0d.0
tulip0: EEPROM default media type Autosense.
tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip0: Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block.
tulip0: Index #3 - Media AUI (#2) described by a 21142 Serial PHY (2) block.
tulip0: Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip0: MII transceiver #0 config 1000 status 782d advertising 01e1.
eth0: Digital DS21143 Tulip rev 65 at 0x1080, 00:80:50:02:73:75, IRQ 11.
PCI: Found IRQ 10 for device 00:06.0
PCI: Sharing IRQ 10 with 03:0a.0
tulip1: EEPROM default media type Autosense.
tulip1: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block.
tulip1: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block.
tulip1: Index #2 - Media 10base2 (#1) described by a 21142 Serial PHY (2) block.
tulip1: Index #3 - Media AUI (#2) described by a 21142 Serial PHY (2) block.
tulip1: Index #4 - Media MII (#11) described by a 21142 MII PHY (3) block.
tulip1: MII transceiver #0 config 1000 status 782d advertising 01e1.
eth1: Digital DS21143 Tulip rev 65 at 0x1400, 00:80:50:02:73:76, IRQ 10.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: IBM-DJSA-210, ATA DISK drive
hdc: CD-224E, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 19640880 sectors (10056 MB) w/384KiB Cache, CHS=19485/16/63
hda: hda1 hda2 hda3
hdc: ATAPI 24X CD-ROM drive, 128kB Cache
Uniform CD-ROM driver Revision: 3.12
end_request: I/O error, dev hdc, sector 0
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
input: PC Speaker
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
cpci_hotplug: CompactPCI Hot Plug Core version: 0.2
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
cpcihp_zt5550: ZT5550 CompactPCI Hot Plug Driver version: 0.2
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 1024 buckets, 16Kbytes
TCP: Hash tables configured (established 8192 bind 10922)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
cpci_hotplug: cannot find ENUM# source, shutting down
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 120k freed
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide0(3,2), internal journal
Adding 514072k swap on /dev/hda3. Priority:-1 extents:1
eth0: Setting full-duplex based on MII#0 link partner capability of 45e1.
spurious 8259A interrupt: IRQ7.
eth1: Setting full-duplex based on MII#0 link partner capability of 01e1.
warning: process `update' used the obsolete bdflush system call
Fix your initscripts?
warning: process `update' used the obsolete bdflush system call
Fix your initscripts?
[-- Attachment #3: lspci_system_master.txt --]
[-- Type: text/plain, Size: 7906 bytes --]
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 64
Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
Capabilities: [a0] AGP version 1.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f5000000-f5ffffff
Prefetchable memory behind bridge: fff00000-000fffff
BridgeCtl: Parity- SERR- NoISA+ VGA+ MAbort- >Reset- FastB2B+
00:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 165 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 1080 [size=128]
Region 1: Memory at f4001000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
00:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 165 (5000ns min, 10000ns max), cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 1400 [size=128]
Region 1: Memory at f4001400 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=256K]
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 [Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Region 4: I/O ports at 14a0 [size=16]
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64
Interrupt: pin D routed to IRQ 9
Region 4: I/O ports at 1060 [size=32]
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin ? routed to IRQ 9
00:08.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Bus: primary=00, secondary=02, subordinate=02, sec-latency=68
I/O behind bridge: 00002000-00002fff
Memory behind bridge: f6000000-f61fffff
Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
00:0b.0 Class ff00: Ziatech Corporation: Unknown device 5550 (rev 03)
Subsystem: Ziatech Corporation: Unknown device 5550
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 9
Region 0: I/O ports at 1480 [size=32]
Region 1: Memory at f4000000 (32-bit, non-prefetchable) [size=4K]
00:0c.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Bus: primary=00, secondary=03, subordinate=03, sec-latency=68
I/O behind bridge: 00003000-00003fff
Memory behind bridge: f6200000-f63fffff
Prefetchable memory behind bridge: 00000000fff00000-0000000000000000
BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
01:00.0 VGA compatible controller: Chips and Technologies F69000 HiQVideo (rev 64) (prog-if 00 [VGA])
Subsystem: Chips and Technologies F69000 HiQVideo
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
Expansion ROM at <unassigned> [disabled] [size=256K]
02:0d.0 Bridge: Digital Equipment Corporation DECchip 21554 (rev 01)
Subsystem: Ziatech Corporation: Unknown device 5541
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f6101000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 2400 [size=256]
Region 2: I/O ports at 2000 [size=256]
Region 3: Memory at f6000000 (32-bit, non-prefetchable) [size=1M]
Region 4: Memory at f6100000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 0
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e4] Slot ID: 0 slots, First-, chassis 00
Capabilities: [ec] #06 [0000]
03:0a.0 Bridge: Digital Equipment Corporation DECchip 21554 (rev 01)
Subsystem: Ziatech Corporation: Unknown device 5541
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B+
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64, cache line size 08
Interrupt: pin A routed to IRQ 10
Region 0: Memory at f6301000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at 3400 [size=256]
Region 2: I/O ports at 3000 [size=256]
Region 3: Memory at f6200000 (32-bit, non-prefetchable) [size=1M]
Region 4: Memory at f6300000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 0
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [e4] Slot ID: 0 slots, First-, chassis 00
Capabilities: [ec] #06 [0080]
[-- Attachment #4: proc_iomem.txt --]
[-- Type: text/plain, Size: 1221 bytes --]
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000c9800-000c9fff : Extension ROM
000ca000-000ca7ff : Extension ROM
000f0000-000fffff : System ROM
00100000-0fffffff : System RAM
00100000-002fda69 : Kernel code
002fda6a-003c7d67 : Kernel data
f4000000-f4000fff : PCI device 1138:5550 (Ziatech Corporation)
f4000000-f4000fff : cpcihp_zt5550
f4001000-f40013ff : Digital Equipment Co DECchip 21142/43
f4001000-f40013ff : tulip
f4001400-f40017ff : Digital Equipment Co DECchip 21142/43 (#2)
f4001400-f40017ff : tulip
f5000000-f5ffffff : PCI Bus #01
f5000000-f5ffffff : Chips and Technologi F69000 HiQVideo
f6000000-f61fffff : PCI Bus #02
f6000000-f60fffff : Digital Equipment Co DECchip 21554
f6100000-f6100fff : Digital Equipment Co DECchip 21554
f6101000-f6101fff : Digital Equipment Co DECchip 21554
f6200000-f63fffff : PCI Bus #03
f6200000-f62fffff : Digital Equipment Co DECchip 21554 (#2)
f6300000-f6300fff : Digital Equipment Co DECchip 21554 (#2)
f6301000-f6301fff : Digital Equipment Co DECchip 21554 (#2)
f8000000-fbffffff : Intel Corp. 440BX/ZX/DX - 82443B
fffc0000-ffffffff : reserved
[-- Attachment #5: proc_ioports.txt --]
[-- Type: text/plain, Size: 1018 bytes --]
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00e1-00e1 : #ENUM hotswap signal register
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-103f : Intel Corp. 82371AB/EB/MB PIIX4
1040-105f : Intel Corp. 82371AB/EB/MB PIIX4
1060-107f : Intel Corp. 82371AB/EB/MB PIIX4
1080-10ff : Digital Equipment Co DECchip 21142/43
1080-10ff : tulip
1400-147f : Digital Equipment Co DECchip 21142/43 (#2)
1400-147f : tulip
1480-149f : PCI device 1138:5550 (Ziatech Corporation)
14a0-14af : Intel Corp. 82371AB/EB/MB PIIX4
2000-2fff : PCI Bus #02
2000-20ff : Digital Equipment Co DECchip 21554
2400-24ff : Digital Equipment Co DECchip 21554
3000-3fff : PCI Bus #03
3000-30ff : Digital Equipment Co DECchip 21554 (#2)
3400-34ff : Digital Equipment Co DECchip 21554 (#2)
^ permalink raw reply
* Re: XFree86 vs. 2.5.54 - reboot
From: Bob_Tracy(0000) @ 2003-01-08 21:35 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel
In-Reply-To: <3E1C880A.87A93CFA@digeo.com>
Andrew Morton wrote:
> "Bob_Tracy(0000)" wrote:
> > AMD K6-III 450 running a 2.4.19 kernel with vesafb, XFree86 4.1.0, and
> > a USB mouse works fine. Same setup with a 2.5.54 kernel does a cold
> > reboot when I type "startx".
>
> I saw exactly the same. In my case it appears to be due to miscompilation
> of a particular sysenter patch which went into 2.5.53. If you're using
> gcc-2.91.66 (aka `kgcc') then try 2.95.x instead.
I'm running gcc-2.95.3 here. Is that a "sufficiently correct" version
to avoid the miscompilation problem?
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------
^ permalink raw reply
* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: Richard B. Johnson @ 2003-01-08 21:37 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Nakajima, Jun, Linux kernel
In-Reply-To: <3E1C8CD2.4070402@zytor.com>
On Wed, 8 Jan 2003, H. Peter Anvin wrote:
> Nakajima, Jun wrote:
> >
> > Normally all accesses should be long (0xcf8/0xcfc) but x86 is byte addresseable and some chipsets do support byte accesses.
> > We do not encourage use of byte accesses as it will not be supported in future platforms.
> >
>
> The PCI standard is quite explicit: byte accesses are permitted to the
> data window (0xCFC) and not permitted to the address window (0xCF8).
> Accepting byte accesses to the address window, or not supporting byte
> accesses to the data window, *will* result in breakage (I can attest to
> this fact quite well.)
>
> -hpa
>
After power-on reset, or a hardware reset if provided (not SW
reset), you do a byte-write to CSE (Configuration Space Enable).
CSE is at 0xCF8. The 8-bit field is:
00000000B
| ||_________ SCE (special cycle enable)
| |__________ <1,3> Target function number
|_____________ non-zero = enable configuration
This is done by the BIOS because once the enable configuration bits
are set, all accesses are supposed to be 32 bits.
There is also another byte-port at 0xCFA this is called the
forward register and it must be set before enabling configuration
transactions. This register identifies one of 256 possible
PCI buses.
None of the 8-bit registers are supposed to be touched (they
are not accessible) after configuration transactions are
enabled. All of the configuration registers are specified
as numbered doubleword registers, from 0 to 15. Attempting to
read or write less than a doubleword can stop the bus interface
state-machine, locking up everything. This is because many of
the physical lines are shared (see IDSEL, muxed to address lines).
If the exact step-by-step bus activity for which it was designed,
does not occur, all bets are off!
This was hinted by "Nakajima, Jun" <jun.nakajima@intel.com>.
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: PCI code: why need outb (0x01, 0xCFB); ?
From: Petr Vandrovec @ 2003-01-08 21:33 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: H. Peter Anvin, linux-kernel
On 8 Jan 03 at 22:22, Maciej W. Rozycki wrote:
> On Wed, 8 Jan 2003, Petr Vandrovec wrote:
>
> > > > 1. which device is at port address 0xCFB?
> > >
> > > Hopefully none.
> >
> > Actually I'm not sure. This code is here since at least 2.0.28,
> > and during googling I even found code for direct PCI access
> > (http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
> > which sets lowest bit at 0xCFB to 1 before doing PCI config
> > accesses and reset it back to original value afterward.
> >
> > So I believe that there were some chipsets (probably in 486&PCI times)
> > which did conf1/conf2 accesses depending on value of this bit.
> > Unfortunately I was not able to confirm this - almost nobody provides
> > northbridge datasheets from '94 era, even Intel does not provide them
> > (f.e. Neptune) anymore :-(
>
> Fortunately that's not true. Grab the relevant docs from:
> 'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
> 0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
> explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
> config space using conf2 accesses.
Thanks, page 34 of 290479.pdf is exactly what I was looking for
(i.e. write 1 to 0xCFB to get PCI conf1, write 0 to get PCI conf2).
Next time I'll complain immediately instead of spending time with
browsing Intel website and google.
Thanks,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Valdis.Kletnieks @ 2003-01-08 21:33 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200301081057.h08Av1og000585@darkstar.example.net>
[-- Attachment #1: Type: text/plain, Size: 356 bytes --]
On Wed, 08 Jan 2003 10:57:01 GMT, John Bradford said:
> What I was thinking of was a virtual device that allocated a new
> sector whenever an old one was overwritten - kind of like a journaled
> filesystem, but without the filesystem, (I.E. just the journal) :-).
$ DIR FOO.TXT;*
FOO.TXT;1 FOO.TXT;2 FOO.TXT;2
VMS-style file versioning, anybody? ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: /dev/random, /dev/urandom
From: Ray Olszewski @ 2003-01-08 21:22 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <avi1hh$hai$1@main.gmane.org>
At 03:27 PM 1/8/03 -0500, Jamie Risk wrote:
>I'm compiling OpenSSH, and to access /dev/random, and /dev/urandom, the
>configure script needs to be run as root.
>
>What sort of trauma am I in for if I make those device permissions read
>accessible by everyone?
Nothing serious that I can think of (though I suppose a malicious user
might "use up" the system's entropy). The man page for "random" recommends
mode 644 for both devices. Standard Debian installs make them world readable.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Matthias Andree @ 2003-01-08 21:29 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <E18WB8R-0004k9-00@fencepost.gnu.org>
On Wed, 08 Jan 2003, Richard Stallman wrote:
> When you take part of my statement, stretch it, interpret it based on
> assumptions you know I disagree with, and present the result as
> something I said, that doesn't prove anything. It is childish.
>
> There is no ethical obligation to mention secondary contributions
> incorporated in a large project. There ethical obligation is to cite
> the main developer. In the GNU/Linux system, the GNU Project is the
> principal contributor; the system is more GNU than anything else,
> and we started it.
You overestimate your influence. Now please go invest your energy into
something that a) is more likely to succeed, b) does not happen on this
list.
--
Matthias Andree
^ permalink raw reply
* [PATCH] kallsyms off-by-one and sorting
From: Hugh Dickins @ 2003-01-08 21:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, Kai Germaschewski, Rusty Russell, Daniel Ritz,
linux-kernel
kallsyms was off-by-one, showing the preceding symbol name. For
example, if best index 0, no string was copied into the namebuf.
And it seems odd to do stem compression on symbols sorted by value:
save more space sorting by name. It's harder then to avoid aliases
for a value: but very few in kernel text, so scrap last_addr check.
Against current BK: please apply.
Hugh
--- 2.5.54-bk/Makefile Thu Jan 2 09:06:03 2003
+++ linux/Makefile Wed Jan 8 20:46:44 2003
@@ -355,7 +355,7 @@
kallsyms.o := .tmp_kallsyms2.o
quiet_cmd_kallsyms = KSYM $@
-cmd_kallsyms = $(NM) -n $< | scripts/kallsyms > $@
+cmd_kallsyms = $(NM) $< | scripts/kallsyms > $@
.tmp_kallsyms1.o .tmp_kallsyms2.o: %.o: %.S scripts FORCE
$(call if_changed_dep,as_o_S)
--- 2.5.54-bk/kernel/kallsyms.c Wed Jan 8 20:14:29 2003
+++ linux/kernel/kallsyms.c Wed Jan 8 20:46:44 2003
@@ -25,8 +25,6 @@
unsigned long *offset,
char **modname, char *namebuf)
{
- unsigned long i, best = 0;
-
/* This kernel should never had been booted. */
if ((void *)kallsyms_addresses == &kallsyms_dummy)
BUG();
@@ -35,32 +33,34 @@
namebuf[0] = 0;
if (addr >= (unsigned long)_stext && addr <= (unsigned long)_etext) {
- unsigned long symbol_end;
+ unsigned long below = 0;
+ unsigned long above = (unsigned long)_etext;
+ unsigned long i, best = 0;
char *name = kallsyms_names;
- /* They're sorted, we could be clever here, but who cares? */
for (i = 0; i < kallsyms_num_syms; i++) {
- if (kallsyms_addresses[i] > kallsyms_addresses[best] &&
- kallsyms_addresses[i] <= addr)
- best = i;
+ unsigned long kaddr = kallsyms_addresses[i];
+ if (kaddr <= addr) {
+ if (kaddr > below) {
+ below = kaddr;
+ best = i;
+ }
+ } else {
+ if (kaddr < above)
+ above = kaddr;
+ }
}
/* Grab name */
- for (i = 0; i < best; i++) {
+ for (i = 0; i <= best; i++) {
unsigned prefix = *name++;
strncpy(namebuf + prefix, name, 127 - prefix);
name += strlen(name) + 1;
}
- /* Base symbol size on next symbol. */
- if (best + 1 < kallsyms_num_syms)
- symbol_end = kallsyms_addresses[best + 1];
- else
- symbol_end = (unsigned long)_etext;
-
- *symbolsize = symbol_end - kallsyms_addresses[best];
+ *symbolsize = above - below;
*modname = NULL;
- *offset = addr - kallsyms_addresses[best];
+ *offset = addr - below;
return namebuf;
}
--- 2.5.54-bk/scripts/kallsyms.c Wed Jan 8 20:14:30 2003
+++ linux/scripts/kallsyms.c Wed Jan 8 20:46:44 2003
@@ -5,7 +5,7 @@
* This software may be used and distributed according to the terms
* of the GNU General Public License, incorporated herein by reference.
*
- * Usage: nm -n vmlinux | scripts/kallsyms > symbols.S
+ * Usage: nm vmlinux | scripts/kallsyms > symbols.S
*/
#include <stdio.h>
@@ -91,7 +91,6 @@
static void
write_src(void)
{
- unsigned long long last_addr;
int i, valid = 0;
char *prev;
@@ -109,16 +108,12 @@
printf(".globl kallsyms_addresses\n");
printf("\tALGN\n");
printf("kallsyms_addresses:\n");
- for (i = 0, last_addr = 0; i < cnt; i++) {
+ for (i = 0; i < cnt; i++) {
if (!symbol_valid(&table[i]))
continue;
- if (table[i].addr == last_addr)
- continue;
-
printf("\tPTR\t%#llx\n", table[i].addr);
valid++;
- last_addr = table[i].addr;
}
printf("\n");
@@ -132,20 +127,16 @@
printf("\tALGN\n");
printf("kallsyms_names:\n");
prev = "";
- for (i = 0, last_addr = 0; i < cnt; i++) {
+ for (i = 0; i < cnt; i++) {
int k;
if (!symbol_valid(&table[i]))
continue;
- if (table[i].addr == last_addr)
- continue;
-
for (k = 0; table[i].sym[k] && table[i].sym[k] == prev[k]; ++k)
;
printf("\t.byte 0x%02x ; .asciz\t\"%s\"\n", k, table[i].sym + k);
- last_addr = table[i].addr;
prev = table[i].sym;
}
printf("\n");
^ permalink raw reply
* Re: iptables u32 match code for review/testing/...
From: Harald Welte @ 2003-01-08 21:16 UTC (permalink / raw)
To: Don Cohen; +Cc: netfilter-devel
In-Reply-To: <15900.33229.827518.797424@isis.cs3-inc.com>
[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]
On Wed, Jan 08, 2003 at 11:53:49AM -0800, Don Cohen wrote:
> Well, not quite that bad. It's actually o(10x(10+10)). The structure
> sizes seem to be 5+8 so actually using 1300 bytes. I don't know
> whether there's more space wasted on alignment.
> Would it work to make that 10 into a module parm (or three) ?
unfortunately not. The size of this structure needs to be known at
compile time of the kernel and iptables userspace (and they have to be
the same, obviously).
> > Sorry, I didn't make myself clear. if u32 is used the right way, it is
> > way better than lots of the static matches within iptables. However, it
> I don't know what "the right way" means. A more specific match will
> be faster to execute and easier to specify. The advantage of u32 is
> generality.
You are still comparing u32 to a current iptables match. What is more
interesting is comaring u32 against a whole iptables chain which uses
only static matches (i.e. matching criteria that can be expressed in u32
syntax).
> Perhaps you should view it as temporary until something better
> arrives. You might consider changing the architecture later.
> My impression is that jamal <hadi@cyberus.ca> is well on the way to
> using tc to replace iptables. And I begin to see that his approach
> (or at least what I imagine to be his approach) might actually be
> a lot more efficient.
Yes. Unfortunately I am not able to reproduce the (verbal) discussions
between Jamal, Werner Almesberger, Robert Olsson and me...
Nobody questions that what he's doing is more efficient. In fact,
almost anything you can do (with a fundamentally different
architecture) for matching a packet based on static matching criteria
(i.e. port number=x, tos=y, ttl=z, ...) present in the packet header
will be more efficient than iptables. See also the nf-hipac project.
But will it be as easily extensible as iptables?
Will it support efficient matching of out-of-packet data? (i.e.
state, random, nth, conntrack, helper, ... matches of iptables)
And in the end the question is: How much efficiency at this level do we
need? In a time of stateful firewalling, most people don't do lots of
classification based on 'static' criteria. In iptables-terminology: One
of the first rules will be '-m state --state ESTABLISHED -j ACCEPT',
resulting in only a single rule to be iterated for every packet part of
an already established connection...
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: Virtual WORM device
From: Vishal Verma @ 2003-01-08 18:24 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200301071841.h07If7QJ002323@darkstar.example.net>
>
> Another possibility would be to create a meta-device that works like a
> cross between the loopback device, and WORM device, I.E. start at the
> begining, and allocate sectors sequentially. Whenever a sector would
> normally be overwritten, a new one is allocated instead. This way,
> you could always access the filesystem as it was at any mount in time.
OR you can check-in your entire filesystem into CVS ;)
^ permalink raw reply
* Re: Killing off the boot sector (was: [STATUS 2.5] January 8, 2002)
From: John Bradford @ 2003-01-08 21:23 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel
In-Reply-To: <avi06f$89g$1@cesium.transmeta.com>
> Can we *please* kill off the stupid in-kernel boot sector?
>
> Here is a patch that guts it to print an error message. It's even
> tested.
> -# This procedure turns off the floppy drive motor, so
> -# that we enter the kernel in a known state, and
> -# don't have to worry about it later.
> -# NOTE: Doesn't save %ax or %dx; do it yourself if you need to.
> -
> -kill_motor:
> -#if 1
> - xorw %ax, %ax # reset FDC
> - xorb %dl, %dl
> - int $0x13
> -#else
> - movw $0x3f2, %dx
> - xorb %al, %al
> - outb %al, %dx
> -#endif
> - ret
Shouldn't that part stay, incase somebody boots a machine from a
floppy, and leaves it running for hours?
> + .ascii "Direct booting from floppy is no longer supported.\r\n"
> + .ascii "Please use a boot loader program instead.\r\n"
> + .ascii "\n"
> + .ascii "Remove disk and press any key to reboot . . .\r\n"
Couldn't you put an ASCII penguin in there? :-)
John.
^ permalink raw reply
* Re: PCI code: why need outb (0x01, 0xCFB); ?
From: Maciej W. Rozycki @ 2003-01-08 21:22 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: H. Peter Anvin, linux-kernel
In-Reply-To: <CACAEBD1F1C@vcnet.vc.cvut.cz>
On Wed, 8 Jan 2003, Petr Vandrovec wrote:
> > > 1. which device is at port address 0xCFB?
> >
> > Hopefully none.
>
> Actually I'm not sure. This code is here since at least 2.0.28,
> and during googling I even found code for direct PCI access
> (http://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs_freeware/gerald.zip/DIRECTNT.CPP?auto=CPP)
> which sets lowest bit at 0xCFB to 1 before doing PCI config
> accesses and reset it back to original value afterward.
>
> So I believe that there were some chipsets (probably in 486&PCI times)
> which did conf1/conf2 accesses depending on value of this bit.
> Unfortunately I was not able to confirm this - almost nobody provides
> northbridge datasheets from '94 era, even Intel does not provide them
> (f.e. Neptune) anymore :-(
Fortunately that's not true. Grab the relevant docs from:
'ftp://download.intel.com/support/chipsets/430nx/'. The semantics of
0xcf8, 0xcf9, 0xcfa and 0xcfb I/O ports when used as byte quantities is
explained there. Note that 0xcf8 and 0xcfa are the way to get at the PCI
config space using conf2 accesses.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ 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.