* Re: EISA ID for PnP modem and resource allocation
From: Adam Belay @ 2004-01-26 19:22 UTC (permalink / raw)
To: Amit Gurdasani; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.56.0401051713370.4783@athena.localdomain>
On Mon, Jan 05, 2004 at 05:23:27PM +0400, Amit Gurdasani wrote:
> On Sun, 4 Jan 2004, Russell King wrote:
>
> :On Mon, Dec 29, 2003 at 10:50:37PM +0000, Adam Belay wrote:
> :> > ttyS0 at I/O 0x3f8 (irq = 0) is a 16550A
> :> > ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> :> > ttyS2 at I/O 0x3e8 (irq = 4) is a 16550A
> :> > parport0: irq 7 detected
> :>
> :> Hmm, it shouldn't be reporting irq 0. The probbing code may be confused.
> :> I would guess it is on irq 4.
> :
> :irq0 on x86 means "I'll use polled mode".
It occured to me that we should probably check which resources the pnpbios is
reporting. If you have a chance, could you please show me the output of this
hack.
Thanks,
Adam
--- a/drivers/serial/8250_pnp.c 2004-01-23 15:05:39.000000000 +0000
+++ b/drivers/serial/8250_pnp.c 2004-01-26 19:10:34.000000000 +0000
@@ -32,6 +32,8 @@
#define UNKNOWN_DEV 0x3000
+#define SERIAL_DEBUG_PNP 1
+
static const struct pnp_device_id pnp_dev_table[] = {
/* Archtek America Corp. */
@@ -402,8 +404,8 @@
if (HIGH_BITS_OFFSET)
serial_req.port = pnp_port_start(dev, 0) >> HIGH_BITS_OFFSET;
#ifdef SERIAL_DEBUG_PNP
- printk("Setup PNP port: port %x, irq %d, type %d\n",
- serial_req.port, serial_req.irq, serial_req.io_type);
+ printk("Setup PNP port: port %x, irq %d, type %d, pnp_node %x\n",
+ serial_req.port, serial_req.irq, serial_req.io_type, dev->number);
#endif
serial_req.flags = ASYNC_SKIP_TEST | ASYNC_AUTOPROBE;
^ permalink raw reply
* Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344
From: Willem Riede @ 2004-01-27 0:32 UTC (permalink / raw)
To: linux-scsi
For additional fun shaking bugs out of ide-scsi, I dusted of my old
PD/CD drive (retired years ago in favor of a CD Writer).
Besides having to set host->max_lun = 2; in idescsi_attach() to
have both luns of this device detected:
Jan 26 17:13:23 fallguy kernel: scsi6 : SCSI host adapter emulation for IDE ATAPI devices
Jan 26 17:13:23 fallguy kernel: Vendor: NEC Model: PD-1 ODX654P Rev: A111
Jan 26 17:13:23 fallguy kernel: Type: CD-ROM ANSI SCSI revision: 02
Jan 26 17:13:23 fallguy kernel: sr1: scsi3-mmc drive: 6x/6x xa/form2 cdda tray
Jan 26 17:13:23 fallguy kernel: Vendor: NEC Model: PD-1 ODX654P Rev: A111
Jan 26 17:13:23 fallguy kernel: Type: Optical Device ANSI SCSI revision: 02
Jan 26 17:13:23 fallguy kernel: SCSI device sdc: 1298496 512-byte hdwr sectors (665 MB)
Jan 26 17:13:23 fallguy kernel: sdc: Write Protect is off
Jan 26 17:13:23 fallguy kernel: SCSI device sdc: drive cache: write back
I get a bunch of the following warning:
Jan 26 17:13:23 fallguy kernel: Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344
Jan 26 17:13:23 fallguy kernel: Call Trace:
Jan 26 17:13:23 fallguy kernel: [<e0850192>] scsi_single_lun_run+0x202/0x230 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e084a33d>] scsi_put_command+0xbd/0x160 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e0850347>] scsi_run_queue+0x187/0x190 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e0850524>] scsi_end_request+0xf4/0x150 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e08508f7>] scsi_io_completion+0x1c7/0x4b0 [scsi_mod]
Jan 26 17:13:23 fallguy kernel: [<e0829a32>] sd_rw_intr+0x82/0x260 [sd_mod]
Jan 26 17:13:24 fallguy kernel: [<e084aed1>] scsi_finish_command+0x81/0xe0 [scsi_mod]
Jan 26 17:13:24 fallguy kernel: [<e084ade8>] scsi_softirq+0xc8/0xf0 [scsi_mod]
Jan 26 17:13:24 fallguy kernel: [<c012d6a7>] do_softirq+0xc7/0xd0
Jan 26 17:13:24 fallguy kernel: [<c010e395>] do_IRQ+0x165/0x220
Jan 26 17:13:24 fallguy kernel: [<c011c04d>] smp_apic_timer_interrupt+0xdd/0x150
Jan 26 17:13:24 fallguy kernel: [<c010c21c>] common_interrupt+0x18/0x20
Jan 26 17:13:24 fallguy kernel: [<c01089f0>] default_idle+0x0/0x40
Jan 26 17:13:24 fallguy kernel: [<c0108a19>] default_idle+0x29/0x40
Jan 26 17:13:24 fallguy kernel: [<c0108aab>] cpu_idle+0x3b/0x50
Jan 26 17:13:24 fallguy kernel: [<c0128f80>] printk+0x180/0x260
Jan 26 17:13:24 fallguy kernel:
Most are similar from do_IRQ up, io_completion called from sd_rw_intr or (sr) rw_intr,
which make its way to scsi_single_lun_run. (I don't understand why scsi_put_command
shows up, I believe it should be scsi_end_request -> scsi_next_request -> scsi_run_queue
-> scsi_single_lun_run.
One is different, don't know if that's a fluke (kernel log buffer overrun?) or evidence
of a rogue path...
Jan 26 17:14:12 fallguy kernel: Badness in scsi_single_lun_run at /root/scsi/scsi_lib.c:344
Jan 26 17:14:12 fallguy kernel: Call Trace:
Jan 26 17:14:12 fallguy kernel: [<e0850192>] scsi_single_lun_run+0x202/0x230 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084a33d>] scsi_put_command+0xbd/0x160 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e0850347>] scsi_run_queue+0x187/0x190 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084fd01>] scsi_wait_req+0xa1/0xb0 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084fb90>] scsi_wait_done+0x0/0xd0 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084a02e>] scsi_allocate_request+0x2e/0x70 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084bf7d>] ioctl_internal_command+0x6d/0x200 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e084c17f>] scsi_set_medium_removal+0x6f/0xa0 [scsi_mod]
Jan 26 17:14:12 fallguy kernel: [<e0829602>] sd_release+0x72/0x90 [sd_mod]
Jan 26 17:14:12 fallguy kernel: [<c0176b54>] blkdev_put+0x214/0x260
Jan 26 17:14:12 fallguy kernel: [<c016d60a>] __fput+0x10a/0x120
Jan 26 17:14:12 fallguy kernel: [<c016b7a9>] filp_close+0x59/0x90
Jan 26 17:14:13 fallguy kernel: [<c016b85f>] sys_close+0x7f/0x100
Jan 26 17:14:13 fallguy kernel: [<c010b8af>] syscall_call+0x7/0xb
Jan 26 17:14:13 fallguy kernel:
Somehow it appears that io completion sometimes happens twice without
current_sdev->sdev_target->starget_sdev_user being set to a new owner so
that the WARN_ON(!current_sdev->sdev_target->starget_sdev_user) triggers...
(I have proven to my satisfaction that no path exists that can set
current_sdev->sdev_target->starget_sdev_user to NULL to cause this).
Setting starget_sdev_user happens in scsi_request_fn(). Do any paths exist
that start io that don't use it?
Probably to simple minded to suspect the request sense following a command that
reports "Check Condition"?
Ideas of where to look next appreciated.
Thanks, Willem Riede.
^ permalink raw reply
* [Kernel-janitors] reviewing KJ patches
From: Randy.Dunlap @ 2004-01-27 0:30 UTC (permalink / raw)
To: kernel-janitors
It sure would help if someone other than me was reviewing some
kernel-janitors patches .... :(
Yes, there is an occasional comment, usually about style.
And those are fine, but patches often affect correctness also,
and I don't see many comments about those.
--
~Randy
kernel-janitors project: http://janitor.kernelnewbies.org/
[I know that Willy has been away for 2 weeks. :]
_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
http://lists.osdl.org/mailman/listinfo/kernel-janitors
^ permalink raw reply
* Adding Fonts in SuSE Linux?
From: Dave @ 2004-01-27 0:29 UTC (permalink / raw)
To: linux-newbie
How does Linux handle fonts? Can I install True Type Fonts like the
ones I use in Win... (Sorry...) that inferior OS?
Dave
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"So many electrons and so little time!!"
73 K6DBH Dave
Also at, K6DBH@ARRL.net
. .
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
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: kernel BUG at include/linux/list.h:148!
From: David Martínez Moreno @ 2004-01-27 0:24 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, ender
In-Reply-To: <20040126161615.143b23b2.akpm@osdl.org>
El Martes, 27 de Enero de 2004 01:16, Andrew Morton escribió:
> Someone else was seeing something similar. Reverting
>
>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm1/broken-out/sysfs-pin-kobject.patch
>
> apparently fixed it.
Andrew, thank you very much for your prompt response.
I'll try tomorrow, as it seemed to had hung and I need to go to the
university to reboot it.
Have you kicked it out of your next release? I see that is into
2.6.2-rc1-mm3.
Anyway I'll take a look and will report to you.
Thanks again,
Ender.
--
Network engineer
Debian developer
^ permalink raw reply
* [Bridge] web site update
From: Stephen Hemminger @ 2004-01-27 0:28 UTC (permalink / raw)
To: bridge
The data on the bridge http://bridge.sourceforge.net
web site was getting out of date. So I did a
cleanup rewrite of the info. The main changes are:
* adding a howto that is up to date with 2.4/2.6
* removing all the 2.2 related info since the
2.2 patches are no longer supported (at least by me).
Any comments or feedback would be appreciated.
Expect the following in the next couple weeks:
- better info about Spanning Tree Protocol (STP)
- new version of bridge-utilities; better error handling
- pre-built packages of new utilities for Fedora Core-1
and SuSe 9.
^ permalink raw reply
* iniquitous newcomer childbirth huber shame
From: Ida Smith @ 2004-01-27 0:28 UTC (permalink / raw)
To: netdev; +Cc: cvs
[-- Attachment #1: Type: text/plain, Size: 172 bytes --]
earn reid exchange knowledgeable hines draft dip hail inequitable
confiscate recusant escalate inspire dictionary
hippocrates aborning hundredth minus elan footpad cady
[-- Attachment #2: Type: text/html, Size: 2893 bytes --]
^ permalink raw reply
* Re: latest 2.6 patch for dpt_i20 driver
From: Karen Shaeffer @ 2004-01-27 0:25 UTC (permalink / raw)
To: Jasper Slits; +Cc: linux-scsi
In-Reply-To: <20040126120908.GA40438@xs4all.nl>
On Mon, Jan 26, 2004 at 01:09:09PM +0100, Jasper Slits wrote:
> I managed to get dpt_i2o working with kernel 2.6.1-rc2.
>
> First of it all, it's still risky to do it. But here is how:
>
> get Mark's patch ->
> http://marc.theaimsgroup.com/?l=linux-scsi&m=107210932819564&w=2
>
> Hack the ./drivers/scsi/dpt_i2o.c and remove all references to the
> access_count member.
Thanks for your comments.
I actually got the latest patch from Mark over at Adaptec. This patch wraps
all the access_count references in ifdefs, so I didn't have to make any
modifications. It compiled and runs as is.
Thanks again,
Karen
--
Karen Shaeffer
Neuralscape, Palo Alto, Ca. 94306
shaeffer@neuralscape.com http://www.neuralscape.com
^ permalink raw reply
* Re: Is there a way to keep the 2.6 kjournald from writing to idle disks? (to allow spin-downs)
From: bill davidsen @ 2004-01-27 0:21 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20040125205219.GE26600@luna.mooo.com>
In article <20040125205219.GE26600@luna.mooo.com>,
Micha Feigin <michf@post.tau.ac.il> wrote:
| There are two things to do. First you should mount the disk with the
| noatime option.
Hopefully on an idle system there isn't any access, so there isn't any
atime impact. It would be nice if the atime write was very lazy, as in
only when the file is closed or something. Like an atimeonclose option.
| The other thing is ext3 which is updating its journal every 5
| seconds. I was told that laptop-mode was imported into 2.6 by now (I
| think that it is in the main stream). Check the kernel docs there
| should be some mount option to state the dirty time for the ext3
| journal. The method changed since 2.4 so I don't remember the 2.6
| option since I don't use it yet, sorry.
Someone will have to explain that one, in a normal mount I would not
expect an idle system to be doing anything on the filesystems.
--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
^ permalink raw reply
* RE: [ANNOUNCE] Cooperative Linux
From: David Schwartz @ 2004-01-27 0:20 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0401260632040.26321-100000@chimarrao.boston.redhat.com>
> On Mon, 26 Jan 2004, JustFillBug wrote:
> > How about a bare bone OS whose sole purpose is to run multiple OS on top
> > of it? A pure VM OS.
> It's easier if that OS is Linux, so we can reuse all the
> device drivers.
I would love to see code for Linux to allow you to create any number of VMs
with various configurable combinations of emulated hardware. Vmware is
extremely inflexible. Are there any projects under way to do that?
DS
^ permalink raw reply
* Re: [PATCH 2.6.2-rc1-mm3] fs/xfs/xfs_log_recover.c
From: Nathan Scott @ 2004-01-27 0:19 UTC (permalink / raw)
To: Bryan Whitehead; +Cc: linux-kernel
In-Reply-To: <20040126234159.GD781@frodo>
On Tue, Jan 27, 2004 at 10:41:59AM +1100, Nathan Scott wrote:
> On Sat, Jan 24, 2004 at 08:48:59PM -0800, Bryan Whitehead wrote:
> > On compile I get this:
> >
> > fs/xfs/xfs_log_recover.c: In function `xlog_recover_reorder_trans':
> > fs/xfs/xfs_log_recover.c:1534: warning: `flags' might be used uninitialized in this function
> >
> > I previously sent this patch and it was wrong.
>
> What compiler version are you using? Is this a recent gcc or an
Sorry, I'm still half a sleep -- I see this too with the recent
fix in this routine, looks like many current gcc versions report
it. I guess initialising flags to zero will be the simplest way
to workaround it.
thanks.
--
Nathan
^ permalink raw reply
* Updates config files
From: Marco d'Itri @ 2004-01-27 0:19 UTC (permalink / raw)
To: linux-hotplug
[-- Attachment #1: Type: text/plain, Size: 306 bytes --]
I believe these are reasonably complete for a normal system, with the
exception of scsi-devfs.sh which still needs a lot of work.
BTW, ide-devfs.sh is broken because it populates discs/ and cdroms/
without checking if the SCSI script already created links there.
--
ciao, |
Marco | [4326 inK/P7I0FuS4s]
[-- Attachment #2: udev.permissions --]
[-- Type: text/plain, Size: 2002 bytes --]
# name:user:group:mode
# character devices
ptmx:root:tty:0666
random:root:root:0666
urandom:root:root:0444
kmem:root:kmem:0640
mem:root:kmem:0640
port:root:kmem:0640
null:root:root:0666
zero:root:root:0666
full:root:root:0666
misc/rtc:root:audio:0660
tts/*:root:dialout:0660
rfcomm/*:root:dialout:0660
tty[BCDEFHILMPRSTUVWX][0-9]*:root:dialout:0660
ttyS[ACIR][0-9]*:root:dialout:0660
ttyUSB[0-9]*:root:dialout:0660
ttyACM[0-9]*:root:dialout:0660
ippp[0-9]*:root:dialout:0660
isdn[0-9]*:root:dialout:0660
isdnctrl[0-9]*:root:dialout:0660
capi[0-9.]*:root:dialout:0660
dcbri[0-9]*:root:dialout:0660
ircomm[0-9]*:root:dialout:0660
snd/*:root:audio:0660
sound/*:root:audio:0660
admmidi*:root:audio:0660
adsp*:root:audio:0660
aload*:root:audio:0660
amidi*:root:audio:0660
amixer*:root:audio:0660
audio*:root:audio:0660
dmfm*:root:audio:0660
dsp*:root:audio:0660
audio*:root:audio:0660
mixer*:root:audio:0660
music:root:audio:0660
sequencer*:root:audio:0660
printers/*:root:lp:0660
usb/lp[0-9]*:root:lp:0660
lp[0-9]*:root:lp:0660
parport[0-9]*:root:lp:0660
irlpt[0-9]*:root:lp:0660
usblp[0-9]*:root:lp:0660
input/*:root:root:0644
js:root:root:0644
djs:root:root:0644
dri/card[0-9]*:root:video:0660
fb/*:root:video:0620
agpgart:root:video:0660
v4l/*:root:video:0660
video[0-9]*:root:video:0660
radio[0-9]*:root:video:0660
vbi[0-9]*:root:video:0660
vtx[0-9]*:root:video:0660
# block devices
floppy/*:root:floppy:0660
fd[0-9]*:root:floppy:0660
ram[0-9]*:root:disk:0660
raw/*:root:disk:0660
ide/*:root:disk:0660
hd[a-s][0-9]*:root:disk:0660
scsi/*:root:disk:0660
sd[a-z][0-9]*:root:disk:0660
sd[a-i][a-z][0-9]*:root:disk:0660
s[grt][0-9]*:root:disk:0660
scd[0-9]*:root:cdrom:0660
dasd[0-9]*:root:disk:0660
ataraid[0-9]*:root:disk:0660
loop/*:root:disk:0660
loop[0-9]*:root:disk:0660
md/*:root:disk:0660
md[0-9]*:root:disk:0660
dm-*:root:disk:0640
ht[0-9]*:root:tape:0660
nht[0-9]*:root:tape:0660
pt[0-9]*:root:tape:0660
npt[0-9]*:root:tape:0660
st[0-9]*:root:tape:0660
nst[0-9]*:root:tape:0660
[-- Attachment #3: udev.rules --]
[-- Type: text/plain, Size: 3542 bytes --]
# There are a number of modifiers that are allowed to be used in some
# of the different fields. They provide the following subsitutions:
# %n - the "kernel number" of the device.
# For example, 'sda3' has a "kernel number" of '3'
# %k - the kernel name for the device.
# %M - the kernel major number for the device
# %m - the kernel minor number for the device
# %b - the bus id for the device
# %c - the string returned by the PROGRAM. (Note, this doesn't work within
# the PROGRAM field for the obvious reason.)
# %% - the '%' char itself.
#
# IDE block devices
BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
# SCSI block devices
BUS="scsi", KERNEL="sd[a-z][0-9]*", PROGRAM="/etc/udev/scsi-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
BUS="scsi", KERNEL="sd[a-i][a-z][0-9]*", PROGRAM="/etc/udev/scsi-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
BUS="scsi", KERNEL="s[grt][0-9]*", PROGRAM="/etc/udev/scsi-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
BUS="scsi", KERNEL="scd[0-9]*", PROGRAM="/etc/udev/scsi-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
BUS="scsi", KERNEL="st[0-9]*", PROGRAM="/etc/udev/scsi-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
BUS="scsi", KERNEL="nst[0-9]*", PROGRAM="/etc/udev/scsi-devfs.sh %k %b %n", NAME="%1c", SYMLINK="%k %2c"
# block devices
KERNEL="md[0-9]*", NAME="md/%n", SYMLINK="%k"
KERNEL="loop[0-9]*", NAME="loop/%n" #, SYMLINK="%k"
# tty devices
KERNEL="tty[0-9]*", NAME="vc/%n"
KERNEL="ttyS[0-9]*", NAME="tts/%n"
KERNEL="ttyUSB[0-9]*", NAME="tts/USB%n"
# vc devices
KERNEL="vcs", NAME="vcc/0"
KERNEL="vcs[0-9]*", NAME="vcc/%n"
KERNEL="vcsa", NAME="vcc/a0"
KERNEL="vcsa[0-9]*", NAME="vcc/a%n"
# v4l devices
KERNEL="video0", NAME="v4l/video%n", SYMLINK="video"
KERNEL="video[0-9]*", NAME="v4l/video%n"
KERNEL="radio0", NAME="v4l/radio%n", SYMLINK="radio"
KERNEL="radio[0-9]*", NAME="v4l/radio%n"
KERNEL="vbi0", NAME="v4l/vbi%n", SYMLINK="vbi"
KERNEL="vbi[0-9]*", NAME="v4l/vbi%n"
KERNEL="vtx0", NAME="v4l/vtx%n", SYMLINK="vtx"
KERNEL="vtx[0-9]*", NAME="v4l/vtx%n"
# misc devices
KERNEL="apm_bios", NAME="misc/apm_bios", SYMLINK="apm_bios"
KERNEL="agpgart", NAME="misc/agpgart", SYMLINK="agpgart"
KERNEL="psaux", NAME="misc/psaux" #, SYMLINK="psaux"
KERNEL="rtc", NAME="misc/rtc", SYMLINK="rtc"
KERNEL="card[0-9]*", NAME="dri/card%n"
KERNEL="i2c-[0-9]*", NAME="i2c/%n"
KERNEL="ram[0-9]*", NAME="rd/%n" #, SYMLINK="%k"
KERNEL="lp[0-9]*", NAME="printers/%n"
# sound devices
KERNEL="controlC[0-9]*", NAME="snd/%k"
KERNEL="hw[CD0-9]*", NAME="snd/%k"
KERNEL="pcm[CD0-9cp]*", NAME="snd/%k"
KERNEL="midi[CD0-9]*", NAME="snd/%k"
KERNEL="timer", NAME="snd/%k"
KERNEL="seq", NAME="snd/%k"
KERNEL="audio*", NAME="sound/%k"
KERNEL="dsp*", NAME="sound/%k"
KERNEL="adsp*", NAME="sound/%k"
KERNEL="midi*", NAME="sound/%k"
KERNEL="mixer*", NAME="sound/%k"
KERNEL="sequencer*", NAME="sound/%k"
KERNEL="amidi*", NAME="sound/%k"
KERNEL="dmmidi*", NAME="sound/%k"
KERNEL="admmidi*", NAME="sound/%k"
# input devices
KERNEL="mice", NAME="input/%k"
KERNEL="mouse*", NAME="input/%k"
KERNEL="event*", NAME="input/%k"
KERNEL="js*", NAME="input/%k"
KERNEL="ts*", NAME="input/%k"
# device mapper creates its own device nodes so ignore these
KERNEL="dm-[0-9]*", NAME=""
[-- Attachment #4: scsi-devfs.sh --]
[-- Type: application/x-sh, Size: 1026 bytes --]
^ permalink raw reply
* 2.6.2-rc2 Hangs on boot (was: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED)
From: John Stoffel @ 2004-01-27 0:18 UTC (permalink / raw)
To: Andrew Morton
Cc: John Stoffel, ak, Valdis.Kletnieks, bunk, cova, eric,
linux-kernel
In-Reply-To: <20040125220027.30e8cdf3.akpm@osdl.org>
>>>>> "Andrew" == Andrew Morton <akpm@osdl.org> writes:
Andrew> "John Stoffel" <stoffel@lucent.com> wrote:
>>
>> Sure, the darn thing wouldn't boot, it kept Oopsing with the
>> test_wp_bit oops (that I just posted more details about).
Andrew> Does this fix the test_wp_bit oops?
Andrew> --- 25/init/main.c~test_wp_bit-oops-fix 2004-01-25 15:29:53.000000000 -0800
Andrew> +++ 25-akpm/init/main.c 2004-01-25 15:30:03.000000000 -0800
Andrew> @@ -434,9 +434,9 @@ asmlinkage void __init start_kernel(void
Andrew> }
Andrew> #endif
Andrew> page_address_init();
Andrew> + sort_main_extable();
Andrew> mem_init();
Andrew> kmem_cache_init();
Andrew> - sort_main_extable();
Andrew> if (late_time_init)
Andrew> late_time_init();
Andrew> calibrate_delay();
No, nor does this fix my booting problem(s) with 2.6.2-rc2. I'm now
back and running 2.6.1-mm5 without any problems. Is there any further
info I can give, or patches I can apply? I've applied the early
printk patch, the above patch, and I'm at a loss where the problem is.
It hangs at the following spot:
Linux version 2.6.2-rc2 (john@jfsnew) (gcc version 3.3.3 20040110
(prerelease) (Debian)) #2 SMP Mon Jan 26 09:17:00 EST 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000002fffe000 (usable)
BIOS-e820: 000000002fffe000 - 0000000030000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffe00000 - 0000000100000000 (reserved)
767MB LOWMEM available.
found SMP MP-table at 000fe710
hm, page 000fe000 reserved twice.
hm, page 000ff000 reserved twice.
hm, page 000f0000 reserved twice.
On node 0 totalpages: 196606
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 192510 pages, LIFO batch:16
HighMem zone: 0 pages, LIFO batch:1
Should I start adding in printks, or would it make sense to go back
through the various 2.6.2-bk# snapshots looking for where the problem
hit?
Here's my PCI info, just in case this info helps:
> lspci
00:00.0 Host bridge: Intel Corp. 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corp. 440GX - 82443GX AGP bridge
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0d.0 RAID bus controller: Triones Technologies, Inc. HPT302 (rev
01)
00:10.0 PCI bridge: Hint Corp HB6 Universal PCI-PCI bridge
(non-transparent mode) (rev 13)
00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX
[Cyclone] (rev 24)
00:13.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev
03)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP
(rev 82)
02:08.0 USB Controller: NEC Corporation USB (rev 41)
02:08.1 USB Controller: NEC Corporation USB (rev 41)
02:08.2 USB Controller: NEC Corporation USB 2.0 (rev 02)
02:0b.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394
Controller (Link)
03:06.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev
06)
03:0a.0 SCSI storage controller: Adaptec AHA-2940U2/U2W / 7890/7891
03:0e.0 SCSI storage controller: Adaptec AIC-7880U (rev 01)
^ permalink raw reply
* Re: IMQ Replacement
From: Andy Furniss @ 2004-01-27 0:17 UTC (permalink / raw)
Cc: Netfilter Mailing List
In-Reply-To: <40153757.2010108@dsl.pipex.com>
Andy Furniss wrote:
> There is also discussion on the LARTC list at the moment - someone
> called roy has rewritten IMQ but still sees crashes. He thinks they are
> related to locally generated traffic, so IMQ for ingress should be OK.
He just posted this, thought it may be of interest.
Finaly I made imq driver stable it did not crashed for all 5 hours under
high load, soo looks stable.
(old one was crashing after 1-5 min for me)
no need to patch anything just compile and insmod, should work with any
kernel probably must be > than 2.4.20
This is completely diferent code than old imq.
you can find it on my server http://pupa.da.ru
please tell how it works for you and how stable it is.
^ permalink raw reply
* Re: kernel BUG at include/linux/list.h:148!
From: Andrew Morton @ 2004-01-27 0:16 UTC (permalink / raw)
To: David Martínez Moreno; +Cc: linux-kernel
In-Reply-To: <200401270042.02840.ender@debian.org>
David Martínez Moreno <ender@debian.org> wrote:
>
> Hello, I'm using -mm branch since 2.6.0-pre kernels, and now I'm finding
> problems (well, *another* type of problems) since 2.6.1-rc1-mm2. Last kernel
> without this error was 2.6.1-rc2-mm1.
>
> The error is always the same (at least to me, poor non kernel-hacker):
>
> ------------[ cut here ]------------
> kernel BUG at include/linux/list.h:148!
> invalid operand: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c012ee1d>] Not tainted VLI
> EFLAGS: 00010203
> EIP is at __remove_from_page_cache+0x71/0x7b
> eax: c13e22b8 ebx: dd2058bc ecx: c13e22c0 edx: c1122c90
> esi: c13e22b8 edi: dfdb5e60 ebp: dd2058bc esp: dfdb5d88
> ds: 007b es: 007b ss: 0068
> Process kswapd0 (pid: 8, threadinfo=dfdb4000 task=dfdbace0)
> Stack: dd2058c0 000145cd 00000001 c13e22b8 c0137e0b c13e22b8 c02fce0a d6df1480
> 00000001 000000b1 00000000 dfdb5db4 dfdb5db4 dfdb5dc0 00000003 c04ade88
> 00000001 c10502f8 c03d58b4 00000003 c04b0560 00000001 00000001 c13a7c80
> Call Trace:
> [<c0137e0b>] shrink_list+0x2c0/0x476
> [<c02fce0a>] __kfree_skb+0x68/0xd9
> [<c013813f>] shrink_cache+0x17e/0x2df
> [<c015b74b>] shrink_dcache_memory+0x23/0x25
> [<c0137a76>] shrink_slab+0x11b/0x15e
Someone else was seeing something similar. Reverting
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc1/2.6.2-rc1-mm1/broken-out/sysfs-pin-kobject.patch
apparently fixed it.
^ permalink raw reply
* Re: [linux-lvm] Re: LVM2 + Linux 2.6.1 questions
From: Navindra Umanee @ 2004-01-27 0:14 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <yw1xektm3edc.fsf@ford.guide>
Måns Rullgård <mru@kth.se> wrote:
> > 2) Why do I see, for example, a /dev/mapper/v01-home entry,
> > instead of /dev/v01/home, when running 'df' and 'mount'? I
> > see that /dev/mapper/v01/home symlinks to
> > /dev/mapper/v01-home, which must account for this, though I
> > thought that because I'd specified /dev/v01/home, that it'd
> > appear as such? Not that this really matters I suppose ;-)
>
> I see the /dev/vg/link name.
Mine shows /dev/mapper/vg-link too. I would definitely prefer
/dev/vg/link because at least it's not implementation dependent... but
I guess it's mostly an aesthetic thing.
Any idea why yours is different? Different version of mount maybe?
Using mount-2.11z here...
Later,
Navin.
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Nick Piggin @ 2004-01-27 0:07 UTC (permalink / raw)
To: Andrew Theurer; +Cc: Martin J. Bligh, Rusty Russell, linux-kernel
In-Reply-To: <200401261740.12657.habanero@us.ibm.com>
Andrew Theurer wrote:
>>>To me, it'd make more sense to add the CPUs to the scheduler structures
>>>as they get brought online. I can also imagine machines where you have
>>>a massive (infinite?) variety of possible CPUs that could appear -
>>>like an NUMA box where you could just plug arbitrary numbers of new
>>>nodes in as you wanted.
>>>
>>I guess so, but you'd still need NR_CPUS to be >= that arbitrary
>>number.
>>
>>
>>>Moreover, as the CPUs aren't fixed numbers in advance, how are you going
>>>to know which node to put them in, etc? Setting up every possible thing
>>>in advance seems like an infeasible way to do hotplug to me.
>>>
>>Well this would be the problem. I guess its quite possible that
>>one doesn't know the topology of newly added CPUs before hand.
>>
>>Well OK, this would require a per architecture function to handle
>>CPU hotplug. It could possibly just default to arch_init_sched_domains,
>>and just completely reinitialise everything which would be the simplest.
>>
>
>Call me crazy, but why not let the topology be determined via userspace at a
>more appropriate time? When you hotplug, you tell it where in the scheduler
>to plug it. Have structures in the scheduler which represent the
>nodes-runqueues-cpus topology (in the past I tried a node/rq/cpu structs with
>simple pointers), but let the topology be built based on user's desires thru
>hotplug.
>
Well isn't userspace's idea of topology just what the kernel tells it?
I'm not sure what it would buy you... but I guess it wouldn't be too
much harder than doing it in kernel, just a matter of making the userspace
API.
BTW. I guess you haven't seen my sched domains code. It can describe
arbitrary topologies.
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Nigel Cunningham @ 2004-01-27 0:12 UTC (permalink / raw)
To: Pavel Machek
Cc: Benjamin Herrenschmidt, Hugang, Patrick Mochel,
Linux Kernel Mailing List, linuxppc-dev list
In-Reply-To: <20040126232148.GF310@elf.ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
On Tue, 2004-01-27 at 12:21, Pavel Machek wrote:
> Notice that swsusp needs half of physical memory free by design. That
> means that we need _some_ freeing. Nigel's swsusp2 works around that
> at cost of more complicated implementation.
Yes, my method is a bit more complicated.
Yours doesn't always need some freeing though - you only need to free
memory until that 1/2 limitation is met. Last time I looked at it, it
freed memory until it could free no more. Is that still true?
Nigel
--
My work on Software Suspend is graciously brought to you by
LinuxFund.org.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2.6.2-rc1-mm3] fs/xfs/xfs_log_recover.c
From: Bryan Whitehead @ 2004-01-27 0:09 UTC (permalink / raw)
To: Nathan Scott; +Cc: Bryan Whitehead, linux-kernel
In-Reply-To: <20040126234159.GD781@frodo>
Nathan Scott wrote:
> On Sat, Jan 24, 2004 at 08:48:59PM -0800, Bryan Whitehead wrote:
>
>>On compile I get this:
>>
>>fs/xfs/xfs_log_recover.c: In function `xlog_recover_reorder_trans':
>>fs/xfs/xfs_log_recover.c:1534: warning: `flags' might be used uninitialized in this function
>>
>>I previously sent this patch and it was wrong.
>
>
> What compiler version are you using? Is this a recent gcc or an
> older version - if the former, is gcc really getting dumber? if
> the latter, I'm wondering why I haven't come across this anytime
> in the last few years of compiling xfs. Or is this some non-gcc
> compiler out of left field?
>
> thanks.
>
This is gcc 3.3.2 on gentoo linux.
gcc may be getting dumber, or just more precautious?
--
Bryan Whitehead
Email:driver@megahappy.net
WorkE:driver@jpl.nasa.gov
^ permalink raw reply
* Re: New NUMA scheduler and hotplug CPU
From: Martin J. Bligh @ 2004-01-27 0:09 UTC (permalink / raw)
To: Andrew Theurer, Nick Piggin; +Cc: Rusty Russell, linux-kernel
In-Reply-To: <200401261740.12657.habanero@us.ibm.com>
> Call me crazy, but why not let the topology be determined via userspace at a
> more appropriate time? When you hotplug, you tell it where in the scheduler
> to plug it. Have structures in the scheduler which represent the
> nodes-runqueues-cpus topology (in the past I tried a node/rq/cpu structs with
> simple pointers), but let the topology be built based on user's desires thru
> hotplug.
Well, I agree with the "at a more appropriate time" bit. But there's no
real need to make a bunch of complicated stuff out in userspace for this -
we're trying to lay out the scheduler domains according to the hardware
topology of the machine. It's not a userspace namespace or anything.
Having userspace fishing down way deep in hardware specific stuff is
silly - the kernel is there as a hardware abstraction layer.
Now if you wanted to use sched domains for workload management or something
and involve userspace, then yes ... that'd be more appropriate.
> For example, you boot on just the boot cpu, which by default is in the first
> node on the first runqueue. All other cpus, whether being "booted" for the
> for the first time or hotplugged (maybe now there's really no difference),
> the hotplugging tells where the cpu should be, in what node and what
> runqueue. HT cpus work even better, because you can hotplug siblings, once
> at a time if you wanted, to the same runqueue. Or you have cpus sharing a
> die, same thing, lots of choices here. This removes any per-arch updates to
> the kernel for things like scheduler topology, and lets them go somewhere
> else more easily changes, like userspace.
Ummm ... but *none* of that is dictated as policy stuff - it's all just
the hardware layout of the machine. You cannot "decide" as the sysadmin
which node a CPU is in, or which HT sibling it has. It's just there ;-)
The only thing you could possibly dictate is the CPU number you want
assigned to the new CPU, which frankly, I think is pointless - they're
arbitrary tags, and always have been.
M.
^ permalink raw reply
* [LARTC] Filter not listed for firewall filter - and not running!
From: Michael S. Kazmier @ 2004-01-27 0:07 UTC (permalink / raw)
To: lartc
Hello all,
I am having some trouble getting a firewall filter to work with TC. I am
actually setting the mark via EBTables (which is working as far as I can
tell, I am also logging the packet and my syslog reports lots of marks):
ebtables -t broute -A BROUTING -p ipv4 -i eth1 -s 08:00:46:60:B3:57 -j mark
--set-mark 7 --mark-target CONTINUE --log --log-level debug --log-prefix
"EBFW Mark 7"
Now, with the marked packet, I want to rate shape it on ETH0 on its way out.
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1 cbq bandwidth 100Mbit avpkt 1000 cell 8
tc class change dev eth0 root cbq weight 10Mbit allot 1514
tc class add dev eth0 parent 1: classid 1:2500 cbq bandwidth 100Mbit rate
1512Kbit weight 51Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
bounded
tc qdisc add dev eth0 parent 1:2500 handle 2500 sfq perturb 10
tc class add dev eth0 parent 1:2500 classid 1:3500 cbq bandwidth 100Mbit
rate 256Kbit weight 26Kbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
bounded
tc qdisc add dev eth0 parent 1:3500 handle 3500 sfq perturb 10
tc filter add dev eth0 parent 1:2500 protocol ip prio 100 handle 7 fw flowid
1:3500
But the problem is, when I look at stats, my 3500 queue has no traffic and
my filters are blank, I run a " tc filter show dev eth0" and its empty. I
have various u32 filters on eth1 and they show up. If add:
tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match ip dst
0.0.0.0/0 classid 1:2500
I can now see that I have filters on eth0
[root@cbq]# tc filter show dev eth0
[root@cbq]# tc filter add dev eth0 parent 1:0 protocol ip prio 100 u32 match
ip dst 0.0.0.0/0 classid 1:2500
[root@cbq]# tc filter show dev eth0
filter parent 1: protocol ip pref 100 u32
filter parent 1: protocol ip pref 100 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 100 u32 fh 800::800 order 2048 key ht 800
bkt 0 flowid 1:2500
match 00000000/00000000 at 16
[root@cbq]#
What am I missing here???
Thanks,
Mike
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Encrypted Filesystem
From: jw schultz @ 2004-01-27 0:06 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <OFA97B290B.67DE842E-ON87256E27.0061728C-86256E27.0061BB0E@us.ibm.com>
On Mon, Jan 26, 2004 at 11:46:29AM -0600, Michael A Halcrow wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have some time this year to work on an encrypted filesystem for
> Linux. I have surveyed various LUG's, tested and reviewed code for
> currently existing implementations, and have started modifying some
> of them. I would like to settle on a single approach on which to
> focus my efforts, and I am interested in getting feedback from the
> LKML community as to which approach is the most feasible.
>
> This is the feature wish-list that I have compiled, based on personal
> experience and feedback I have received from other individuals and
> groups:
This sounds more like transparent (in-kernel?) file encryption
than an encrypted filesystem. I think there is value in
having both, or all three if you add encrypted block devices.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt
^ permalink raw reply
* Re: [2.6.x] e1000: NETDEV WATCHDOG: eth0: transmit timed out
From: Feldman, Scott @ 2004-01-27 0:37 UTC (permalink / raw)
To: Petr Sebor; +Cc: linux-kernel
In-Reply-To: <C6F5CF431189FA4CBAEC9E7DD5441E01036EA9DA@orsmsx402.jf.intel.com>
On Mon, 26 Jan 2004, Petr Sebor wrote:
> after a weekend and half of working day (with extra torturing of the
> network card)
> the NETDEV WATCHDOG's are not barking anymore with the tso's disabled.
>
> Do you want me to do more testing or will you tell me what _the_ next
> step is ? :-)
Petr, sorry for the suspense. Here's a patch against 2.6.2-rc2 that fixes
a race in the Tx path of e1000 that you may be exposing with TSO on. The
race is:
Tx queue Tx clean (interrupt context)
...
if(h/w Q full) | clean h/w Q
... <---| if(s/w Q stopped)
stop s/w Q | wake s/w Q
So let's try this patch with TSO back on.
--- linux-2.6.2-rc2/drivers/net/e1000/e1000.h.orig 2004-01-26 15:38:40.000000000 -0800
+++ linux-2.6.2-rc2/drivers/net/e1000/e1000.h 2004-01-26 15:35:37.000000000 -0800
@@ -192,6 +192,7 @@
/* TX */
struct e1000_desc_ring tx_ring;
+ spinlock_t tx_lock;
uint32_t txd_cmd;
uint32_t tx_int_delay;
uint32_t tx_abs_int_delay;
--- linux-2.6.2-rc2/drivers/net/e1000/e1000_main.c.orig 2004-01-26 15:38:33.000000000 -0800
+++ linux-2.6.2-rc2/drivers/net/e1000/e1000_main.c 2004-01-26 15:33:25.000000000 -0800
@@ -669,6 +669,7 @@
atomic_set(&adapter->irq_sem, 1);
spin_lock_init(&adapter->stats_lock);
+ spin_lock_init(&adapter->tx_lock);
return 0;
}
@@ -1783,6 +1784,7 @@
struct e1000_adapter *adapter = netdev->priv;
unsigned int first;
unsigned int tx_flags = 0;
+ unsigned long flags;
int count;
if(skb->len <= 0) {
@@ -1790,10 +1792,13 @@
return 0;
}
+ spin_lock_irqsave(&adapter->tx_lock, flags);
+
if(adapter->hw.mac_type == e1000_82547) {
if(e1000_82547_fifo_workaround(adapter, skb)) {
netif_stop_queue(netdev);
mod_timer(&adapter->tx_fifo_stall_timer, jiffies);
+ spin_unlock_irqrestore(&adapter->tx_lock, flags);
return 1;
}
}
@@ -1814,11 +1819,14 @@
e1000_tx_queue(adapter, count, tx_flags);
else {
netif_stop_queue(netdev);
+ spin_unlock_irqrestore(&adapter->tx_lock, flags);
return 1;
}
netdev->trans_start = jiffies;
+ spin_unlock_irqrestore(&adapter->tx_lock, flags);
+
return 0;
}
@@ -2171,6 +2179,8 @@
unsigned int i, eop;
boolean_t cleaned = FALSE;
+ spin_lock(&adapter->tx_lock);
+
i = tx_ring->next_to_clean;
eop = tx_ring->buffer_info[i].next_to_watch;
eop_desc = E1000_TX_DESC(*tx_ring, eop);
@@ -2215,6 +2225,8 @@
if(cleaned && netif_queue_stopped(netdev) && netif_carrier_ok(netdev))
netif_wake_queue(netdev);
+ spin_unlock(&adapter->tx_lock);
+
return cleaned;
}
^ permalink raw reply
* Re: [linux-lvm] Kernel 2.6.1 and LVM2
From: Heinz Mauelshagen @ 2004-01-27 0:02 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <000801c3e25b$a509cc90$9722fea9@terence>
Hi John,
you can essentially reuse the /etc/rc.d/rc.sysinit startup
of Red Hat Linux for LVM1.
Maybe you can feed that back to Fedora development ?
Regards,
Heinz -- The LVM Guy --
en Sat, Jan 24, 2004 at 10:22:51AM +0100, John Cassidy wrote:
> Heinz,
>
>
>
> on the above kernel, all of the necessary steps have been taken to
> get LVM2 to function.
>
>
>
> My problem is I want an appropriate startup script to initiate and halt
> LVM2 at startup and shutdown.
>
>
>
> Distribution is RH Fedora with kernel 2.6.1.
>
>
>
> Any ideas?
>
>
>
> Im voraus..
>
>
>
> Regards/Cordialement/Gruss/Saludos
>
> John Cassidy Dipl.-Ing (Informatique)
>
> S390 & zSeries Systems Engineering
>
> Schleswigstr. 7
>
> D-51065 Cologne
>
> EU
>
> Tel: +49 (0) 221 61 60 777 . GSM: +49 (0) 177 799 58 56
>
> E-Mail: Sean@JDCassidy.net <mailto:Sean@JDCassidy.net>
>
> HTTP :
> <file:///H:\Documents%20and%20Settings\Horace\Application%20Data\Microsoft\S
> ignatures\www.jdcassidy.net> www.jdcassidy.net
>
>
>
>
>
*** Software bugs are stupid.
Nevertheless it needs not so stupid people to solve them ***
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Heinz Mauelshagen Red Hat, Inc.
Consulting Development Engineer Am Sonnenhang 11
56242 Marienrachdorf
Germany
Mauelshagen@RedHat.com +49 2626 141200
FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply
* [Adeos-main] [PATCH] armnommu compile fix
From: Paul Mundt @ 2004-01-27 0:00 UTC (permalink / raw)
To: adeos-main
[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]
Hi,
The current kernel-2.4/adeos-common/include/asm-armnommu/adeos.h has a broken
__adeos_clear_irq(). This looks like it was copied from an SMP-able adeos.h
and cleaned up, with only this one line being left over and subsequently
causing the build to fail.
Against current CVS HEAD.
kernel-2.4/adeos-common/include/asm-armnommu/adeos.h | 1 -
1 files changed, 1 deletion(-)
Index: kernel-2.4/adeos-common/include/asm-armnommu/adeos.h
===================================================================
RCS file: /cvsroot/adeos/adeos/platforms/linux/kernel-2.4/adeos-common/include/asm-armnommu/adeos.h,v
retrieving revision 1.20
diff -u -r1.20 adeos.h
--- kernel-2.4/adeos-common/include/asm-armnommu/adeos.h 9 Jan 2004 10:06:15 -0000 1.20
+++ kernel-2.4/adeos-common/include/asm-armnommu/adeos.h 26 Jan 2004 23:59:04 -0000
@@ -204,7 +204,6 @@
clear_bit(IPIPE_LOCK_FLAG,&(adp)->irqs[irq].control); \
(adp)->cpudata[0].irq_hits[irq] = 0; \
__adeos_clear_pend(adp,irq); \
- } \
} while(0)
#define adeos_virtual_irq_p(irq) ((irq) >= IPIPE_VIRQ_BASE && \
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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.