Re: [RFC] LKML Archive in Maildir Format
Hi Joey,
On Sun, Dec 16, 2018 at 09:21:35AM -1000, Joey Pabalinas wrote:
> > > I spent a lot of time trying to find an LKML archive in Maildir format
> > > that I could use for local searches with nutmuch or something, but all
> > > the links I was able to find were all dead.
> >
> > You might instead use
> >
> > https://www.kernel.org/lore.html
> > https://git.kernel.org/pub/scm/public-inbox/vger.kernel.org/git.git/
>
> That was my first attempt, but the ducumentation for the public-inbox
> format is sort of terrible, and after a few hours trying to convert it
> to Maildir I just gave up.
>
> I ended up just slowly scraping lkml.org for a couple weeks so I
> wouldn't disrupt anything and it worked fairly well. Just looking for
> advice on where to host this now so others might be able to use it.
Now you've caught my attention; first of all, there are more than 3M
messages stored in the lkml.org datase, so I guess you've missed some
messages or something is really broken.
Besides, unless you figured out how to get to the raw data, you've just
scraped a rendering which discards stuff like pgp signatures etc and has
very incomplete headers. Unless you don't care for those of course :)
Note that I've also been toying with the lore dataset, and wrote a tiny tool
to get Maildir-like data out of it; this code is a bit of a single-use-jig
so you'll need to do some coding if you really want to use it. Attached
anyway.
All the best and enjoy,
Jasper
[[source]]
url = "https://pypi.org/simple";
verify_ssl = true
name = "pypi"
[packages]
gitpython = "*"
ipython = "*"
[dev-packages]
[requires]
python_version = "3.7"
from email.parser import BytesParser
from email.message import EmailMessage
from email.policy import default
from git import Repo
our_last_id = ''
#'<20180711142744.gn3...@linux.vnet.ibm.com>'
repo = Repo('/Users/spaans/xsrc/lkml/lkml/git/6.git')
commit = repo.commit("master")
counter = 5000
froms = set()
while True:
tree = commit.tree
blob = tree['m']
data = blob.data_stream.read()
msg = BytesParser(policy=default).parsebytes(data)
msgid = msg['Message-ID']
from_ = msg['From']
froms.add(from_)
print(msgid)
#import pdb; pdb.set_trace()
if len(froms) > 1000:
print("HAVE LOTS OF FRIENDS NOW")
break
if msgid == our_last_id:
print("LADIES & GENTLEMEN, WE'VE GOT HIM")
break
parents = commit.parents
if len(parents) != 1:
print("WUH")
break
else:
commit = commit.parents[0]
#with open("output/%04d.eml" % counter, "bw") as f:
#f.write(data)
counter -= 1
import pprint
pprint.pprint(froms)
signature.asc
Description: PGP signature
kernel panic 3.11.7 in kmem_cache_alloc+0x66/0x150
88203fcd7380 R09: Feb 23 15:20:08 snarfer kernel: [2092159.390731] R10: 0001 R11: R12: 881fff003800 Feb 23 15:20:08 snarfer kernel: [2092159.398111] R13: 0001 R14: 81148855 R15: 00011200 Feb 23 15:20:08 snarfer kernel: [2092159.405493] FS: 7f5aa9ede820() GS:88203fcc() knlGS: Feb 23 15:20:08 snarfer kernel: [2092159.413829] CS: 0010 DS: ES: CR0: 8005003b Feb 23 15:20:08 snarfer kernel: [2092159.419805] CR2: 0001 CR3: 000fe594f000 CR4: 07e0 Feb 23 15:20:08 snarfer kernel: [2092159.427186] Stack: Feb 23 15:20:08 snarfer kernel: [2092159.429430] 8811e20e12f8 880fdaa86000 0010 0021 Feb 23 15:20:08 snarfer kernel: [2092159.437330] 881fd228f2d8 881fe840dba0 00011210 881fe840dbd0 Feb 23 15:20:08 snarfer kernel: [2092159.445217] 880fdaa87b38 880fe731ddc0 880fdaa87af8 81148855 Feb 23 15:20:08 snarfer kernel: [2092159.453099] Call Trace: Feb 23 15:20:08 snarfer kernel: [2092159.455787] [] mempool_alloc_slab+0x15/0x20 Feb 23 15:20:08 snarfer kernel: [2092159.461899] [] mempool_alloc+0x5b/0x160 Feb 23 15:20:08 snarfer kernel: [2092159.467651] [] ? generic_make_request+0xca/0x100 Feb 23 15:20:08 snarfer kernel: [2092159.474155] [] bio_alloc_bioset+0x10b/0x1d0 Feb 23 15:20:08 snarfer kernel: [2092159.480254] [] ext4_bio_write_page+0x297/0x310 Feb 23 15:20:08 snarfer kernel: [2092159.486584] [] mpage_submit_page+0x65/0x90 Feb 23 15:20:08 snarfer kernel: [2092159.492566] [] mpage_map_and_submit_buffers+0x15f/0x260 Feb 23 15:20:08 snarfer kernel: [2092159.499677] [] ext4_writepages+0x67b/0xc60 Feb 23 15:20:08 snarfer kernel: [2092159.505666] [] ? __mark_inode_dirty+0x53/0x2d0 Feb 23 15:20:08 snarfer kernel: [2092159.511998] [] ? dm_any_congested+0x52/0x60 Feb 23 15:20:08 snarfer kernel: [2092159.518073] [] ? dm_table_any_congested+0x74/0x140 Feb 23 15:20:08 snarfer kernel: [2092159.524756] [] do_writepages+0x20/0x40 Feb 23 15:20:08 snarfer kernel: [2092159.530395] [] __filemap_fdatawrite_range+0x59/0x60 Feb 23 15:20:08 snarfer kernel: [2092159.537158] [] SyS_fadvise64_64+0x25c/0x270 Feb 23 15:20:08 snarfer kernel: [2092159.543228] [] SyS_fadvise64+0xe/0x10 Feb 23 15:20:08 snarfer kernel: [2092159.548777] [] system_call_fastpath+0x1a/0x1f Feb 23 15:20:08 snarfer kernel: [2092159.555012] Code: dc 00 00 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 e1 00 00 00 4d 85 ed 0f 84 d8 00 00 00 49 63 44 24 20 49 8b 3c 24 48 8d 4a 01 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b7 49 Feb 23 15:20:08 snarfer kernel: [2092159.577716] RIP [] kmem_cache_alloc+0x66/0x150 Feb 23 15:20:08 snarfer kernel: [2092159.584104] RSP Feb 23 15:20:08 snarfer kernel: [2092159.587822] CR2: 0001 Feb 23 15:20:08 snarfer kernel: [2092159.591484] ---[ end trace f2f9ccfb04094fee ]--- This machine contains two hexacore xeons running with HT enabled, so 24 cores in total, and has 128 GB of RAM, and all NUMA stuff has been disabled in the bios (so this machine behaves as one big machine). It's running a vanilla 3.11.7 , can provide you with the config if needed. This looks to me like it's the same as the problem described in https://lkml.org/lkml/headers/2013/11/30/153 , are there any things to try besides upgrading to a 3.13 ? (This is the second machine on which we have seen this..) Regards, Jasper -- /\/\ ir. Jasper Spaans \ (_)/ Fox-IT \XT: +31-15-2847999 \ / \ M: +31-6-41588725 \/ KvK Haaglanden 27301624 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lkml.org
On Sun, Feb 24, 2008 at 8:39 PM, Randy Dunlap <[EMAIL PROTECTED]> wrote: > On Sun, 24 Feb 2008 18:28:08 + Adrian McMenamin wrote: > > > At the risk of pointing out the obvious (though I cannot find anyone > > else who has commented), this appears to be broken at the moment...(ie > > not picking up new messages) > > > > ...which is a pity as it is a great site > > Did you send email to Jasper Spaans? (jasper at vs19.net) Problem sort of fixed, looks like a joe job with the lkml.org domain, causing the mta to panic because of too many incoming smtp connections. Limits increased, all seems stable again; the archive should be catching up now as the real mail trickles in again. Jasper -- Jasper Spaans http://jasper.es/ This line was last modified 0 seconds ago. -- 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: Gmail and flowed text (was Re: Correction to LZO1X)
On 7/11/07, Satyam Sharma <[EMAIL PROTECTED]> wrote: And yet another patch falls victim to format=flowed ... I need some ideas here myself: I don't want to subscribe from my university mail account -- I like to keep important messages on server, and the account has a 100 MB or so limit that wouldn't survive a week of lkml traffic. [..] I suspect others must have come across this ... any suggestions? Use lkml.org's fabulastic email forward button to forward mails to your university account and reply from there? Cheers, -- Jasper Spaans http://jsp.vs19.net/ This line was last modified 0 seconds ago. - 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: 4GB Physical. Less than 3GB in Linux.
On 4/16/07, Jeff Chua <[EMAIL PROTECTED]> wrote: On 4/16/07, Robert Hancock <[EMAIL PROTECTED]> wrote: > Jeff Chua wrote: > > I've noticed that with 4GB physical ram, I'm only see 3098000 MB on > > the Dell 745, and 3107056MB on the IBM X60s. > > > > I've tested with CONFIG_HIGHMEM4G=y, CONFIG_HIGHMEM64G=y, > > CONFIG_X86_PAE=y, but nothing makes any difference. > > Chipset limitation. It uses up most of the MMIO region above 3GB > preventing RAM from being mapped there, and doesn't support remapping > the covered RAM to above 4GB. Nothing the kernel can do about it. Well, I guess I learned the hard way. So it's better not to buy 4GB ... it turns out to be the same as buying one with just 3GB RAM. Might be a setting in the bios... look for something like memory hole, memory remapping, 4G DRAM, etc. VrGr, -- Jasper Spaans http://jsp.vs19.net/ This line was last modified 0 seconds ago. - 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: crypto algoritms failing?
On Thu, Jan 27, 2005 at 08:43:18PM -0500, James Morris wrote: > Looks like a cleanup broke the test vectors: > http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] > > Patch below, please apply. That fixes it, thanks. -- Jasper Spaans http://jsp.vs19.net/ 10:13:13 up 10208 days, 2:00, 0 users, load average: 6.00 6.00 6.12 signature.asc Description: Digital signature
Re: crypto algoritms failing?
On Thu, Jan 27, 2005 at 07:38:43PM -0500, James Morris wrote: > > Is this supposed to happen? > > No. What is your kernel version? Current bitkeeper + latest swsusp2 patches and hostap driver, however, those two don't come near touching the crypto stuff[1] so they're not really on my suspect shortlist, but I'll see if I can find time to build a vanilla one tomorrow (that is, without swsusp/hostap).. right now, it's time to sleep in my local timezone.. Groet, -- Jasper Spaans http://jsp.vs19.net/ 01:40:46 up 10207 days, 17:27, 0 users, load average: 6.00 6.00 6.12 [1] hostap however does use some crypto algoritms, if I'm not mistaken, but its modules are not loaded in that stage of booting signature.asc Description: Digital signature
crypto algoritms failing?
Hi List, When booting I see this in dmesg: testing tea ECB encryption test 1 (128 bit key): 0a3aea4140a9ba94 fail test 2 (128 bit key): 775d2a6af6ce9209 fail test 3 (128 bit key): be7abb81952d1f1edd89a1250421df95 fail test 4 (128 bit key): e04d5d3cb78c364794189591a9fc49f844d12dc299b8082a078973c24592c690 fail [..] testing xtea ECB encryption test 1 (128 bit key): aa2296e56c61f345 fail test 2 (128 bit key): 823eeb35dcddd9c3 fail test 3 (128 bit key): e204dbf289859eea6135aaedb5cb712c fail test 4 (128 bit key): 0b03cd8abe95fdb1c144910ba5c91bb4a9da1e9eb13e2a8feaa56a85d1f4a8a5 fail CPU in that machine is an athlon xp, cpu flags according to /proc/cpuinfo flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse pni syscall mmxext 3dnowext 3dnow Compiler: gcc 3.3.5 (debian package 1:3.3.5-6) Is this supposed to happen? Jasper -- Jasper Spaans http://jsp.vs19.net/ 00:24:05 up 10207 days, 16:11, 0 users, load average: 6.29 6.03 6.13 There already is an object oriented version of COBOL. It's called "ADD ONE TO COBOL GIVING COBOL." signature.asc Description: Digital signature
Re: 2.6.11-rc2 complains badly aboud badness in local_bh_enable
Hoi, On Sun, Jan 23, 2005 at 03:57:56PM +0100, Marcel Holtmann wrote: > > -rc1 worked fine here. -rc2 complains a lot: > > > > Jan 23 12:59:50 amd kernel: Badness in local_bh_enable at > > kernel/softirq.c:140 [snip] > the problem is the PPP code (not Bluetooth btw.) like others reported so > far. I also see the same problem with the external MadWiFi driver. I'm seeing a similar problem on my machine - one that does not know what ppp is. Main suspect is the network bridging code in combination with iptables; the first lines of the message: Jan 23 07:50:56 spaans kernel: [local_bh_enable+42/109] local_bh_enable+0x2a/0x6d Jan 23 07:50:56 spaans kernel: [pg0+97971/1068110848] ipt_do_table+0x2db/0x310 [ip_tables] Jan 23 07:50:56 spaans kernel: [pg0+942403693/1068110848] ipt_local_out_hook+0x51/0x58 [iptable_filter] Jan 23 07:50:56 spaans kernel: [nf_iterate+64/137] nf_iterate+0x40/0x89 Jan 23 07:50:56 spaans kernel: [pg0+979631787/1068110848] br_nf_local_out_finish+0x0/0x77 [bridge] (Btw, this kernel is enhanced with hostap and swsusp2 support, if needed I can compile a vanilla -rc2) Groet, -- Jasper Spaans http://jsp.vs19.net/ 23:34:43 up 10203 days, 15:21, 0 users, load average: 6.00 6.06 6.20 signature.asc Description: Digital signature
Re: [PATCH] OOM handling
On Mon, Mar 26, 2001 at 01:33:05PM +0200, Ingo Oeser wrote: > > The point being, my database shouldn't be selected for > > termination. Nobody ever got fired for kill -9'ing netscape, > > but Oracle is a different story. I urge you, consider the > > patch. > > No, you got fired for not setting ulimits. Your boss is right > then! > > ulimit -d 65536 > ulimit -v 81920 Ehm, right. Running netscape (or any other memory hog which doesn't belong on a server) on a production server seems reason enough for a little talk with your boss. On the other hand, if no other apps are running on your box, and Oracle gets killed due to OOM, you probably have underestimated your hardware needs, or Oracle has gone haywire, which is a good reason for killing it. Thus, nothing seems wrong with the current kill algorithm to me... Just my two cents, -- Q_. Jasper Spaans <[EMAIL PROTECTED]> `~\http://jsp.ds9a.nl/ Mr /\ Tel/Fax: +31-20-8749842 Zap Move all .sig for great justice! - 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: [bug] test13-pre4 nfs/ip_defrag crash (smp)
On Mon, Dec 25, 2000 at 04:34:37PM -0800, Linus Torvalds wrote: > > > On Mon, 25 Dec 2000, Jasper Spaans wrote: > > > > I am having some reproducible crashes with 2.4.0-test13-pre4, whenever I > > do some 'heavy' nfs-ing.. decoded oops: > > It looks like most of what you have is modules. Is netfilter enabled as a > module too? Can you reproduce it without modules, in case it's a > autounload race or similar? Right, I've just recompiled with nfs, iptables and my nic driver (8139too) in the kernel. Testing[*] with nfs v2 and v3 crashes it, first oops is with v2, second with v3: [*]: just copying a set of large files between two machines running 2.4.0-test13-pre4 [which are able to saturate the 10Mbps link between them], when copying to a slower machine running 2.2.18, it doesn't crash. ksymoops 2.3.4 on i686 2.4.0-test13-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (default) -m /boot/System.map-2.4.0-test13-pre4 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 6361636b c020609e *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 6361632f ebx: cf0b4f00 ecx: c91bc824 edx: c9e0bfa0 esi: 0b90 edi: cf0af0c0 ebp: 05c8 esp: c99bfc4c ds: 0018 es: 0018 ss: 0018 Process rpciod (pid: 681, stackpage=c99bf000) Stack: c9e0bfa0 1906 070a 0014 c020648d c9e0bfa0 cf0af0c0 c03219ac c99be000 c99d71c0 cf0af0c0 6361632f c91bc810 c0229262 cf0af0c0 c99bfd48 c0349b38 c0208efc c99bfd58 c02289c9 cf0af0c0 c99bfd48 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 3c 8b 4c 24 1c 89 41 3c c7 47 18 00 00 00 00 8b 54 24 >>EIP; c020609e<= Trace; c020648d Trace; c0229262 Trace; c0208efc Trace; c02289c9 Trace; c0208efc Trace; c0208f10 Trace; c0208f10 Trace; c0200517 Trace; c0227c3a Trace; c0208efc Trace; c0200298 Trace; c0208efc Trace; c0208efc Trace; c0200517 Trace; c0208efc Trace; c020849b Trace; c0208efc Trace; c021e058 Trace; c02085c6 Trace; c021e058 Trace; ea0a Trace; c01f8b0e <__kfree_skb+132/138> Trace; c021e4ee Trace; c021e058 Trace; ea0a Trace; ea0a Trace; ea0a Trace; c0223c96 Trace; c01f5c45 Trace; c023ae9a Trace; c011345d Trace; c016a214 Trace; c023dde9 Trace; c023ad45 Trace; c0239043 Trace; c023c58b <__rpc_execute+c3/338> Trace; c023c989 <__rpc_schedule+119/15c> Trace; c023d26e Trace; c0107480 Code; c020609e <_EIP>: Code; c020609e<= 0: 8b 40 3c mov0x3c(%eax),%eax <= Code; c02060a1 3: 8b 4c 24 1c mov0x1c(%esp,1),%ecx Code; c02060a5 7: 89 41 3c mov%eax,0x3c(%ecx) Code; c02060a8 a: c7 47 18 00 00 00 00 movl $0x0,0x18(%edi) Code; c02060af 11: 8b 54 24 00 mov0x0(%esp,1),%edx Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. ksymoops 2.3.4 on i686 2.4.0-test13-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (default) -m /boot/System.map-2.4.0-test13-pre4 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 400fcab8 c020609e *pde = 0e6eb067 Oops: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 400fca7c ebx: cf96d8c0 ecx: c89a2024 edx: cf1eae60 esi: 1720 edi: cf96d820 ebp: 1158 esp: c898bc4c ds: 0018 es: 0018 ss: 0018 Process rpciod (pid: 809, stackpage=c898b000) Stack: cf1eae60 82a9 070a 0014 c020648d cf1eae60 cf96d820 c03219ac c898a000 cb0f6120 cf96d820 400fc
[bug] test13-pre4 nfs/ip_defrag crash (smp)
Hi! I am having some reproducible crashes with 2.4.0-test13-pre4, whenever I do some 'heavy' nfs-ing.. decoded oops: ksymoops 2.3.4 on i686 2.4.0-test13-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test13-pre4/ (default) -m /boot/System.map-2.4.0-test13-pre4 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address eabc089f c01e263e *pde = Oops: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: eabc0863 ebx: c40c53e0 ecx: c54a1824 edx: c28079a0 esi: 0b90 edi: c5a0df40 ebp: 05c8 esp: ce699c4c ds: 0018 es: 0018 ss: 0018 Process rpciod (pid: 2358, stackpage=ce699000) Stack: c28079a0 0a2b 070a 0014 c01e2a2d c28079a0 c5a0df40 c02ce7ac ce698000 c36f9c40 c5a0df40 eabc0863 c54a1810 d1147a82 c5a0df40 ce699d48 c02f6878 c01e549c ce699d58 d11471c9 c5a0df40 ce699d48 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 3c 8b 4c 24 1c 89 41 3c c7 47 18 00 00 00 00 8b 54 24 >>EIP; c01e263e<= Trace; c01e2a2d Trace; eabc0863 Trace; d1147a82 <[8139too]rtl8139_set_rx_mode+56/270> Trace; c01e549c Trace; d11471c9 <[8139too]rtl8139_rx_interrupt+151/24c> Trace; c01e549c Trace; c012f810 <__alloc_pages+12c/2d4> Trace; d114640a <[8139too]rtl8139_hw_start+226/574> Trace; c01e549c Trace; c01dc838 Trace; c01e549c Trace; c01e549c Trace; c01dcab7 Trace; c01e549c Trace; d114913c <[8139too].data.end+51d/43e1> Trace; c01e4a3b Trace; c01e549c Trace; c01fa5f8 Trace; c01d71d5 Trace; c01e4b66 Trace; c01fa5f8 Trace; ea0a Trace; c01d50ae <__kfree_skb+132/138> Trace; c01faa8e Trace; c01fa5f8 Trace; ea0a Trace; ea0a Trace; ea0a Trace; c0200236 Trace; c01d21e5 Trace; d110b84a <[uhci]uhci_show_queues+13e/228> Trace; c01e1cd6 Trace; c01e1e0c Trace; d11677d0 <[ipt_LOG].data.end+3bd9/b469> Trace; d1170ee8 <.bss.end+1465/> Trace; d110e7e9 <[uhci]alloc_uhci+2c1/310> Trace; d110b6f5 <[uhci]uhci_is_skeleton_qh+19/30> Trace; d11099f3 <[usbcore]usbdevfs_root_inode_operations+13/40> Trace; d110cf3b <[uhci]uhci_submit_bulk+1b3/238> Trace; d110d264 <[uhci]uhci_result_isochronous+4/a4> Trace; d110d339 <[uhci]uhci_find_urb_ep+35/d0> Trace; d110dc2b <[uhci]rh_submit_urb+7b/670> Trace; d1116cc4 <[sunrpc]xprt_reserve_status+74/7c> Trace; d1116cc4 <[sunrpc]xprt_reserve_status+74/7c> Trace; d1116cbc <[sunrpc]xprt_reserve_status+6c/7c> Trace; d1116cbc <[sunrpc]xprt_reserve_status+6c/7c> Trace; c0107480 Trace; d1116cc4 <[sunrpc]xprt_reserve_status+74/7c> Trace; d1116cd0 <[sunrpc]xprt_request_init+4/90> Code; c01e263e <_EIP>: Code; c01e263e<= 0: 8b 40 3c mov0x3c(%eax),%eax <= Code; c01e2641 3: 8b 4c 24 1c mov0x1c(%esp,1),%ecx Code; c01e2645 7: 89 41 3c mov%eax,0x3c(%ecx) Code; c01e2648 a: c7 47 18 00 00 00 00 movl $0x0,0x18(%edi) Code; c01e264f 11: 8b 54 24 00 mov0x0(%esp,1),%edx Kernel panic: Aiee, killing interrupt handler! Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
On Thu, Dec 14, 2000 at 05:50:35PM -0500, Mohammad A. Haque wrote: [zap] > Oops start flying by when I access via NFS. > > If you need the actual Oops messages we're gonna have to get someone > who can setup a serial console. I captured one on my console, anyone interested please drop me a note. Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
On Tue, Dec 12, 2000 at 07:08:09PM -0800, Linus Torvalds wrote: > > The following patch disabled that code. > > If this fix makes the oops go away, then the proper fix for the problem is > not the #if 0, but do add something like Well, this fix did make the oops go away, but it also caused another scary oops -- not sure whether my stack trace is in any way how it should be, but it oopses in nfsd, and has a stacktrace as follows: >>EIP; c01e379e<= Trace; c01e3b80 Trace; d1121502 <[ip_conntrack]ip_ct_gather_frags+2e/ac> Trace; c01e65ec Trace; d1120c49 <[ip_conntrack]ip_conntrack_in+39/2cc> Trace; c01e65ec Trace; d11223aa <[ip_conntrack]ip_conntrack_local+5a/60> Trace; c01e65ec Trace; c01d4e08 Trace; c01e65ec Trace; c01e65ec Trace; c01d5087 Trace; c01e65ec Trace; d11235e8 <[ip_conntrack]ip_conntrack_local_out_ops+0/18> Trace; c01e5b8b Trace; c01e65ec Trace; c01fb748 Trace; c01e5cb6 Trace; c01fb748 Trace; ea0a Trace; c01e14fb Trace; c01fbbde Trace; c01fb748 Trace; ea0a Trace; ea0a Trace; e5cfff3e Trace; ea0a Trace; c0201386 Trace; c01d3355 Trace; d113e8f3 Trace; d113ee21 Trace; d113fd26 Trace; d1166a00 Trace; d113e4e9 Trace; d1166768 Trace; d11573ad Trace; c0109a88 Quite scary.. especially the ea0a part. I've disabled nfs, and it seems to work ok right now. Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
On Tue, Dec 12, 2000 at 11:06:07AM -0800, Linus Torvalds wrote: > > Dec 12 14:04:50 spaans kernel: invalid operand: > > Dec 12 14:04:50 spaans kernel: CPU:1 > > Dec 12 14:04:50 spaans kernel: EIP:0010:[end_buffer_io_bad+85/92] > > > > Dec 12 14:04:50 spaans kernel: Call Trace: > > [raid5_end_buffer_io+68/128] > > [complete_stripe+151/272] > > [handle_stripe+331/1092] > > [raid5d+173/260] > > [md_thread+299/508] > > Looks like somebody didn't initialize the "b_end_io" pointer - the code > defaults to it being "end_buffer_io_bad" (which oopses unconditionally on > purpose exactly to find places where it wasn't initialized). > > And it obviously looks like it's the raid5 code that does it. > > To get better debug output, could you please do something for me? > > In fs/buffer.c, get rid of "end_buffer_io_bad" completely, and replace all > users of it with NULL. > > Then, in drivers/block/ll_rw_block.c: generic_make_request(), add a test > like > > if (!bh->b_end_io) BUG(); > > to the top of that function. > > You'll still get a oops, but the difference is that you'll get the oops > when the request is queued, rather than when the requst is finished, which > will make it easier to figure out what the thing is that leads up to this. Right, well, I applied your suggestions, and I got it to oops -- dunno how, but it oopsed. Unable to handle kernel NULL pointer dereference at virtual address *pde = Oops: CPU:0 EIP:0010:[<>] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: 0008 ecx: c146c400 edx: 0202 esi: c154d560 edi: c154d400 ebp: c70791a0 esp: c14ade9c ds: 0018 es: 0018 ss: 0018 Process raid5d (pid: 9, stackpage=c14ad000) Stack: c01c916c c70791a0 0001 0008 c154d400 0002 c01c9ccf c154d400 0002 0001 c154d400 c146c400 c154d400 0003 0003 c146c400 c01ca827 c154d400 c154d400 c146c400 00a2 c14b1ec0 c02e8c80 Call Trace: [] [] [] [] [] [] [] [] [] Code: Bad EIP value. >>EIP; Before first symbol Trace; c01c916c Trace; c01c9ccf Trace; c01ca827 Trace; c018c070 Trace; c018c0c9 Trace; c018c3ed Trace; c01cad99 Trace; c01d1b57 Trace; c0109a88 Strange thing is that it doesn't call BUG() and the trace seems quite identical -- this caused me to start looking at the code in drivers/md/raid5.c and it seems this null pointer deref is coming from there - Neil, do you have some documentation on how this code should work, as stripe_head causes some null-pointer-derefs inside my head.. It seems a stripe_head is quite similar to a block_head, but why is raid5_end_buffer_io calling the bh_end_io function from the stripe_head, I'd assume it should be called from ll_rw_block.c? Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
On Wed, Dec 13, 2000 at 06:56:22AM +1100, Neil Brown wrote: > Guilt by association :-) > > What this bit of code (complete_stripe/raid5_end_buffer_io) is doing > is observing that it as completed some I/O request that was made of > the raid5 device and is calling the b_end_io on the buffer_head that > is was passed. So it is not one of raid5's buffers that has the bad > b_end_io, but someone else's buffer that raid5 was asked to service. > > You say "things with a mysql-db on a raid5-device". Can I interpret > this to mean that mysql was talking driectly to /dev/md0, or is there > some filesystem in-between? > Either way, I expect Linus' suggestion will provide the answer. Will try to reproduce this, with Linus' suggestion; btw, this mysql-db is running on ext2, nothing exotic. Regards, -- Q_.Jasper Spaans <mailto:[EMAIL PROTECTED]>-o) `~\ Conditional Access/DVB-C/OpenTV/Unix-adviseur/\\ Mr /\_\_v Zap Een ongezellig dure consultant nodig? Mail [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[BUG] raid5 crash with 2.4.0-test12 [Was: Linux-2.4.0-test12]
On Mon, Dec 11, 2000 at 06:52:55PM -0800, Linus Torvalds wrote: > > Ok, there it is. Noticeable changes from pre8 are mainly (a) new tq list > compile fixes and (b) the NetApp snapshot thing. > - final: > - Neil Brown: raid and md cleanups Hmm, while doing some not-so-heavy things with a mysql-db on a raid5-device this kernel Oopsed on me; ksymoops output [which went through klogd, shouldn't matter that much, klogd was using the right System.map]: Dec 12 14:04:50 spaans kernel: invalid operand: Dec 12 14:04:50 spaans kernel: CPU:1 Dec 12 14:04:50 spaans kernel: EIP:0010:[end_buffer_io_bad+85/92] Dec 12 14:04:50 spaans kernel: EFLAGS: 00010286 Dec 12 14:04:50 spaans kernel: eax: 001c ebx: c5418dc8 ecx: edx: 0100 Dec 12 14:04:50 spaans kernel: esi: cfd9b960 edi: cfd9b800 ebp: c5418d80 esp: c14ade8c Dec 12 14:04:50 spaans kernel: ds: 0018 es: 0018 ss: 0018 Dec 12 14:04:50 spaans kernel: Process raid5d (pid: 9, stackpage=c14ad000) Dec 12 14:04:50 spaans kernel: Stack: c0225409 c022575a 02fd 0008 c01c91ac c5418d80 0001 0008 Dec 12 14:04:50 spaans kernel:cfd9b800 0002 c01c9d0f cfd9b800 0002 0001 cfd9b800 Dec 12 14:04:50 spaans kernel:c146c400 cfd9b800 0003 0003 c146c400 c01ca867 cfd9b800 cfd9b800 Dec 12 14:04:50 spaans kernel: Call Trace: [tvecs+13949/58456] [tvecs+14798/58456] [raid5_end_buffer_io+68/128] [complete_stripe+151/272] [handle_stripe+331/1092] [raid5d+173/260] [md_thread+299/508] Dec 12 14:04:50 spaans kernel: Code: 0f 0b 83 c4 0c 5b c3 55 57 56 53 8b 5c 24 14 8b 54 24 18 85 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 0f 0b ud2a Code; 0002 Before first symbol 2: 83 c4 0c add$0xc,%esp Code; 0005 Before first symbol 5: 5bpop%ebx Code; 0006 Before first symbol 6: c3ret Code; 0007 Before first symbol 7: 55push %ebp Code; 0008 Before first symbol 8: 57push %edi Code; 0009 Before first symbol 9: 56push %esi Code; 000a Before first symbol a: 53push %ebx Code; 000b Before first symbol b: 8b 5c 24 14 mov0x14(%esp,1),%ebx Code; 000f Before first symbol f: 8b 54 24 18 mov0x18(%esp,1),%edx Code; 0013 Before first symbol 13: 85 00 test %eax,(%eax) Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: What is 2.4.0-test10: md1 has overlapping physical units with md2!
On Sun, Nov 19, 2000 at 03:39:43AM -0800, George Garvey wrote: > Is this something to be concerned about? It sounds like a disaster waiting > to happen from the message. This is on 2 systems (with similar disk setups > [same other than size]). > Nov 18 16:31:02 mwg kernel: md: serializing resync, md1 has overlapping physical >units with md2! Nope, nothing to worry about -- it's just a bad choice of wording ;) What it means is that some partititions in md1 and md2 are on the same disk, and that the md-code will not do the reconstruction of these arrays in parallel [of course, for performance reasons]. Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] raid5 link error? (was [PATCH] raid5 fix after xor.c cleanup)
On Sat, Nov 18, 2000 at 12:35:36PM +0100, Jasper Spaans wrote: > Hmm, next time I'll need to eat my own dogfood -- this patch doesn't work, > it only compiles. Don't use it. It seems to me the original code was correct, but the linking isn't in the right order and the initcalls are in the wrong order (ie, raid5.c::raid5_init() is being called before xor.c::calibrate_xor_block() -- any linking gurus out there who can help me out on this one? Feeling a bit of a schizo, but getting used to my brown paper bag, Regards -- Q_.Jasper Spaans <mailto:[EMAIL PROTECTED]>-o) `~\ Conditional Access/DVB-C/OpenTV/Unix-adviseur/\\ Mr /\_\_v Zap Een ongezellig dure consultant nodig? Mail [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] raid5 fix after xor.c cleanup
On Fri, Nov 17, 2000 at 11:41:44PM +0100, Jasper Spaans wrote: > due to the xor.c cleanup in 2.4.0-test11-pre5+, raid5 compiled into the > kernel fails when booting, because the calibrate_xor_block function > hasn't been called while registering a raid5 volume; this leads to a > panic, as no checksumming function has been chosen. > > Here's a tiny patch to restore that functionality, can you apply it? Hmm, next time I'll need to eat my own dogfood -- this patch doesn't work, it only compiles. Don't use it. Regards, -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] raid5 fix after xor.c cleanup
Hi Ingo & lists,
due to the xor.c cleanup in 2.4.0-test11-pre5+, raid5 compiled into the
kernel fails when booting, because the calibrate_xor_block function
hasn't been called while registering a raid5 volume; this leads to a
panic, as no checksumming function has been chosen.
Here's a tiny patch to restore that functionality, can you apply it?
Regards,
--
Jasper Spaans <[EMAIL PROTECTED]>
diff -Nru linux-2.4.0-test11-pre6-orig/drivers/md/raid5.c
linux-2.4.0-test11-pre6/drivers/md/raid5.c
--- linux-2.4.0-test11-pre6-orig/drivers/md/raid5.c Fri Nov 17 23:21:18 2000
+++ linux-2.4.0-test11-pre6/drivers/md/raid5.c Fri Nov 17 23:19:24 2000
@@ -2344,6 +2344,9 @@
int raid5_init (void)
{
+#ifndef MODULE
+ calibrate_xor_block();
+#endif
return register_md_personality (RAID5, &raid5_personality);
}
diff -Nru linux-2.4.0-test11-pre6-orig/drivers/md/xor.c
linux-2.4.0-test11-pre6/drivers/md/xor.c
--- linux-2.4.0-test11-pre6-orig/drivers/md/xor.c Fri Nov 17 23:21:18 2000
+++ linux-2.4.0-test11-pre6/drivers/md/xor.cFri Nov 17 23:31:36 2000
@@ -98,7 +98,7 @@
speed / 1000, speed % 1000);
}
-static int
+int
calibrate_xor_block(void)
{
void *b1, *b2;
@@ -139,5 +139,6 @@
}
MD_EXPORT_SYMBOL(xor_block);
+MD_EXPORT_SYMBOL(calibrate_xor_block);
module_init(calibrate_xor_block);
diff -Nru linux-2.4.0-test11-pre6-orig/include/linux/raid/xor.h
linux-2.4.0-test11-pre6/include/linux/raid/xor.h
--- linux-2.4.0-test11-pre6-orig/include/linux/raid/xor.h Fri Nov 17 23:21:48
2000
+++ linux-2.4.0-test11-pre6/include/linux/raid/xor.hFri Nov 17 23:33:03 2000
@@ -6,6 +6,7 @@
#define MAX_XOR_BLOCKS 5
extern void xor_block(unsigned int count, struct buffer_head **bh_ptr);
+extern int calibrate_xor_block(void);
struct xor_block_template {
struct xor_block_template *next;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test11pre2-ac1 and previous problem
On Sun, Nov 12, 2000 at 01:27:13PM +1100, Keith Owens wrote: > >That's a pretty wierd trace. You seem to have addresses related > >to the `apm' kernel thread on mysqld's stack. > > Normal unfortunately. Firstly the ix86 oops code just scans the stack > and prints anything that looks like it might be a kernel address. It > makes no attempt to confirm that these really are return addresses, so > an ix86 oops trace gets lots of false positives. Secondly that trace > was converted by klogd (symbols in call trace line instead of numbers) > not by ksymoops, I do not trust the klogd algorithm at all. All right, here's another one, this time using the oops directly from the console -- this seems to give better symbols.. The 'console shuts up ...' works, the oops from the other CPU didn't get put out. Will try test11-pre3 + kdb this afternoon, if it compiles. Regards, -- Jasper Spaans <[EMAIL PROTECTED]> ksymoops 2.3.4 on i686 2.4.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test11/ (default) -m /boot/System.map-2.4.0-test11-pre2 (specified) NMI Watchdog detected LOCKUP on CPU1, registers: CPU:1 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 0086 eax: ebx: ce78 ecx: edx: esi: 0002 edi: ebp: cd0f1eb0 esp: cd0f1ea8 ds: 0018 es: 0018 ss: 0018 Process mysqld (pid: 5799, stackpage=cd0f1000) Stack: ce78 0021 c01152ea ce78 0021 0086 c01153c6 0021 cd0f1f04 ce78 00040001 cd0f 0021 c011589a 0021 cd0f1f04 ce78 cd0f c1458000 cd0f ce78 0021 Call Trace: [] [] [] [] [] [] [] [] Code: 80 3d 00 44 2e c0 00 f3 90 7e f5 e9 67 59 ee ff 80 3b 00 f3 >>EIP; c02347c4<= Trace; c01152ea Trace; c01153c6 Trace; c011589a Trace; c0122012 Trace; c011e727 Trace; c011eaf8 Trace; c011eb4e Trace; c010b203 Code; c02347c4 <_EIP>: Code; c02347c4<= 0: 80 3d 00 44 2e c0 00 cmpb $0x0,0xc02e4400 <= Code; c02347cb 7: f3 90 repz nop Code; c02347cd 9: 7e f5 jle0 <_EIP> Code; c02347cf b: e9 67 59 ee ffjmpffee5977 <_EIP+0xffee5977> c011a13b Code; c02347d4 10: 80 3b 00 cmpb $0x0,(%ebx) Code; c02347d7 13: f3 00 00 repz add %al,(%eax)
Re: 2.4.0-test11pre2-ac1 and previous problem
On Sat, Nov 11, 2000 at 11:25:00AM +1100, Andrew Morton wrote: > > NMI Watchdog detected LOCKUP on CPU3, registers: > Oh no. Another one. Could you please try this attached > patch (against test11-pre2) and see if the diagnostics > come out? And yet another one... I applied your patch, and ran my oopses through ksymoops, results attached. Kernel: 2.4.0-test11-pre2 + reiserfs-3.6.18 2 * P-II 350, 256 MB RAM, no special hardware, AFAIK. Of course, more details are available. Regards, -- Jasper Spaans <[EMAIL PROTECTED]> ksymoops 2.3.4 on i686 2.4.0-test11. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test11/ (default) -m /boot/System.map-2.4.0-test11-pre2 (specified) Nov 11 13:37:08 spaans kernel: NMI Watchdog detected LOCKUP on CPU1, registers: Nov 11 13:37:08 spaans kernel: CPU:1 Nov 11 13:37:08 spaans kernel: EIP:0010:[tvecs+21104/42928] Nov 11 13:37:08 spaans kernel: EFLAGS: 0086 Nov 11 13:37:08 spaans kernel: eax: ebx: ce78 ecx: edx: Nov 11 13:37:08 spaans kernel: esi: 0002 edi: ebp: cd0f1eb0 esp: cd0f1ea8 Nov 11 13:37:08 spaans kernel: ds: 0018 es: 0018 ss: 0018 Nov 11 13:37:08 spaans kernel: Process mysqld (pid: 5799, stackpage=cd0f1000) Nov 11 13:37:08 spaans kernel: Stack: ce78 0021 c01152ea ce78 0021 0086 c01153c6 Nov 11 13:37:08 spaans kernel:0021 cd0f1f04 ce78 00040001 cd0f 0021 c011589a Nov 11 13:37:08 spaans kernel:0021 cd0f1f04 ce78 cd0f c1458000 cd0f ce78 0021 Nov 11 13:37:08 spaans kernel: Call Trace: [do_ioctl+334/820] [do_ioctl+554/820] [apm+358/644] [will_become_orphaned_pgrp+14/124] [do_fork+211/2788] [do_fork+1188/2788] [do_fork+1274/2788] Nov 11 13:37:08 spaans kernel: Code: 80 3d 00 44 2e c0 00 f3 90 7e f5 e9 67 59 ee ff 80 3b 00 f3 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 80 3d 00 44 2e c0 00 cmpb $0x0,0xc02e4400 Code; 0007 Before first symbol 7: f3 90 repz nop Code; 0009 Before first symbol 9: 7e f5 jle0 <_EIP> Code; 000b Before first symbol b: e9 67 59 ee ffjmpffee5977 <_EIP+0xffee5977> ffee5977 Code; 0010 Before first symbol 10: 80 3b 00 cmpb $0x0,(%ebx) Code; 0013 Before first symbol 13: f3 00 00 repz add %al,(%eax) Nov 11 13:37:08 spaans kernel: NMI Watchdog detected LOCKUP on CPU0, registers: Nov 11 13:37:08 spaans kernel: CPU:0 Nov 11 13:37:08 spaans kernel: EIP:0010:[__down+339/588] Nov 11 13:37:08 spaans kernel: EFLAGS: 0097 Nov 11 13:37:08 spaans kernel: eax: c02e4420 ebx: ca6c ecx: edx: Nov 11 13:37:08 spaans kernel: esi: c02e4420 edi: ca6c1fa8 ebp: ca6c1fa8 esp: ca6c1f90 Nov 11 13:37:08 spaans kernel: ds: 0018 es: 0018 ss: 0018 Nov 11 13:37:08 spaans kernel: Process mysqld (pid: 5801, stackpage=ca6c1000) Nov 11 13:37:08 spaans kernel: Stack: c0234797 ca6c 40083890 bf5ffc00 fff2 0008 ca6c1fbc c0119ad4 Nov 11 13:37:08 spaans kernel:16a9 bf5ff8e8 bf5ff8b4 c010b203 16a9 bf5ff8e8 Nov 11 13:37:08 spaans kernel:40083890 bf5ffc00 bf5ff8b4 009c 002b 002b 009c 401a03e4 Nov 11 13:37:08 spaans kernel: Call Trace: [tvecs+21059/42928] [proc_sel+68/140] [restore_sigcontext+63/328] Nov 11 13:37:08 spaans kernel: Code: 83 38 01 78 fb f0 ff 08 0f 88 ef ff ff ff c3 90 90 90 90 90 Code; Before first symbol <_EIP>: Code; Before first symbol 0: 83 38 01 cmpl $0x1,(%eax) Code; 0003 Before first symbol 3: 78 fb js 0 <_EIP> Code; 0005 Before first symbol 5: f0 ff 08 lock decl (%eax) Code; 0008 Before first symbol 8: 0f 88 ef ff ff ff js fffd <_EIP+0xfffd> fffd Code; 000e Before first symbol e: c3ret Code; 000f Before first symbol f: 90nop Code; 0010 Before first symbol 10: 90nop Code; 0011 Before first symbol 11: 90nop Code; 0012 Before first symbol 12: 90nop Code; 0013 Before first symbol 13: 90nop
Re: mount -t bind gone?
On Mon, Sep 25, 2000 at 11:29:48AM -0700, H. Peter Anvin wrote: > I guess mount -t bind is officially gone. What is the new official > replacement? New system call? A simple solution: update your version of mount, and try mount --bind /foo /bar Regards, Jasper PS. If you look at the code in fs/super.c at line 1338, you'll see there's a new mount flag, and the old code at line 1348 has been deactivated. -- Jasper Spaans <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
