* [parisc-linux] 2.4.20-paxx Config problem?
From: jsoe0708 @ 2002-12-19 18:06 UTC (permalink / raw)
To: parisc-linux
Hi all,
Let me first wish you and your families a Merry Christmas and a Happy New=
Year.
Also thanks you all for relevant help.
I need again help because I used a .config file of my own and I obtain a
kernel 2.4.20-paxx operational on my b2k.
I also try to test the one suggested in arch/parisc/debian-configs/32.
But this one make hung the kernel at "search devices..." step and the gre=
en
led on the ide cdrom stay light.
Here is the diff between mine and the suggested:
--- config-2.4.20-pa14 2002-12-19 17:36:14.000000000 +0100
+++ 32 2002-12-18 14:27:04.000000000 +0100
@@ -101,32 +101,33 @@
#
CONFIG_MD=3Dy
CONFIG_BLK_DEV_MD=3Dy
-# CONFIG_MD_LINEAR is not set
-# CONFIG_MD_RAID0 is not set
+CONFIG_MD_LINEAR=3Dy
+CONFIG_MD_RAID0=3Dy
CONFIG_MD_RAID1=3Dy
-# CONFIG_MD_RAID5 is not set
+CONFIG_MD_RAID5=3Dy
# CONFIG_MD_MULTIPATH is not set
-CONFIG_BLK_DEV_LVM=3Dy
+# CONFIG_BLK_DEV_LVM is not set
#
# Networking options
#
CONFIG_PACKET=3Dy
-# CONFIG_PACKET_MMAP is not set
-# CONFIG_NETLINK_DEV is not set
+CONFIG_PACKET_MMAP=3Dy
+CONFIG_NETLINK_DEV=3Dy
CONFIG_NETFILTER=3Dy
CONFIG_NETFILTER_DEBUG=3Dy
CONFIG_FILTER=3Dy
CONFIG_UNIX=3Dy
CONFIG_INET=3Dy
-# CONFIG_IP_MULTICAST is not set
+CONFIG_IP_MULTICAST=3Dy
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=3Dy
# CONFIG_IP_PNP_DHCP is not set
-# CONFIG_IP_PNP_BOOTP is not set
+CONFIG_IP_PNP_BOOTP=3Dy
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
+# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
# CONFIG_SYN_COOKIES is not set
@@ -147,7 +148,7 @@
CONFIG_IP_NF_MATCH_TOS=3Dm
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_DSCP is not set
-# CONFIG_IP_NF_MATCH_AH_ESP is not set
+CONFIG_IP_NF_MATCH_AH_ESP=3Dm
# CONFIG_IP_NF_MATCH_LENGTH is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_TCPMSS=3Dm
@@ -172,7 +173,7 @@
# CONFIG_IP_NF_TARGET_DSCP is not set
CONFIG_IP_NF_TARGET_MARK=3Dm
CONFIG_IP_NF_TARGET_LOG=3Dm
-# CONFIG_IP_NF_TARGET_ULOG is not set
+CONFIG_IP_NF_TARGET_ULOG=3Dm
CONFIG_IP_NF_TARGET_TCPMSS=3Dm
# CONFIG_IP_NF_ARPTABLES is not set
CONFIG_IP_NF_COMPAT_IPCHAINS=3Dm
@@ -310,12 +311,12 @@
#
CONFIG_BLK_DEV_SD=3Dy
CONFIG_SD_EXTRA_DEVS=3D40
-CONFIG_CHR_DEV_ST=3Dm
+CONFIG_CHR_DEV_ST=3Dy
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=3Dy
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_SR_EXTRA_DEVS=3D2
-CONFIG_CHR_DEV_SG=3Dm
+CONFIG_CHR_DEV_SG=3Dy
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
@@ -370,7 +371,7 @@
CONFIG_53C700_USE_CONSISTENT=3Dy
# CONFIG_SCSI_NCR53C7xx is not set
CONFIG_SCSI_SYM53C8XX_2=3Dy
-CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=3D0
+CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=3D1
CONFIG_SCSI_SYM53C8XX_DEFAULT_TAGS=3D16
CONFIG_SCSI_SYM53C8XX_MAX_TAGS=3D64
# CONFIG_SCSI_SYM53C8XX_IOMAPPED is not set
@@ -381,7 +382,7 @@
CONFIG_ASK_ZALON=3Dy
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=3D8
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=3D32
-CONFIG_SCSI_NCR53C8XX_SYNC=3D80
+CONFIG_SCSI_NCR53C8XX_SYNC=3D20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
@@ -444,7 +445,7 @@
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=3Dy
-# CONFIG_PCNET32 is not set
+CONFIG_PCNET32=3Dm
CONFIG_ADAPTEC_STARFIRE=3Dm
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
@@ -483,7 +484,7 @@
#
# Ethernet (1000 Mbit)
#
-CONFIG_ACENIC=3Dm
+# CONFIG_ACENIC is not set
# CONFIG_ACENIC_OMIT_TIGON_I is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
@@ -492,7 +493,7 @@
CONFIG_HAMACHI=3Dm
CONFIG_YELLOWFIN=3Dm
CONFIG_SK98LIN=3Dm
-# CONFIG_TIGON3 is not set
+CONFIG_TIGON3=3Dm
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
@@ -533,8 +534,8 @@
# Input core support
#
CONFIG_INPUT=3Dy
-CONFIG_INPUT_KEYBDEV=3Dm
-CONFIG_INPUT_MOUSEDEV=3Dm
+CONFIG_INPUT_KEYBDEV=3Dy
+CONFIG_INPUT_MOUSEDEV=3Dy
CONFIG_INPUT_MOUSEDEV_SCREEN_X=3D1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=3D768
# CONFIG_INPUT_JOYDEV is not set
@@ -550,7 +551,25 @@
CONFIG_SERIAL_CONSOLE=3Dy
CONFIG_SERIAL_GSC=3Dy
# CONFIG_SERIAL_EXTENDED is not set
-# CONFIG_SERIAL_NONSTANDARD is not set
+CONFIG_SERIAL_NONSTANDARD=3Dy
+# CONFIG_COMPUTONE is not set
+# CONFIG_ROCKETPORT is not set
+# CONFIG_CYCLADES is not set
+# CONFIG_DIGIEPCA is not set
+# CONFIG_DIGI is not set
+# CONFIG_ESPSERIAL is not set
+# CONFIG_MOXA_INTELLIO is not set
+# CONFIG_MOXA_SMARTIO is not set
+# CONFIG_ISI is not set
+# CONFIG_SYNCLINK is not set
+# CONFIG_SYNCLINKMP is not set
+# CONFIG_N_HDLC is not set
+# CONFIG_RISCOM8 is not set
+# CONFIG_SPECIALIX is not set
+# CONFIG_SX is not set
+# CONFIG_RIO is not set
+# CONFIG_STALDRV is not set
+CONFIG_PDC_CONSOLE=3Dy
CONFIG_UNIX98_PTYS=3Dy
CONFIG_UNIX98_PTY_COUNT=3D256
CONFIG_PRINTER=3Dy
@@ -581,7 +600,7 @@
# CONFIG_INPUT_PCIGAME is not set
# CONFIG_INPUT_CS461X is not set
# CONFIG_INPUT_EMU10K1 is not set
-# CONFIG_INPUT_SERIO is not set
+CONFIG_INPUT_SERIO=3Dy
# CONFIG_INPUT_SERPORT is not set
#
@@ -644,15 +663,14 @@
#
CONFIG_HP_SDC=3Dy
# CONFIG_HP_SDC_RTC is not set
-# CONFIG_HIL_MLC is not set
-
-#
-# Serial IO support needed for HIL keyboard and mouse support
-#
+CONFIG_HIL_MLC=3Dy
+CONFIG_HP_SDC_MLC=3Dy
#
# HIL device driver
#
+CONFIG_HIL_KBD=3Dy
+CONFIG_HIL_PTR=3Dy
#
# Multimedia devices
@@ -677,7 +695,7 @@
# CONFIG_BFS_FS is not set
CONFIG_EXT3_FS=3Dy
CONFIG_JBD=3Dy
-CONFIG_JBD_DEBUG=3Dy
+# CONFIG_JBD_DEBUG is not set
CONFIG_FAT_FS=3Dm
CONFIG_MSDOS_FS=3Dm
# CONFIG_UMSDOS_FS is not set
@@ -691,7 +709,7 @@
CONFIG_ISO9660_FS=3Dy
CONFIG_JOLIET=3Dy
# CONFIG_ZISOFS is not set
-CONFIG_JFS_FS=3Dy
+# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
CONFIG_MINIX_FS=3Dm
@@ -962,7 +980,7 @@
# Kernel hacking
#
CONFIG_MAGIC_SYSRQ=3Dy
-# CONFIG_DEBUG_SPINLOCK is not set
+CONFIG_DEBUG_SPINLOCK=3Dy
#
# Library routines
Is somebody see what could be wrong (It would also help me for 2.5 with
which met the same pb a time ago)?
See you next year.
Thanks again ,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* [PATCH][TRIVIAL] drivers/video/tdfxfb.c compile failure (Linux 2.5.52)
From: Gergely Nagy @ 2002-12-19 18:06 UTC (permalink / raw)
To: linux-fbdev-devel, linux-kernel
Hi!
drivers/video/tdfxfb.c does not compile, because banshee_wait_idle()
is used before declaration. A simple fix follows:
--- linux-2.5.52/drivers/video/tdfxfb.c.old 2002-12-19 18:55:03.000000000 +0100
+++ linux-2.5.52/drivers/video/tdfxfb.c 2002-12-19 18:56:25.000000000 +0100
@@ -166,6 +166,7 @@
static void tdfxfb_copyarea(struct fb_info *info, struct fb_copyarea *area);
static void tdfxfb_imageblit(struct fb_info *info, struct fb_image *image);
static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor);
+static inline void banshee_wait_idle(struct fb_info *info);
static struct fb_ops tdfxfb_ops = {
.owner = THIS_MODULE,
^ permalink raw reply
* Re: 2.4.19, don't "hdparm -I /dev/hde" if hde is on a Asus A7V133 Promise ctrlr, or...
From: Ross Biro @ 2002-12-19 18:12 UTC (permalink / raw)
To: vda
Cc: Alan Cox, D.A.M. Revok, Andre Hedrick, Manish Lachwani,
Linux Kernel Mailing List
In-Reply-To: <200212190951.gBJ9pCs28149@Port.imtp.ilyichevsk.odessa.ua>
Denis Vlasenko wrote:
>OTOH mere mortals are allowed to make full dump of PCI config ;)
>
>
>
Some vendors use index/data registers in the config space, so unless you
know of their existance, a PCI config dump doesn't help.
^ permalink raw reply
* Re: PPC Tree structures (Was, at some point: Re: Support for Arctic platform (405LP based))
From: Cort Dougan @ 2002-12-19 18:06 UTC (permalink / raw)
To: Tom Rini; +Cc: Paul Mackerras, linuxppc-embedded
In-Reply-To: <20021216201301.GA2513@opus.bloom.county>
} But regardless of all of that, there's nothing related to this being a
} 'marcelo' tree or not as you can't pick and choose bk csets without
} everything preceeding it. Ideally we can get to the point of not really
} needing a seperate tree like 2.2 is (which could go if someone wants to
} sit down and think about the LongTrail-specific changes in there).
There's a great advantage to it being based on Marcelo's tree. I can pull
in several projects that I need along with the PPC changes I need into my
own tree. I think that would help a lot of people out.
In fact, it should help merging with Marcelo a great deal. You can easily
pull in main-line changes.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 18:08 UTC (permalink / raw)
To: John Bradford; +Cc: Dan Kegel, linux-kernel
In-Reply-To: <200212191800.gBJI03ZT002284@darkstar.example.net>
John Bradford wrote:
>>>Following on from yesterday's discussion about there not being much
>>>interaction between the kernel Bugzilla and the developers, I began
>>>wondering whether Bugzilla might be a bit too generic to be suited to
>>>kernel development, and that maybe a system written from the ground up
>>>for reporting kernel bugs would be better?
>>>
>>>I.E. I am prepared to write it myself, if people think it's
>>>worthwhile.
>>
>>Quoting Linus
>>(http://marc.theaimsgroup.com/?l=linux-kernel&m=103911905214446&w=2):
>>
>>>And many things _can_ be done without throwing out old designs.
>>>Implementation improvements are quite possible without trying to make
>>>something totally new to the outside. ...
>>>
>>>Not throwing out the baby with the bath-water doesn't mean that you cannot
>>>improve the system. I'm only arguing against stupid people who think they
>>>need a revolution to improve - most real improvements are evolutionary.
>>
>
> True, but there is always a point where you have to say, "This isn't
> working, we need to re-write it". Coding by cutting and pasting
> existing code is not a great idea.
>
>
>>I bet the thing to do is to spend some time as one of the
>>elves who make bugzilla.kernel.org work smoothly despite
>>the software; then figure out what incremental tweak you
>>can make to the software to make the elves' and users' lives
>>better.
>
>
> I am not prepared to start editing the existing Bugzilla code - there
> is nothing about it that I think it right at the moment. I could
> write a better bug tracking database in a couple of weeks if I wanted
> to.
Ok, have you looked at other bug tracking programs? Can you find
something you can build on? Take a look at this list of issue tracking
software:
http://www.a-a-p.org/tools_tracking.html
It has a lot of possibilities... different combinations of features and
implementation languages.
Could you perhaps expound a bit on your statement "there is nothing
about [bugzilla] that I think [is] right at the moment"?
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: [PATCH] (4/5) improved notifier callback mechanism - read copy update
From: John Levon @ 2002-12-19 18:08 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: linux-kernel
In-Reply-To: <1040319430.23567.15.camel@dell_ss3.pdx.osdl.net>
On Thu, Dec 19, 2002 at 09:37:10AM -0800, Stephen Hemminger wrote:
> Thanks, will look into it in more detail. Perhaps figuring out how to do
> oprofile without sleeping would be best.
You can try, but I don't think you'll get far ... maintaining the
necessary "no samples present for exited process" invariant is difficult
without sleeping.
It would seem better just to force the profiling hooks to use a
different API
regards
john
--
"ALL television is children's television."
- Richard Adler
^ permalink raw reply
* Re: Problems with CONFIG_PREEMPT
From: Jun Sun @ 2002-12-19 17:59 UTC (permalink / raw)
To: Colin.Helliwell; +Cc: linux-mips, rml, jsun
In-Reply-To: <OF6E5B6266.DFC7C2F8-ON80256C94.002DE2D6@zarlink.com>
On Thu, Dec 19, 2002 at 09:10:40AM +0000, Colin.Helliwell@Zarlink.Com wrote:
>
> Thanks for the patch, but unfortunately the problem is still the same.
If the problem happens very soon after you boot up, there is something
*obviously* wrong. The most common problem is that you have an interupt
handling path not going through standard do_IRQ(). Then you need to
do similar treatment like those in ll_timer_interrupt().
The second thing is to look for any *new* global variables you may
introduce in your kernel. Most of current global variables are either
safe or taken care of (Although another update patch will come out
today or tomorrow to really close the final hole we have).
> I'm
> not sure whether it occurs as a result of interrupts, or just after a
> certain amount of scheduler 'activity' as it sits there copying the initrd
> into ram disk. A few interrupts are enabled, but its only the MIPS timer
> which should be generating any interrupts at that point (I'll check that,
> in case its relevant).
FYI, I have mips kernel with initrd running just fine with preemptible kernel.
In fact, it has passed some very stressful tests with initrd.
> I presume the change from "sti()" to "__sti()" was a semantic (or SMP)
> thing, since the former is #defined to the latter anyway? Please note also
> the following modification which was required to 2.4.19:
>
This is true. Since our kernel had synchronize_irq() added long time ago,
I probably forgot about it when I created the pre-k patch.
Jun
^ permalink raw reply
* Re: Notification hooks
From: Randy.Dunlap @ 2002-12-19 18:02 UTC (permalink / raw)
To: Joseph Fannin; +Cc: Larry McVoy, linux-kernel
In-Reply-To: <20021219063445.GA30990@zion.rivenstone.net>
On Thu, 19 Dec 2002, Joseph Fannin wrote:
| On Mon, Dec 16, 2002 at 09:24:15AM -0800, Larry McVoy wrote:
| >
| > Just for linux.bkbits.net or for the openlogging tree? To remind people,
| > linux.bkbits.net has Linus/Marcelo trees but openlogging.org has the
| > union of all trees anywhere in the world. And openlogging doesn't have
| > contents, it just has comments.
|
| Sorry to hijack this thread like this, but I can't find a better
| forum for it.
|
| Several times I have browsed linux source trees at bkbits.net and
| found a changeset I have wanted to have as a patch. I can search for
| the changeset, and read the commit messages, and even read the patch
| on the screen, but there is no good way to download that patch as a
| file (viewing the page source doesn't help because the patch has html
| markup interspersed with it).
|
| The only way to get the patch is to either 'scrape' the screen
| with copy and paste and try to fix the broken whitespace or to use bk
| to clone the entire tree and extract the patch via bk export. It's a
| real pain, and for no good reason I can see.
|
| Would it be possible to add a link to the bkbits.net pages to an
| un-marked up changeset patch? It would be great to have this for
| trees other than linux.bkbits.net too -- like Dave Jones'
| agpgart.bkbits.net for example.
Have you looked at the (text-mode) csets at
http://www.kernel.org/pub/linux/kernel/v2.5/testing/cset/
Who generates these?
--
~Randy
^ permalink raw reply
* cd access crashes kernel 2.5.52
From: phil @ 2002-12-19 18:02 UTC (permalink / raw)
To: linux-kernel
This message is in the dmesg, then accessing the cd-rom causes the kernel to crash
scsi HBA driver idescsi didn't set max_sectors, please fix the template
ERROR: SCSI host `ide-scsi' has no error handling
ERROR: This is not a safe way to run your SCSI host
ERROR: The error handling must be added to this driver
Call Trace: [<c0243eac>] [<c024c082>] [<c0243eec>] [<c010507a>] [<c0105040>]
[<c0107129>]
^ permalink raw reply
* RE: latest acpi: new behavior of the UPBI method
From: Moore, Robert @ 2002-12-19 17:48 UTC (permalink / raw)
To: 'Jacques GANGLOFF', acpi-devel
This will be fixed in the next release of the ACPI CA software, early in
January.
The problem is related to the ACPI 2.0 specification and the rules for
conversion of Buffer data to String data. There is a "legacy" issue
concerning ACPI 1.0 implementations (MS) that was not taken into
consideration during development of ACPI 2.0 -- and this issue is going to
force a change to the ACPI specification itself.
I think this fix will help solve a number of "mysterious" issues.
Bob Moore
-----Original Message-----
From: Jacques GANGLOFF [mailto:jacques-gXTsMEhN/Y091FlJP1ih0VAUjnlXr6A1@public.gmane.org]
Sent: Thursday, December 19, 2002 7:11 AM
To: acpi-devel
Subject: [ACPI] latest acpi: new behavior of the UPBI method
Hi,
On my VAIO FX702, I have a recurrent problem
with the battery info:
* the time needed to dump /proc/acpi/battery/BAT1/info
is about 0.5s and during this time the box is frozen.
* the last entries in info are corrupted, i.e. model number,
serial number, battery type and OEM info.
As reported by another VAIO user on this list, my feeling is
that these problems are linked.
The interesting thing with the latest acpi patch (20021212), is that
the corruption in the last entries of info has changed. Now I get :
cat /proc/acpi/battery/BAT1/info
present: yes
design capacity: 44400 mWh
last full capacity: 44400 mWh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 400 mWh
design capacity low: 384 mWh
capacity granularity 1: 64 mWh
capacity granularity 2: 64 mWh
model number: 50 43 47 41 2D 42 50 37 31 41 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
serial number: 20 20 20 20 20 20 20 20 00
battery type: 4C 49 4F 4E 20 43 6F 72 70 2E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
OEM info: 53 6F 6E 79 20 43 6F 72 70 2E 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A
This is a progress since if we translate all the hex numbers in ASCII
caracters we get :
model number: PCGA-BP71A
serial number:
battery type: LION Corp.
OEM info: Sony Corp.
which is rather close to what it should be (except for the "LION Corp."
???).
So why are these information given in hex dump format ? And why
is this dump so long ? My skill in AML programming is near from
beginner, so I need some help to go further.
Below is the dump that includes the faultly method (UPBI), I suppose it
should be a
good starting point.
Cheers,
Jacques
Device(BAT1) {
Name(_HID, 0x0a0cd041)
Name(_UID, 0x1)
Name(_PCL, Package(0x1) {
\_SB_,
})
Name(PBIF, Package(0xd) {
0x0,
0x5,
0x5,
0x1,
0x39d0,
0x0190,
0x0180,
0x40,
0x40,
"BAT1",
" ",
" ",
" ",
})
Name(PBST, Package(0x4) {
0x0,
0x5,
0x5,
0x2710,
})
Name(UBIF, 0x01e9)
Name(BP__, 0x1)
Method(_STA) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local1)
And(Local1, 0x1, Local0)
If(Local0) {
Store(0x1, BP__)
}
Else {
Store(0x0, BP__)
}
Store(Local1, \_SB_.PCI0.PIB_.EC0_.BATO)
And(0xfffe, \_SB_.PCI0.PIB_.EC0_.BATF,
\_SB_.PCI0.PIB_.EC0_.BATF)
If(And(0xc0, \_SB_.PCI0.PIB_.EC0_.BATO, )) {
Or(\_SB_.PCI0.PIB_.EC0_.BATF, 0x1,
\_SB_.PCI0.PIB_.EC0_.BATF)
}
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
}
}
If(BP__) {
Return(0x1f)
}
Else {
Return(0xf)
}
}
Method(_BIF) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(BP__) {
UPBI()
}
Else {
IVBI()
}
Store(0x01e9, UBIF)
}
}
Return(PBIF)
}
Method(_BST) {
If(\_SB_.PCI0.PIB_.EC0_.ECON) {
If(\_SB_.PCI0.PIB_.EC0_.ECOK) {
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local1)
And(Local1, 0x1, Local0)
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
If(Local0) {
UPBS()
}
Else {
IVBS()
}
}
}
Else {
IVBS()
}
Return(PBST)
}
Method(UPBI) {
Store(Zero, Local0)
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1400))) {
Store(VTOB(Subtract(_UID, 0x1, )), Local1)
Or(ShiftLeft(Local1, 0xc, ), 0x0fff, Local2)
Store(Zero, Local3)
\_SB_.PCI0.PIB_.EC0_.SMWR(0x8, 0x14, 0x1, Local2)
\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x14, 0x1, RefOf(Local3))
Store(Zero, Local0)
Store(0xc, Local1)
Store(Buffer(0xd) {0x0, 0x18, 0x0, 0x0, 0x19, 0x0, 0x0,
0x0, 0x0, 0x21, 0x0, 0x22, 0x20 }, Local2)
While(LGreater(Local1, 0x8)) {
If(LNot(And(UBIF, VTOB(Local1), ))) {
GBFE(Local2, Local1, RefOf(Local3))
If(Local3) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0xb, 0x16,
Local3, RefOf(Local4)))) {
GBFE(Local4, 0x20, RefOf(Local5))
PBFE(Local4, Local5, 0x20)
Increment(Local5)
PBFE(Local4, Local5, 0x0)
Store(Local4, Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
}
Decrement(Local1)
}
While(LGreater(Local1, 0x0)) {
If(LNot(And(UBIF, VTOB(Local1), ))) {
GBFE(Local2, Local1, RefOf(Local3))
If(Local3) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x16,
Local3, RefOf(Local5)))) {
Store(Local5, Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
}
Decrement(Local1)
}
Store(0xa, Local1)
If(LNot(And(UBIF, VTOB(Local1), ))) {
If(LNot(\_SB_.PCI0.PIB_.EC0_.SMRD(0x9, 0x16, 0x1c,
RefOf(Local5)))) {
Store(ToBCD(Local5, ), Local0)
Store(ITOS(Local0), Index(PBIF, Local1, ))
Or(UBIF, VTOB(Local1), UBIF)
Store(Ones, Local0)
}
}
Store(\_SB_.PCI0.PIB_.EC0_.BANK, Local1)
Store(0x3, \_SB_.PCI0.PIB_.EC0_.BANK)
Store(\_SB_.PCI0.PIB_.EC0_.MFCP, Local2)
If(LEqual(Local2, 0x0)) {
Store(0x5, Index(PBIF, 0x2, ))
}
Else {
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBIF, 0x2, ))
}
Store(Local1, \_SB_.PCI0.PIB_.EC0_.BANK)
Store(DerefOf(Index(PBIF, 0x1, )), Local2)
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBIF, 0x1, ))
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
Return(Local0)
}
Method(UPBS) {
Store(Zero, Local0)
If(LNot(Acquire(\_SB_.PCI0.PIB_.EC0_.MUT0, 0x1388))) {
Store(0x2, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local2)
If(And(Local2, 0x8000, )) {
Or(Local2, 0xffff0000, Local2)
Add(Not(Local2, ), 0x1, Local2)
}
Store(\_SB_.PCI0.PIB_.INF3, Local3)
Store(\_SB_.PCI0.PIB_.INF2, Local5)
If(LNot(LEqual(Local2, DerefOf(Index(PBST, 0x1, ))))) {
Multiply(Local2, 0xa, Local2)
Store(Local2, Index(PBST, 0x1, ))
Store(Ones, Local0)
}
If(LNot(LEqual(Local3, DerefOf(Index(PBST, 0x3, ))))) {
Multiply(Local3, 0x14, Local3)
Divide(Local3, 0x40, Local4, Local3)
Store(Local3, Index(PBST, 0x3, ))
Store(Ones, Local0)
}
If(LNot(LEqual(Local5, DerefOf(Index(PBST, 0x2, ))))) {
Multiply(Local5, 0xa, Local5)
Store(Local5, Index(PBST, 0x2, ))
Store(Ones, Local0)
}
Store(0x0, Local4)
Store(0x8, \_SB_.PCI0.PIB_.DID_)
\_SB_.GSMI(0x8d)
Store(\_SB_.PCI0.PIB_.INF1, Local7)
If(And(Local7, 0x0c00, )) {
If(And(Local7, 0x10, )) {
}
Else {
Or(0x2, Local4, Local4)
}
}
Else {
If(And(Local7, 0x0100, )) {
Or(0x1, Local4, Local4)
}
}
If(LNot(LEqual(Local4, DerefOf(Index(PBST, 0x0, ))))) {
Store(Local4, Index(PBST, 0x0, ))
Store(Ones, Local0)
}
Release(\_SB_.PCI0.PIB_.EC0_.MUT0)
}
Return(Local0)
}
Method(HVBI) {
Store(0x9650, Index(PBIF, 0x1, ))
Store(0x9650, Index(PBIF, 0x2, ))
Store(0x39d0, Index(PBIF, 0x4, ))
Store("PCGA-BP71", Index(PBIF, 0x9, ))
Store("LION", Index(PBIF, 0xb, ))
Store("Sony Corp.", Index(PBIF, 0xc, ))
}
Method(IVBI) {
Store(0x01e9, UBIF)
Store(0x5, Index(PBIF, 0x1, ))
Store(0x5, Index(PBIF, 0x2, ))
Store(0x5, Index(PBIF, 0x4, ))
Store("Bad", Index(PBIF, 0x9, ))
Store("Bad", Index(PBIF, 0xa, ))
Store("Bad", Index(PBIF, 0xb, ))
Store("Bad", Index(PBIF, 0xc, ))
}
Method(IVBS) {
Store(0x0, Index(PBST, 0x0, ))
Store(0x5, Index(PBST, 0x1, ))
Store(0x5, Index(PBST, 0x2, ))
Store(0x2710, Index(PBST, 0x3, ))
}
Method(CHBP, 1) {
Store(Zero, Local0)
Store(VTOB(Subtract(_UID, 0x1, )), Local1)
Or(ShiftLeft(Local1, 0xc, ), 0x0fff, Local2)
Store(Zero, Local3)
If(And(Arg0, Local1, )) {
If(BP__) {
UPBS()
}
Else {
If(LEqual(Local2, Or(Local3, 0x0fff, ))) {
UPBI()
}
UPBS()
Store(0x1, BP__)
Store(0x01e9, UBIF)
}
}
Else {
If(BP__) {
Store(0x0, BP__)
IVBI()
IVBS()
Or(0x4, Local0, Local0)
}
}
}
}
--
_________________________________
(
) Jacques GANGLOFF
( Associate Professor
) LSIIT / EAVR
( Bd Sebastien Brant
) 67400 Illkirch
( Tel : +33 (0)3 90 24 44 68
) Fax : +33 (0)3 90 24 44 80
( http://eavr.u-strasbg.fr
)_________________________________
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Eli Carter @ 2002-12-19 17:48 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel, davej, alan, lm, lm, torvalds, vonbrand, akpm
In-Reply-To: <200212191335.gBJDZRDL000704@darkstar.example.net>
John Bradford wrote:
> Following on from yesterday's discussion about there not being much
> interaction between the kernel Bugzilla and the developers, I began
> wondering whether Bugzilla might be a bit too generic to be suited to
> kernel development, and that maybe a system written from the ground up
> for reporting kernel bugs would be better?
Can you perhaps improve bugzilla instead of starting over? (I have not
looked at bugzilla code... I'm just hoping we can build from where we
are instead of starting over.)
> I.E. I am prepared to write it myself, if people think it's
> worthwhile.
>
> For example, we get a lot of posts on LKML like this:
>
> "Hi, foobar doesn't work in 2.4.19"
>
> Now, does that mean:
>
> * The bug first appeared in 2.4.19, and is still in 2.4.20
> * The bug reporter hasn't tested 2.4.20
> * The bug reporter can't test 2.4.20 because something else is broken
> * The bug actually first appeared in 2.4.10, but it didn't irritate
> them enough to complain until now.
This case is not specific to the kernel:
"feature X doesn't work in program Y version Z"
it may appear in Z-3 through Z+1, but fixed in Z+2, etc.
So I hope it is something that could be done in/added to bugzilla.
> A bug database designed from scratch could allow such information to
> be indexed in a way that could be processed and searched usefully. A
> list of tick-boxes for worked/didn't work/didn't test/couldn't test
> for several kernel versions could be presented.
>
> Also, we could have a non-web interface, (telnet or gopher to the bug
> DB, or control it by E-Mail).
Can you interface with bugzilla's database backend maybe? It seems like
refactoring bugzilla might be better?
> It could warn the user if they attach an un-decoded oops that their
> bug report isn't as useful as it could be, and if they mention a
> distribution kernel version, that it's not a tree that the developers
> will necessarily be familiar with.
Perhaps a more generalized hook into bugzilla for 'validating' a bug
report, then code specific validators for kernel work?
> I'm not criticising the fact that we've got Bugzilla up and running,
> but just pointing out that we could do better, (and I'm prepared to
> put in the time and effort). I just need ideas, really.
I certainly do not want to stand in your way! I just hope you can stand
on the shoulders of giants.
Eli
--------------------. "If it ain't broke now,
Eli Carter \ it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------
^ permalink raw reply
* Re: Dedicated kernel bug database
From: John Bradford @ 2002-12-19 18:00 UTC (permalink / raw)
To: Dan Kegel; +Cc: linux-kernel
In-Reply-To: <3E020604.80703@kegel.com>
> > Following on from yesterday's discussion about there not being much
> > interaction between the kernel Bugzilla and the developers, I began
> > wondering whether Bugzilla might be a bit too generic to be suited to
> > kernel development, and that maybe a system written from the ground up
> > for reporting kernel bugs would be better?
> >
> > I.E. I am prepared to write it myself, if people think it's
> > worthwhile.
>
> Quoting Linus
> (http://marc.theaimsgroup.com/?l=linux-kernel&m=103911905214446&w=2):
> > And many things _can_ be done without throwing out old designs.
> > Implementation improvements are quite possible without trying to make
> > something totally new to the outside. ...
> >
> > Not throwing out the baby with the bath-water doesn't mean that you cannot
> > improve the system. I'm only arguing against stupid people who think they
> > need a revolution to improve - most real improvements are evolutionary.
True, but there is always a point where you have to say, "This isn't
working, we need to re-write it". Coding by cutting and pasting
existing code is not a great idea.
> I bet the thing to do is to spend some time as one of the
> elves who make bugzilla.kernel.org work smoothly despite
> the software; then figure out what incremental tweak you
> can make to the software to make the elves' and users' lives
> better.
I am not prepared to start editing the existing Bugzilla code - there
is nothing about it that I think it right at the moment. I could
write a better bug tracking database in a couple of weeks if I wanted
to.
John.
^ permalink raw reply
* Re: [parisc-linux] quad tulip now not functional in 2.4.20
From: jsoe0708 @ 2002-12-19 17:37 UTC (permalink / raw)
To: grundler; +Cc: Ed Schaller, parisc-linux
In-Reply-To: <20021218165813.GA17944@dsl2.external.hp.com>
Hi Grant,
>
>On Tue, Dec 17, 2002 at 08:12:03AM +0100, jsoe0708@tiscali.be wrote:
>> Just to avoid you loose time here is a diff:
>...
>> - if (ee_data[27] =3D=3D 0) { /* No valid media table. */
>> + if (ee_data[27] =3D=3D 0 || ee_data[ee_data[27]] =3D=3D 0) { /* No =
valid media
>> table. */
>
>Like I suspected, backing out this change made add-on boards work again.=
>I've reverted that change in 2.4.20-pa15 along with a traps.c change.
>Please apply by hand and try the 4-port again.
>
Sorry, I was too tired yesterday evening and have not time today :-(.
But I see that Ed successfully tested. Great (I will also test it, ... ne=
xt
year :))
Thanks for all and let me wish you and your families a Merry Christmas an=
d
a Happy New Year,
Joel
*************************************************************************=
*******
Controlez mieux votre consommation Internet...surfez Tiscali Complete...h=
ttp://tiscali.complete.be
^ permalink raw reply
* Re: pcibios functions left in m68knommu port
From: Greg KH @ 2002-12-19 17:42 UTC (permalink / raw)
To: Greg Ungerer; +Cc: linux-kernel
In-Reply-To: <3DFFC5EA.6010201@snapgear.com>
On Wed, Dec 18, 2002 at 10:48:42AM +1000, Greg Ungerer wrote:
> Greg KH wrote:
> >I just noticed the arch/m68knommu/kernel/comempci.c file, which contains
> >a lot of pcibios functions that are now removed from the rest of the
> >kernel. Are these present for any specific reason, or would you be
> >willing to take a patch removing them?
>
> Happy to take a patch.
> Most of that baggage has been carried through since that support
> was first coded (circa linux-2.0.38).
Great, here's a patch against 2.5.52 that removes the unneeded
functions. I think you might be able to remove a few of the static
variables in this file now too, but I don't want to break anything, as I
don't have a machine to test this on.
Hm, I think I have a uCsimm around here somewhere...
thanks,
greg k-h
# removed unused pcibios functions from the m68knommu code.
diff -Nru a/arch/m68knommu/kernel/comempci.c b/arch/m68knommu/kernel/comempci.c
--- a/arch/m68knommu/kernel/comempci.c Thu Dec 19 09:43:11 2002
+++ b/arch/m68knommu/kernel/comempci.c Thu Dec 19 09:43:11 2002
@@ -338,254 +338,6 @@
/*****************************************************************************/
-int pcibios_present(void)
-{
- return(pci_bus_is_present);
-}
-
-/*****************************************************************************/
-
-int pcibios_read_config_dword(unsigned char bus, unsigned char dev,
- unsigned char offset, unsigned int *val)
-{
- volatile unsigned long *rp;
- unsigned long idsel, fnsel;
-
-#ifdef DEBUGPCI
- printk("pcibios_read_config_dword(bus=%x,dev=%x,offset=%x,val=%x)\n",
- bus, dev, offset, val);
-#endif
-
- if (bus || ((pci_slotmask & (0x1 << PCI_SLOT(dev))) == 0)) {
- *val = 0xffffffff;
- return(PCIBIOS_SUCCESSFUL);
- }
-
- rp = (volatile unsigned long *) COMEM_BASE;
- idsel = COMEM_DA_CFGRD | COMEM_DA_ADDR(0x1 << ((dev >> 3) + 16));
- fnsel = (dev & 0x7) << 8;
-
- rp[LREG(COMEM_DAHBASE)] = idsel;
- *val = rp[LREG(COMEM_PCIBUS + (offset & 0xfc) + fnsel)];
-
-#if 1
- /* If we get back what we wrote, then nothing there */
- /* This is pretty dodgy, but, hey, what else do we do?? */
- if (!offset && (*val == ((idsel & 0xfffff000) | (offset & 0x00000fff))))
- *val = 0xffffffff;
-#endif
-
- return(PCIBIOS_SUCCESSFUL);
-}
-
-/*****************************************************************************/
-
-int pcibios_read_config_word(unsigned char bus, unsigned char dev,
- unsigned char offset, unsigned short *val)
-{
- volatile unsigned long *rp;
- volatile unsigned short *bp;
- unsigned long idsel, fnsel;
- unsigned char swapoffset;
-
-#ifdef DEBUGPCI
- printk("pcibios_read_config_word(bus=%x,dev=%x,offset=%x)\n",
- bus, dev, offset);
-#endif
-
- if (bus || ((pci_slotmask & (0x1 << PCI_SLOT(dev))) == 0)) {
- *val = 0xffff;
- return(PCIBIOS_SUCCESSFUL);
- }
-
- rp = (volatile unsigned long *) COMEM_BASE;
- bp = (volatile unsigned short *) COMEM_BASE;
- idsel = COMEM_DA_CFGRD | COMEM_DA_ADDR(0x1 << ((dev >> 3) + 16));
- fnsel = (dev & 0x7) << 8;
- swapoffset = (offset & 0xfc) + (~offset & 0x02);
-
- rp[LREG(COMEM_DAHBASE)] = idsel;
- *val = bp[WREG(COMEM_PCIBUS + swapoffset + fnsel)];
-
- return(PCIBIOS_SUCCESSFUL);
-}
-
-/*****************************************************************************/
-
-int pcibios_read_config_byte(unsigned char bus, unsigned char dev,
- unsigned char offset, unsigned char *val)
-{
- volatile unsigned long *rp;
- volatile unsigned char *bp;
- unsigned long idsel, fnsel;
- unsigned char swapoffset;
-
-#ifdef DEBUGPCI
- printk("pcibios_read_config_byte(bus=%x,dev=%x,offset=%x)\n",
- bus, dev, offset);
-#endif
-
- if (bus || ((pci_slotmask & (0x1 << PCI_SLOT(dev))) == 0)) {
- *val = 0xff;
- return(PCIBIOS_SUCCESSFUL);
- }
-
- rp = (volatile unsigned long *) COMEM_BASE;
- bp = (volatile unsigned char *) COMEM_BASE;
- idsel = COMEM_DA_CFGRD | COMEM_DA_ADDR(0x1 << ((dev >> 3) + 16));
- fnsel = (dev & 0x7) << 8;
- swapoffset = (offset & 0xfc) + (~offset & 0x03);
-
- rp[LREG(COMEM_DAHBASE)] = idsel;
- *val = bp[(COMEM_PCIBUS + swapoffset + fnsel)];
-
- return(PCIBIOS_SUCCESSFUL);
-}
-
-/*****************************************************************************/
-
-int pcibios_write_config_dword(unsigned char bus, unsigned char dev,
- unsigned char offset, unsigned int val)
-{
- volatile unsigned long *rp;
- unsigned long idsel, fnsel;
-
-#ifdef DEBUGPCI
- printk("pcibios_write_config_dword(bus=%x,dev=%x,offset=%x,val=%x)\n",
- bus, dev, offset, val);
-#endif
-
- if (bus || ((pci_slotmask & (0x1 << PCI_SLOT(dev))) == 0))
- return(PCIBIOS_SUCCESSFUL);
-
- rp = (volatile unsigned long *) COMEM_BASE;
- idsel = COMEM_DA_CFGRD | COMEM_DA_ADDR(0x1 << ((dev >> 3) + 16));
- fnsel = (dev & 0x7) << 8;
-
- rp[LREG(COMEM_DAHBASE)] = idsel;
- rp[LREG(COMEM_PCIBUS + (offset & 0xfc) + fnsel)] = val;
- return(PCIBIOS_SUCCESSFUL);
-}
-
-/*****************************************************************************/
-
-int pcibios_write_config_word(unsigned char bus, unsigned char dev,
- unsigned char offset, unsigned short val)
-{
-
- volatile unsigned long *rp;
- volatile unsigned short *bp;
- unsigned long idsel, fnsel;
- unsigned char swapoffset;
-
-#ifdef DEBUGPCI
- printk("pcibios_write_config_word(bus=%x,dev=%x,offset=%x,val=%x)\n",
- bus, dev, offset, val);
-#endif
-
- if (bus || ((pci_slotmask & (0x1 << PCI_SLOT(dev))) == 0))
- return(PCIBIOS_SUCCESSFUL);
-
- rp = (volatile unsigned long *) COMEM_BASE;
- bp = (volatile unsigned short *) COMEM_BASE;
- idsel = COMEM_DA_CFGRD | COMEM_DA_ADDR(0x1 << ((dev >> 3) + 16));
- fnsel = (dev & 0x7) << 8;
- swapoffset = (offset & 0xfc) + (~offset & 0x02);
-
- rp[LREG(COMEM_DAHBASE)] = idsel;
- bp[WREG(COMEM_PCIBUS + swapoffset + fnsel)] = val;
- return(PCIBIOS_SUCCESSFUL);
-}
-
-/*****************************************************************************/
-
-int pcibios_write_config_byte(unsigned char bus, unsigned char dev,
- unsigned char offset, unsigned char val)
-{
- volatile unsigned long *rp;
- volatile unsigned char *bp;
- unsigned long idsel, fnsel;
- unsigned char swapoffset;
-
-#ifdef DEBUGPCI
- printk("pcibios_write_config_byte(bus=%x,dev=%x,offset=%x,val=%x)\n",
- bus, dev, offset, val);
-#endif
-
- if (bus || ((pci_slotmask & (0x1 << PCI_SLOT(dev))) == 0))
- return(PCIBIOS_SUCCESSFUL);
-
- rp = (volatile unsigned long *) COMEM_BASE;
- bp = (volatile unsigned char *) COMEM_BASE;
- idsel = COMEM_DA_CFGRD | COMEM_DA_ADDR(0x1 << ((dev >> 3) + 16));
- fnsel = (dev & 0x7) << 8;
- swapoffset = (offset & 0xfc) + (~offset & 0x03);
-
- rp[LREG(COMEM_DAHBASE)] = idsel;
- bp[(COMEM_PCIBUS + swapoffset + fnsel)] = val;
- return(PCIBIOS_SUCCESSFUL);
-}
-
-/*****************************************************************************/
-
-int pcibios_find_device(unsigned short vendor, unsigned short devid,
- unsigned short index, unsigned char *bus, unsigned char *dev)
-{
- unsigned int vendev, val;
- unsigned char devnr;
-
-#ifdef DEBUGPCI
- printk("pcibios_find_device(vendor=%04x,devid=%04x,index=%d)\n",
- vendor, devid, index);
-#endif
-
- if (vendor == 0xffff)
- return(PCIBIOS_BAD_VENDOR_ID);
-
- vendev = (devid << 16) | vendor;
- for (devnr = 0; (devnr < 32); devnr++) {
- pcibios_read_config_dword(0, devnr, PCI_VENDOR_ID, &val);
- if (vendev == val) {
- if (index-- == 0) {
- *bus = 0;
- *dev = devnr;
- return(PCIBIOS_SUCCESSFUL);
- }
- }
- }
-
- return(PCIBIOS_DEVICE_NOT_FOUND);
-}
-
-/*****************************************************************************/
-
-int pcibios_find_class(unsigned int class, unsigned short index,
- unsigned char *bus, unsigned char *dev)
-{
- unsigned int val;
- unsigned char devnr;
-
-#ifdef DEBUGPCI
- printk("pcibios_find_class(class=%04x,index=%d)\n", class, index);
-#endif
-
- /* FIXME: this ignores multi-function devices... */
- for (devnr = 0; (devnr < 128); devnr += 8) {
- pcibios_read_config_dword(0, devnr, PCI_CLASS_REVISION, &val);
- if ((val >> 8) == class) {
- if (index-- == 0) {
- *bus = 0;
- *dev = devnr;
- return(PCIBIOS_SUCCESSFUL);
- }
- }
- }
-
- return(PCIBIOS_DEVICE_NOT_FOUND);
-}
-
-/*****************************************************************************/
-
/*
* Local routines to interrcept the standard I/O and vector handling
* code. Don't include this 'till now - initialization code above needs
^ permalink raw reply
* Re: vt8235 fix, hopefully last variant
From: John Reiser @ 2002-12-19 17:41 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: AnonimoVeneziano, Patrick Petermair, Roland Quast, LKML
In-Reply-To: <20021219112640.A21164@ucw.cz>
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]
Vojtech Pavlik wrote:
> Can you guys try out this last take on a fix for your ATAPI device
> problems? Applies against clean 2.4.20.
Yes, the vt8235-atapi patch works for me; so did vt8235-dvd, but not vt8235-min.
Mitsumi FX4830T ATAPI CD-ROM, MSI KT3 Ultra2 mainboard (KT333), vt8235.
I modified the patch so that it would apply cleanly to RedHatLinux8.0
kernel-2.4.18-18.8.0 as part of "rpm -bb --target i686 kernel-2.4.18.spec".
The result is attached.
--
John Reiser, jreiser@BitWagon.com
[-- Attachment #2: vt8235-atapi-jreiser.patch --]
[-- Type: text/plain, Size: 870 bytes --]
--- linux/drivers/ide/via82cxxx.c.orig Thu Dec 19 08:35:20 2002
+++ linux/drivers/ide/via82cxxx.c Thu Dec 19 08:43:10 2002
@@ -1,5 +1,5 @@
/*
- * Version 3.35
+ * Version 3.36jreiser
*
* VIA IDE driver for Linux. Supported southbridges:
*
@@ -129,7 +129,7 @@
via_print("----------VIA BusMastering IDE Configuration----------------");
- via_print("Driver Version: 3.35");
+ via_print("Driver Version: 3.36jreiser");
via_print("South Bridge: VIA %s", via_config->name);
pci_read_config_byte(isa_dev, PCI_REVISION_ID, &t);
@@ -295,6 +295,10 @@
ide_timing_merge(&p, &t, &t, IDE_TIMING_8BIT);
}
+ /* Always use 4 address setup clocks on ATAPI devices */
+ if (drive->media != ide_disk)
+ t.setup = 4;
+
via_set_speed(HWIF(drive)->pci_dev, drive->dn, &t);
if (!drive->init_speed)
^ permalink raw reply
* 405LP RTC warning patch
From: Hollis Blanchard @ 2002-12-19 17:31 UTC (permalink / raw)
To: embedded list
[-- Attachment #1: Type: text/plain, Size: 237 bytes --]
As David suggested, this patch warns the user if the RTC frequency is
altered by Linux (at least a little time will have been lost during
firmware boot).
Please apply to _2_4_devel.
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
[-- Attachment #2: 405LP-rtc-warn.diff --]
[-- Type: text/plain, Size: 1429 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux 2.4 for PowerPC development tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1179 -> 1.1180
# arch/ppc/platforms/ibm405lp.c 1.5 -> 1.6
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/19 hollis@granite.austin.ibm.com 1.1180
# print a warning message if RTC frequency is altered
# --------------------------------------------
#
diff -Nru a/arch/ppc/platforms/ibm405lp.c b/arch/ppc/platforms/ibm405lp.c
--- a/arch/ppc/platforms/ibm405lp.c Thu Dec 19 11:27:45 2002
+++ b/arch/ppc/platforms/ibm405lp.c Thu Dec 19 11:27:45 2002
@@ -288,7 +288,14 @@
mtdcr(DCRN_RTC0_CR1, 0x80); /* Disable update cycles/interrupts*/
mtdcr(DCRN_RTC0_WRAP, 0); /* toggle NRST & NMR */
mtdcr(DCRN_RTC0_WRAP, 3);
- mtdcr(DCRN_RTC0_CR0, (RTC_DVBITS & 0x7) << 4); /* input clock */
+
+ /* if necessary, set the input clock frequency */
+ if ((mfdcr(DCRN_RTC0_CR0) >> 4) != RTC_DVBITS) {
+ printk(KERN_WARNING "Warning: RTC frequency was incorrect\n");
+ mtdcr(DCRN_RTC0_CR0,
+ ((RTC_DVBITS & 0x7) << 4) | (mfdcr(DCRN_RTC0_CR0) & 0xf));
+ }
+
mtdcr(DCRN_RTC0_CR1, mfdcr(DCRN_RTC0_CR1) & 0x7f); /* allow updates */
not_initialized = 0;
^ permalink raw reply
* re: Dedicated kernel bug database
From: Dan Kegel @ 2002-12-19 17:46 UTC (permalink / raw)
To: John Bradford, linux-kernel
John Bradford <john@grabjohn.com> wrote:
> Following on from yesterday's discussion about there not being much
> interaction between the kernel Bugzilla and the developers, I began
> wondering whether Bugzilla might be a bit too generic to be suited to
> kernel development, and that maybe a system written from the ground up
> for reporting kernel bugs would be better?
>
> I.E. I am prepared to write it myself, if people think it's
> worthwhile.
Quoting Linus (http://marc.theaimsgroup.com/?l=linux-kernel&m=103911905214446&w=2):
> And many things _can_ be done without throwing out old designs.
> Implementation improvements are quite possible without trying to make
> something totally new to the outside. ...
>
> Not throwing out the baby with the bath-water doesn't mean that you cannot
> improve the system. I'm only arguing against stupid people who think they
> need a revolution to improve - most real improvements are evolutionary.
I bet the thing to do is to spend some time as one of the
elves who make bugzilla.kernel.org work smoothly despite
the software; then figure out what incremental tweak you
can make to the software to make the elves' and users' lives
better.
--
Dan Kegel
Linux User #78045
http://www.kegel.com
^ permalink raw reply
* Re: bug-tracking system.
From: Takashi Iwai @ 2002-12-19 17:30 UTC (permalink / raw)
To: tomasz motylewski; +Cc: alsa-devel
In-Reply-To: <Pine.LNX.4.21.0212191243440.15313-100000@mailserver.intern.bfad.de>
At Thu, 19 Dec 2002 13:06:06 +0100 (CET),
tomasz motylewski wrote:
>
> On Thu, 19 Dec 2002, Takashi Iwai wrote:
>
> > > PS: recently, new people started working on Debian's ALSA packages.
> > > We'll try to forward all the bugs and patches that have piled up against
> > > our packages in the previous era. What's the prefered way of reporting
> > > bugs and problems against alsa packages components?
> >
> > please post to alsa-devel. the bug tracking system seems not working
> > effectively, so far...
>
> Do you mean SourceForge?
yes.
> Don't you think it should be documented THERE?
> Something like "please do not use, post reports to alsa-devel...".
yeah, IMHO, it would be better.
> It usually works like that: relatively new user/developer finds a bug, clicks
> "Bug reporting" from ALSA homepage and is in a system which "seems not working
> effectively".
please note that the above comment is only my own.
it's likely biased much, since i prefer a system like bugzilla to sf's
one. or, simply posts on devel ML, which is well archived.
for me, sf's tracking system is nothing but annoying.
again, this is just my opinion.
the current system might be helpful, for example, for jaroslav.
but anyway, the situation atm looks not good; unresolved bugs has
been growing and piled up, because no one moderates and assigns the
bugs.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: [PATCH] (4/5) improved notifier callback mechanism - read copy update
From: Stephen Hemminger @ 2002-12-19 17:37 UTC (permalink / raw)
To: vamsi, John Levon; +Cc: Linus Torvalds, Alan Cox, Kernel List
In-Reply-To: <20021219181929.A5265@in.ibm.com>
Thanks, will look into it in more detail. Perhaps figuring out how to do
oprofile without sleeping would be best.
On Thu, 2002-12-19 at 04:49, Vamsi Krishna S . wrote:
> Hi Stephen,
>
> On Wed, Dec 18, 2002 at 11:06:08PM +0000, Stephen Hemminger wrote:
> > The notifier interface was only partially locked. The
> > notifier_call_chain needs to be called in places where it is impossible
> > to safely without having deadlocks; for example, NMI watchdog timeout.
> >
> > This patch uses read-copy-update to manage the list. One extra bit of
> > safety is using a reference count on the notifier_blocks to allow for
> > cases like oprofile which need to sleep in a callback.
> >
> <snip>
> >
> > int notifier_call_chain(struct list_head *list, unsigned long val, void
> > *v)
> > {
> > - struct list_head *p;
> > + struct list_head *p, *nxtp;
> > int ret = NOTIFY_DONE;
> >
> > - list_for_each(p, list) {
> > + rcu_read_lock();
> > + list_for_each_safe_rcu(p, nxtp, list) {
> > struct notifier_block *nb =
> > list_entry(p, struct notifier_block, link);
> >
> > + atomic_inc(&nb->inuse);
> > ret = nb->notifier_call(nb,val,v);
> > + atomic_dec(&nb->inuse);
> > +
>
> There could be a small problem here. When rcu_read_lock() is called,
> it bumps the preempt_count, so when the called handler attempts
> to sleep, it will oops with "Bad: scheduling in atomic region".
--
Stephen Hemminger <shemminger@osdl.org>
Open Source Devlopment Lab
^ permalink raw reply
* Re: Hammerfall configuration
From: Paul Davis @ 2002-12-19 17:28 UTC (permalink / raw)
To: patrick reardon; +Cc: alsa-devel
In-Reply-To: <3E01FA02.D0B4CD44@earthlink.net>
>by hand, changing the 'Sync Mode' value from AutoSync to Master
>(should these values be in quotes?), ran "alsactl store hammerfall",
>unloaded then reloaded the alsa m odules, then ran "alsactl restore
>hammerfall. ("hammerfall" is the card's id.) but asound .state
>still indicates Sync Mode is set to AutoSync. "vi
>/proc/asound/hammerfall/rme 9652" reads
you got the process wrong.
1) alsactl store hammerfall
2) edit file
3) alsactl restore hammerfall
no driver unload/load is needed. each time you reload the module
without the 3rd step, you get back to the driver's own default
settings.
>i'm also curious if the "IEC958 sample rate: error flag set" is normal and if
>not, what to
>look at to fix it. asound.state says
it means you have no s/pdif input.
--p
-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now! Before the Holidays pass you by.
T H I N K G E E K . C O M http://www.thinkgeek.com/sf/
^ permalink raw reply
* Re: Dedicated kernel bug database
From: Brian Jackson @ 2002-12-19 17:33 UTC (permalink / raw)
To: John Bradford; +Cc: linux-kernel
In-Reply-To: <200212191335.gBJDZRDL000704@darkstar.example.net>
I would just like to second what somebody said about bugzilla yesterday,
that it is hard to search for bugs that have already been entered. Just
something to think about.
--Brian Jackson
John Bradford writes:
> Following on from yesterday's discussion about there not being much
> interaction between the kernel Bugzilla and the developers, I began
> wondering whether Bugzilla might be a bit too generic to be suited to
> kernel development, and that maybe a system written from the ground up
> for reporting kernel bugs would be better?
>
> I.E. I am prepared to write it myself, if people think it's
> worthwhile.
>
> For example, we get a lot of posts on LKML like this:
>
> "Hi, foobar doesn't work in 2.4.19"
>
> Now, does that mean:
>
> * The bug first appeared in 2.4.19, and is still in 2.4.20
> * The bug reporter hasn't tested 2.4.20
> * The bug reporter can't test 2.4.20 because something else is broken
> * The bug actually first appeared in 2.4.10, but it didn't irritate
> them enough to complain until now.
>
> A bug database designed from scratch could allow such information to
> be indexed in a way that could be processed and searched usefully. A
> list of tick-boxes for worked/didn't work/didn't test/couldn't test
> for several kernel versions could be presented.
>
> Also, we could have a non-web interface, (telnet or gopher to the bug
> DB, or control it by E-Mail).
>
> It could warn the user if they attach an un-decoded oops that their
> bug report isn't as useful as it could be, and if they mention a
> distribution kernel version, that it's not a tree that the developers
> will necessarily be familiar with.
>
> I'm not criticising the fact that we've got Bugzilla up and running,
> but just pointing out that we could do better, (and I'm prepared to
> put in the time and effort). I just need ideas, really.
>
> John.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" 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.tux.org/lkml/
^ permalink raw reply
* Problems with arbitrary TOS-field settings.
From: Rasmus Aveskogh @ 2002-12-19 17:15 UTC (permalink / raw)
To: netfilter; +Cc: erland.almstrom
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
Hi.
I'm having some trouble setting the TOS-field in the IP header _to an arbitrary value_
using iptables.
To manage to do this I first patched iptables (1.2.5) and my kernel (2.4.18-3) with
the patches for FTOS. I recompiled and reinstalled but ended up with:
# iptables -t mangle -A OUTPUT -j FTOS --set-ftos 128
iptables: No chain/target/match by that name
"Ok? Well I might as well upgrade to latest iptables and latest kernel-patches"
Though and done, iptables 1.2.7a installed and all the "patch-o-matic"-patches
installed. According to the documentation the TOS/FTOS-features was now obsolete
in favor of the DSCP option. So I tried again:
# iptables -t mangle -A OUTPUT -j DSCP --set-dscp 128
iptables: No chain/target/match by that name
Well, it says somewhere that only values up to 0x4f was supported
by DSCP, but a lower values doesn't affect the error.
FTOS still seems to be part of the cose though, but same error occurs.
What can I do to fix this? And even if DSCP works, how can I set the 8 IP-header
TOS-bits to a value between 0x00 and 0xff?
Thanks in advance
Rasmus Aveskogh - Utfors AB
[-- Attachment #2: Type: text/html, Size: 2285 bytes --]
^ permalink raw reply
* [RESEND}: owner socket lookup
From: Patrick McHardy @ 2002-12-19 17:03 UTC (permalink / raw)
To: Harald Welte; +Cc: Netfilter Development Mailinglist
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Hi Harald,
about two or three month ago i sent you a pom-patch for the owner match
so it also works in
PREROUTING and INPUT chains. I never received a final response from you.
Please just tell
me your decision so i know it didn't got lost.
This version has bugfixes, the first one had some mixups (saddr instead
of daddr for
udp_v4_lookup) and also didn't release sockets after lookups.
Thanks,
Patrick
[-- Attachment #2: owner-v4-pom.diff-2 --]
[-- Type: text/plain, Size: 7523 bytes --]
diff -urN patch-o-matic-20020825-orig/extra/owner-socketlookup.patch patch-o-matic-20020825/extra/owner-socketlookup.patch
--- patch-o-matic-20020825-orig/extra/owner-socketlookup.patch 1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic-20020825/extra/owner-socketlookup.patch 2002-12-19 17:51:24.000000000 +0100
@@ -0,0 +1,201 @@
+diff -urN linux-2.4.19-clean/include/net/tcp.h linux-2.4.19/include/net/tcp.h
+--- linux-2.4.19-clean/include/net/tcp.h 2002-08-03 02:39:46.000000000 +0200
++++ linux-2.4.19/include/net/tcp.h 2002-12-19 17:42:45.000000000 +0100
+@@ -140,6 +140,7 @@
+ extern void tcp_bucket_unlock(struct sock *sk);
+ extern int tcp_port_rover;
+ extern struct sock *tcp_v4_lookup_listener(u32 addr, unsigned short hnum, int dif);
++extern struct sock *tcp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 hnum, int dif);
+
+ /* These are AF independent. */
+ static __inline__ int tcp_bhashfn(__u16 lport)
+diff -urN linux-2.4.19-clean/include/net/udp.h linux-2.4.19/include/net/udp.h
+--- linux-2.4.19-clean/include/net/udp.h 2001-11-22 20:47:15.000000000 +0100
++++ linux-2.4.19/include/net/udp.h 2002-12-19 17:42:45.000000000 +0100
+@@ -69,6 +69,8 @@
+ extern int udp_ioctl(struct sock *sk, int cmd, unsigned long arg);
+ extern int udp_disconnect(struct sock *sk, int flags);
+
++extern struct sock *udp_v4_lookup(u32 saddr, u16 sport, u32 daddr, u16 dport, int dif);
++
+ extern struct udp_mib udp_statistics[NR_CPUS*2];
+ #define UDP_INC_STATS(field) SNMP_INC_STATS(udp_statistics, field)
+ #define UDP_INC_STATS_BH(field) SNMP_INC_STATS_BH(udp_statistics, field)
+diff -urN linux-2.4.19-clean/net/ipv4/netfilter/ipt_owner.c linux-2.4.19/net/ipv4/netfilter/ipt_owner.c
+--- linux-2.4.19-clean/net/ipv4/netfilter/ipt_owner.c 2002-12-19 17:43:07.000000000 +0100
++++ linux-2.4.19/net/ipv4/netfilter/ipt_owner.c 2002-12-19 17:47:38.000000000 +0100
+@@ -2,17 +2,26 @@
+ locally generated outgoing packets.
+
+ Copyright (C) 2000 Marc Boucher
++
++ 08/28/2002 Patrick McHardy <kaber@trash.net>
++ - Modified to also match properties of receiving sockets
+ */
+ #include <linux/module.h>
+ #include <linux/skbuff.h>
+ #include <linux/file.h>
++#include <linux/ip.h>
++#include <linux/tcp.h>
++#include <linux/udp.h>
+ #include <net/sock.h>
++#include <net/tcp.h>
++#include <net/udp.h>
++#include <net/route.h>
+
+ #include <linux/netfilter_ipv4/ipt_owner.h>
+ #include <linux/netfilter_ipv4/ip_tables.h>
+
+ static int
+-match_comm(const struct sk_buff *skb, const char *comm)
++match_comm(const struct sock *sk, const char *comm)
+ {
+ struct task_struct *p;
+ struct files_struct *files;
+@@ -28,7 +37,7 @@
+ if(files) {
+ read_lock(&files->file_lock);
+ for (i=0; i < files->max_fds; i++) {
+- if (fcheck_files(files, i) == skb->sk->socket->file) {
++ if (fcheck_files(files, i) == sk->socket->file) {
+ read_unlock(&files->file_lock);
+ task_unlock(p);
+ read_unlock(&tasklist_lock);
+@@ -44,7 +53,7 @@
+ }
+
+ static int
+-match_pid(const struct sk_buff *skb, pid_t pid)
++match_pid(const struct sock *sk, pid_t pid)
+ {
+ struct task_struct *p;
+ struct files_struct *files;
+@@ -59,7 +68,7 @@
+ if(files) {
+ read_lock(&files->file_lock);
+ for (i=0; i < files->max_fds; i++) {
+- if (fcheck_files(files, i) == skb->sk->socket->file) {
++ if (fcheck_files(files, i) == sk->socket->file) {
+ read_unlock(&files->file_lock);
+ task_unlock(p);
+ read_unlock(&tasklist_lock);
+@@ -75,10 +84,10 @@
+ }
+
+ static int
+-match_sid(const struct sk_buff *skb, pid_t sid)
++match_sid(const struct sock *sk, pid_t sid)
+ {
+ struct task_struct *p;
+- struct file *file = skb->sk->socket->file;
++ struct file *file = sk->socket->file;
+ int i, found=0;
+
+ read_lock(&tasklist_lock);
+@@ -119,41 +128,67 @@
+ int *hotdrop)
+ {
+ const struct ipt_owner_info *info = matchinfo;
++ struct sock *sk = NULL;
++ int ret = 0;
+
+- if (!skb->sk || !skb->sk->socket || !skb->sk->socket->file)
+- return 0;
++ if (out) {
++ sk = skb->sk;
++ } else {
++ struct iphdr *iph = skb->nh.iph;
++ if (iph->protocol == IPPROTO_TCP) {
++ struct tcphdr *tcph =
++ (struct tcphdr*)((u_int32_t*)iph + iph->ihl);
++ sk = tcp_v4_lookup(iph->saddr, tcph->source,
++ iph->daddr, tcph->dest,
++ ((struct rtable*)skb->dst)->rt_iif);
++ } else if (iph->protocol == IPPROTO_UDP) {
++ struct udphdr *udph =
++ (struct udphdr*)((u_int32_t*)iph + iph->ihl);
++ sk = udp_v4_lookup(iph->saddr, udph->source, iph->daddr,
++ udph->dest, skb->dev->ifindex);
++ }
++ }
++
++ if (!sk || !sk->socket || !sk->socket->file)
++ goto out;
+
+ if(info->match & IPT_OWNER_UID) {
+- if((skb->sk->socket->file->f_uid != info->uid) ^
++ if((sk->socket->file->f_uid != info->uid) ^
+ !!(info->invert & IPT_OWNER_UID))
+- return 0;
++ goto out;
+ }
+
+ if(info->match & IPT_OWNER_GID) {
+- if((skb->sk->socket->file->f_gid != info->gid) ^
++ if((sk->socket->file->f_gid != info->gid) ^
+ !!(info->invert & IPT_OWNER_GID))
+- return 0;
++ goto out;
+ }
+
+ if(info->match & IPT_OWNER_PID) {
+- if (!match_pid(skb, info->pid) ^
++ if (!match_pid(sk, info->pid) ^
+ !!(info->invert & IPT_OWNER_PID))
+- return 0;
++ goto out;
+ }
+
+ if(info->match & IPT_OWNER_SID) {
+- if (!match_sid(skb, info->sid) ^
++ if (!match_sid(sk, info->sid) ^
+ !!(info->invert & IPT_OWNER_SID))
+- return 0;
++ goto out;
+ }
+
+ if(info->match & IPT_OWNER_COMM) {
+- if (!match_comm(skb, info->comm) ^
++ if (!match_comm(sk, info->comm) ^
+ !!(info->invert & IPT_OWNER_COMM))
+- return 0;
++ goto out;
+ }
+
+- return 1;
++ ret = 1;
++
++out:
++ if (in && sk)
++ sock_put(sk);
++
++ return ret;
+ }
+
+ static int
+@@ -164,8 +199,10 @@
+ unsigned int hook_mask)
+ {
+ if (hook_mask
+- & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING))) {
+- printk("ipt_owner: only valid for LOCAL_OUT or POST_ROUTING.\n");
++ & ~((1 << NF_IP_LOCAL_OUT) | (1 << NF_IP_POST_ROUTING) |
++ (1 << NF_IP_LOCAL_IN) | (1 << NF_IP_PRE_ROUTING))) {
++ printk("ipt_owner: only valid for LOCAL_OUT, LOCAL_IN, "
++ "POST_ROUTING or PRE_ROUTING.\n");
+ return 0;
+ }
+
+diff -urN linux-2.4.19-clean/net/netsyms.c linux-2.4.19/net/netsyms.c
+--- linux-2.4.19-clean/net/netsyms.c 2002-08-03 02:39:46.000000000 +0200
++++ linux-2.4.19/net/netsyms.c 2002-12-19 17:42:45.000000000 +0100
+@@ -588,4 +588,9 @@
+ EXPORT_SYMBOL(net_call_rx_atomic);
+ EXPORT_SYMBOL(softnet_data);
+
++#if defined(CONFIG_IP_NF_MATCH_OWNER)||defined(CONFIG_IP_NF_MATCH_OWNER_MODULE)
++EXPORT_SYMBOL(tcp_v4_lookup);
++EXPORT_SYMBOL(udp_v4_lookup);
++#endif /* CONFIG_IP_NF_MATCH_OWNER */
++
+ #endif /* CONFIG_NET */
diff -urN patch-o-matic-20020825-orig/extra/owner-socketlookup.patch.help patch-o-matic-20020825/extra/owner-socketlookup.patch.help
--- patch-o-matic-20020825-orig/extra/owner-socketlookup.patch.help 1970-01-01 01:00:00.000000000 +0100
+++ patch-o-matic-20020825/extra/owner-socketlookup.patch.help 2002-12-19 17:31:05.000000000 +0100
@@ -0,0 +1,13 @@
+Author: Patrick McHardy <kaber@trash.net>
+Status: working
+
+The patch allows you to use the owner match in the INPUT/PREROUTING chains to
+match properties of the receiving socket.
+
+Example:
+
+ # Allow packets coming in on eth0 to sockets owned be local user
+ # kaber
+
+ iptables -A INPUT -i eth0 -m owner --uid-owner kaber -j ACCEPT
+
^ permalink raw reply
* mremap use-after-free [was Re: 2.5.52-mm2]
From: Hugh Dickins @ 2002-12-19 17:02 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml, linux-mm
In-Reply-To: <3E01943B.4170B911@digeo.com>
On Thu, 19 Dec 2002, Andrew Morton wrote:
> Andrew Morton wrote:
> > ...
> > slab-poisoning.patch
> > more informative slab poisoning
>
> This patch has exposed a quite long-standing use-after-free bug in
> mremap(). It make the machine go BUG when starting the X server if
> memory debugging is turned on.
Good catch, shame about the patch!
Please don't apply this, or its 2.4 sister, as is.
> The bug might be present in 2.4 as well..
I doubt that (but may be wrong, I haven't time right now to think as
twistedly as mremap demands). The code (patently!) expects new_vma
to be good at the end, it certainly wasn't intending to unmap it;
but 2.5 split_vma has been through a couple of convulsions, either
of which might have resulted in the potential for new_vma to be
freed where before it was guaranteed to remain.
Do you know the vmas before and after, and the mremap which did this?
I couldn't reproduce it starting X here, and an example would help to
uncloud my mind. But you can reasonably answer that one example won't
prove anything, and where there's doubt, the code must be defensive.
(Besides, I'll be offline shortly.)
On to the patch...
> --- 25/mm/mremap.c~move_vma-use-after-free Thu Dec 19 00:51:49 2002
> +++ 25-akpm/mm/mremap.c Thu Dec 19 01:08:45 2002
> @@ -183,14 +183,16 @@ static unsigned long move_vma(struct vm_
> next = find_vma_prev(mm, new_addr, &prev);
> if (next) {
> if (prev && prev->vm_end == new_addr &&
> - can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
> + can_vma_merge(prev, vma->vm_flags) &&
> + !(vma->vm_flags & VM_SHARED)) {
> spin_lock(&mm->page_table_lock);
> prev->vm_end = new_addr + new_len;
> spin_unlock(&mm->page_table_lock);
> new_vma = prev;
> if (next != prev->vm_next)
> BUG();
> - if (prev->vm_end == next->vm_start && can_vma_merge(next, prev->vm_flags)) {
> + if (prev->vm_end == next->vm_start &&
> + can_vma_merge(next, prev->vm_flags)) {
> spin_lock(&mm->page_table_lock);
> prev->vm_end = next->vm_end;
> __vma_unlink(mm, next, prev);
> @@ -201,7 +203,8 @@ static unsigned long move_vma(struct vm_
> kmem_cache_free(vm_area_cachep, next);
> }
> } else if (next->vm_start == new_addr + new_len &&
> - can_vma_merge(next, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
> + can_vma_merge(next, vma->vm_flags) &&
> + !(vma->vm_flags & VM_SHARED)) {
> spin_lock(&mm->page_table_lock);
> next->vm_start = new_addr;
> spin_unlock(&mm->page_table_lock);
> @@ -210,7 +213,8 @@ static unsigned long move_vma(struct vm_
> } else {
> prev = find_vma(mm, new_addr-1);
> if (prev && prev->vm_end == new_addr &&
> - can_vma_merge(prev, vma->vm_flags) && !vma->vm_file && !(vma->vm_flags & VM_SHARED)) {
> + can_vma_merge(prev, vma->vm_flags) &&
> + !(vma->vm_flags & VM_SHARED)) {
> spin_lock(&mm->page_table_lock);
> prev->vm_end = new_addr + new_len;
> spin_unlock(&mm->page_table_lock);
Hmmm. Am I right to suppose that all the changes above are "cleanup"
which you couldn't resist making while you looked through this code,
but entirely irrelevant to the bug in question? If those mods above
were right, they should be the subject of a separate patch.
There's certainly room for cleanup there, but my preference would be
to remove "can_vma_merge" completely, or at least its use in mremap.c,
using its explicit tests instead. It looks like it was originally
quite appropriate for a use or two in mmap.c, but obscurely unhelpful
here - because in itself it is testing a bizarre asymmetric subset of
what's needed (that subset which remained to be tested in its original
use in mmap.c).
The problem with your changes above is, you've removed the !vma->vm_file
tests, presumably because you noticed that can_vma_merge already tests
!vma->vm_file. But "vma" within can_vma_merge is "prev" or "next" here:
they are distinct tests, and you're now liable to merge an anonymous
mapping with a private file mapping - nice if it's from /dev/zero,
but otherwise not. Please just cut those hunks out.
(Of course, I wouldn't have spotted this if I hadn't embarked on,
then retreated from, a similar cleanup myself a few months back.)
> @@ -227,12 +231,16 @@ static unsigned long move_vma(struct vm_
> }
>
> if (!move_page_tables(vma, new_addr, addr, old_len)) {
> + unsigned long must_fault_in;
> + unsigned long fault_in_start;
> + unsigned long fault_in_end;
> +
> if (allocated_vma) {
> *new_vma = *vma;
> INIT_LIST_HEAD(&new_vma->shared);
> new_vma->vm_start = new_addr;
> new_vma->vm_end = new_addr+new_len;
> - new_vma->vm_pgoff += (addr - vma->vm_start) >> PAGE_SHIFT;
> + new_vma->vm_pgoff += (addr-vma->vm_start) >> PAGE_SHIFT;
Hrrmph.
> if (new_vma->vm_file)
> get_file(new_vma->vm_file);
> if (new_vma->vm_ops && new_vma->vm_ops->open)
> @@ -251,19 +259,25 @@ static unsigned long move_vma(struct vm_
> } else
> vma = NULL; /* nothing more to do */
>
> - do_munmap(current->mm, addr, old_len);
> -
Anguished cry! There was careful manipulation of VM_ACCOUNT before and
after do_munmap, now you've for no reason moved do_munmap down outside.
> /* Restore VM_ACCOUNT if one or two pieces of vma left */
> if (vma) {
> vma->vm_flags |= VM_ACCOUNT;
> if (split)
> vma->vm_next->vm_flags |= VM_ACCOUNT;
> }
> +
> + must_fault_in = new_vma->vm_flags & VM_LOCKED;
> + fault_in_start = new_vma->vm_start;
> + fault_in_end = new_vma->vm_end;
> +
> + do_munmap(current->mm, addr, old_len);
> +
> + /* new_vma could have been invalidated by do_munmap */
> +
> current->mm->total_vm += new_len >> PAGE_SHIFT;
> - if (new_vma->vm_flags & VM_LOCKED) {
> + if (must_fault_in) {
> current->mm->locked_vm += new_len >> PAGE_SHIFT;
> - make_pages_present(new_vma->vm_start,
> - new_vma->vm_end);
> + make_pages_present(fault_in_start, fault_in_end);
> }
> return new_addr;
> }
But the bugfix part of it looks good.
Hugh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Promise SX6000 question.
From: Seth Hall @ 2002-12-19 17:02 UTC (permalink / raw)
To: linux-raid@vger.kernel.org; +Cc: linuxcomments, Jordan Rhody, support, support
Hi,
I am using a Promise SX6000 RAID controller and five Seagate 120GB drives to
create a 480GB RAID-5 array, to be used under Slackware v8.1. I was able to
compile and load the Promise pti_st.o module, and subsequently was able to
create a single new large partition on the /dev/sda1 drive, as follows:
Disk /dev/sda1: 64 heads, 32 sectors, 457758 cylinders
Units = cylinders of 2048 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1p1 1 457758 468744176 83 Linux
The problem is I cannot seem to create a file system on this new partition. I
was assuming that ext3 would be a good initial choice, at least while we were
fooling around using this new array.
Any thoughts about what I might be doing wrong, or what I might be missing?
Thanks,
Seth Hall
Speech Comm. Group
MIT, Cambridge
^ 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.