Re: USBDEVFS_URB_TYPE_INTERRUPT
Sigh. What do half the answers always show up seconds after clicking 'Send'? I see there is a FILL_URB_INT macro in linux/usb.h, but the only things using it seem to be drivers (as opposed to usbstress, libusb, etc). The ioctl call supports USBDEVFS_SUBMITURB, but passing a type USBDEVFS_URB_TYPE_INTERRUPT returns EINVAL. If the ioctl calls are the 'proper' way to talk to the USB drivers, should my code be calling usb_submit_urb directly if I want to pass interrupt type messages? I don't really want to write a full-up kernel mode driver for this device, but interrupt type messages are the preferred method for communicating, since once a message needs to be sent, it should be timely (whereas control messages could be delayed a significant amount on a busy USB channel). -- John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI is as SCSI don't...
On Tue, Jun 05, 2001 at 11:08:04PM -0700, Alan Olsen wrote: > The basic effect is that the kernel will not load. Something breaks hard > in it. Any clue on what the last thing printed to the kernel log is? Hardware you have? .config for the kernel? Come on Alan, I know you can give better bug reports than that :) greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USBDEVFS_URB_TYPE_INTERRUPT
On Wed, Jun 06, 2001 at 01:31:41AM -0400, John Chris Wren wrote: > > I was designing a USB based device and was looking through the 2.4.5 kernel > code, and noticed that while it supports bulk, iso, and control types, there > is no support for interrupt types. A grep through the entire kernel source > code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in > linux/usbdevice_fs.h, but no where is it used. Any thoughts as to why that > might be? > > A google search didn't seem to turn up any answers either. Try this thread for why it is not supported: http://marc.theaimsgroup.com/?l=linux-usb-devel=99004006207974=2 If you still have questions about this, the linux-usb-devel mailing list is the better place to discuss it. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USBDEVFS_URB_TYPE_INTERRUPT
I was designing a USB based device and was looking through the 2.4.5 kernel code, and noticed that while it supports bulk, iso, and control types, there is no support for interrupt types. A grep through the entire kernel source code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in linux/usbdevice_fs.h, but no where is it used. Any thoughts as to why that might be? A google search didn't seem to turn up any answers either. -- John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI is as SCSI don't...
Forgot to list my working environment... Redhat 7.1 patched to pretty close to the latest. (As of a week ago or so.) P-III 600 with 256 megs of ram and lots of disk, so resource starvation is not an issue. (Unless something got REALLY big in the last few patches.) On Tue, 5 Jun 2001, Alan Olsen wrote: > I am trying to get 2.4.5 and/or 2.4.5-ac9 working. Both are choking on > compile with an odd error message or four... > > In file included from /usr/src/linux-2.4.5-ac9/include/linux/raid/md.h:50, > from ll_rw_blk.c:30: > /usr/src/linux-2.4.5-ac9/include/linux/raid/md_k.h: In function > `pers_to_level':/usr/src/linux-2.4.5-ac9/include/linux/raid/md_k.h:41: > warning: control reaches end of non-void function > > I am seeing similar messages in the AIC7xxx code. > > The basic effect is that the kernel will not load. Something breaks hard > in it. > > My C is pretty rusty. (Too much IS work as of late...) Does anyone know > what this message is and why it is occuring? > > I am currently using 2.4.4-ac11 and it does not have this problem. > > My reason for upgrading is that cdrecord gave me the following error, and > I was hoping that 2.4.5 would have fixed it... > > Starting new track at sector: 0 > CDB: 2A 00 00 00 9E FF 00 00 1F 80 > cdrecord: Input/output error. write_teac_g1: scsi sendcmd: retryable error > Sense Bytes: 70 00 0B 00 00 00 00 0A 00 00 00 01 BA 00 00 00 > status: 0x2 (CHECK CONDITION) > Sense Key: 0xB Aborted Command, Segment 0 > Sense Code: 0xBA Qual 0x00 (no write data - buffer empty) Fru 0x0 > Sense flags: Blk 0 (not valid) > > cdrecord: Input/output error. write_teac_g1: scsi sendcmd: retryable error > write track data: error after 83359744 bytes > status: 0x2 (CHECK CONDITION) > Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 > WARNING: adding dummy block to close track. > CDB: 2A 00 00 00 9E FF 00 00 01 00 > Sense Bytes: 70 00 0B 00 00 00 00 0A 00 00 00 01 BA 00 00 00 > Sense Key: 0xB Aborted Command, Segment 0 > Sense Code: 0xBA Qual 0x00 (no write data - buffer empty) Fru 0x0 > Sense flags: Blk 0 (not valid) > > Ideas...? (At least it give me time to finish Linus's autobiography while > I am rebuilding things, but I am quickly running out of book. ]:> ) > > [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply > Alan Olsen| to my mail, just hit the ctrl, alt and del keys. > "In the future, everything will have its 15 minutes of blame." > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SCSI is as SCSI don't...
I am trying to get 2.4.5 and/or 2.4.5-ac9 working. Both are choking on compile with an odd error message or four... In file included from /usr/src/linux-2.4.5-ac9/include/linux/raid/md.h:50, from ll_rw_blk.c:30: /usr/src/linux-2.4.5-ac9/include/linux/raid/md_k.h: In function `pers_to_level':/usr/src/linux-2.4.5-ac9/include/linux/raid/md_k.h:41: warning: control reaches end of non-void function I am seeing similar messages in the AIC7xxx code. The basic effect is that the kernel will not load. Something breaks hard in it. My C is pretty rusty. (Too much IS work as of late...) Does anyone know what this message is and why it is occuring? I am currently using 2.4.4-ac11 and it does not have this problem. My reason for upgrading is that cdrecord gave me the following error, and I was hoping that 2.4.5 would have fixed it... Starting new track at sector: 0 CDB: 2A 00 00 00 9E FF 00 00 1F 80 cdrecord: Input/output error. write_teac_g1: scsi sendcmd: retryable error Sense Bytes: 70 00 0B 00 00 00 00 0A 00 00 00 01 BA 00 00 00 status: 0x2 (CHECK CONDITION) Sense Key: 0xB Aborted Command, Segment 0 Sense Code: 0xBA Qual 0x00 (no write data - buffer empty) Fru 0x0 Sense flags: Blk 0 (not valid) cdrecord: Input/output error. write_teac_g1: scsi sendcmd: retryable error write track data: error after 83359744 bytes status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 WARNING: adding dummy block to close track. CDB: 2A 00 00 00 9E FF 00 00 01 00 Sense Bytes: 70 00 0B 00 00 00 00 0A 00 00 00 01 BA 00 00 00 Sense Key: 0xB Aborted Command, Segment 0 Sense Code: 0xBA Qual 0x00 (no write data - buffer empty) Fru 0x0 Sense flags: Blk 0 (not valid) Ideas...? (At least it give me time to finish Linus's autobiography while I am rebuilding things, but I am quickly running out of book. ]:> ) [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "In the future, everything will have its 15 minutes of blame." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
Quite positive it's the right map file. I used -m and specified the exact file. David Jeff Garzik wrote: >David Ford wrote: > >> >>EIP; c01269f9<= >>Trace; c01b1021 >>Trace; c01b1c43 >>Trace; c01b2643 >>Trace; c0137fc0 <__emul_lookup_dentry+a4/fc> >>Trace; c0138871 >>Trace; c0167ccb >>Trace; c012e389 >>Trace; c012e2c2 >> > >This trace looks corrupted to me... are you sure that System.map for the >crashed kernel matches -exactly- with the one ksymoops used to decode >this? It uses /proc/ksyms by default, which is incorrect for most >postmortem ksymoops runs... > >rtl8139_interrupt doesn't call tx_timeout, which doesn't call >read_eeprom, which doesn't call proc_getdata. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
David Ford wrote: > >>EIP; c01269f9<= > Trace; c01b1021 > Trace; c01b1c43 > Trace; c01b2643 > Trace; c0137fc0 <__emul_lookup_dentry+a4/fc> > Trace; c0138871 > Trace; c0167ccb > Trace; c012e389 > Trace; c012e2c2 This trace looks corrupted to me... are you sure that System.map for the crashed kernel matches -exactly- with the one ksymoops used to decode this? It uses /proc/ksyms by default, which is incorrect for most postmortem ksymoops runs... rtl8139_interrupt doesn't call tx_timeout, which doesn't call read_eeprom, which doesn't call proc_getdata. -- Jeff Garzik | An expert is one who knows more and more about Building 1024| less and less until he knows absolutely everything MandrakeSoft | about nothing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac9
2.4.5-ac8 has a brokenness about it.
sshd stalled in [down] with the following, subsequent sshd attempts
which needed a tty resulted in D state the same as the first:
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001b ebx: c13bf768 ecx: c0345060 edx: 2c76
esi: c0a54000 edi: c0a549aa ebp: c0a549aa esp: c57afe54
ds: 0018 es: 0018 ss: 0018
Process sshd (pid: 3627, stackpage=c57af000)
Stack: c02cab45 04dc 800a c03dc900 c03dc900 1000
0246
c01b1021 0c3c 0007 c03dc900 c01b1c43 000a c03dc900
c03dc900
c13c9e50 000a
c13c9e50
Call Trace: [] [] [] []
[]
[] [] [] [] []
Code: 0f 0b 83 c4 08 89 f6 f6 43 11 04 74 51 b8 a5 c2 0f 17 87 06
>>EIP; c01269f9<=
Trace; c01b1021
Trace; c01b1c43
Trace; c01b2643
Trace; c0137fc0 <__emul_lookup_dentry+a4/fc>
Trace; c0138871
Trace; c0167ccb
Trace; c012e389
Trace; c012e2c2
Trace; c012e5b0
Trace; c0106a93
Code; c01269f9
<_EIP>:
Code; c01269f9<=
0: 0f 0b ud2a <=
Code; c01269fb
2: 83 c4 08 add$0x8,%esp
Code; c01269fe
5: 89 f6 mov%esi,%esi
Code; c0126a00
7: f6 43 11 04 testb $0x4,0x11(%ebx)
Code; c0126a04
b: 74 51 je 5e <_EIP+0x5e> c0126a57
Code; c0126a06
d: b8 a5 c2 0f 17mov$0x170fc2a5,%eax
Code; c0126a0b
12: 87 06 xchg %eax,(%esi)
Alan Cox wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/
>
>Intermediate diffs are available from
> http://www.bzimage.org
>
>In terms of going through the code audit almost all the sound drivers still
>need fixing to lock against format changes during a read/write. Poll creating
>and starting a buffer as write does and also mmap during write, write during
>an mmap.
>
>2.4.5-ac9
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Network Performance Testing Summary
On Wed, Jun 06, 2001 at 02:52:03AM +, John William wrote: > > The curse of the HP Vectra XU 5/90 strikes again! > > What is interesting is that I tried the NetGear FA310, FA311, 3COM 3cSOHO > and 3C905C-TX cards and both the receive and transmit speeds (measured with > both iperf and netperf) were so close to each other as to be a non-issue. > > Several people e-mailed me to let me know that "card 'X' performance is > terrible, I can only get good performance with card 'Y'". So, I just thought > I should send this message out to set things a bit straight. Did you monitor CPU usage during these tests? I did some throughput comparing a DLink RTL8139 based card to a 3C905C-TX card on a K6-2 450. Both managed to fully saturate 100Mbps. However, the DLink used up ~90% CPU, and the 3Com only used about 50% CPU. This was on 2.4.5, with the 8139too driver from 2.4.3. -Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fix for initrd panic in 2.4.5
Not many people have seen this, but the i_bdev field in fake_inode in
ioctl_by_bdev() is uninitialised. Since this field is dereferenced by
BLKFLSBUF in rd_ioctl, it can lead to a panic (depending on what happens to be
on the stack). The attached fixes the problem and clears all the fields in
fake_inode to make any other problems like this show up.
James Bottomley
Index: fs/block_dev.c
===
RCS file: /home/jejb/CVSROOT/linux/2.4/fs/block_dev.c,v
retrieving revision 1.1.1.10
diff -u -r1.1.1.10 block_dev.c
--- fs/block_dev.c 2001/05/26 15:33:37 1.1.1.10
+++ fs/block_dev.c 2001/06/02 13:14:35
@@ -596,13 +596,14 @@
int ioctl_by_bdev(struct block_device *bdev, unsigned cmd, unsigned long arg)
{
kdev_t rdev = to_kdev_t(bdev->bd_dev);
- struct inode inode_fake;
+ struct inode inode_fake = { 0 };
int res;
mm_segment_t old_fs = get_fs();
if (!bdev->bd_op->ioctl)
return -EINVAL;
inode_fake.i_rdev=rdev;
+ inode_fake.i_bdev = bdev;
init_waitqueue_head(_fake.i_wait);
set_fs(KERNEL_DS);
res = bdev->bd_op->ioctl(_fake, NULL, cmd, arg);
Re: Break 2.4 VM in five easy steps
On Wed, 6 Jun 2001, Andrew Morton wrote:
> "Jeffrey W. Baker" wrote:
> >
> > Because the 2.4 VM is so broken, and
> > because my machines are frequently deeply swapped,
>
> The swapoff algorithms in 2.2 and 2.4 are basically identical.
> The problem *appears* worse in 2.4 because it uses lots
> more swap.
>
> > they can sometimes take over 30 minutes to shutdown.
>
> Yes. The sys_swapoff() system call can take many minutes
> of CPU time. It basically does:
>
> for (each page in swap device) {
> for (each process) {
> for (each page used by this process)
> stuff
Sure, and at shutdown time when swapoff is called, there is only 1
process, init, which isn't swapped out anymore. So this should run like
lightning.
Repeat: something is horribly wrong with the VM's management of pages,
lists, swap, cache, etc.
-jwb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Wed, Jun 06, 2001 at 12:16:30PM +1000, Andrew Morton wrote: > "Jeffrey W. Baker" wrote: > > > > Because the 2.4 VM is so broken, and > > because my machines are frequently deeply swapped, > > The swapoff algorithms in 2.2 and 2.4 are basically identical. > The problem *appears* worse in 2.4 because it uses lots > more swap. I disagree with the terminology you're using. It *is* worse in 2.4, period. If it only *appears* worse, then if I encounter a situation where a 2.2 box has utilized as much swap as a 2.4 box, I should see the same results. Yet this happens not to be the case. A 2.2 box that's a hundred or more megs into swap, even when that swap space is "actual programs" rather than just mysteriously allocated swap (as with 2.4), it only takes the time to page all that off disk back into RAM, making the machine a little sluggish while it's happening and definitely not making the machine entirely unresponsive. On the other hand, a 2.4 box that's a hundred or more megs into swap, even when there's nothing actually running to take up that swap space, i.e. it's just "mysteriously allocated for some reason" swap, will take several minutes, while the CPU is pegged, the drive is inactive, and the entire machine is completely unresponsive to anything - for all appearances locked up tight. I have been unable to make a box running the 2.2 kernel behave the same way as 2.4 does, even if I put the 2.2 kernel under severe memory pressure and the 2.4 kernel is entirely idle with no tasks but the most basic system processes running. So from my perspective, which really is a real-world perspective because I can cause this same behaviour during normal day-to-day desktop operation of my machine, the behaviour of 2.4 *is* different from the behaviour of 2.2 when it comes to memory management. > > they can sometimes take over 30 minutes to shutdown. > > Yes. The sys_swapoff() system call can take many minutes > of CPU time. It basically does: >[...] > It's interesting that you've found a case where this > actually has an operational impact. I can't tell if this is humour or not. I hope it is, because I can sure show you actual operational impact of this mis-behaviour all day long. :) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Network Performance Testing Summary
This is a follow up message to the original "Abysmal Receive Performance" message. Thanks to everyone who e-mailed me with suggestions. Well, after poking around, I eventually narrowed the problem down to the fact that the system BIOS did not enable PCI->RAM write posting. After I enabled that with the bridge optimization setting in 2.2.19, network RECV performance went from ~5Mbps to 41Mbps. The curse of the HP Vectra XU 5/90 strikes again! What is interesting is that I tried the NetGear FA310, FA311, 3COM 3cSOHO and 3C905C-TX cards and both the receive and transmit speeds (measured with both iperf and netperf) were so close to each other as to be a non-issue. Several people e-mailed me to let me know that "card 'X' performance is terrible, I can only get good performance with card 'Y'". So, I just thought I should send this message out to set things a bit straight. I know this machine isn't exactly cutting-edge, but I have to admit I was a little surprised to see all four of the cards I tested clustered so close together (so close, that you could call it 41.8Mpbs RECV and 52.2Mbps XMIT for all cards). FWIW, it is somewhat interesting that 2.4.3 performance is so horrible with PCI->RAM posting disabled, whereas 2.2.19 doesn't take nearly the same hit. Using the 1.1.7 Tulip driver from Sourceforge didn't change this at all. With write posting enabled, things 2.4.3 ended up performing better than 2.2.19. So, thanks to everyone who helped me out. Looks like I now need to start a FAQ just for Vectra XU 5/90 owners so they can get their machines to work... - John _ Get your FREE download of MSN Explorer at http://explorer.msn.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
"Jeffrey W. Baker" wrote:
>
> Because the 2.4 VM is so broken, and
> because my machines are frequently deeply swapped,
The swapoff algorithms in 2.2 and 2.4 are basically identical.
The problem *appears* worse in 2.4 because it uses lots
more swap.
> they can sometimes take over 30 minutes to shutdown.
Yes. The sys_swapoff() system call can take many minutes
of CPU time. It basically does:
for (each page in swap device) {
for (each process) {
for (each page used by this process)
stuff
It's interesting that you've found a case where this
actually has an operational impact.
Haven't looked at it closely, but I think the algorithm
could become something like:
for (each process) {
for (each page in this process) {
if (page is on target swap device)
get_it_off()
}
}
for (each page in swap device) {
if (it is busy)
complain()
}
That's 10^4 to 10^6 times faster.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
I also need some 2.4 features and can't really goto 2.2. I would have to agree that the VM is too broken for production...looking forward to the work that (hopefully) will be in 2.4.6 to resolve these issues. "Jeffrey W. Baker" wrote: > On Tue, 5 Jun 2001, Derek Glidden wrote: > > > > > After reading the messages to this list for the last couple of weeks and > > playing around on my machine, I'm convinced that the VM system in 2.4 is > > still severely broken. > > > > This isn't trying to test extreme low-memory pressure, just how the > > system handles recovering from going somewhat into swap, which is a real > > day-to-day problem for me, because I often run a couple of apps that > > most of the time live in RAM, but during heavy computation runs, can go > > a couple hundred megs into swap for a few minutes at a time. Whenever > > that happens, my machine always starts acting up afterwards, so I > > started investigating and found some really strange stuff going on. > > I reboot each of my machines every week, to take them offline for > intrusion detection. I use 2.4 because I need advanced features of > iptables that ipchains lacks. Because the 2.4 VM is so broken, and > because my machines are frequently deeply swapped, they can sometimes take > over 30 minutes to shutdown. They hang of course when the shutdown rc > script turns off the swap. The first few times this happened I assumed > they were dead. > > So, unlike what certain people like to repeatedly claim, the 2.4 VM > problems are causing havoc in the real world. > > -jwb > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- --- Russell Leighton[EMAIL PROTECTED] Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IP ToS routing problem and fix
Hi Alexey. I've been having a problem getting ToS routing working properly, well, the way I wanted it to. Basically, it would not route using anything except the RFC 1349 ToS settings. I've prepared the attached patch to add a new configuration option to allow routing based on RFC 2474 Diffserv DSCP values in the IPv4 TOS field. Attached is a test script which works for the following setup. The test machine has eth1 and eth2 on the same ethernet network. There is another machine on the test ethernet network that the test machine pings. The IP addresses used in the setup are: test:eth1 = 192.168.0.1. test:eth2 = 192.168.0.2. target = 192.168.0.3. I've also included the output of the test for an unpatched 2.4.5 system and a patched 2.4.5 system. Please have a look and let me know what you think. I wouldn't promote putting this in the regular kernel until I've let it run around here for a few weeks. cheers -mark -- Mark Frazer <[EMAIL PROTECTED]> # Configure.help needs updating for the new config option. # This option makes the old IP_ROUTE_TOS boolean a choice # option allowing either the old RFC1349 behaviour or the # RFC2474 behaviour. diff -urN linux-2.4.5/Documentation/Configure.help linux-2.4.5-mjf/Documentation/Configure.help --- linux-2.4.5/Documentation/Configure.helpThu May 24 18:03:06 2001 +++ linux-2.4.5-mjf/Documentation/Configure.helpMon Jun 4 18:23:31 2001 @@ -3943,13 +3943,30 @@ equal "cost" and chooses one of them in a non-deterministic fashion if a matching packet arrives. -IP: use TOS value as routing key -CONFIG_IP_ROUTE_TOS - The header of every IP packet carries a TOS (Type Of Service) value +IP: use of TOS value as routing key +CONFIG_IP_ROUTE_TOSNOTUSED + The second octet of the IP header is defined by several Internet RFCs. + The linux routing facility can make a routing decision on several of + the interpretations of this RFC. This second octect in the header was + originally named the Type of Service field in Postel's RFC 971. This + choice allows you to select the treatment you wish to use in your + network. + + None indicates that the ToS field will not be used to make routing + decisions. + + TOS indicates that the ToS field will be treated as specified in + RFC 1349. The header of every IP packet carries a single TOS value with which the packet requests a certain treatment, e.g. low latency - (for interactive traffic), high throughput, or high reliability. If - you say Y here, you will be able to specify different routes for - packets with different TOS values. + (for interactive traffic), high throughput, high reliability, or minimum + cost. These settings are mutually exclusive. Note that the minimum cost + setting is clobbered if ECN is activated. + + DSCP indicates that the ToS field will be treated as specified in + RFC 2474. This selects treating the field as a DiffServ Differentiated + Service Code Point which allow the top 6 bits of the field to be used + to specify a per hop behaviour which is generally set by policy at each + routing point in the network. IP: use netfilter MARK value as routing key CONFIG_IP_ROUTE_FWMARK # Minor fix do netfilter location in the kernel docs. diff -urN linux-2.4.5/Documentation/kernel-docs.txt linux-2.4.5-mjf/Documentation/kernel-docs.txt --- linux-2.4.5/Documentation/kernel-docs.txt Fri Apr 6 13:42:48 2001 +++ linux-2.4.5-mjf/Documentation/kernel-docs.txt Mon May 28 12:37:26 2001 @@ -333,7 +333,8 @@ * Title: "The Kernel Hacking HOWTO" Author: Various Talented People, and Rusty. - URL: http://www.samba.org/~netfilter/kernel-hacking-HOWTO.html + URL: http://netfilter.gnumonks.org/unreliable-guides/kernel-hacking/ + lk-hacking-guide.html Keywords: HOWTO, kernel contexts, deadlock, locking, modules, symbols, return conventions. Description: From the Introduction: "Please understand that I @@ -393,9 +394,8 @@ * Title: "Linux Kernel Locking HOWTO" Author: Various Talented People, and Rusty. - URL: - http://netfilter.kernelnotes.org/unreliable-guides/kernel-locking- - HOWTO.html + URL: http://netfilter.gnumonks.org/unreliable-guides/kernel-locking/ + lklockingguide.html Keywords: locks, locking, spinlock, semaphore, atomic, race condition, bottom halves, tasklets, softirqs. Description: The title says it all: document describing the # I've placed the mask for valid DSCP values here. diff -urN linux-2.4.5/include/linux/ip.h linux-2.4.5-mjf/include/linux/ip.h --- linux-2.4.5/include/linux/ip.h Fri May 25 21:01:27 2001 +++ linux-2.4.5-mjf/include/linux/ip.h Mon Jun 4 18:31:30 2001 @@ -38,6 +38,8 @@ #define IPTOS_PREC_PRIORITY 0x20 #define IPTOS_PREC_ROUTINE 0x00 +/* RFC 2474 Diffserv code point */ +#define IPTOS_DSCP_MASK0xFC /* IP options */ #define
Lockup in 2.4.5-ac2
Hi all! Enjoying the -ac2 kernel except for one minor thing: it locks up. Problem occurs whenever large amounts of data are transferred across the network. This includes web pages, iso cd images, and compressed files. I can transfer large amounts of data from the internet and to the internet however. It is a hardlock, I cannot even get the SysRq key to help me out. System specs: P-III 550 256MB RAM (1 DIMM) Abit SH6 (i815 based) Motherboard Using onboard Video/Audio Kernel 2.4.5-ac2 Debian GNU/Linux 2.2rev3 Realtek 8139B (see attached dmesg.output file) 10BaseT Network with 128K Satellite link to outside world Tried protocols: Samba FTP HTTP NFS If you need any more info let me know. Thanks! Glenn Shannon Systems Administrator Gibbons Enterprises Corporation, Palau [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SysRq bug for tErm and kIll with init
Good evening,
The problem is annoying, the fix is trivial.
I am not subscribed to the list, so PLEASE CC ME when replying.
Summary:
Magic SysRq behaves improperly with tErm and kIll in regards to how it
deals with init. killalL is fine (ignoring the 0x8000 "Ugly hack" :)
Description:
When you use these features of SysRq, the kernel is supposed to send a
signal to all processes except init. Well in reality the kernel sends a
signal to "all" processes including init. The reason nobody has ever
noticed this is that sysvinit doesn't do anything on SIGTERM, and the
kernel won't kill pid 1.
Affected kernels:
All current. This is present in both 2.2.19 and 2.4.6-pre1 kernels. I
didn't check 2.0.x, but i believe 2.0.x lacked the magic sysrq hack
anyway.
$Id: sysrq.c,v 1.15 1998/08/23 14:56:41 mj Exp $
Solution:
drivers/char/sysrq.c
send_sig_all()
line 47 in 2.4.6-pre1
// -- Evil code --
for_each_task(p) {
if (p->mm) { /* Not swapper nor kernel thread */
if (p->pid == 1 && even_init) /* Ugly hack to kill init */
p->pid = 0x8000;
force_sig(sig, p);
}
}
// --end--
So what happens is if send_sig_all is supposed to kill init then p->pid is
set to 0x8000. This is bad, but it works fine so who really cares. Now,
if even_init is 0 (like with tErm and kIll), p->pid is still 1 when
force_sig() is called. If p->pid is 1 and even_init is 0, nothing should
be done.
// -- Fixed code --
for_each_task(p) {
if (p->mm) {/* Not swapper nor kernel thread */
if (p->pid == 1 && even_init)/* Ugly hack to kill init */
p->pid = 0x8000;
if (p->pid != 1)
force_sig(sig, p);
}
}
// --end--
Amazing what 1 line of code fixes, isn't it?
How the problem was found:
The busybox (busybox.lineo.com) init reboots when it sees SIGTERM :).
Since this is a 1 line fix I'd like to see it go into the kernel soon,
maybe even for the 2.4.6-pre2 kernel. I don't want to sound
like a jerk, but it would be cool if I was listed at the top of
sysrq.c for submitting a bugfix or something =].
Remember to cc me when replying.
Thanks,
Adam Slattery
Sunrise Linux Development Team
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: forcibly unmap pages in driver?
>> Later, the program calls the ioctl() again to set a smaller >> buffer size, or closes the file descriptor. At this point >> I'd like to shrink the buffer or free it completely. But I >> can't assume that the program will be nice and munmap() the >> region for me > Look at drivers/char/drm, for example. At mmap time they allocate a > vm_ops to the address space. With that you catch changes to the vma > structure initiated by a user mmap, munmap, etc. You could also > dynamically map the pages in using the nopage method (optional). OK I think I have a solution... Whenever I need to re-allocate or free the DMA buffer, I could set all of the user's corresponding page table entries to deny all access. Then I'd get a page fault on the next access to the buffer, and inside nopage() I could update the user's mapping or send a SIGBUS as appropriate (hmm, just like restoring a file mapping that was thrown away)... So I just have to figure out how to find the user's page table entries that are pointing to the DMA buffer. Regards, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd and MM overload fix
On Wed, 6 Jun 2001, Andrea Arcangeli wrote: > > that would fix it too indeed, OTOH I think changing the empty zone > handling in the kernel is beyond the scope of the bugfix (grep for > zone->size in mm/*.c :). Certainly making empty zones transparent to the > vm sounds much cleaner from a mm/*.c point of view but it may be faster > to skip the block with a branch instead of always computing it. Agreed. I'd like to do both. Having uninitialized random stuff around and depending on jumping over code that might access it sounds like really bad practice. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd and MM overload fix
On Wednesday66 0666 6 June 2001 01:16, Linus Torvalds wrote:
> On Wed, 6 Jun 2001, Andrea Arcangeli wrote:
> > Anybody running on a machine with some zone empty (<16Mbyte boxes (PDAs),
> > <1G x86 with highmem enabled kernel or an arch with an iommu like alpha)
> > probably noticed that the MM was unusable on those hardware
> > configurations (as I also incidentally mentioned a few times on l-k in
> > the last months).
> >
> > Yesterday I checked and here it is the fix (included in 2.4.5aa3).
>
> I think the real problem is that zone->pages_{min,low,high} aren't
> initialized at all for empty zones. If they were initialized (to zero, of
> course), the shortage calculations would have worked automatically.
>
> Using uninitialized variables is always bad. Your patch is certainly fine,
> but I think we should also make the init code clear the zone data for
> empty zones so that these kinds of "use uninitialized stuff" things cannot
> happen. No?
>
Lets see - that zone will have no free nor inactive pages
In page_alloc.c:254 function __alloc_pages_limit
where water_mark will be zero too...
if (z->free_pages + z->inactive_clean_pages >= water_mark) {
we will attempt a lot of interesting/unnecessary stuff.
But it should be caught by the test a few lines up...
if (!z->size)
BUG();
In page_alloc.c:331 (function __alloc_pages)
if (z->free_pages >= z->pages_low) {
page = rmqueue(z, order);
if (page)
return page;
Hmm... a lot more than first meets the eye.
Note: >= matches < in another place, removing the = will leave the mm stuck...
/RogerL
--
Roger Larsson
Skellefteå
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd and MM overload fix
On Tue, Jun 05, 2001 at 04:16:57PM -0700, Linus Torvalds wrote: > but I think we should also make the init code clear the zone data for > empty zones so that these kinds of "use uninitialized stuff" things cannot > happen. No? that would fix it too indeed, OTOH I think changing the empty zone handling in the kernel is beyond the scope of the bugfix (grep for zone->size in mm/*.c :). Certainly making empty zones transparent to the vm sounds much cleaner from a mm/*.c point of view but it may be faster to skip the block with a branch instead of always computing it. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Break 2.4 VM in five easy steps
On Tue, 5 Jun 2001, Derek Glidden wrote: > > After reading the messages to this list for the last couple of weeks and > playing around on my machine, I'm convinced that the VM system in 2.4 is > still severely broken. > > This isn't trying to test extreme low-memory pressure, just how the > system handles recovering from going somewhat into swap, which is a real > day-to-day problem for me, because I often run a couple of apps that > most of the time live in RAM, but during heavy computation runs, can go > a couple hundred megs into swap for a few minutes at a time. Whenever > that happens, my machine always starts acting up afterwards, so I > started investigating and found some really strange stuff going on. I reboot each of my machines every week, to take them offline for intrusion detection. I use 2.4 because I need advanced features of iptables that ipchains lacks. Because the 2.4 VM is so broken, and because my machines are frequently deeply swapped, they can sometimes take over 30 minutes to shutdown. They hang of course when the shutdown rc script turns off the swap. The first few times this happened I assumed they were dead. So, unlike what certain people like to repeatedly claim, the 2.4 VM problems are causing havoc in the real world. -jwb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forcibly unmap pages in driver?
[EMAIL PROTECTED] said: > My driver uses a variable-size DMA buffer that it shares with user-space; I > provide an ioctl() to choose the buffer size and allocate the buffer. Say > the user program chooses a large buffer size, and mmap()s the entire buffer. > Later, the program calls the ioctl() again to set a smaller buffer size, or > closes the file descriptor. At this point I'd like to shrink the buffer or > free it completely. But I can't assume that the program will be nice and > munmap() the region for me - it might still have the large buffer mapped. > What should I do here? > > An easy solution would to allocate the largest possible buffer as my driver > is loaded, even if not all of it will be exposed to user-space. I don't > really like this choice because the buffer needs to be pinned in memory, and > the largest useful buffer size is very big (several tens of MB). Maybe I > should disallow more than one buffer allocation per open() of the device... > But the memory mapping will stay around even after close(), correct? I'd > hate to have to keep the buffer around until my driver module is unloaded. I see. Your explanation makes sense, and close won't affect the mmap (unless you explicitly trigger it in the driver, which you should). Other drivers deal with this; you may want to go grepping for do_munmap and see how they handle it. [ > [EMAIL PROTECTED] said: ] > > However, do_munmap() will call zap_page_range() for you and take care of > > cache and TLB flushing if you're going to do this in the kernel. > > I'm not sure if I could use do_munmap() -- how will I know if the user > program has called munmap() already, and then mmap()ed something else in the > same place? Then I'd be killing the wrong mapping... Look at drivers/char/drm, for example. At mmap time they allocate a vm_ops to the address space. With that you catch changes to the vma structure initiated by a user mmap, munmap, etc. You could also dynamically map the pages in using the nopage method (optional). The less elegant way of doing this is to put in your userspace API some conditions which say: if you do the following: open(fd); ioctl(fd, give_me_the_buf); munmap(some_or_all_of_the_buf); buf2 = mmap(...); close(fd); /* or ioctl(fd, shrink_the_buf); */ buf2[27] = 3; you will be killed with a sigbus. I.e. don't manually munmap the region. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kswapd and MM overload fix
On Wed, 6 Jun 2001, Andrea Arcangeli wrote:
>
> Anybody running on a machine with some zone empty (<16Mbyte boxes (PDAs),
> <1G x86 with highmem enabled kernel or an arch with an iommu like alpha)
> probably noticed that the MM was unusable on those hardware
> configurations (as I also incidentally mentioned a few times on l-k in
> the last months).
>
> Yesterday I checked and here it is the fix (included in 2.4.5aa3).
I think the real problem is that zone->pages_{min,low,high} aren't
initialized at all for empty zones. If they were initialized (to zero, of
course), the shortage calculations would have worked automatically.
Using uninitialized variables is always bad. Your patch is certainly fine,
but I think we should also make the init code clear the zone data for
empty zones so that these kinds of "use uninitialized stuff" things cannot
happen. No?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Does anybody know, where is the MIPS linux mailing list ?
On Tue, Jun 05, 2001 at 06:21:50PM -0400, Alexandr Andreev wrote: > Hi all! I need to ask some questions about linux-2.4.3 for MIPS. [EMAIL PROTECTED], subscription handled via majordomo. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: forcibly unmap pages in driver?
> That seems a bit perverse. How will the poor userspace program know > not to access the pages you have yanked away from it? If you plan > to kill it, better to do that directly. If you plan to signal it > that the mapping is gone, it can just call munmap() itself. Thanks Pete. I will explain situation I am envisioning; perhaps there is a better way to handle this -- My driver uses a variable-size DMA buffer that it shares with user-space; I provide an ioctl() to choose the buffer size and allocate the buffer. Say the user program chooses a large buffer size, and mmap()s the entire buffer. Later, the program calls the ioctl() again to set a smaller buffer size, or closes the file descriptor. At this point I'd like to shrink the buffer or free it completely. But I can't assume that the program will be nice and munmap() the region for me - it might still have the large buffer mapped. What should I do here? An easy solution would to allocate the largest possible buffer as my driver is loaded, even if not all of it will be exposed to user-space. I don't really like this choice because the buffer needs to be pinned in memory, and the largest useful buffer size is very big (several tens of MB). Maybe I should disallow more than one buffer allocation per open() of the device... But the memory mapping will stay around even after close(), correct? I'd hate to have to keep the buffer around until my driver module is unloaded. > However, do_munmap() will call zap_page_range() for you and take care of > cache and TLB flushing if you're going to do this in the kernel. I'm not sure if I could use do_munmap() -- how will I know if the user program has called munmap() already, and then mmap()ed something else in the same place? Then I'd be killing the wrong mapping... Regards, Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac9
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac9 o Fix gameport link problems (Vojtech Pavlik) o Fix an oops in the sg driver(Tachino Nobuhiro) o Fix brlock indexing bug (Takanori Kawano) o Add parport_pc_unregister_port (Tim Waugh) o Configure.help updates (Eric Raymond) o Fix xircom_cb problems with some cisco kit (Ion Badulescu) o Fix tdfxfb cursor rendering bug (Franz Melchior) o Add driver for the sony vaio i/o controller (Stelian Pop, Junchi Morita, Takaya Kinjo, Andrew Tridgell) o Orinoco updates for symbol, intel, 3com cards (Jean Tourrihles) o Use list_del_init in uhci driver(Herbert Xu) o Fix a uhci SMP deadlock (Herbert Xu) o Allow faster freeing of reisefs metadata(Chris Mason) o Fix error path leaks in reiserfs(Chris Mason, Vladimir Saveliev) o Fix NFS problems triggered by 2.4.5 mmap change (Trond Myklebust) o Resynchronize with m68k tree(Jes Sorensen) o Add es1371 sound driver locking (Frank Davis) o Fix a small error in the trident locking(Frank Davis) 2.4.5-ac8 o Fix sign handling bug in random sysctl (me) | From Stanford tools o Add more idents to the NS558 driver (Vojtech Pavlik) o Fix oops on some HID descriptor sets(Vojtech Pavlik) o Fix reuse bug in UML net code + clean up(Jeff Dike) o ES1370 driver locking (Frank Davis) o Update init/main.c patch for umask (Andrew Tridgell) o Fix uml fault race, and looping fault on(Jeff Dike) protection error o Update devices.txt (H Peter Anvin) o Update the airo driver (fix pci pm oops.(Jeff Garzik) spinlock abuse, delete after kfree, unchecked copies) o Remove old UML umn driver (Jeff Dike) o Fix resource leaks and printk levels in isapnp (Mike Borrelli) o Add new procfs programming documentation(Erik Mouw) o Fix usb xconfig breakage(Andrzej Krzysztofowicz) o Replace accidentaly lost UP_APIC help (Mikael Pettersson) o Olypmic driver update (Mike Phillips) o Clean up LVM spelling, debug macros (Andreas Dilger) o Make various bits of LVM static (Andreas Dilger) o Make lvm_snapshot_use_rate its own function (Andreas Dilger) o Make lvm_do_lv_create loop the right amount o Fix lvm stamping on a semaphore causing an oops o Fix lvm hardware block size handling(Andrea Arcangeli) 2.4.5-ac7 o UML cleanups(Jeff Dike) o Trap invalid addresses in UML ethernet driver (Jeff Dike) o Reimplment UML user space access(Jeff Dike) o Add device node support to hostfs (Jorgen Cederlof) o Fix hang if the UML net helper fails to run (Jeff Dike) o Support setting time in UML kernels (Livio Baldini Soares) o Move more non portable code out of UML core (Jeff Dike) o Merge most of remaining UML ppc changes (Chris Emerson) o Printk cleanups, remove one non portable(James Stevenson) o Add speaker mixer support to the cmpci mixer(Carlos Gorges) o Fix inittdata ordering in i2c docs (Andrzej Krzysztofowicz) o Add usb skeleton driver (Greg Kroah-Hartmann) o Fix ns558 unload(Marcus Meissner) o Further cs46xx fixing (Frank Davies) o S/390 updates from the IBM folks(Martin Schwidefsky) o CS46xx pop/crackle fixes on IBM T20 (Thomas Woller) o Make USB require PCI(me) o Tulip driver update (Jeff Garzik) o Fix slip/slhc missing symbols problem (Michael Guntsche) o IRDA updates(Dag Brattli) o Add cs4232 isapnp probing (Marcus Meissner) o Merge airo_cs driver(Benjamin Reed, Javier Achirica,
kswapd and MM overload fix
Anybody running on a machine with some zone empty (<16Mbyte boxes (PDAs),
<1G x86 with highmem enabled kernel or an arch with an iommu like alpha)
probably noticed that the MM was unusable on those hardware
configurations (as I also incidentally mentioned a few times on l-k in
the last months).
Yesterday I checked and here it is the fix (included in 2.4.5aa3).
--- 2.4.5aa3/mm/vmscan.c.~1~Sat May 26 04:03:50 2001
+++ 2.4.5aa3/mm/vmscan.cTue Jun 5 03:41:06 2001
@@ -791,6 +788,8 @@
for(i = 0; i < MAX_NR_ZONES; i++) {
int zone_shortage;
zone_t *zone = pgdat->node_zones+ i;
+ if (!zone->size)
+ continue;
zone_shortage = zone->pages_high;
zone_shortage -= zone->inactive_dirty_pages;
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: forcibly unmap pages in driver?
[EMAIL PROTECTED] said: > I am writing a device driver that, like many others, exposes a shared memory > region to user-space via mmap(). The region is allocated with vmalloc(), the > pages are marked reserved, and the user-space mapping is implemented with > remap_page_range(). > > In my driver, I may have to free the underlying vmalloc() region while the > user-space program is still running. I need to remove the user-space > mapping -- otherwise the user process would still have access to the > now-freed pages. I need an inverse of remap_page_range(). > > Is zap_page_range() the function I am looking for? Unfortunately it's not > exported to modules =(. As a quick fix, I was thinking I could just remap > all of the user pages to point to a zeroed page or something... > > Another question- in the mm.c sources, I see that many of the memory-mapping > functions are surrounded by calls to flush_cache_range() and > flush_tlb_range(). But I don't see these calls in many drivers. Is it > necessary to make them when my driver maps or unmaps the shared memory > region? That seems a bit perverse. How will the poor userspace program know not to access the pages you have yanked away from it? If you plan to kill it, better to do that directly. If you plan to signal it that the mapping is gone, it can just call munmap() itself. However, do_munmap() will call zap_page_range() for you and take care of cache and TLB flushing if you're going to do this in the kernel. Your driver mmap function is called by do_mmap_pgoff() which takes care of those issues, and there is no (*munmap) in file_operations--- perhaps you are the first driver writer to want to unmap in the kernel. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Break 2.4 VM in five easy steps
After reading the messages to this list for the last couple of weeks and
playing around on my machine, I'm convinced that the VM system in 2.4 is
still severely broken.
This isn't trying to test extreme low-memory pressure, just how the
system handles recovering from going somewhat into swap, which is a real
day-to-day problem for me, because I often run a couple of apps that
most of the time live in RAM, but during heavy computation runs, can go
a couple hundred megs into swap for a few minutes at a time. Whenever
that happens, my machine always starts acting up afterwards, so I
started investigating and found some really strange stuff going on.
To demonstrate this to a co-worker, I cooked up this really simple,
really stupid, very effective test. (Note that this all is probably
specific to IA32, which is the platform on which I'm running.)
-- How to Break your 2.4 kernel VM in 5 easy steps
1) compile the following code:
#include
void main(void) {
/* allocate a buttload of memory and try to touch it all */
void *ptr = (void *)calloc(1, sizeof(int)) ;
/* sleep for a bit to let the system quiesce */
sleep(20);
/* let it all go away now */
free(ptr);
}
2) depending on the amount of RAM/swap available in your machine, you
might need to adjust the calloc to allocate a different amount. This
allocates about 400MB.
3) Run the program, or more than one copy at once. You want to put your
machine somewhat into swap, but not totally overwhelmed. On the system
I'm using to write this, with 512MB of RAM and 512MB of swap, I run two
copies of this program simultaneously and it puts me a couple hundred
megs into swap.
4) Let the program exit, run "free" or cat /proc/memstat or something to
make sure your machine has paged a bunch of stuff out into swap.
5) try to "swapoff" your swap partition and watch the machine become
completely and entirely unresponsive for several minutes.
--
If I do this on my machine, which is a K7-700 on an ASUS K7M motherboard
with 512MB each of swap and RAM where I'm writing this (but I can make
any machine running 2.4 behave the same way, and any version I've tried
it with from 2.4.2 on up through most of the -ac kernels too), the
machine will become _entirely_ unresponsive for several minutes. The HD
comes on for a few seconds at the very start of the "swapoff", CPU
utilization immediately pegs up to 100% system time, and then for a few
minutes after, as far as anyone can tell, the machine is TOTALLY locked
up. No console response, no response from anything on the machine.
However, after a few minutes of TOTAL catatonia, it will mysteriously
come back to life, having finally released all its swap.
Now, this is a VERY contrived test, but there are a couple of things
about doing this against 2.4 compared with 2.2 that seem VERY BROKEN to
me.
1) Running this against a machine running a 2.2-series kernel does
nothing out of the ordinary. You hit a bunch of swap, exit the
"allocate" program, swapoff, and everything is fine after a few seconds
of disk activity as it pages everything back into RAM. Least surprise.
Under 2.4, when you "swapoff" it appears as far as anyone can tell that
the machine has locked up completely. Very surprising. In fact, the
first time it happened to me, I hit the Big Red Switch thinking the
machine _had_ locked up. It wasn't until I started playing around with
memory allocation a bit more and read some of the problems on LKML that
I started to realize it wasn't locked up - just spinning.
2) Under 2.2, when the "allocate" programs exit, the amount of mem and
swap that show up in the "used" column are quite small - about what
you'd expect from all the apps that are actually running. No surprise
there. Under 2.4, after running the "allocate" program, "free" shows
about 200MB each under mem and swap as "used". A lot of memory shows up
in the "cached" column, so that explains the mem usage, (although not
what's cached, unless it's caching swap activity, which is odd) but what
the heck is in that swap space? Very surprising.
Now, I'm sure some of the response will be "Don't run 2.4. If you want
to run a stable kernel run 2.2." That may be a reasonable, but there
are a couple of features and a couple of drivers that make the 2.4 very
appealing, and somewhat necessary, to me. Also, I want to help FIX
these problems. I don't know if my hokey test is an indication of
something for real, but hopefully it's something that's simple enough
that a lot of people can run it and see if they experience similar
things.
And, AFAIC, a truly stable kernel (like 2.2) should be able to go deep
into swap, and once the applications taking up the memory have exited,
be able to turn off that swap and not have something utterly surprising,
like the machine becoming comatose for several minutes, happen. If it
does, that's an indication to me that there is something severely wrong.
Now, with that being said, is there anything
Re: Comment on patch to remove nr_async_pages limitA
On Tuesday 05 June 2001 23:00, Mike Galbraith wrote: > On Tue, 5 Jun 2001, Benjamin C.R. LaHaise wrote: > > Swapping early causes many more problems than swapping late as > > extraneous seeks to the swap partiton severely degrade performance. > > That is not the case here at the spot in the performance curve I'm > looking at (transition to throughput). > > Does this mean the block layer and/or elevator is having problems? > Why would using avaliable disk bandwidth vs letting it lie dormant be > a generically bad thing?.. this I just can't understand. The > elevator deals with seeks, the vm is flat not equipped to do so.. it > contains such concept. Clearly, if the spindle a dirty file page belongs to is idle, we have goofed. With process data the situation is a little different because the natural home of the data is not the swap device but main memory. The following gets pretty close to the truth: when there is memory pressure, if the spindle a dirty process page belongs to is idle, we have goofed. Well, as soon as I wrote those obvious truths I started thinking of exceptions, but they are silly exceptions such as: - read disk block 0 - dirty last block of disk - dirty 1,000 blocks starting at block 0. For good measure, delete the file the last block of the disk belongs to. We have just sent the head off on a wild goose chase, but we had to work at it. To handle such a set of events without requiring prescience we need to be able to cancel disk writes, but just ignoring such oddball situations is the next best thing. That's all by way of saying I agree with you. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: reschedule_idle changes in ac kernels
I ran the VolanoMark and TPC-H benchmarks on an 8 CPU system to observe the differences when changing the value at which preemptions are triggered. I used the 2.4.5 kernel as a basis and only changed the 'max_prio = ' statement in reschedule_idle() to change the preemption trigger threshold. In the 2.4.5 kernel the value of max_prio is set to 1. The results: In VolanoMark, changing the preemption trigger from 1 to 0 resulted in a 4% drop in throughput. In TPC-H there was virtually no difference when going from 1 to 0. If anything, the results were slightly better with 0 as a threshold value as opposed to 1. My guess is that the threshold value was changed from 0 to 1 in the 2.4 kernel for better performance with some workload. Anyone remember what that workload was/is? -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HP scanner SCSI card with 53c400a
Hi I have an old SCSI card that came with old HP scanner. It contains NCR 53c400a chip, one 3pin jumper and some PAL logics. I tried modprobe g_NCR5380 ncr_53c400a=1 ncr_addr=0x280 ncr_irq=255 as described in kernel docs, and it writes No device always. It works fine at address 0x280 under Winslows. Is there a chance to make it working under Linux 2.4.x? Tomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] more fs/super.c cleanups (5)
Chunk 5:
* we put vfsmounts into hash, keyed by pair dentry/vfsmount of
mountpoint. attach_mnt() and detach_mnt() do the obvious thing.
* follow_down() and friends do lookup in that hash, instead of
traversing ->d_vfsmnt. It kills scalability problem with many parallel
trees (if you remember, that's what was planned from the very beginning;
d_vfsmount was a "it works for now" sort of thing).
* d_vfsmnt is gone. In its place we have a counter - how many
things are mounted on that dentry. That (along with the above) covers all
uses of d_vfsmnt. First of all, d_mountoint() is easier (->d_mounted != 0
instead of !list_empty()). Besides, struct dentry became smaller.
* we allocate vfsmounts from the cache of their own now.
OK, that's probably it for 6-pre1. It Works Here(tm), it had been done with
equivalent transformations and I hope that chunks are small enough to be
easy to verify. Next part changes mount_sem locking (internal to fs/super.c),
so I'd rather keep it separate.
Please, apply.
Al
diff -urN S6-pre1-graft_tree/fs/autofs4/expire.c S6-pre1-mntcache/fs/autofs4/expire.c
--- S6-pre1-graft_tree/fs/autofs4/expire.c Sat Apr 28 02:12:56 2001
+++ S6-pre1-mntcache/fs/autofs4/expire.cTue Jun 5 08:18:04 2001
@@ -66,19 +66,11 @@
non-busy mounts */
static int check_vfsmnt(struct vfsmount *mnt, struct dentry *dentry)
{
- int ret = 0;
- struct list_head *tmp;
-
- list_for_each(tmp, >d_vfsmnt) {
- struct vfsmount *vfs = list_entry(tmp, struct vfsmount,
- mnt_clash);
- DPRINTK(("check_vfsmnt: mnt=%p, dentry=%p, tmp=%p, vfs=%p\n",
-mnt, dentry, tmp, vfs));
- if (vfs->mnt_parent != mnt || /* don't care about busy-ness of other
namespaces */
- !is_vfsmnt_tree_busy(vfs))
- ret++;
- }
+ int ret = dentry->d_mounted;
+ struct vfsmount *vfs = lookup_mnt(mnt, dentry);
+ if (vfs && is_vfsmnt_tree_busy(vfs))
+ ret--;
DPRINTK(("check_vfsmnt: ret=%d\n", ret));
return ret;
}
diff -urN S6-pre1-graft_tree/fs/dcache.c S6-pre1-mntcache/fs/dcache.c
--- S6-pre1-graft_tree/fs/dcache.c Fri May 25 21:51:12 2001
+++ S6-pre1-mntcache/fs/dcache.cTue Jun 5 08:18:04 2001
@@ -616,7 +616,7 @@
dentry->d_name.hash = name->hash;
dentry->d_op = NULL;
dentry->d_fsdata = NULL;
- INIT_LIST_HEAD(>d_vfsmnt);
+ dentry->d_mounted = 0;
INIT_LIST_HEAD(>d_hash);
INIT_LIST_HEAD(>d_lru);
INIT_LIST_HEAD(>d_subdirs);
@@ -1283,6 +1283,7 @@
dcache_init(mempages);
inode_init(mempages);
+ mnt_init(mempages);
bdev_cache_init();
cdev_cache_init();
}
diff -urN S6-pre1-graft_tree/fs/namei.c S6-pre1-mntcache/fs/namei.c
--- S6-pre1-graft_tree/fs/namei.c Fri May 25 21:51:14 2001
+++ S6-pre1-mntcache/fs/namei.c Tue Jun 5 08:18:04 2001
@@ -351,22 +351,17 @@
static inline int __follow_down(struct vfsmount **mnt, struct dentry **dentry)
{
- struct list_head *p;
+ struct vfsmount *mounted;
+
spin_lock(_lock);
- p = (*dentry)->d_vfsmnt.next;
- while (p != &(*dentry)->d_vfsmnt) {
- struct vfsmount *tmp;
- tmp = list_entry(p, struct vfsmount, mnt_clash);
- if (tmp->mnt_parent == *mnt) {
- *mnt = mntget(tmp);
- spin_unlock(_lock);
- mntput(tmp->mnt_parent);
- /* tmp holds the mountpoint, so... */
- dput(*dentry);
- *dentry = dget(tmp->mnt_root);
- return 1;
- }
- p = p->next;
+ mounted = lookup_mnt(*mnt, *dentry);
+ if (mounted) {
+ *mnt = mntget(mounted);
+ spin_unlock(_lock);
+ dput(*dentry);
+ mntput(mounted->mnt_parent);
+ *dentry = dget(mounted->mnt_root);
+ return 1;
}
spin_unlock(_lock);
return 0;
diff -urN S6-pre1-graft_tree/fs/super.c S6-pre1-mntcache/fs/super.c
--- S6-pre1-graft_tree/fs/super.c Tue Jun 5 08:17:28 2001
+++ S6-pre1-mntcache/fs/super.c Tue Jun 5 08:18:04 2001
@@ -281,13 +281,25 @@
static LIST_HEAD(vfsmntlist);
+static struct list_head *mount_hashtable;
+static int hash_mask, hash_bits;
+static kmem_cache_t *mnt_cache;
+
+static inline unsigned long hash(struct vfsmount *mnt, struct dentry *dentry)
+{
+ unsigned long tmp = ((unsigned long) mnt / L1_CACHE_BYTES);
+ tmp += ((unsigned long) dentry / L1_CACHE_BYTES);
+ tmp = tmp + (tmp >> hash_mask);
+ return tmp & hash_bits;
+}
+
struct vfsmount *alloc_vfsmnt(void)
{
- struct vfsmount *mnt = kmalloc(sizeof(struct vfsmount),
Re: 2.4.5-ac8 hardlocks when going to standby
On Tue, Jun 05, 2001 at 09:37:52PM +0100, Alan Cox wrote: > > 2.4.5-ac[4678] all lock hard (no sysreq) when pushing my > > power-button (setup from the bios to go to standby) or > > when running apm --standby. (apm version 3.0final, RH6.2) > > apm --suspend works the way it should. > > > > 2.4.5/2.4.6-pre1 don't hardlock. > > Are you using the same build options for both > What machine is this - laptop ? It's not a laptop. Tbird 950 + Abit KT7 (KT133) UP APIC is enabled in -ac[4678] and emu10k1 is the in-kernel version instead of the one from CVS in -ac8 - which shouldn't matter because -ac[467] ran with the CVS-version. 2.4.6-pre1 runs emu10k1 from CVS. I'll compile -ac8 without UP-APIC, but I don't think I'll have time to mail the results until tommorow. --- 2.4.5-ac8-configTue Jun 5 23:05:55 2001 +++ 2.4.6-pre1-config Tue Jun 5 23:05:57 2001 @@ -20,10 +20,9 @@ CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y -CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y -CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y +CONFIG_X86_LOCAL_APIC=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y @@ -129,9 +128,7 @@ CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_SOUND=m -CONFIG_SOUND_EMU10K1=m CONFIG_USB=m CONFIG_USB_DEVICEFS=y CONFIG_USB_UHCI=m -CONFIG_DEBUG_KERNEL=y CONFIG_MAGIC_SYSRQ=y -- Linux 2.4.6-pre1 #2 Tue Jun 5 18:08:24 CEST 2001 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] more fs/super.c cleanups (4)
Chunk 4: OK, this one is interesting.
* new function - graft_tree(what, where). It does necessary locking
and checks and mounts existing vfsmount on given point. Basically, it's the
common part of mounting and binding. Checks are usual - mountpoint is not
dead, we are not trying to mount directory on non-directory or vice versa.
* clone_mnt(vfsmount, root) - creates vfsmount of subtree.
* do_loopback() turned into "find what we want to bind, clone that
vfsmount setting its root to that dentry and graft it on mountpoint"
* do_add_mount() (aka. normal mounting) is "allocate vfsmount, then
find superblock, then attach it to already allocated vfsmount, check that
we are not stacking it onto the same fs and graft on mountpoint". The good
thing being: we are done with the ugliness on the "can't mount here, need
to kill superblock". We simply do mntput() on the vfsmount we have. Always.
If it was successfully grafted on the mountpoint - fine, we are left with
->mnt_count == 1. If we didn't make it - last reference goes away and we
are doing the right thing again.
Another good thing is that vfsmount allocation is gone from the area where
we keep mountpoint locked. That helps later big way, since we can clean
the mount/rmdir and mount/unlink race-prevention nicely - it's easier if
we can get the critical area in mount non-blocking.
Please, apply.
Al
diff -urN S6-pre1-do_add_mount/fs/super.c S6-pre1-graft_tree/fs/super.c
--- S6-pre1-do_add_mount/fs/super.c Tue Jun 5 08:16:35 2001
+++ S6-pre1-graft_tree/fs/super.c Tue Jun 5 08:17:28 2001
@@ -330,9 +330,7 @@
* dentry (if any).
*/
-static struct vfsmount *add_vfsmnt(struct nameidata *nd,
- struct dentry *root,
- const char *dev_name)
+static struct vfsmount *add_vfsmnt(struct dentry *root, const char *dev_name)
{
struct vfsmount *mnt;
struct super_block *sb = root->d_inode->i_sb;
@@ -351,18 +349,11 @@
}
}
mnt->mnt_sb = sb;
-
- spin_lock(_lock);
- if (nd && !IS_ROOT(nd->dentry) && d_unhashed(nd->dentry))
- goto fail;
mnt->mnt_root = dget(root);
+ mnt->mnt_mountpoint = mnt->mnt_root;
+ mnt->mnt_parent = mnt;
- if (nd) {
- attach_mnt(mnt, nd);
- } else {
- mnt->mnt_mountpoint = mnt->mnt_root;
- mnt->mnt_parent = mnt;
- }
+ spin_lock(_lock);
list_add(>mnt_instances, >s_mounts);
list_add(>mnt_list, vfsmntlist.prev);
spin_unlock(_lock);
@@ -370,12 +361,60 @@
get_filesystem(sb->s_type);
out:
return mnt;
+}
+
+static struct vfsmount *clone_mnt(struct vfsmount *old_mnt, struct dentry *root)
+{
+ char *name = old_mnt->mnt_devname;
+ struct vfsmount *mnt = alloc_vfsmnt();
+
+ if (!mnt)
+ goto out;
+
+ if (name) {
+ mnt->mnt_devname = kmalloc(strlen(name)+1, GFP_KERNEL);
+ if (mnt->mnt_devname)
+ strcpy(mnt->mnt_devname, name);
+ }
+ mnt->mnt_sb = old_mnt->mnt_sb;
+ mnt->mnt_root = dget(root);
+ mnt->mnt_mountpoint = mnt->mnt_root;
+ mnt->mnt_parent = mnt;
+
+ spin_lock(_lock);
+ list_add(>mnt_instances, _mnt->mnt_instances);
+ spin_unlock(_lock);
+out:
+ return mnt;
+}
+
+static int graft_tree(struct vfsmount *mnt, struct nameidata *nd)
+{
+ if (S_ISDIR(nd->dentry->d_inode->i_mode) !=
+ S_ISDIR(mnt->mnt_root->d_inode->i_mode))
+ return -ENOTDIR;
+
+ down(>dentry->d_inode->i_zombie);
+ if (IS_DEADDIR(nd->dentry->d_inode))
+ goto fail1;
+
+ spin_lock(_lock);
+ if (!IS_ROOT(nd->dentry) && d_unhashed(nd->dentry))
+ goto fail;
+
+ attach_mnt(mnt, nd);
+ list_add(>mnt_list, vfsmntlist.prev);
+ spin_unlock(_lock);
+ up(>dentry->d_inode->i_zombie);
+ if (mnt->mnt_sb->s_type->fs_flags & FS_SINGLE)
+ get_filesystem(mnt->mnt_sb->s_type);
+ mntget(mnt);
+ return 0;
fail:
spin_unlock(_lock);
- if (mnt->mnt_devname)
- kfree(mnt->mnt_devname);
- kfree(mnt);
- return NULL;
+fail1:
+ up(>dentry->d_inode->i_zombie);
+ return -ENOENT;
}
static void move_vfsmnt(struct vfsmount *mnt,
@@ -1154,35 +1193,30 @@
static int do_loopback(struct nameidata *nd, char *old_name)
{
struct nameidata old_nd;
- int err = 0;
+ struct vfsmount *mnt;
+ int err;
+
+ err = mount_is_safe(nd);
+ if (err)
+ return err;
+
if (!old_name || !*old_name)
return -EINVAL;
- if (path_init(old_name, LOOKUP_POSITIVE, _nd))
+
+ if (path_init(old_name, LOOKUP_POSITIVE|LOOKUP_FOLLOW, _nd))
err =
Re: Comment on patch to remove nr_async_pages limitA
On Tue, 5 Jun 2001, Benjamin C.R. LaHaise wrote: > On Tue, 5 Jun 2001, Mike Galbraith wrote: > > > Yes. If we start writing out sooner, we aren't stuck with pushing a > > ton of IO all at once and can use prudent limits. Not only because of > > potential allocation problems, but because our situation is changing > > rapidly so small corrections done often is more precise than whopping > > big ones can be. > > Hold on there big boy, writing out sooner is not better. What if the (do definitely beat my thoughts up, please don't use condescending terms) In some cases, it definitely is. I can routinely improve throughput by writing more.. that is a measurable and reproducable fact. I know also from measurement that it is not _always_ the right thing to do. > memory shortage is because real data is being written out to disk? (I would hope that we're doing our best to always be writing real data to disk. I also know that this isn't always the case.) > Swapping early causes many more problems than swapping late as extraneous > seeks to the swap partiton severely degrade performance. That is not the case here at the spot in the performance curve I'm looking at (transition to throughput). Does this mean the block layer and/or elevator is having problems? Why would using avaliable disk bandwidth vs letting it lie dormant be a generically bad thing?.. this I just can't understand. The elevator deals with seeks, the vm is flat not equipped to do so.. it contains such concept. Avoiding write is great, delaying write is not at _all_ great. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] more fs/super.c cleanups (3)
Chunk 3:
Takes the normal mounting into a helper similar to do_loopback()
et.al., makes do_mount() cleaner. Please, apply
Al
diff -urN S6-pre1-do_mount/fs/super.c S6-pre1-do_add_mount/fs/super.c
--- S6-pre1-do_mount/fs/super.c Tue Jun 5 08:15:33 2001
+++ S6-pre1-do_add_mount/fs/super.c Tue Jun 5 08:16:35 2001
@@ -1203,6 +1203,76 @@
return do_remount_sb(nd->mnt->mnt_sb, flags, data);
}
+static int do_add_mount(struct nameidata *nd, char *type, int flags,
+ char *name, void *data)
+{
+ struct file_system_type * fstype;
+ struct nameidata nd;
+ struct vfsmount *mnt = NULL;
+ struct super_block *sb;
+ int retval = 0;
+
+ if (!type || !memchr(type, 0, PAGE_SIZE))
+ return -EINVAL;
+
+ /* we need capabilities... */
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+
+ /* ... filesystem driver... */
+ fstype = get_fs_type(type);
+ if (!fstype)
+ return -ENODEV;
+
+ /* get superblock, locks mount_sem on success */
+ if (fstype->fs_flags & FS_NOMOUNT)
+ sb = ERR_PTR(-EINVAL);
+ else if (fstype->fs_flags & FS_REQUIRES_DEV)
+ sb = get_sb_bdev(fstype, name, flags, data);
+ else if (fstype->fs_flags & FS_SINGLE)
+ sb = get_sb_single(fstype, flags, data);
+ else
+ sb = get_sb_nodev(fstype, flags, data);
+
+ retval = PTR_ERR(sb);
+ if (IS_ERR(sb))
+ goto fs_out;
+
+ /* Something was mounted here while we slept */
+ while(d_mountpoint(nd->dentry) && follow_down(>mnt, >dentry))
+ ;
+
+ /* Refuse the same filesystem on the same mount point */
+ retval = -EBUSY;
+ if (nd->mnt->mnt_sb == sb && nd->mnt->mnt_root == nd->dentry)
+ goto fail;
+
+ retval = -ENOENT;
+ if (!nd->dentry->d_inode)
+ goto fail;
+ retval = -ENOTDIR;
+ if (!S_ISDIR(nd->dentry->d_inode->i_mode))
+ goto fail;
+ down(>dentry->d_inode->i_zombie);
+ if (!IS_DEADDIR(nd->dentry->d_inode)) {
+ retval = -ENOMEM;
+ mnt = add_vfsmnt(nd, sb->s_root, name);
+ }
+ up(>dentry->d_inode->i_zombie);
+ if (!mnt)
+ goto fail;
+ retval = 0;
+unlock_out:
+ up(_sem);
+fs_out:
+ put_filesystem(fstype);
+ return retval;
+
+fail:
+ kill_super(sb);
+ goto unlock_out;
+}
+
static int copy_mount_options (const void *data, unsigned long *where)
{
int i;
@@ -1253,10 +1323,7 @@
long do_mount(char * dev_name, char * dir_name, char *type_page,
unsigned long flags, void *data_page)
{
- struct file_system_type * fstype;
struct nameidata nd;
- struct vfsmount *mnt = NULL;
- struct super_block *sb;
int retval = 0;
/* Discard magic */
@@ -1276,86 +1343,16 @@
if (retval)
return retval;
- /* just change the flags? - capabilities are checked in do_remount() */
- if (flags & MS_REMOUNT) {
- retval = do_remount(, flags&~MS_REMOUNT, (char *)data_page);
- goto nd_out;
- }
-
- /* "mount --bind"? Equivalent to older "mount -t bind" */
- /* No capabilities? What if users do thousands of these? */
- if (flags & MS_BIND) {
+ if (flags & MS_REMOUNT)
+ retval = do_remount(, flags&~MS_REMOUNT,
+ (char *)data_page);
+ else if (flags & MS_BIND)
retval = do_loopback(, dev_name);
- goto nd_out;
- }
-
- /* For the rest we need the type */
-
- retval = -EINVAL;
- if (!type_page || !memchr(type_page, 0, PAGE_SIZE))
- goto nd_out;
-
- retval = -EPERM;
- /* for the rest we _really_ need capabilities... */
- if (!capable(CAP_SYS_ADMIN))
- goto nd_out;
-
- retval = -ENODEV;
- /* ... filesystem driver... */
- fstype = get_fs_type(type_page);
- if (!fstype)
- goto nd_out;
-
- /* get superblock, locks mount_sem on success */
- if (fstype->fs_flags & FS_NOMOUNT)
- sb = ERR_PTR(-EINVAL);
- else if (fstype->fs_flags & FS_REQUIRES_DEV)
- sb = get_sb_bdev(fstype, dev_name, flags, data_page);
- else if (fstype->fs_flags & FS_SINGLE)
- sb = get_sb_single(fstype, flags, data_page);
else
- sb = get_sb_nodev(fstype, flags, data_page);
-
- retval = PTR_ERR(sb);
- if (IS_ERR(sb))
- goto fs_out;
-
- /* Something was mounted here while we slept */
- while(d_mountpoint(nd.dentry) && follow_down(, ))
- ;
-
- /* Refuse the same filesystem on the same mount point */
- retval
Re: lots of pppd (down) stall SMP linux-2.4.x
Try your test with "High Memory Support" disabled. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] more fs/super.c fixes (2)
Chunk 2:
Since all branches of do_mount() (mounting, binding, remounting)
do the same thing (lookup of directory) we can take that lookup in the
beginning of do_mount() and pass to do_loopback() and do_remount()
nameidata instead of name.
Please, apply
Al
diff -urN S6-pre1-do_remount/fs/super.c S6-pre1-do_mount/fs/super.c
--- S6-pre1-do_remount/fs/super.c Tue Jun 5 08:14:29 2001
+++ S6-pre1-do_mount/fs/super.c Tue Jun 5 08:15:33 2001
@@ -1151,9 +1151,9 @@
/*
* do loopback mount.
*/
-static int do_loopback(char *old_name, char *new_name)
+static int do_loopback(struct nameidata *nd, char *old_name)
{
- struct nameidata old_nd, new_nd;
+ struct nameidata old_nd;
int err = 0;
if (!old_name || !*old_name)
return -EINVAL;
@@ -1161,31 +1161,25 @@
err = path_walk(old_name, _nd);
if (err)
goto out;
- if (path_init(new_name, LOOKUP_POSITIVE, _nd))
- err = path_walk(new_name, _nd);
+ err = mount_is_safe(nd);
if (err)
goto out1;
- err = mount_is_safe(_nd);
- if (err)
- goto out2;
err = -EINVAL;
- if (S_ISDIR(new_nd.dentry->d_inode->i_mode) !=
+ if (S_ISDIR(nd->dentry->d_inode->i_mode) !=
S_ISDIR(old_nd.dentry->d_inode->i_mode))
- goto out2;
+ goto out1;
err = -ENOMEM;
down(_sem);
/* there we go */
- down(_nd.dentry->d_inode->i_zombie);
- if (IS_DEADDIR(new_nd.dentry->d_inode))
+ down(>dentry->d_inode->i_zombie);
+ if (IS_DEADDIR(nd->dentry->d_inode))
err = -ENOENT;
- else if (add_vfsmnt(_nd, old_nd.dentry, old_nd.mnt->mnt_devname))
+ else if (add_vfsmnt(nd, old_nd.dentry, old_nd.mnt->mnt_devname))
err = 0;
- up(_nd.dentry->d_inode->i_zombie);
+ up(>dentry->d_inode->i_zombie);
up(_sem);
-out2:
- path_release(_nd);
out1:
path_release(_nd);
out:
@@ -1198,25 +1192,15 @@
* on it - tough luck.
*/
-static int do_remount(const char *dir,int flags,char *data)
+static int do_remount(struct nameidata *nd, int flags, char *data)
{
- struct nameidata nd;
- int retval = 0;
-
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
- if (path_init(dir, LOOKUP_FOLLOW|LOOKUP_POSITIVE, ))
- retval = path_walk(dir, );
- if (retval)
- return retval;
-
- retval = -EINVAL;
- if (nd.dentry == nd.mnt->mnt_root)
- retval = do_remount_sb(nd.mnt->mnt_sb, flags, data);
+ if (nd->dentry != nd->mnt->mnt_root)
+ return -EINVAL;
- path_release();
- return retval;
+ return do_remount_sb(nd->mnt->mnt_sb, flags, data);
}
static int copy_mount_options (const void *data, unsigned long *where)
@@ -1286,38 +1270,41 @@
if (dev_name && !memchr(dev_name, 0, PAGE_SIZE))
return -EINVAL;
- /* OK, looks good, now let's see what do they want */
+ /* ... and get the mountpoint */
+ if (path_init(dir_name, LOOKUP_FOLLOW|LOOKUP_POSITIVE, ))
+ retval = path_walk(dir_name, );
+ if (retval)
+ return retval;
/* just change the flags? - capabilities are checked in do_remount() */
- if (flags & MS_REMOUNT)
- return do_remount(dir_name, flags & ~MS_REMOUNT,
- (char *) data_page);
+ if (flags & MS_REMOUNT) {
+ retval = do_remount(, flags&~MS_REMOUNT, (char *)data_page);
+ goto nd_out;
+ }
/* "mount --bind"? Equivalent to older "mount -t bind" */
/* No capabilities? What if users do thousands of these? */
- if (flags & MS_BIND)
- return do_loopback(dev_name, dir_name);
+ if (flags & MS_BIND) {
+ retval = do_loopback(, dev_name);
+ goto nd_out;
+ }
/* For the rest we need the type */
+ retval = -EINVAL;
if (!type_page || !memchr(type_page, 0, PAGE_SIZE))
- return -EINVAL;
+ goto nd_out;
+ retval = -EPERM;
/* for the rest we _really_ need capabilities... */
if (!capable(CAP_SYS_ADMIN))
- return -EPERM;
+ goto nd_out;
+ retval = -ENODEV;
/* ... filesystem driver... */
fstype = get_fs_type(type_page);
if (!fstype)
- return -ENODEV;
-
- /* ... and mountpoint. Do the lookup first to force automounting. */
- if (path_init(dir_name,
- LOOKUP_FOLLOW|LOOKUP_POSITIVE|LOOKUP_DIRECTORY, ))
- retval = path_walk(dir_name, );
- if (retval)
- goto fs_out;
+ goto nd_out;
/* get superblock, locks mount_sem on
[PATCH] more fs/super.c cleanups (1)
Linus, here's the next series of fs/super.c cleanups, cut into
small chunks. Patches are incremental.
Chunk #1:
Switches special case in do_umount() to do_remount_sb() (from
do_remount()); takes all per-superblock steps of remount into remount_sb().
That will allow to clean the lookup logics in the do_remount()/do_lookup()/
do_mount() (next chunk).
Please, apply.
Al
diff -urN S6-pre1/fs/super.c S6-pre1-do_remount/fs/super.c
--- S6-pre1/fs/super.c Tue Jun 5 06:21:52 2001
+++ S6-pre1-do_remount/fs/super.c Tue Jun 5 08:14:29 2001
@@ -55,7 +55,6 @@
extern int root_mountflags;
static int do_remount_sb(struct super_block *sb, int flags, char * data);
-static int do_remount(const char *dir, int flags, char * data);
/* this is initialized in init/main.c */
kdev_t ROOT_DEV;
@@ -923,6 +922,10 @@
if (!(flags & MS_RDONLY) && sb->s_dev && is_read_only(sb->s_dev))
return -EACCES;
/*flags |= MS_RDONLY;*/
+ if (flags & MS_RDONLY)
+ acct_auto_close(sb->s_dev);
+ shrink_dcache_sb(sb);
+ fsync_dev(sb->s_dev);
/* If we are remounting RDONLY, make sure there are no rw files open */
if ((flags & MS_RDONLY) && !(sb->s_flags & MS_RDONLY))
if (!fs_may_remount_ro(sb))
@@ -1004,11 +1007,14 @@
* call reboot(9). Then init(8) could umount root and exec /reboot.
*/
if (mnt == current->fs->rootmnt) {
+ int retval = 0;
/*
* Special case for "unmounting" root ...
* we just try to remount it readonly.
*/
- return do_remount("/", MS_RDONLY, NULL);
+ if (!(sb->s_flags & MS_RDONLY))
+ retval = do_remount_sb(sb, MS_RDONLY, 0);
+ return retval;
}
spin_lock(_lock);
@@ -1202,24 +1208,14 @@
if (path_init(dir, LOOKUP_FOLLOW|LOOKUP_POSITIVE, ))
retval = path_walk(dir, );
- if (!retval) {
- struct super_block * sb = nd.dentry->d_inode->i_sb;
- retval = -ENODEV;
- if (sb) {
- retval = -EINVAL;
- if (nd.dentry == sb->s_root) {
- /*
-* Shrink the dcache and sync the device.
-*/
- shrink_dcache_sb(sb);
- fsync_dev(sb->s_dev);
- if (flags & MS_RDONLY)
- acct_auto_close(sb->s_dev);
- retval = do_remount_sb(sb, flags, data);
- }
- }
- path_release();
- }
+ if (retval)
+ return retval;
+
+ retval = -EINVAL;
+ if (nd.dentry == nd.mnt->mnt_root)
+ retval = do_remount_sb(nd.mnt->mnt_sb, flags, data);
+
+ path_release();
return retval;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac8 hardlocks when going to standby
Hi, 2.4.5-ac[4678] all lock hard (no sysreq) when pushing my power-button (setup from the bios to go to standby) or when running apm --standby. (apm version 3.0final, RH6.2) apm --suspend works the way it should. 2.4.5/2.4.6-pre1 don't hardlock. lspci -vvxxx output and .config are attached. Any ideas? -- Linux 2.4.6-pre1 #2 Tue Jun 5 18:08:24 CEST 2001 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) Subsystem: ABIT Computer Corp.: Unknown device a401 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 05 03 06 00 10 22 02 00 00 06 00 08 00 00 10: 08 00 00 d0 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 7b 14 01 a4 30: 00 00 00 00 a0 00 00 00 00 00 00 00 00 00 00 00 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- Reset- FastB2B- Capabilities: [80] Power Management version 2 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 06 11 05 83 07 00 30 22 00 00 04 06 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 01 01 00 f0 00 00 00 20: 00 d4 f0 d5 00 d6 f0 d6 00 00 00 00 00 00 00 00 30: 00 00 00 00 80 00 00 00 00 00 00 00 00 00 0c 00 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- [disabled] [size=256K] Capabilities: [d0] AGP version 1.0 Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2 Command: RQ=0 SBA- AGP- 64bit- FW- Rate= Capabilities: [dc] Power Management version 1 Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- 00: 86 80 00 78 07 00 b0 02 21 00 00 03 00 00 00 00 10: 08 00 00 d6 00 00 00 d5 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 b0 10 00 01 30: 00 00 00 00 d0 00 00 00 00 00 00 00 0b 01 00 00 CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_KMOD=y CONFIG_MK7=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_USE_3DNOW=y CONFIG_X86_PGE=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_PM=y CONFIG_APM=y CONFIG_APM_RTC_IS_GMT=y CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_DEV_LOOP=m CONFIG_MD=y CONFIG_BLK_DEV_LVM=m CONFIG_PACKET=m CONFIG_PACKET_MMAP=y CONFIG_NETLINK=y CONFIG_RTNETLINK=y CONFIG_NETLINK_DEV=y CONFIG_NETFILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_SYN_COOKIES=y CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_UNCLEAN=m CONFIG_IP_NF_MATCH_OWNER=m CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IDE=y CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_BLK_DEV_IDECD=y CONFIG_BLK_DEV_IDEFLOPPY=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_VIA82CXXX=y CONFIG_IDEDMA_AUTO=y CONFIG_BLK_DEV_IDE_MODES=y CONFIG_SCSI=y CONFIG_BLK_DEV_SD=y CONFIG_SD_EXTRA_DEVS=40 CONFIG_SCSI_IMM=m CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_PLIP=m CONFIG_PPP=m CONFIG_PPP_ASYNC=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_UNIX98_PTYS=y
smp errors in 2.4!!
> I encounter this compilation error: > /usr/x.c:2112: struct has no member named > "event_Rsmp_7b16c344" I assume you have a variable called 'event', and that name got replaced by a versioned symbol. Yes, 'event' is a global variable in the kernel ;-) Do you include in that file? I usually use 'gcc -E' to find such problems. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PID's
This is probably a mundane question, but... Is there a way to recycle unused PID's without rebooting the kernel? So instead of the next available PID always getting larger and larger, just reset it to use the first unused PID after 1. Is this possible? -- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID of init != 1 when initrd with pivot_root
On Tue, 5 Jun 2001, W. Michael Petullo wrote: > > But the problem still remains. How do I make my /sbin/init run with PID 1 > > using initial ramdisk under the new root change mechanism? I don't want to > > use the old change_root mechanism... > > I had the same problem when doing some development for mkCDrec. > This project uses busybox, whose init does not run if its PID != 1. > I asked the busybox folks same question you did and never got a response. Maybe I'm wrong here, but I had the same problem at some point and my solution was to rename /linuxrc (to /linux, and booting with init=/linux). I believe the code which special cases /linuxrc might be in the way here. Maybe you want to try this, if it helps I think Documentation/initrd.txt needs to be updated. --Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID of init != 1 when initrd with pivot_root
> > But the problem still remains. How do I make my /sbin/init run with PID 1 > > using initial ramdisk under the new root change mechanism? I don't want to > > use the old change_root mechanism... > > I had the same problem when doing some development for mkCDrec. > This project uses busybox, whose init does not run if its PID != 1. > I asked the busybox folks same question you did and never got a response. > > As a kludge, and after looking at the busybox source code, I renamed init > to linuxrc. In this case the program is functionally equivalent to init, > except that it does not do the PID == 1 check. > > An excerpt from my real linuxrc: > > echo Pivot_root: my PID is $$ > # exec /usr/sbin/chroot . /sbin/init < dev/console > dev/console 2>&1 > # Okay, try this: > exec /usr/sbin/chroot . /sbin/linuxrc < /dev/console > /dev/console 2>&1 > > /sbin/linuxrc is actually init, renamed. > I fugured it out. The Documentation/initrd.txt says to use root=/dev/rd/0 with devfs. Well, that's wrong. You should use root=/dev/ram0 even with devfs no matter what the documentation says. And my linuxrc finaly runs with PID == 1. Ivan Vadovic - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Comment on patch to remove nr_async_pages limit
On Tue, 5 Jun 2001, Mike Galbraith wrote: > Yes. If we start writing out sooner, we aren't stuck with pushing a > ton of IO all at once and can use prudent limits. Not only because of > potential allocation problems, but because our situation is changing > rapidly so small corrections done often is more precise than whopping > big ones can be. Hold on there big boy, writing out sooner is not better. What if the memory shortage is because real data is being written out to disk? Swapping early causes many more problems than swapping late as extraneous seeks to the swap partiton severely degrade performance. -ben - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
smp errors in 2.4!!
I encounter this compilation error: /usr/x.c:2112: struct has no member named "event_Rsmp_7b16c344" The structure has that field and I don't have the conflicting structure name anywhere in my code and in the system files too. The makefile uses sed and *.d files. Could anyone help me out as how to fix this. Thanks Jalaja __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: patch for ide.2.4.5-ac8
Thanks Todd,
Everyone knows that I was not an english major ;-)
Cheers,
On Tue, 5 Jun 2001, Todd M. Roy wrote:
> Andre,
> Minor typo fix:
> --- ide-dma.c.~1~ Tue Jun 5 14:39:06 2001
> +++ ide-dma.c Tue Jun 5 15:04:54 2001
> @@ -708,15 +708,15 @@
> if ((!dma_base) && (!second_chance)) {
> unsigned long set_bmiba = 0;
> second_chance++;
> - switch(dev->vender) {
> - PCI_VENDOR_ID_AL:
> - set_bmiba = DEFAULT_BMALIBA; break;
> - PCI_VENDOR_ID_VIA:
> - set_bmiba = DEFAULT_BMCRBA; break;
> - PCI_VENDOR_ID_INTEL:
> - set_bmiba = DEFAULT_BMIBA; break;
> - default:
> - return dma_base;
> + switch (dev->vendor) {
> + case PCI_VENDOR_ID_AL:
> + set_bmiba = DEFAULT_BMALIBA; break;
> + case PCI_VENDOR_ID_VIA:
> + set_bmiba = DEFAULT_BMCRBA; break;
> + case PCI_VENDOR_ID_INTEL:
> + set_bmiba = DEFAULT_BMIBA; break;
> + default:
> + return dma_base;
> }
> pci_write_config_dword(dev, 0x20, set_bmiba|1);
> goto second_chance_to_dma;
>
> Cheers,
> Todd
> **
> This footnote confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> **
>
Andre Hedrick
ASL Kernel Development
Linux ATA Development
-
ASL, Inc. Toll free: 1-877-ASL-3535
1757 Houret Court Fax: 1-408-941-2071
Milpitas, CA 95035Web: www.aslab.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
patch for ide.2.4.5-ac8
Andre,
Minor typo fix:
--- ide-dma.c.~1~ Tue Jun 5 14:39:06 2001
+++ ide-dma.c Tue Jun 5 15:04:54 2001
@@ -708,15 +708,15 @@
if ((!dma_base) && (!second_chance)) {
unsigned long set_bmiba = 0;
second_chance++;
- switch(dev->vender) {
- PCI_VENDOR_ID_AL:
- set_bmiba = DEFAULT_BMALIBA; break;
- PCI_VENDOR_ID_VIA:
- set_bmiba = DEFAULT_BMCRBA; break;
- PCI_VENDOR_ID_INTEL:
- set_bmiba = DEFAULT_BMIBA; break;
- default:
- return dma_base;
+ switch (dev->vendor) {
+case PCI_VENDOR_ID_AL:
+ set_bmiba = DEFAULT_BMALIBA; break;
+case PCI_VENDOR_ID_VIA:
+ set_bmiba = DEFAULT_BMCRBA; break;
+case PCI_VENDOR_ID_INTEL:
+ set_bmiba = DEFAULT_BMIBA; break;
+default:
+ return dma_base;
}
pci_write_config_dword(dev, 0x20, set_bmiba|1);
goto second_chance_to_dma;
Cheers,
Todd
**
This footnote confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kHTTPd hangs 2.4.5 boot when moduled
"David Gordon (LMC)" wrote: > I found that when kHTTPd is compiled as a module, kernel 2.4.5 will hang > at boot. However, when kHTTPd is omitted or compiled into the kernel, > the boot is okay. This is very strange. Does your kernel do the same if you compile IPv6 as module and khttpd off ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: the value of PROC_CHANGE_PENALTY
On Mon, 4 Jun 2001, Mark Hahn wrote: > > am I correct ? > > and if so, is this what the authors meant, or did they simply forget > > to update PROC_CHANGE_PENALTY's value when moving from 2.2 to 2.4 ? > > I don't believe anyone has proposed a relation between nice > and cpu-affinity; the latter has always been a fairly arbitrary > constant. I see, but even so, in linux-2.2 this arbitrary constant allows a non realtime task to migrate, and totally prohibits it in linux-2.4 (unless some other cpu is idle). i.e. maybe there is no relation between the max value of the static priority and PROC_CHANGE_PENALTY, but you get a scheduler that behaves quite differently when you change one without the other. I think that if it's indeed an arbitrary value, then it should have been modified along with the modification of the quantum's length, because this way the 2.2 behavior (which I assume somebody adopted for a reason) would have remained the same. However, if you say that PROC_CHANGE_PENALTY does somehow embody the cpu-time wasted because of migration (due to cache etc.) regardless of the quantum's length, then PROC_CHANGE_PENALTY should probably remain the same and I got my answer. Is this what you mean ? thanks, Dan. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reiserfs leak in errors paths
Hi guys,
A few of the reiserfs errors paths for i/o error neglect to release
buffer heads. This patch makes sure things get released properly
and if dirty buffers were prepared for the log, also makes sure
the dirty bits are reset (by using unfix_nodes intead of pathrelse).
Vladimir Saveliev helped out with this one, it was against 2.4.4, but
I just retested under 2.4.5.
Alan, please apply.
-chris
diff -urN linux-2.4.4.tmp/fs/reiserfs/fix_node.c linux-2.4.4/fs/reiserfs/fix_node.c
--- linux-2.4.4.tmp/fs/reiserfs/fix_node.c Sat Apr 14 05:26:07 2001
+++ linux-2.4.4/fs/reiserfs/fix_node.c Mon May 14 15:31:52 2001
@@ -2719,12 +2719,6 @@
{
inti;
-#ifdef CONFIG_REISERFS_CHECK
-if ( ! tb->vn_buf )
- reiserfs_panic (tb->tb_sb,
- "PAP-16050: unfix_nodes: pointer to the virtual node is NULL");
-#endif
-
/* Release path buffers. */
pathrelse_and_restore (tb->tb_sb, tb->tb_path);
@@ -2781,7 +2775,8 @@
}
}
#endif /* 0 */
-reiserfs_kfree (tb->vn_buf, tb->vn_buf_size, tb->tb_sb);
+if (tb->vn_buf)
+ reiserfs_kfree (tb->vn_buf, tb->vn_buf_size, tb->tb_sb);
}
diff -urN linux-2.4.4.tmp/fs/reiserfs/stree.c linux-2.4.4/fs/reiserfs/stree.c
--- linux-2.4.4.tmp/fs/reiserfs/stree.c Sat Apr 14 05:26:07 2001
+++ linux-2.4.4/fs/reiserfs/stree.c Mon May 14 15:31:52 2001
@@ -1724,7 +1724,7 @@
continue;
reiserfs_warning ("PAP-5610: reiserfs_cut_from_item: item %K not found\n",
p_s_item_key);
- pathrelse (p_s_path);
+ unfix_nodes (_cut_balance);
return (n_ret_value == IO_ERROR) ? -EIO : -ENOENT;
} /* while */
@@ -1994,12 +1994,14 @@
while ( (retval = fix_nodes(M_PASTE, _paste_balance, NULL, p_c_body)) ==
REPEAT_SEARCH ) {
/* file system changed while we were in the fix_nodes */
retval = search_for_position_by_key (th->t_super, p_s_key, p_s_search_path);
- if (retval == IO_ERROR)
- return -EIO;
+ if (retval == IO_ERROR) {
+ retval = -EIO ;
+ goto error_out ;
+ }
if (retval == POSITION_FOUND) {
reiserfs_warning ("PAP-5710: reiserfs_paste_into_item: entry or pasted
byte (%K) exists", p_s_key);
- pathrelse (p_s_search_path);
- return -EEXIST;
+ retval = -EEXIST ;
+ goto error_out ;
}
#ifdef CONFIG_REISERFS_CHECK
@@ -2013,9 +2015,11 @@
do_balance(_paste_balance, NULL/*ih*/, p_c_body, M_PASTE);
return 0;
}
-
+retval = (retval == NO_DISK_SPACE) ? -ENOSPC : -EIO;
+error_out:
+/* this also releases the path */
unfix_nodes(_paste_balance);
-return (retval == NO_DISK_SPACE) ? -ENOSPC : -EIO;
+return retval ;
}
@@ -2040,14 +2044,15 @@
while ( (retval = fix_nodes(M_INSERT, _ins_balance, p_s_ih, p_c_body)) ==
REPEAT_SEARCH) {
/* file system changed while we were in the fix_nodes */
retval = search_item (th->t_super, key, p_s_path);
- if (retval == IO_ERROR)
- return -EIO;
-
+ if (retval == IO_ERROR) {
+ retval = -EIO;
+ goto error_out ;
+ }
if (retval == ITEM_FOUND) {
reiserfs_warning ("PAP-5760: reiserfs_insert_item: "
"key %K already exists in the tree\n", key);
- pathrelse (p_s_path);
- return -EEXIST;
+ retval = -EEXIST ;
+ goto error_out;
}
}
@@ -2057,8 +2062,11 @@
return 0;
}
+retval = (retval == NO_DISK_SPACE) ? -ENOSPC : -EIO;
+error_out:
+/* also releases the path */
unfix_nodes(_ins_balance);
-return (retval == NO_DISK_SPACE) ? -ENOSPC : -EIO;
+return retval;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: kHTTPd hangs 2.4.5 boot when moduled
> I found that when kHTTPd is compiled as a module, kernel > 2.4.5 will hang ... > I run an Intel RH7.0 machine. Please note the following discrepancy between RH70 and the minimal required versions of the following 3 packages (I am ommitting others, like pci or reiserfs stuff, as these seem irrelevant to your case. See Docu*/Changes on 2.4.5 for details) package RH7.0 has...2.4.2 and on needs... util-linux 2.10m 2.10o modutils2.3.21 2.4.2 e2fsprogs 1.181.19 HTH, Vassilii - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 11:30:51AM -0700, Jeff V. Merkey wrote: > On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: > > > is curious as to how these folks did this. They exploited BIND 8.2.3 > > > to get in and logs indicated that someone was using a "back door" in > > Bind runs as root. > > > We are unable to determine just how they got in exactly, but they > > > kept trying and created an oops in the affected code which allowed > > > the attack to proceed. > > Are you sure they didnt in fact simply screw up live patching the kernel to > > cover their traces > Could have. The kernel is unable to dismount the root volume when booted. > I can go through the drive and remove confidential stuffd and just leave > the system intact and post the entire system image to my ftp server. This would be a good thing for those of us involved in investigating these sorts of things. :-/ > I have changed all the passwords on the server, so what's there is no > big deal. This server was public FTP and web/email, so nothing really > super "confidential" on it. > Jeff Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
kHTTPd hangs 2.4.5 boot when moduled
Hi CC at [EMAIL PROTECTED] if reply I found that when kHTTPd is compiled as a module, kernel 2.4.5 will hang at boot. However, when kHTTPd is omitted or compiled into the kernel, the boot is okay. I run an Intel RH7.0 machine. David Gordon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ethertap
Hi!
According /usr/src/linux/Documentation/networking/ethertap.txt I've tried
to use ethertap for my experimental user space TCP/IP implementation
testing. I'm using kernel 2.2.19 (UP).
I load ethertap kernel module and configure it with ifconfig. Nice,
ping works, ifconfig show tap0. /dev/tap0 exists, major and minor is
correct.
But opening /dev/tap0 does not work!
munmap(0x127000, 55843) = 0
getpid()= 29070
open("/dev/tap0", O_RDWR|O_NONBLOCK)= -1 ENOSYS (Function not implemented)
open("/dev/tap0", O_RDWR|O_NONBLOCK)= -1 ENOSYS (Function not implemented)
open("/dev/tap0", O_RDWR|O_NONBLOCK)= -1 ENODEV (No such device)
write(2, "Cannot open /dev/tap0: No such d"..., 38Cannot open /dev/tap0: No such device
What can be the problem? How can I use /dev/tap0 then? I exactly followed
instructions read in ethertap.txt but it does not work ;-(((
- Gabor
PS: please cc me, I've got problems with getting mails from this list it
seems :(
--
--[ Gábor Lénárt ]---[ Vivendi Telecom Hungary ]-[ [EMAIL PROTECTED] ]--
U have 8 bit comp or chip of them and it's unused or to be sold? Call me!
---[ +36 30 2270823 ]--> LGB <-[ Linux/UNIX/8bit 4ever ]-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OOPS] 245ac7 - ncr53c8xx && reiserfs
On Tuesday, June 05, 2001 03:00:40 PM -0400 Carlos E Gorges <[EMAIL PROTECTED]> wrote: > Hi all, > > I get some problems w/ 2.4.5-ac7, ncr53c8xx w/ 2.4.4-ac18 works fine. > > I gave a small looked on problem .. > the problem apparently is w/ ncr53c8xx driver ( who accuses timeout ), > and make reiserfs call BUG() : > reiserfs does this when it fails to write metadata or log buffers, continuing without a panic or readonly mount will result in FS corruption. A forced readonly mount is a much better solution, but I haven't had a chance yet to make sure it safely prevents writeback of all metadata, and cleans things up properly. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.4.5] Fix NFS Oops w.r.t. unhashed inodes
Hi Linus, One consequence of the removal of the 'put_inode: force_delete' made for 2.4.5 mmap() is that we now use the 'magic nfs' codepath in iput(). The result is that when we unhash inodes due to staleness in nfs_revalidate_inode(), we now end up calling clear_inode() in iput without first calling truncate_inode_pages(), and thus trigger the BUG() on line 486 in fs/inode.c. After discussion with Al, I think the minimal solution would be to add a call to truncate_inode_pages() to the magic nfs code. To do the call in nfs_revalidate_inode() itself (Al's suggestion) would be racy w.r.t. adding pages in read or write itself. A second consequence of the removal of force_delete was the fact that file or directory deletion no longer results in the inode getting thrown out of the icache upon last iput(). This gave problems due to inode number reuse on the userland nfsd. The solution is to update i_nlink when we delete or rmdir. Cheers, Trond --- linux-2.4.5-pre6/fs/inode.c.origFri May 25 14:15:38 2001 +++ linux-2.4.5-pre6/fs/inode.c Wed May 30 12:17:29 2001 @@ -1044,6 +1044,8 @@ inode->i_state|=I_FREEING; inodes_stat.nr_inodes--; spin_unlock(_lock); + if (inode->i_data.nrpages) + truncate_inode_pages(>i_data, 0); clear_inode(inode); } } --- linux-2.4.5-pre6/fs/nfs/dir.c.orig Fri May 25 14:15:38 2001 +++ linux-2.4.5-pre6/fs/nfs/dir.c Thu May 31 14:53:32 2001 @@ -753,6 +753,8 @@ nfs_zap_caches(dir); error = NFS_PROTO(dir)->rmdir(dir, >d_name); + if (!error) + dentry->d_inode->i_nlink = 0; return error; } @@ -870,6 +872,8 @@ error = NFS_PROTO(dir)->remove(dir, >d_name); if (error < 0) goto out; + if (inode) + inode->i_nlink--; out_delete: /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problems with ipx on Kernel 2.4.5
Hi, is it possible that the novell ipx protokoll is a little bit broken on Kernel 2.4.5? -schnipp-- if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.5; fi depmod: *** Unresolved symbols in\ /lib/modules/2.4.5/kernel/net/ipx/ipx.o depmod: unregister_8022_client depmod: make_EII_client depmod: register_8022_client depmod: register_snap_client depmod: make_8023_client depmod: destroy_8023_client depmod: destroy_EII_client depmod: unregister_snap_client schnapp- ---schnipp- cat /usr/src/linux/.config: # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y # CONFIG_SBUS is not set CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODVERSIONS is not set # CONFIG_KMOD is not set # # Processor type and features # # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUM4 is not set CONFIG_MK6=y # CONFIG_MK7 is not set # CONFIG_MCRUSOE is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MCYRIXIII is not set CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_TSC=y CONFIG_X86_USE_PPRO_CHECKSUM=y # CONFIG_TOSHIBA is not set CONFIG_MICROCODE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set # CONFIG_MATH_EMULATION is not set # CONFIG_MTRR is not set # CONFIG_SMP is not set # CONFIG_X86_UP_IOAPIC is not set # # General setup # CONFIG_NET=y # CONFIG_VISWS is not set CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y # CONFIG_EISA is not set # CONFIG_MCA is not set CONFIG_HOTPLUG=y # # PCMCIA/CardBus support # # CONFIG_PCMCIA is not set CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y # CONFIG_KCORE_AOUT is not set # CONFIG_BINFMT_AOUT is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y # CONFIG_PM is not set # CONFIG_ACPI is not set # CONFIG_APM is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=y CONFIG_PARPORT_PC_FIFO=y CONFIG_PARPORT_PC_SUPERIO=y # CONFIG_PARPORT_AMIGA is not set # CONFIG_PARPORT_MFC3 is not set # CONFIG_PARPORT_ATARI is not set # CONFIG_PARPORT_SUNBPP is not set CONFIG_PARPORT_OTHER=y CONFIG_PARPORT_1284=y # # Plug and Play configuration # CONFIG_PNP=y CONFIG_ISAPNP=y # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_BLK_DEV_XD is not set # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_BLK_DEV_INITRD is not set # # Multi-device support (RAID and LVM) # CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set # CONFIG_MD_RAID1 is not set # CONFIG_MD_RAID5 is not set CONFIG_BLK_DEV_LVM=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_NETLINK=y CONFIG_RTNETLINK=y # CONFIG_NETLINK_DEV is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_RTNETLINK=y CONFIG_NETLINK=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_ROUTE_LARGE_TABLES is not set # CONFIG_IP_PNP is not set # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y CONFIG_ARPD=y CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y # # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y CONFIG_IP_NF_FTP=y CONFIG_IP_NF_QUEUE=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_LIMIT=y CONFIG_IP_NF_MATCH_MAC=y CONFIG_IP_NF_MATCH_MARK=y CONFIG_IP_NF_MATCH_MULTIPORT=y CONFIG_IP_NF_MATCH_TOS=y # CONFIG_IP_NF_MATCH_TCPMSS is not set CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_UNCLEAN=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_MIRROR=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_IP_NF_TARGET_REDIRECT=y CONFIG_IP_NF_NAT_FTP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_IPV6 is not set # CONFIG_KHTTPD is not set # CONFIG_ATM is
Re: 2.4.6-pre1 unresolved symbols
Thanks, Patch applied. On Tue, 5 Jun 2001, Jeff Garzik wrote: > Shawn Starr wrote: > > > > I have noticed unresolves symbols for the netfilter modules. this occurs > > durning depmod -a. > > Note they are the same unresolved symbol. > > Ingo Molnar has posted a patch for this, entitled > [patch] softirq-2.4.6-B4 > > or you can edit kernel/ksyms.c yourself, and add the lines > > EXPORT_SYMBOL(do_softirq); > EXPORT_SYMBOL(tasklet_schedule); > EXPORT_SYMBOL(tasklet_hi_schedule); > > -- > Jeff Garzik | An expert is one who knows more and more about > Building 1024| less and less until he knows absolutely everything > MandrakeSoft | about nothing. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] Re: Linux 2.4.5-ac6
On Tue, Jun 05, 2001 at 05:11:01PM +0200, Maciej W. Rozycki wrote:
> Iterating over memory areas twice is ugly.
Hmm, yes. However, your patch isn't pretty, too. You may check
the same area twice, and won't satisfy requested address > TASK_UNMAPPED_BASE.
What do you think about following? Everything is scanned only once, and
returned address matches specified one as close as possible.
Ivan.
--- linux/mm/mmap.c.origMon Jun 4 14:19:02 2001
+++ linux/mm/mmap.c Tue Jun 5 21:05:23 2001
@@ -398,22 +398,30 @@ free_vma:
static inline unsigned long arch_get_unmapped_area(struct file *filp, unsigned long
addr, unsigned long len, unsigned long pgoff, unsigned long flags)
{
struct vm_area_struct *vma;
+ unsigned long addr_limit = TASK_SIZE - len;
if (len > TASK_SIZE)
return -ENOMEM;
if (addr) {
addr = PAGE_ALIGN(addr);
- vma = find_vma(current->mm, addr);
- if (TASK_SIZE - len >= addr &&
- (!vma || addr + len <= vma->vm_start))
- return addr;
+ if (addr <= TASK_UNMAPPED_BASE)
+ goto scan_low;
+ addr_limit = addr;
+ for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
+ if (TASK_SIZE - len < addr)
+ break;
+ if (!vma || addr + len <= vma->vm_start)
+ return addr;
+ addr = vma->vm_end;
+ }
}
addr = PAGE_ALIGN(TASK_UNMAPPED_BASE);
+scan_low:
for (vma = find_vma(current->mm, addr); ; vma = vma->vm_next) {
/* At this point: (!vma || addr < vma->vm_end). */
- if (TASK_SIZE - len < addr)
+ if (addr_limit < addr)
return -ENOMEM;
if (!vma || addr + len <= vma->vm_start)
return addr;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tuesday 05 June 2001 14:57, Chris Wedgwood wrote: > I don't know about the CRIS (never heard of it, what is it?) I wondered about that too. From Documentation/cris: What is CRIS ? -- CRIS is an acronym for 'Code Reduced Instruction Set'. It is the CPU architecture in Axis Communication AB's range of embeddedn etwork CPU's, called ETRAX. The latest CPU is called ETRAX 100LX, where LX stands for 'Linux' because the chip was designed to be a good host for the Linux operating system. Interesting, huh? -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: semaphores and noatomic flag
whould it be possible to use pthread semaphore/mutex/cond_var on shared-via-mmap() chunks of memory instead ? regards -- +--+ |Rossetti Davide INFN - Sezione Roma I - gruppo V, prog. APEmille| | web: http://apegate.roma1.infn.it/~rossetti | |" E-mail : [EMAIL PROTECTED] | ||o o| phone : (+39)-06-49914412 | |--o00O-O00o-- fax: (+39)-06-49914423 (+39)-06-4957697 | | address: Dipartimento di Fisica (V.E.) | | Universita' di Roma "La Sapienza" | | P.le Aldo Moro,5 I - 00185 Roma - Italy| | gnupg pub. key: http://apegate.roma1.infn.it/~rossetti/gnupg.txt| | | |"Outside of a dog,a book is a man's best friend. Inside of a dog, | | it's too dark to read." - Groucho Marx | +--+ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: TRG vger.timpanogas.org hacked
On Tue, 5 Jun 2001, Randal, Phil wrote: > Bind 8.2.4 was released on May 17th, with the standard > comment "BIND 8.2.4 is the latest version of ISC BIND 8. > We strongly recommend that you upgrade to BIND 9.1 or, if > that is not immediately possible, to BIND 8.2.4 due to > certain security vulnerabilities in previous versions." > > However, there are no release notes on ISC's web site, > and their vulnerabilities page lists no known security > flaws in Bind 8.2.3. > > But the paranoid part of me does wonder :-) There really are no known vulnerabilities in BIND 8.2.3. There are a number of bug fixes which would make upgrading a good idea, though. The "previous versions" mentioned were those earlier than 8.2.3. Brian - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Agpgart for AMD761
It seems to be working just fine here (kernel 2.4.5), provided that the "agp_try_unsupported=1" option is specified. This tells the driver to assume that it behaves like known chipsets from the same vendor. On Tue, Jun 05, 2001 at 03:00:53PM +0200, [EMAIL PROTECTED] wrote: > I was wondering what is the state of support for the AMD761 Northbridge > chip, especially regarding agp operations since I don't see it listed > in the kernel configuration for the AGPGart device. > Please CC any answer to my address, since I'm not subscribed to the > list. > Thanks in advance. > > Paolo Pedroni PGP signature
Re: Comment on patch to remove nr_async_pages limit
Ed Tomlinson <[EMAIL PROTECTED]> writes: [snip] > Maybe we can have the best of both worlds. Is it possible to allocate the BH > early and then defer the IO? The idea being to make IO possible without having > to allocate. This would let us remove the async page limit but would ensure > we could still free. > Yes, this is a good idea if you ask me. Basically, to remove as many limits as we can, and also to secure us from the deadlocks. With just a few pages of extra memory for the reserved buffer heads, I think it's a fair game. Still, pending further analysis... -- Zlatko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Comment on patch to remove nr_async_pages limit
Mike Galbraith <[EMAIL PROTECTED]> writes: > On Mon, 4 Jun 2001, Marcelo Tosatti wrote: > > > Zlatko, > > > > I've read your patch to remove nr_async_pages limit while reading an > > archive on the web. (I have to figure out why lkml is not being delivered > > correctly to me...) > > > > Quoting your message: > > > > "That artificial limit hurts both swap out and swap in path as it > > introduces synchronization points (and/or weakens swapin readahead), > > which I think are not necessary." > > > > If we are under low memory, we cannot simply writeout a whole bunch of > > swap data. Remember the writeout operations will potentially allocate > > buffer_head's for the swapcache pages before doing real IO, which takes > > _more memory_: OOM deadlock. > > What's the point of creating swapcache pages, and then avoiding doing > the IO until it becomes _dangerous_ to do so? That's what we're doing > right now. This is a problem because we guarantee it will become one. > We guarantee that the pagecache will become almost pure swapcache by > delaying the writeout so long that everything else is consumed. > Huh, this looks just like my argument, just put in different words. I should have read this sooner. :) -- Zlatko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Comment on patch to remove nr_async_pages limit
Marcelo Tosatti <[EMAIL PROTECTED]> writes: [snip] > Exactly. And when we reach a low watermark of memory, we start writting > out the anonymous memory. > Hm, my observations are a little bit different. I find that writeouts happen sooner than the moment we reach low watermark, and many times just in time to interact badly with some read I/O workload that made a virtual shortage of memory in the first place. Net effect is poor performance and too much stuff in the swap. > > In experiments, speeding swapcache pages on their way helps. Special > > handling (swapcache bean counting) also helps. (was _really ugly_ code.. > > putting them on a seperate list would be a lot easier on the stomach:) > > I agree that the current way of limiting on-flight swapout can be changed > to perform better. > > Removing the amount of data being written to disk when we have a memory > shortage is not nice. > OK, then we basically agree that there is a place for improvement, and you also agree that we must be careful while trying to achieve that. I'll admit that my patch is mostly experimental, and its best effect is this discussion, which I enjoy very much. :) -- Zlatko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Comment on patch to remove nr_async_pages limit
Marcelo Tosatti <[EMAIL PROTECTED]> writes: > Zlatko, > > I've read your patch to remove nr_async_pages limit while reading an > archive on the web. (I have to figure out why lkml is not being delivered > correctly to me...) > > Quoting your message: > > "That artificial limit hurts both swap out and swap in path as it > introduces synchronization points (and/or weakens swapin readahead), > which I think are not necessary." > > If we are under low memory, we cannot simply writeout a whole bunch of > swap data. Remember the writeout operations will potentially allocate > buffer_head's for the swapcache pages before doing real IO, which takes > _more memory_: OOM deadlock. > My question is: if we defer writing and in a way "loose" that 4096 bytes of memory (because we decide to keep the page in the memory for some more time), how can a much smaller buffer_head be a problem? I think we could always make a bigger reserve of buffer heads just for this purpose, to make swapout more robust, and then don't impose any limits on the number of the outstanding async io pages in the flight. Does this make any sense? -- Zlatko - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac6: IDE deadlocks/bugs + unexpected IO-APIC
Hi ! I have an ABit VP6 (Dual PIII, infamous VIA686, onboard IDE + onboard HPT370). This is a new machine, so I didn't test it on several kernels. Using 2.4.4-ac11 (SMP), it started to deadlock really often when accessing the new disk (Seagate Barracuda, udma5, big reiserfs partition + swap) I put on the HPT370, even when mounting it. Using 2.4.5-ac6, things are much better, but sometimes it hangs at boot around "RAMDISK: Loading 4096 blocks [1 disk] into ram disk ..." - I say "around" because sometimes it displays "ACPI: Core Subsystem version ...", and sometimes not. And sometimes it still hangs randomly. No messages, nothing special in the logs except an "unexpected IO-APIC" (that's why I put linux-smp in Cc:) and 40 Megs (!!) of: Jun 2 23:11:58 bip kernel: attempt to access beyond end of device Jun 2 23:11:58 bip kernel: 07:00: rw=0, want=4906986, limit=4906984 Jun 2 23:11:58 bip kernel: attempt to access beyond end of device Jun 2 23:11:58 bip kernel: 07:00: rw=0, want=4906988, limit=4906984 Jun 2 23:11:58 bip kernel: attempt to access beyond end of device Jun 2 23:11:58 bip kernel: 07:00: rw=0, want=4906986, limit=4906984 Jun 2 23:11:58 bip kernel: attempt to access beyond end of device Jun 2 23:11:58 bip kernel: 07:00: r<6>07:00: rw=0, want=4906988, limi4 Jun 2 23:11:58 bip kernel: att<6>07:4 Jun 2 23:11:58 bip kernel: attemp<6>07:00: rw=0, want=4906988, 4 Jun 2 23:11:58 bip kernel: att<6>07:004 Jun 2 23:11:58 bip kernel: attemp<6>07:00: rw=0, want=4906988, li4 Jun 2 23:11:58 bip kernel: atte<6>07:004 Jun 2 23:11:58 bip kernel: att<6>07:00: rw=0, want=4906988, l4 Jun 2 23:11:58 bip kernel: attempt t<6>074 Jun 2 23:11:58 bip kernel: attem<6>07:00: rw=0, want=4906988, limit=4 Jun 2 23:11:58 bip kernel: at<6>07:00: rw=0, 4 Jun 2 23:11:58 bip kernel: atte<6>07:00: rw=0, want=4906988, limit=4 dated between Jun 2 23:11:58 and Jun 2 23:14:10 The thing that annoys me is that today, I just found the my /etc/motd with junk appended (a bit of C code). /etc/motd is on my root partition on a disk (Seagate ST36531A, big ext2 partition + swap) NOT on the HPT370, but on the first onboard IDE. I know (now that I looked a bit in the archives) that the VIA686 chipset isn't reliable. Any hint to make my PC work while keeping reasonable performance ? What should I do to help ? Xav [root@bip:~]$ lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT82C691 [Apollo PRO] (rev c4) Subsystem: ABIT Computer Corp.: Unknown device a204 Flags: bus master, medium devsel, latency 8 Memory at d000 (32-bit, prefetchable) [size=64M] Capabilities: [a0] AGP version 2.0 Capabilities: [c0] Power Management version 2 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3 AGP] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: 9000-9fff Memory behind bridge: d800-d9ff Prefetchable memory behind bridge: d400-d7ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 40) Subsystem: ABIT Computer Corp.: Unknown device Flags: bus master, stepping, medium devsel, latency 0 Capabilities: [c0] Power Management version 2 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 06) (prog-if 8a [Master SecP PriP]) Subsystem: VIA Technologies, Inc. VT82C586 IDE [Apollo] Flags: bus master, medium devsel, latency 32 I/O ports at a000 [size=16] Capabilities: [c0] Power Management version 2 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at a400 [size=32] Capabilities: [80] Power Management version 2 00:07.3 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 16) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at a800 [size=32] Capabilities: [80] Power Management version 2 00:07.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Flags: medium devsel, IRQ 11 Capabilities: [68] Power Management version 2 00:09.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8020 (prog-if 10 [OHCI]) Subsystem: Ads Technologies Inc: Unknown device Flags: bus master, medium devsel, latency 32, IRQ 9 Memory at db005000 (32-bit, non-prefetchable) [size=2K] Memory at db00 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 1 00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139
Re: strange network hangs using kdb
On Tue, 5 Jun 2001 12:20:25 -0400, John Jasen <[EMAIL PROTECTED]> wrote: >On Wed, 6 Jun 2001, Keith Owens wrote: >> On Tue, 5 Jun 2001 11:20:26 -0400, >> John Jasen <[EMAIL PROTECTED]> wrote: >> >When we use kdb on one of the systems, the other system stops receiving >> >packets. >> >> man linux/Documentation/kdb/kdb.mm, section Interrupts and KDB. > >I would expect one system to fall off the network, when it is put into >kdb. However, why does it have any effect on the other system, which may >or may not be in kdb? It does not. kdb is intrusive when it trips but even it cannot reach across a network and stop another machine. Look for a networking problem on the other system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] reiserfs mark_journal_new
Hi guys,
The 2.2.x reiserfs journal code marks newly allocated metadata so that if
it is freed in the same transaction (common due to balancing), it can
immediately be reused as a data block. It also allows faster freeing for
these blocks.
This tested patch enables that code for 2.4.x, Alan please include.
-chris
diff -ur diff/linux/fs/reiserfs/fix_node.c linux/fs/reiserfs/fix_node.c
--- diff/linux/fs/reiserfs/fix_node.c Mon Jan 15 18:31:19 2001
+++ linux/fs/reiserfs/fix_node.cFri Feb 2 15:40:54 2001
@@ -936,6 +936,7 @@
if (p_s_tb->FEB[p_s_tb->cur_blknum])
BUG();
+mark_buffer_journal_new(p_s_new_bh) ;
p_s_tb->FEB[p_s_tb->cur_blknum++] = p_s_new_bh;
}
diff -Nru a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
--- a/fs/reiserfs/journal.c Fri Jun 1 13:22:16 2001
+++ b/fs/reiserfs/journal.c Fri Jun 1 13:22:16 2001
@@ -2550,6 +2550,7 @@
bh = get_hash_table(p_s_sb->s_dev, blocknr, p_s_sb->s_blocksize) ;
/* if it is journal new, we just remove it from this transaction */
if (bh && buffer_journal_new(bh)) {
+mark_buffer_notjournal_new(bh) ;
clear_prepared_bits(bh) ;
cleaned = remove_from_transaction(p_s_sb, blocknr, cleaned) ;
} else {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Tue, Jun 05, 2001 at 10:29:28AM +0200, Ingo Molnar wrote: > > - even when it works, it is necessarily very very very slow. Not to be > >used lightly. As you can imagine, the work-around is even slower. > > i've measured it once, IIRC it was around 10-15 millisecs on normal > pentiums, so while it's indeed the slowest x86 instruction on the planet, > it's still perhaps acceptable for hot-swapping ECC RAM. I can already hear the realtime crowd bitch ... Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
On Wed, Jun 06, 2001 at 12:57:03AM +1200, Chris Wedgwood wrote: > I don't know about the CRIS (never heard of it, what is it?), but on > an Athlon when benchmarking stuff, I could still see L1 cache hits > from data that was 15 seconds old under certain work-loads (obviously > not gcc!). Does anyone know how old something may exisit in cache > before being written back to RAM? I know of no architecture that has a time limit that after which's expire caches get written back to memory. In other words cache lines may stay dirty for an indefinate time if things are just right. Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID of init != 1 when initrd with pivot_root
>>> Well, I upgraded and found pivot_root and the problem is that how do I make >>> init run with PID 1. My linuxrc gets PID 7. >>> >>> 1 ?00:03:05 swapper >>> ... >>> 7 ?00:00:00 linuxrc >>> >>> init doesn't like running with any other PID than 1. I could probably revert >>> to the not so old way of doing things and exit linuxrc and let the kernel >>> change root. But then I wouldn't be able to mount root over samba :-(. >>> >>> ... >> This is this way for backwards bug compatibility. Use the following >> command line options to make it behave properly: >> >> ram=/dev/ram0 init=/linuxrc > ... > > But the problem still remains. How do I make my /sbin/init run with PID 1 > using initial ramdisk under the new root change mechanism? I don't want to > use the old change_root mechanism... I had the same problem when doing some development for mkCDrec. This project uses busybox, whose init does not run if its PID != 1. I asked the busybox folks same question you did and never got a response. As a kludge, and after looking at the busybox source code, I renamed init to linuxrc. In this case the program is functionally equivalent to init, except that it does not do the PID == 1 check. An excerpt from my real linuxrc: echo Pivot_root: my PID is $$ # exec /usr/sbin/chroot . /sbin/init < dev/console > dev/console 2>&1 # Okay, try this: exec /usr/sbin/chroot . /sbin/linuxrc < /dev/console > /dev/console 2>&1 /sbin/linuxrc is actually init, renamed. I am sure this is not the preferred method. Please let me know if you find the correct solution. -- W. Michael Petullo :wq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre1 unresolved symbols
Shawn Starr wrote: > > I have noticed unresolves symbols for the netfilter modules. this occurs > durning depmod -a. Note they are the same unresolved symbol. Ingo Molnar has posted a patch for this, entitled [patch] softirq-2.4.6-B4 or you can edit kernel/ksyms.c yourself, and add the lines EXPORT_SYMBOL(do_softirq); EXPORT_SYMBOL(tasklet_schedule); EXPORT_SYMBOL(tasklet_hi_schedule); -- Jeff Garzik | An expert is one who knows more and more about Building 1024| less and less until he knows absolutely everything MandrakeSoft | about nothing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6-pre1 unresolved symbols
I have noticed unresolves symbols for the netfilter modules. this occurs durning depmod -a. Shawn. On Tue, 5 Jun 2001, George Bonser wrote: > > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/3c59x.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/bonding.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/plip.o > depmod: tasklet_hi_schedule > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/net/slip.o > depmod: do_softirq > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/scsi/imm.o > depmod: tasklet_hi_schedule > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/drivers/scsi/ppa.o > depmod: tasklet_hi_schedule > depmod: *** Unresolved symbols in > /lib/modules/2.4.6-pre1/kernel/net/ipv6/ipv6.o > depmod: do_softirq > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: meaning of vmalloc shortcut comment in fault.c
Bjorn Wesen wrote: > > Can someone elaborate on why it's bad to refer to tsk directly below (this > is a 2.4.5 change in x86) and why it's needed on x86 and not other archs.. > > What should I do for an arch that does not have a "cr3" machine register > to check with ? %cr3 is the page table pointer on the x86. Changing the page table pointer and changing the stack pointer (from which tsk is derived) is not done atomically during a task switch. If an interrupt happens in between and causes a page fault on a vmalloced area, using tsk may refer to the wrong page tables. %cr3 by definition always has the current page table pointer. -- Brian Gerst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
Well, my rebuild kernel / reboot / recompile module just finished. Unfortunately, the printk warning was still there. I replaced the unconditional #define MODVERSIONS with #include #ifdef CONFIG_MODVERSIONS #define MODVERSIONS #include #endif this is at the top of my source file. (before module.h and linux.h) (as seen somewhere on the web) and it compiles without warnings now. Now all I need is some info on module oparameters and using /proc :) Thanks again. - Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Does anybody know, where is the MIPS linux mailing list ?
Hi all! I need to ask some questions about linux-2.4.3 for MIPS. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
On Tue, 05 Jun 2001 10:10:26 -0700, Stephen Wille Padnos <[EMAIL PROTECTED]> wrote: >Arthur had pointed out that modules.h should be included, then kernel.h. Is >there a place where I can find out more about header file order dependencies? With the existing design for module symbol versions, module.h must appear before other headers, to obtain the mapping of normal symbols to hashed symbols. That restriction will be removed in 2.5, when the broken Makefile design for module versions is replaced. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Missing cache flush.
Bjorn Wesen wrote: > > I'd agree that to be really certain, a "flush_dcache()" function > should be implemented and used when an erase finishes. Like David Miller > wrote somewhere in the thread, one way is to use your knowledge of the > arch's cache and do suitable dummy accesses to flush it, if there is no > explicit command to do it. But that's just up to the arch coders.. > Here's a stupid question: Are there any processors out there that have a cache but no explicit cache-flush command? If not (i.e. no such "funny" processors), then what's wrong with the arch dependent include through a define to execute the arch specific asm command? The only issue (besides knowing the cache size at run time) that I can think about the "dummy" eviction scheme is that you now need to xfer potentially 3 times the cache size data to and from memory: #1. The dummy read #2. The eviction of the entire cache data being evicted #3. The refilling of the cache with good data again, as the dummy data cannot really represent anything useful. Is my thinking here completely non coherent with others? ;) Vipin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 08:05:34AM +0100, Alan Cox wrote: > > is curious as to how these folks did this. They exploited BIND 8.2.3 > > to get in and logs indicated that someone was using a "back door" in > Bind runs as root. It doesn't have to. In fact, I just set up a RedHat 6.2 Honeypot a couple of weeks ago researching Bind based worms that are becoming a problem. Much to my surprise, that OOB RedHat 6.2 system ran bind as "named -u named" and was running Bind under a common user id. RedHat 6.0 runs it as root and I haven't checked 6.1 yet. Don't know about the other distros, yet. > > We are unable to determine just how they got in exactly, but they > > kept trying and created an oops in the affected code which allowed > > the attack to proceed. > Are you sure they didnt in fact simply screw up live patching the kernel to > cover their traces That would be a hint that they MIGHT have been trying to get a Linux kernel stealth module going. Several of the worms I'm looking at include the Adore LKM to hide processes, files, and sockets. That worm (as several others like it) also upgrade the version of Bind they broke in through to prevent further compromise. There will be a security advisory out on these worms, probably later this week. Mike -- Michael H. Warfield| (770) 985-6132 | [EMAIL PROTECTED] (The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471| possible worlds. A pessimist is sure of it! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
meaning of vmalloc shortcut comment in fault.c
Can someone elaborate on why it's bad to refer to tsk directly below (this
is a 2.4.5 change in x86) and why it's needed on x86 and not other archs..
What should I do for an arch that does not have a "cr3" machine register
to check with ?
/BW
vmalloc_fault:
{
/*
* Synchronize this task's top level page-table
* with the 'reference' page table.
*
* Do _not_ use "tsk" here. We might be inside
* an interrupt in the middle of a task switch..
*/
int offset = __pgd_offset(address);
pgd_t *pgd, *pgd_k;
pmd_t *pmd, *pmd_k;
pte_t *pte_k;
asm("movl %%cr3,%0":"=r" (pgd));
pgd = offset + (pgd_t *)__va(pgd);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
um. duh. Thanks. I guess it helps to know the right FM to R. :) Arthur had pointed out that modules.h should be included, then kernel.h. Is there a place where I can find out more about header file order dependencies? (damn - that sounds like a Microsoft help question) Keith Owens wrote: > Read the very last line of every message on linux-kernel. and to think I used to laugh at people who forgot to do that :) - Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Exporting new functions from kernel 2.2.14
Thanks. Actually, the symbols in question aren't in modules. The kernel is module enabled, but all drivers are being compiled in (this is for an embedded system). My external module (which needs to grab the timer interrupt) is in a separate source tree. Thanks for the printk info - I guess boneheads like me could use a FAQ that tells which order the miscellaneoud include files need to be in. (I had modules.h after linux.h). I changed the order, butI am waiting for a recompile now, so I don't know if the reordering worked. Arthur Naseef wrote: ... > you can edit the .ver file yourself (under /usr/src/linux/include/modules/) > and add entries. This will eliminate the funny versioning, as in: > As far as the printk() warning, you need to make sure your module code > includes the right header files. In this case, I believe you need to grab > after including . > > I hope this helps. > > -art > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
can I call wake_up_interruptible_all from an interrupt service routine?
Interrupt service routine of a driver makes a wake_up_interruptible_all() call to wake up a kernel thread. Is that legitimate? Thanks for any advice you might have. please cc: your response to me if you decide to post to the mailing list. Bulent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-2.4.5[-ac8] warnings while compiling
Hello Leonid Mamtchenkov,
Once you wrote about "linux-2.4.5[-ac8] warnings while compiling":
LM> While compile kernel 2.4.5 or 2.4.5-ac8 I get lots of warning, which look like
LM> this:
LM> kernel.stderr start
LM> In file included from /usr/src/linux-2.4.5-ac8/include/linux/raid/md.h:51,
LM> from init/main.c:25:
LM> /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:21:33: warning:
"__ver_proc_root_driver" redefined
LM> /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:21:1: warning: this
is the location of the previous definition
LM> - kernel.stderr end -
Sorry for replying to myself, but the problem can be solved by doing
"make mrproper" (thanks to Bill Pringlemeir).
Now I am left only with following warnings, in case someone is interested.
start kernel.stderr.1
In file included from /usr/src/linux-2.4.5-ac8/include/linux/raid/md.h:51,
from init/main.c:25:
/usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h: In function `pers_to_level':
/usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h:41: warning: control reaches end of
non-void function
In file included from /usr/src/linux-2.4.5-ac8/include/linux/raid/md.h:51,
from ll_rw_blk.c:31:
/usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h: In function `pers_to_level':
/usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h:41: warning: control reaches end of
non-void function
{standard input}: Assembler messages:
{standard input}:64: Warning: indirect lcall without `*'
{standard input}:134: Warning: indirect lcall without `*'
{standard input}:186: Warning: indirect lcall without `*'
In file included from /usr/src/linux-2.4.5-ac8/include/linux/raid/md.h:51,
from check.c:22:
/usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h: In function `pers_to_level':
/usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h:41: warning: control reaches end of
non-void function
dmi_scan.c:161: warning: `disable_ide_dma' defined but not used
pci-pc.c:952: warning: `pci_fixup_via691' defined but not used
pci-pc.c:965: warning: `pci_fixup_via691_2' defined but not used
{standard input}: Assembler messages:
{standard input}:784: Warning: indirect lcall without `*'
{standard input}:869: Warning: indirect lcall without `*'
{standard input}:955: Warning: indirect lcall without `*'
{standard input}:993: Warning: indirect lcall without `*'
{standard input}:1025: Warning: indirect lcall without `*'
{standard input}:1057: Warning: indirect lcall without `*'
{standard input}:1088: Warning: indirect lcall without `*'
{standard input}:1117: Warning: indirect lcall without `*'
{standard input}:1146: Warning: indirect lcall without `*'
{standard input}:1433: Warning: indirect lcall without `*'
{standard input}:1529: Warning: indirect lcall without `*'
fault.c:123: warning: `print_pagetable_entries' defined but not used
bbootsect.s: Assembler messages:
bbootsect.s:257: Warning: indirect lcall without `*'
bsetup.s: Assembler messages:
bsetup.s:1374: Warning: indirect lcall without `*'
Root device is (3, 2)
Boot sector 512 bytes.
Setup is 4532 bytes.
System is 669 kB
- end kernel.stderr.1 -
--
Best regards,
Leonid Mamtchenkov
System Administrator
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: TRG vger.timpanogas.org hacked
On Tue, Jun 05, 2001 at 01:07:05PM +, Henning P. Schmiedehausen wrote: > Connected to vger.timpanogas.com. > Escape character is '^]'. > SSH-1.5-1.2.27 > > Well known exploits downloadable at any of the better hacking sites. This _may_ be misleading. I had several boxes where I patched ssh 1.2.27 as a short-term solution. Anyway, we're getting OT :-) Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lots of pppd (down) stall SMP linux-2.4.x
Hi folks, I have a pretty nasty problem w/ pppd (2.4.0) on SMP versions of 2.4.x (I've tried 2.4.0.SuSE to 2.4.4). I am running >25 pppds on a Dual-Pentium933, 3GB, Asus CUR-DLS motherboard (ServerWorks SE). The pppds are running fine (I am using pppoe plugin from Michael Ostrowski, and/or a user process doing the PPPoE). BUT once I try to bring the ppds down to fast (killall is a perfect way) the system stalls, i.e. no Oops, no login etc. however, switching consoles via keyboard works, ping'ing the IP from the net still works. None of the log files hold any useful information... If I bring the pppds down using a slow loop (one kill per second or slower) the machine does NOT stall. I'v tried many different SMP related patches from this list (ppp_async, tty) but none of them helped on my problem. And - of course - the problem does NOT exist on the same box using the same kernel base w/o SMP support!!! Any help is very much appreciated! Thanks Immanuel -- Till Immanuel Patzschke mailto: [EMAIL PROTECTED] interNetwork AG Phone: +49-(0)611-1731-121 Bierstadter Str. 7 Fax:+49-(0)611-1731-31 D-65189 Wiesbaden Web:http://www.internetwork-ag.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Exporting new functions from kernel 2.2.14
Steve:
I still have not figured out the magic that creates the .ver files which
would resolve your concern with the symbol versions, but I do know that
you can edit the .ver file yourself (under /usr/src/linux/include/modules/)
and add entries. This will eliminate the funny versioning, as in:
grab_timer_interrupt_R__ver_grab_timer_interrupt
You can pick a hash value to use. For example, you might add the following:
#define __ver_grab_timer_interrupt a1b2c3d4
#define grab_timer_interrupt_set_ver(grab_timer_interrupt)
As far as the printk() warning, you need to make sure your module code
includes the right header files. In this case, I believe you need to grab
after including .
I hope this helps.
-art
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Stephen Wille
> Padnos
> Sent: Tuesday, June 05, 2001 11:55 AM
> To: Linux Kernel
> Subject: Exporting new functions from kernel 2.2.14
>
>
> Hello, all.
>
> I am writing a pseudo-realtime control system, based on kernel 2.2.14.
> The only RT-like task needs to hang off the timer IRQ. I am using
> techniques like those in the book "Linux Kernel Internals", by Beck, et
> al..
>
> The patches in that book won't apply (they are for 2.1.24 or lower),
> plus I want a somewaht different functionality, which brings me to my
> question: How can I get (modversions-enabled) functions exported from
> arch/i386/kernel/irq.c?
>
> I see in /proc/ksyms that there are some functions exported from there
> ({enable,disable}_irq, probe_irq_{on,off}, etc.), and they have correct
> looking versions.
>
> When I add my new finctions to i386ksyms.c:
> EXPORT_SYMBOL(grab_timer_interrupt);
> EXPORT_SYMBOL(release_timer_interrupt);
>
> I get names like
>
> grab_timer_interrupt_R__ver_grab_timer_interrupt
> release_timer_interrupt_R__ver_release_timer_interrupt
>
> instead of
> local_irq_count_R4d40375f
>
> Additionally, when I make a dummy module (a la Alessandro Rubini's
> "Hello" module in "Linux Device Drivers"), I get the following warning:
> control.c:31: warning: implicit declaration of function
> `printk_R1b7d4074'
> The module seems to work (it printk's "module loaded" on load and
> "module unloaded" on unload), but I suspect that this is because I am
> printk()-ing unformatted text strings - only one parameter gets sent.
>
> So, I obviously have missed some basics about:
> a) versioning,
> b) exporting symbols, and
> c) modules.
>
> could soemone please enlighten me, or direct me along the path of
> enlightenment :)
>
> Thanks
> - Steve
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: USB requiring PCI
On Mon, 4 Jun 2001 [EMAIL PROTECTED] wrote: > I don't know the details of the implementation, but the CRIS port > (ETRAX 100LX) has support for USB but no PCI. A builtin non-PCI USB-host controller, that is. And the driver is in the kernel so we do support it as well :) /BW > > > AC> o Make USB require PCI(me) > > > Huh?! > > > How about people from StrongArm sa11x0 port, who have USB host > controller (in > > > sa companion chip) but do not have PCI? > > > > The strongarm doesnt have a USB master but a slave. > > > > > Probably there are more such embedded architectures with USB > controllers, > > > but not PCI bus. > > > > Currently we don't support any of them. > > > > > How about ISA USB host controllers? > > > > They do not exist. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uninterruptable sleep (usually IO)
How can I kill such D state processes under 2.4.5? Have a bunch of "sleeping" mount requests, I can't even kill them. __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Agpgart for AMD761
I was wondering what is the state of support for the AMD761 Northbridge chip, especially regarding agp operations since I don't see it listed in the kernel configuration for the AGPGart device. Please CC any answer to my address, since I'm not subscribed to the list. Thanks in advance. Paolo Pedroni - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-2.4.5[-ac8] warnings while compiling
Hello All, While compile kernel 2.4.5 or 2.4.5-ac8 I get lots of warning, which look like this: kernel.stderr start In file included from /usr/src/linux-2.4.5-ac8/include/linux/raid/md.h:51, from init/main.c:25: /usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h: In function `pers_to_level': /usr/src/linux-2.4.5-ac8/include/linux/raid/md_k.h:41: warning: control reaches end of non-void function In file included from /usr/src/linux-2.4.5-ac8/include/linux/modversions.h:194, from /usr/src/linux-2.4.5-ac8/include/linux/module.h:21, from fork.c:19: /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:1:33: warning: "__ver_proc_sys_root" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:1:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:3:33: warning: "__ver_proc_symlink" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:3:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:5:33: warning: "__ver_proc_mknod" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:5:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:7:33: warning: "__ver_proc_mkdir" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:7:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:9:33: warning: "__ver_create_proc_entry" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:9:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:11:33: warning: "__ver_remove_proc_entry" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:11:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:13:25: warning: "__ver_proc_root" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:13:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:15:33: warning: "__ver_proc_root_fs" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:15:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:17:25: warning: "__ver_proc_net" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:17:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:19:25: warning: "__ver_proc_bus" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:19:1: warning: this is the location of the previous definition /usr/src/linux-2.4.5-ac8/include/linux/modules/root.ver:21:33: warning: "__ver_proc_root_driver" redefined /usr/src/linux-2.4.5-ac8/include/linux/modules/procfs_syms.ver:21:1: warning: this is the location of the previous definition - kernel.stderr end - Is there a patch available to fix this problem? -- Best regards, Leonid Mamtchenkov System Administrator - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Trident 9660 problem
Hi I have following problem: I have an old Olivetti computer as the router. After I upgraded it to 2.4.2 kernel (RedHat 7.1), the screen always blanks in the moment when it starts to write the boot messages. The screen is completely black and no signal on Hsync/Vsync on VGA conncetor. So the monitor goes to the sleep mode after a while. But the rest of the computer works as usual during this problem. Only the video output is disabled. I tried several vga= options but with the same result. The video chip is reported as "Trident 9660" by both X Windows and M$ Windoze. Is this problem known? Tomas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IRQ conflicts
>With 2.4.5 I *often* get kernel Oopses with IRQ >routing error messages. This never happend before >and the only one change was a a second network >card inserted into the mobo and changed kernel >from 2.4.3 to 2.4.5. As as wrote... Here is one of them, getting every 3 hours... CPU: 0 EIP: 0010:[] EFLAGS: 00010202 eax: c233cae0 ebx: 1025 ecx: edx: 1025 esi: c21334a0 edi: c233c380 ebp: 0060 esp: c01fdddc ds: 0018es: 0018ss: 0018 Process swapper (pid: 0, stackpage=c01fd000) Stack: ... Call Trace: ... Code: 8b 1b 8b 42 70 83 f8 01 74 0a ff 4a 70 0f 94 c0 84 c0 74 09 Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
