* Re: PROBLEM: dvd-drive no longer works (2.4.20)
From: Alvaro Lopes @ 2002-12-11 17:15 UTC (permalink / raw)
To: Brendon Higgins; +Cc: linux-kernel
In-Reply-To: <200212111204.59505.bh_doc@users.sourceforge.net>
Brendon Higgins wrote:
>hdc: status error: status=0x7f { DriveReady DeviceFault SeekComplete
>DataRequest CorrectedError Index Error }
>
>
This looks weird. It's signalling a device fault *and * corrected error.
Jens ?
^ permalink raw reply
* Re: Is this going to be true ?
From: Serge Kuznetsov @ 2002-12-11 17:18 UTC (permalink / raw)
To: Joseph D. Wagner, linux-kernel
In-Reply-To: <001801c2a0a9$02613f40$2e863841@joe>
> 1) Future development of the Windows operating system or some of its
> components will be *BSD based. The Microsoft Corporation will never touch
> Linux. Period. The lawyers simply wouldn't allow it. The lawyers think of
> GNU GPL as an infectious disease, and so anything Linux is out of the
> question. The BSD license is far more favorable to proprietary development,
> since it allows you to close off the source. Hence, assimilating a *BSD
> structure, component, or piece of code is far more likely.
BTW, It explains me why M$ made server side CLI for FreeBSD, not Linux.
^ permalink raw reply
* Re: Is this going to be true ?
From: Dave Jones @ 2002-12-11 17:29 UTC (permalink / raw)
To: Serge Kuznetsov; +Cc: Joseph D. Wagner, linux-kernel
In-Reply-To: <072501c2a138$8365c2c0$9c094d8e@wcom.ca>
On Wed, Dec 11, 2002 at 12:12:41PM -0500, Serge Kuznetsov wrote:
> But why do you think Microsoft will come back to *nix lane?
> AFAIK, they closed their Xenix project back in 80s.
> Do you think they will resurrect it?
Is this really relevant to Linux-kernel ?
Please take this back to slashdot where it belongs.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Reliable hardware
From: Jason L Tibbitts III @ 2002-12-11 17:21 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1039626108.17702.64.camel@irongate.swansea.linux.org.uk>
>>>>> "AC" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
AC> The AMD duals have been a disaster in my experience.
I do have a bunch of these running reliably (RH 7.3 plus the latest
OpenMosix kernel). I had to go through a few combinations of
motherboard and RAM (four different manufacturers of RAM) before I got
something that works. Processors are MP 1900+ or 2000+, boards are
Tyan S2466, memory is in PC2100 ECC registered 512MB sticks from
Corsair. Case and power supply are PC Power and Cooling, mid tower,
450W PS, every fan bay filled. These machines have been rock
stable for months except for a failed IBM deathstar drive and an
over-temp shutdown when the room AC failed.
I still have a couple of the 760MP boards (as opposed to the MPX
boards) which I just can't get to run properly with two processors.
- J<
^ permalink raw reply
* Re: [Linux-ia64] a couple questions on pfmon-2.0
From: Stephane Eranian @ 2002-12-11 17:14 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805539@msgid-missing>
Ray,
On Tue, Dec 10, 2002 at 04:11:24PM -0600, Ray Bryant wrote:
> Stephane,
>
> There are both 2.0 and 2.0-1 versions mentioned in your note. Are these
> versions signifcantly different?? which one should we be using?
>
That's the same version. The -1 comes from RPM version number.
> WRT documentation -- this is great, much improved. One question I still
> had is the following: If I fork a child process, after calling
> pfm_initialize(), and, assuming we bind threads to processors in some
> fashion, do I need to call pfm_initialize() again in the child thread?
> What if the child thread is created by pthread_create()?
Yes, pfm_initialize() only needs to be called once per application. It
is used to autodetect the host PMU.
>
> My experience with this is that most routines have to be called on the
> thread (e. g. things that get or set PMU regs have to be called in the
> appropriate child process, whilst things like pfm_initialize() only need
> to be called in the parent thread). Is that correct at all?
>
> So I'm wondering if it would help in the documentation if you could
> distinguish between these two cases in some way. That would make it
> clearer (for me, at least). I'm not sure how to do this in a way that
> is independent of the way you started
> the threads though. Perhaps you can use the words "once per context" or
> some such.
>
The library is threadsafe. It is important to keep in mind that
the library NEVER invokes the perfmonctl() system call. As such, the library
functions can be called from anywhere, the master thread or worker threads.
The case of pfm_initialize() is kind of unique. What you see in pfmon is
just one way of using the library. For pfmon and in case of system wide
monitoring, all the CPUS monitor the same set of events, so we prepare
the arguments to the perfmonctl() once in the master thread and then we
simply use them in all the pinned worker threads. The CPU-specific information
is mostly in the pfarg_context_t argument which is not a library data structure
but a kernel structure.
> Or is this all covered someplace in the docs that I haven't found yet?
No, but I will make the clarification in the man pages.
--
-Stephane
^ permalink raw reply
* Re: Is this going to be true ?
From: Roy Sigurd Karlsbakk @ 2002-12-11 17:26 UTC (permalink / raw)
To: Serge Kuznetsov, Joseph D. Wagner, linux-kernel
In-Reply-To: <071a01c2a137$a8646460$9c094d8e@wcom.ca>
On Wednesday 11 December 2002 18:06, Serge Kuznetsov wrote:
> What I can say is what Linux kernel development outperforms
> M$-Windows development in timeline by many parameters.
>
> That what I know for sure.
>
> For this moment M$ have only nice and comfy GUI, but I hope it will change
> very soon.
You've had to have stood with your head in the sand for a few years not to see
that Microsoft actually has a good OS as well. Win2k _does_ have nice
features and runs fast. The main problem with comparing unices and Windoze,
is the question "What is an operating system"? Is the kernel the OS? Are the
libraries part of it as well? Is X part it? Windows has a good bunch of APIs
that quite a few userspace programmers love. Unices + libs + X don't have the
same abstraction as Windows has, resulting in longer, more low-level
development.
I don't like Windows, but saying there's nothing except the GUI doesn't make
you look smarter.
roy
--
Roy Sigurd Karlsbakk, Datavaktmester
ProntoTV AS - http://www.pronto.tv/
Tel: +47 9801 3356
Computers are like air conditioners.
They stop working when you open Windows.
^ permalink raw reply
* Re: IDE module problem
From: Maciej W. Rozycki @ 2002-12-11 17:20 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-mips
In-Reply-To: <20021211084914.A6755@mvista.com>
On Wed, 11 Dec 2002, Jun Sun wrote:
> > > This is because arch/mips/lib/Makefile says:
> > >
> > > obj-$(CONFIG_IDE) += ide-std.o ide-no.o
> > [...]
> > > 3) use some smart trick in Makefile so that we include those
> > > two files only if CONFIG_IDE is 'y' or 'm'. (How?)
> >
> > obj-$(CONFIG_IDE_MODULE)
>
> This does not work. Apparently, CONFIG_IDE_MODULE is not created
> for makefile part.
Indeed -- my fault. Variables such as $(CONFIG_IDE) are four-state and
for the module case they are simply set to "m". But then you can use
"ifeq ($(CONFIG_IDE),m)". Another approach is to invent an additional
variable automatically set to "y" whenever CONFIG_IDE is enabled.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Is this going to be true ?
From: Alvaro Lopes @ 2002-12-11 17:21 UTC (permalink / raw)
To: Serge Kuznetsov; +Cc: Joseph D. Wagner, linux-kernel
In-Reply-To: <072501c2a138$8365c2c0$9c094d8e@wcom.ca>
Serge Kuznetsov wrote:
>I totaly agree with you.
>
>But why do you think Microsoft will come back to *nix lane?
>AFAIK, they closed their Xenix project back in 80s.
>Do you think they will resurrect it?
>
>
I just remembered... what happened to SCO ? Isn't it still from Microsoft?
--
Álvaro Lopes
---------------------
A .sig is just a .sig
^ permalink raw reply
* [TRIVIAL] [PATCH] fix spelling mistake
From: John Bradford @ 2002-12-11 17:23 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-scsi
[-- Attachment #1: ASCII English text --]
[-- Type: text/plain, Size: 618 bytes --]
--- linux-2.4.20-pre1-orig/drivers/scsi/README.ncr53c8xx 2002-12-11 17:14:48.000000000 +0000
+++ linux-2.4.20-pre1/drivers/scsi/README.ncr53c8xx 2002-12-11 17:18:24.000000000 +0000
@@ -1025,7 +1025,7 @@
then it will for sure win the next SCSI BUS arbitration.
Since, there is no way to know what devices are trying to arbitrate for the
-BUS, using this feature can be extremally unfair. So, you are not advised
+BUS, using this feature can be extremely unfair. So, you are not advised
to enable it, or at most enable this feature for the case the chip lost
the previous arbitration (boot option 'iarb:1').
^ permalink raw reply
* Re: GDB patch
From: Nigel Stephens @ 2002-12-11 17:24 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Carsten Langgaard, Ralf Baechle, linux-mips
In-Reply-To: <20021211165218.GA11767@nevyn.them.org>
Daniel Jacobowitz wrote:
>>Certainly 'p' is the logical inverse of 'P', so we'll change our gdb
>>remote stub to use that. So how about accepting Carsten's change, with
>>the 'R' case removed, and 'r' changed to 'p'?
>>
>>
>
>Can't do it. I strongly suspect that it will render the stub unusable
>with current versions of FSF GDB. Your tools add an explicit size to
>the packet and the community tools do not; so when they probe for and
>discover the P packet, they will probably try to use it and get
>confused. That's why I'd like to discuss this on the GDB list first.
>
>
I don't see why it wouldn't work:
1) Existing FSF gdb doesn't use 'p' yet anyway - it will continue to
work as before, using the 'g' request to fetch all the registers.
2) If and when gdb does use 'p', then there's still no problem - if the
kernel gdb stub sees a 'p' request without the ":SIZE" extension, it can
just treat it like the FSF protocol and use the "default" register size.
Nigel
^ permalink raw reply
* Re: Malta board patch
From: Maciej W. Rozycki @ 2002-12-11 17:27 UTC (permalink / raw)
To: Jun Sun; +Cc: Carsten Langgaard, Ralf Baechle, linux-mips
In-Reply-To: <20021211090405.B6755@mvista.com>
On Wed, 11 Dec 2002, Jun Sun wrote:
> > irq = *(volatile u32 *)(KSEG1ADDR(BONITO_PCICFG_BASE));
> > + __asm__ __volatile__(
> > + ".set\tnoreorder\n\t"
> > + ".set\tnoat\n\t"
> > + "sync\n\t"
> > + ".set\tat\n\t"
> > + ".set\treorder");
> > irq &= 0xff;
> > BONITO_PCIMAP_CFG = 0;
> > break;
>
> Would a higher level macro such as __sync or fast_mb be better here?
Fixed by Ralf in the CVS already. :-)
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* [DUMB QUESTION] bonding. ethernet bonding.
From: Paul P Komkoff Jr @ 2002-12-11 17:38 UTC (permalink / raw)
To: Linux Kernel Mailing List
hmm. I'm very very unfamiliar with this thing. So when I first tried
to install it I downloaded latest bonding code against 2.4.20 from
sf.net/projects/bonding , patched my kernel with it and etc etc ...
... skipping ...
boot. ip ad flush dev eth{0,1}
modprobe bonding miimon=100
ip ad add myip/mymask brd + dev bond0
ifenslave bond0 eth0 eth1
ip li set bond0 up
switch on the other side (3com superstack 3) configured for trunking
on that 2 ports.
and then
ping $addr_on_local_net do nothing
hmm
tcpdump -i bond0 -vvv -n host $addr_on_local_net
will show me arp replies that $addr_on_local_net is on some
mac_address but
ip ne sh
will show that arp lookup is incomplete then failed
What's wrong?
Maybe other patches I've put in conflicting with this?
--
Paul P 'Stingray' Komkoff 'Greatest' Jr /// (icq)23200764 /// (http)stingr.net
When you're invisible, the only one really watching you is you (my keychain)
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Justin T. Gibbs @ 2002-12-11 17:31 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: James Bottomley, linux-scsi
In-Reply-To: <20021211153935.A23704@infradead.org>
>> > - fix kbuild integration
>>
>> Can you explain what failed before? I don't mind using aic7xxx-y
>> or aic79xx-y instead of *-obj, but I would like to understand what
>> bug this fixes.
>
> AIC79xx support could be selected without PCI beeing set, letting
> the makefile silently not build it
Okay. Sine the choice directive is now gone, is there a compelling reason
to put the "old" aic7xxx driver Kconfig directives in the same Kconfig
file as the new driver? It is kind of nice to have the separation since
Adaptec cannot support the old driver. I also take it that you were also
unable to make the choice directive do the right thing? That was the
original reason for removing the "old driver" Kconfig directives. The
way your patch stands now, I don't believe there is anything to prevent
both drivers from being compiled statically into the kernel. If so, the
resulting kernel will not boot.
--
Justin
^ permalink raw reply
* RE: 2.5 Changes doc update.
From: Holzrichter, Bruce @ 2002-12-11 17:38 UTC (permalink / raw)
To: 'Dave Jones', Linux Kernel
> IDE.
> ~~~~
> - Known problems with the current IDE code.
> o Simplex IDE devices (eg Ali15x3) are missing DMA sometimes
> o Serverworks OSB4 may panic on bad blocks or other non
> fatal errors
> o PCMCIA IDE hangs on eject
> o Most PCMCIA devices have unload races and may oops on eject
> o Modular IDE does not yet work, modular IDE PCI modules sometimes
> oops on loading
> o Silicon Image controllers give really bad performance currently.
>
FWIW to you, though I know this is mostly x86 centric, there are Endian
issues with current 2.5 IDE, and Big Endian machines such as sparc64 won't
work right now with IDE.
B.
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Jeff Garzik @ 2002-12-11 17:40 UTC (permalink / raw)
To: Rusty Russell; +Cc: jt, Linux kernel mailing list, Jeff Garzik, dahinds, davem
In-Reply-To: <20021211093007.B58402C093@lists.samba.org>
On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> In message <20021211010512.GA5853@bougret.hpl.hp.com> you write:
> > o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
> > down to the use of MOD_INC_USE_COUNT. The header file module.h give
> > hints on how I should convert that to the new world (use
> > try_module_get), however your FAQ seems to say something else (just
> > remove them, they are useless). I'm quite confused, because those
> > MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
> > guidance.
>
> Looking at these files:
>
> idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
> MOD_INC_USE_COUNT.
Incorrect but close: one uses SET_MODULE_OWNER(netdev) for this.
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Jean Tourrilhes @ 2002-12-11 17:43 UTC (permalink / raw)
To: Rusty Russell; +Cc: Linux kernel mailing list, Jeff Garzik, dahinds, davem
In-Reply-To: <20021211093007.B58402C093@lists.samba.org>
On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> In message <20021211010512.GA5853@bougret.hpl.hp.com> you write:
> > Hi,
>
> Hi Jean!
>
> Thanks for the report.
Yes, for a change I'm trying to be helpful ;-)
> > Debian Boot :
> > -----------
> > o Din't pick up new modutils in the init scripts. Probably
> > because I used install option 1b in README (/usr/local/sbin).
> > o Re-install with option 1a (/sbin), works fine.
> > o Maybe this needs to be in README.
>
> Debian have picked up the module-init-tools, so although they're a bit
> lagged as I type this, I expect this to become a less common occurrance.
I'm using stable, which mean that I'm lagging behind Debian...
> > Pcmcia and airo_cs :
> > ------------------
> > o Loads with error below, airo_cs driver is functional.
> > o i82365 cannot be unloaded, it's unsafe.
> > o removal of airo_cs : "Uninitialised timer!/nThis is a
> > warning. Your computer is OK". Call trace on demand. Also, the module
> > airo not removed (probably due to problem with airo_cs).
>
> That, in itself, should be harmless.
Yes, but this is new and I don't really like it. I suspect
something is wrong in the Pcmcia code itself. Last I tried was 2.5.46
and I see some suspicious init_timer() added where I would not expect,
and some missing where they would be needed.
Hum... Who is in charge ?
> > o re-insertion of the card : nothing happens. No messages.
> > o After reboot, /etc/init.d/pcmcia stop -> same thing + script
> > hang + a few [kmodule1? <defunct>]. This prevent the computer to
> > reboot or shutdown properly (== fsck at next boot).
>
> Wierd. The PCMCIA scripts make assumptions about layout of
> /lib/modules/`uname -r` which was broken by the removal of the
> directory hierarchy. It's not the only thing (mkinitrd also wants
> this). While relying on the layout of the kernel source tree is
> broken, no better alternatives have some up, so this is queued to be
> reverted once I test that it doesn't break the current tools (which
> *should* handle it).
I personally believe the timer thingy is important and cause
of problems.
> There is a known bug where an *old* rmmod will hang (it has the effect
> of "rmmod --wait": I have a patch to differentiate the two
> effectively, but it requires everyone to upgrade to 0.9 or above,
> which they have probably done by now).
> > o af_irda, irda-usb & irtty-sir are "unsafe". I tracked that
> > down to the use of MOD_INC_USE_COUNT. The header file module.h give
> > hints on how I should convert that to the new world (use
> > try_module_get), however your FAQ seems to say something else (just
> > remove them, they are useless). I'm quite confused, because those
> > MOD_INC_USE_COUNT have a definite purpose... I would appreciate more
> > guidance.
>
> Looking at these files:
>
> idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
> MOD_INC_USE_COUNT.
This was the easy one.
> irtty-sir.c: The ldisc code needs an owner field, and it needs to use
> it. Until then, this warning is best left where it is.
Ok.
> af_irda: The caller needs to do something here, too. Dave?
Ok.
> Rusty.
Thanks a lot !
Jean
^ permalink raw reply
* Re: Re: [2.5.50, ACPI] link error
From: James D Strandboge @ 2002-12-11 17:35 UTC (permalink / raw)
To: ACPI mailing list
In-Reply-To: <1039622414.17702.29.camel-MMxVpc8zpTQVh3rx8e9g/fyykp6/JSeS3vcXtXqGYxw@public.gmane.org>
On Wed, 2002-12-11 at 11:00, Alan Cox wrote:
> On Wed, 2002-12-11 at 10:14, Ducrot Bruno wrote:
> > No. You are wrong. I need to suspend allmost all the drivers, and the
> > video chipset is not an execption (or go to a console before suspending,
> > in fact).
> > You still need to bug NVIDIA in order to have proper pm support
> > in their driver.
>
> To an extent. However you can also switch back to text mode on suspend
> to disk, then resume back into text mode and effectively switch back
> into X11
>
I have done exactly this when closing my lid (cause the screen blanks
and when it comes back, it is messed up). It can be completely
automated with scripts for acpid, so this effectively becomes a
non-issue.
Jamie Strandboge
--
Email: jstrand1-aYIB8uWIUb2Vn7q6wjsIow@public.gmane.org
GPG/PGP ID: 26384A3A
Fingerprint: D9FF DF4A 2D46 A353 A289 E8F5 AA75 DCBE 2638 4A3A
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [parisc-linux] another kernel compilation error
From: Grant Grundler @ 2002-12-11 17:37 UTC (permalink / raw)
To: Tim Kemna; +Cc: parisc-linux
In-Reply-To: <006e01c2a11c$71745200$4fe85982@kabel.utwente.nl>
On Wed, Dec 11, 2002 at 02:51:44PM +0100, Tim Kemna wrote:
> I'm trying to compile a kernel, version 2.4.20-pa13. But I get the following
> error:
...
> drivers/char/char.o: In function `hp_diva_check':
> drivers/char/char.o(.text.hp_diva_check+0x60): undefined reference to
> `rs_interrupt'
Maybe you don't have CONFIG_PCI=y/CONFIG_SERIAL_SHARE_IRQ=y?
grant
^ permalink raw reply
* Re: watch exception only for kseg0 addresses..?
From: Maciej W. Rozycki @ 2002-12-11 17:38 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <20021211165854.GA12223@nevyn.them.org>
On Wed, 11 Dec 2002, Daniel Jacobowitz wrote:
> That way we expose more of the hardware to userland; and the thing
> that's most important to me is that GDB not have to know if it's on a
> MIPS32 or an R4650 when determining how watchpoints work.
> IWatch/DWatch are two particular watchpoints or distinguished by access
> type? I.E. what would GDB need to know to know which it is setting?
The watchpoints would always be interfaced the same way, regardless of
the underlying implementation, of course. For the IWatch/DWatch, I'd
assign their numbers somehow (e.g. IWatch is watchpoint #0 and DWatch is
#1, following the sequence used for their CP0 register numbers). A user
such as GDB would have to determine the capabilities of all watchpoints as
I described and would discover that watchpoint #0 only accepts instruction
fetch events and watchpoint #1 only accepts data read/write ones.
This way we can accept an arbitrary underlying implementation.
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
^ permalink raw reply
* Re: Linux 2.4.21-pre1
From: Petr Vandrovec @ 2002-12-11 17:51 UTC (permalink / raw)
To: Alan Cox; +Cc: lkml, andre, ralf.hildebrandt
On 11 Dec 02 at 17:29, Alan Cox wrote:
> Ok this seems to be the problem
>
> 00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) (prog-if
> 8a [Master SecP PriP])
> Subsystem: Toshiba America Info Systems: Unknown device 0001
> 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
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at cff8 [size=8]
> Region 1: I/O ports at cff4 [size=4]
> Region 2: I/O ports at cfe8 [size=8]
> Region 3: I/O ports at cfe4 [size=4]
>
>
> The hardware isnt at the normal ide base addresse, yet the chip is
> reporting that it isnt in native mode. As far as I can see this
> configuration isnt allowed.
An old, pre-BMDMA, "PCI IDE Controller Specification, rev 1.0, 3/4/94"
I have here says on page 3, in chapter 2.4, second and third paragraphs say:
--
When a channel is in 'compatibility' mode, the controller can either
disable the first four Base Address registers (i.e.; make them not
writable and return 0's when read) or leave them fully programmable. In
either case the values in these registers are ignored as long as the
channel is in 'compatibility' mode.
When a channel is in compatibility mode the IRQ used by the channel
must be the 'compatibility' IRQ. PCI interrupt lines must not be effected
by that channel's interrupt. Conversely, when the channel is in native-PCI
mode the channel's interrupt should be connected to the appropriate INTx#.
Compatibility IRQs should not be effected (i.e.; they should be tristated).
--
> We see that the chip isnt in native mode so we defer to the legacy
> scanner. Since the ports are not valid the legacy scanner doesn't find
> them.
>
> Any thoughts on how we should handle this case Andre ?
We should ignore BARs (and reported INT#) when chip is not in native mode,
but I'm sure that it breaks something else (note that I do not know any
chip which honors BARs when using compatible mode; only problematic piece
of hardware I know is PDC20265, but this one does not report itself
as IDE hardware, so for this chip we have special cases in the code already;
maybe VIA uses IRQ number specified in PCI config space instead of
14/15?).
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply
* Help...
From: manish @ 2002-12-11 17:45 UTC (permalink / raw)
To: netfilter
Hello
Its really nice to see a detail information about NAT
in Linux 2.4 NAT HOWTO.It works well but i have a
small problem, i m not able to connect to voice from
my internal LAN to the internet. I am giving you the
details, which will help you to understand my problem.
A----------B----------C
|
|
|
D
Here A is my windows client with IP address
192.168.101.1 Mask 255.255.0.0
Here B is my Linux7.3 Server with IP address
192.168.0.1 Mask 255.255.0.0
B is also connected to Internet with Generic Serial
Modem (ppp0).
Here C is my windows client with IP address
192.168.101.3 Mask 255.255.0.0
Here D is my Linux client with IP address 192.168.80.1
Mask 255.255.0.0.
I am sharing internet to all my client i.e A, C and D.
using this command.
> iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
# Turn on the IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
Upto this everything works fine all clients (A, C, D)
share internets.
Now if i wanted to start any chat services i.e Yahoo
Messenger or vat tool the person who has logged on
from A not able to use audio chat to person
logged on from C or D.
or even a person who is also online from out of this
network also not able to call or do voice chat.
# I had use this command after that
> iptables -t nat -A PREROUTING -i ppp0 -j DNAT
--to-destination 192.168.101.3
This time i am able to call people from outside from
machine C (192.168.101.3) and also able to do voice
conversation in vat. But another side A and D are not
able to talk to that person outside the network. Also
the above command will not for other hosts A and D. At
a time only one machine is able to make a vat
connection from B.
1) What should i do so A, C, and D all together can
use to call outside and able to do voice conversation
in vat?
2) what should i do so A can talk to B in yahoo or vat
voice chat?
please let me know that is there any solution for my
problem?
Thanks
Regards.
Manish.
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ permalink raw reply
* Re: 2.5 Changes doc update.
From: Roger Luethi @ 2002-12-11 17:54 UTC (permalink / raw)
To: Dave Jones, Linux Kernel
In-Reply-To: <20021211172559.GA8613@suse.de>
On Wed, 11 Dec 2002 17:25:59 +0000, Dave Jones wrote:
> - A backwards compatable set of module utilities is available
> including v0.7 of the new-style utils in source RPM format from
> http://www.kernel.org/pub/linux/kernel/people/rusty/modules/modutils-2.4.21-5.src.rpm
That release was not backwards compatible. This one is:
http://www.kernel.org/pub/linux/kernel/people/rusty/modules/modutils-2.4.21-7.src.rpm
Roger
^ permalink raw reply
* Re: patch for aty128fb.c
From: Benjamin Herrenschmidt @ 2002-12-11 18:01 UTC (permalink / raw)
To: James Simmons; +Cc: Paul Mackerras, linux-kernel
In-Reply-To: <Pine.LNX.4.33.0212110635110.2617-100000@maxwell.earthlink.net>
On Wed, 2002-12-11 at 15:42, James Simmons wrote:
>
> > Currently it can only put one rage 128 chip to sleep, but that is ok
> > for now since I've never seen a laptop with two rage 128 chips yet. :)
> > The generic device model will ultimately give us a better way to
> > handle sleep/wakeup.
>
> Actually I started to looking into doing that. I noticed struct
> pci_driver having a resume and suspend function. Is this related? I just
> started to looking into the new PM code.
It's +/- related, but pls don't play with that now, I need to dig into
it in much details myself, I don't think I'll use the pci callbacks
anyway.
Ben.
^ permalink raw reply
* [TRIVIAL PATCH] remove warnings/errors from arch/i386/kernel/suspend_asm.S
From: Andy Pfiffer @ 2002-12-11 17:57 UTC (permalink / raw)
To: pavel; +Cc: linux-kernel@vger.kernel.org
Some earlier versions of gas (2.10.91 specifically) will error out on
the "movw %eax,%ds" in arch/i386/kernel/suspend_asm.S. gas 2.11.92
complains but continues.
Here is a trivial patch that eliminates two warnings.
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.865 -> 1.866
# arch/i386/kernel/suspend_asm.S 1.2 -> 1.3
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/11 andyp@joe.pdx.osdl.net 1.866
# Correct syntax to remove assembler warnings and errors.
# --------------------------------------------
#
diff -Nru a/arch/i386/kernel/suspend_asm.S b/arch/i386/kernel/suspend_asm.S
--- a/arch/i386/kernel/suspend_asm.S Wed Dec 11 09:51:22 2002
+++ b/arch/i386/kernel/suspend_asm.S Wed Dec 11 09:51:22 2002
@@ -6,7 +6,7 @@
#include <asm/segment.h>
#include <asm/page.h>
-ENTRY(do_magic):
+ENTRY(do_magic)
pushl %ebx
cmpl $0,8(%esp)
jne .L1450
@@ -66,7 +66,7 @@
.L1453:
movl $104,%eax
- movw %eax, %ds
+ movw %ax, %ds
movl saved_context_esp, %esp
movl saved_context_ebp, %ebp
movl saved_context_eax, %eax
@@ -88,4 +88,4 @@
loop2:
.quad 0
.previous
-
\ No newline at end of file
+
^ permalink raw reply
* Re: 2.5 Changes doc update.
From: Jeff Garzik @ 2002-12-11 17:58 UTC (permalink / raw)
To: Dave Jones, Linux Kernel
In-Reply-To: <20021211172559.GA8613@suse.de>
On Wed, Dec 11, 2002 at 05:25:59PM +0000, Dave Jones wrote:
> Kernel build system.
> ~~~~~~~~~~~~~~~~~~~~
> - Versus 2.4, the build system has been much improved.
> You should notice quicker builds, and less spontaneous rebuilds
> of files on subsequent builds from already built trees.
> - make xconfig now requires the qt libraries.
> - Make menuconfig/oldconfig has no user-visible changes other than speed,
> whilst numerous improvements have been made.
> - Several new debug targets exist: 'allyesconfig' 'allnoconfig' 'allmodconfig'.
> - For infomation: The above improvements are not CML2 / kbuild-2.5 related.
I think the coolest things (to me) of the new build system need to be
noted too,
- "make" is now the preferred target; it does <arch-zimage> and modules.
- "make -jN" is now the preferred parallel-make execution. Do not
bother to provide "MAKE=xxx".
^ 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.