Re: reproducable panic with python
Yes, this has been fixed. Python was using MAP_ANON|MAP_NOSYNC
mmap()'s and this resulted in the possibility of msync() encountering
an optimized vm_map_entry that did not yet have a VM object associated
with it, causing a panic.
Both -stable and -current have been fixed to handle the case.
-current was fixed on March 7th, and -stable on March 8th.
-Matt
:On Wed, 6 Mar 2002, David Malone wrote:
:
: On Tue, Mar 05, 2002 at 11:11:48PM +, Harry Newton wrote:
: #!/usr/local/bin/python2.2
:
: import mmap
: m = mmap.mmap(-1,256,mmap.MAP_ANON)
: m = 1
:
: I've made a little progress on this. It doesn't work with python2.0.
: It does work on both -stable and -current. The trace back on -current
: looks is included below. It's doing a msync when it doesdies.
:
:{...}
:
:I've not seen any followup concerning resolution of this - have any
:conclusions been reached?
:
:--
:Andrew I MacIntyre These thoughts are mine alone...
:E-mail: [EMAIL PROTECTED] | Snail: PO Box 370
:[EMAIL PROTECTED]|Belconnen ACT 2616
:Web:http://www.andymac.org/|Australia
:
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with unsubscribe freebsd-stable in the body of the message
:
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
RE: PCI 802.11b recommendations?
Hi, did anyone have a success putting USB based(!!!) Intel 2011B to work unde 4.5-STABLE ? I have one on Compaq notebook and I would *really* like to use it. Thank you in advance, Milon -- [EMAIL PROTECTED] -Original Message- From: Eric Masson [mailto:[EMAIL PROTECTED]] Sent: Friday, January 25, 2002 12:15 PM To: M. Warner Losh Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: PCI 802.11b recommendations? Warner == M Warner Losh [EMAIL PROTECTED] writes: Warner My brother runs his Intel 2011 on his 4.5-RC VAIO without Warner hassle. However, this is the pcmcia version, not the PCI Warner version. Hello Warner, I was facing the same problem with the pcmcia card without the pci bridge. It seems I'm using an outdated cvsup mirror to feed mine (commits logged in cvs-all not appearing on my local cvsup server), just switched to cvsup.uk.FreeBSD.org, I'll rebuild the world this WE and test next week (have to go to the main office to test). Eric -- Pour comprendre la suite, je collectionne les CD que je reçois d'un peu partout y compris ceux que je grille involontairement, tout cela pour me fabriquer une lampe qui diffuse par la tranche des CD empilés... -+- AB in Guide du Macounet Pervers : Bien Recycler ses CD AOL -+- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
[no subject]
subscribeyou be cool To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: 3Ware, Western Digital disks, and stray interrupts
Albert We're running a 6410 with four WD1000 disks and have had only Albert one failure so far. Anyway, according to the author of the twe Albert driver, Michael Smith, a firmware upgrade for the 7xxx series Albert controllers should be available by now. Thanks, I had missed that post. We might have to switch from RELENG_4_5 to RELENG_4 for that box and try it. Not the end of the world, we've just gotten to like tracking those branches. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
SUKCES - baza e-mail firm
Szanowni Panstwo Proponujemy Panstwu najwieksza baze mailowa polskich firm i przedsiebiorstw, ktora zawiera ponad 100.000 adresow e-mail za jedyne 499,- pln. E-mailowa masowa wysylka ofert - jest jedna z najtanszych, najskuteczniejszych i natychmiast dzialajacych form reklamy, pomagajaca nawiazac cenne kontakty handlowe. Ponad 100.000 wyslanych listow e-mail przypomina swoja iloscia naklad duzej gazety. Wiecej informacji na naszej stronie: http://www.drhi.net Jesli nie chca Panstwo otrzymywac w przyszlosci informacji od nas prosimy o wyslanie pustego maila na adres [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Network stalls with 4.5
David Wolfskill [EMAIL PROTECTED] writes: You might try doing something as crude as while (1) netstat -ni sleep 10 end and use that to see of you're getting errors or collisions durng the stalls. Thanks. They've all been up for 20-30 days, and show zero errors or collisions. Also, we're not having this problem with the Linux or OpenBSD boxes on the same LAN, so it doesn't seem to be a cabling or hub problem. Aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
4.5-RELEASE kernel panic
Hello All,
Below is an abbreviated kernel debugging session from a kernel panic. I
suspect this is due to a bug in the network routing code. Somehow, a null
pointer got thrown in the works. Could someone more knowledgable of these
things have a look? I can provide more information as requested.
Thanks!
My system: FreeBSD 4.5-RELEASE on an AMD Athlon 1 GHz, 512 MB RAM, Intel
Etherexpress PRO 100S.
What I found with gdb -k:
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x303031f
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01b9049
stack pointer = 0x10:0xc030cf78
frame pointer = 0x10:0xc030cfc8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = Idle
interrupt mask =
trap number = 12
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:474
#1 0xc016fbfb in boot (howto=260) at ../../kern/kern_shutdown.c:313
#2 0xc016fff5 in panic (fmt=0xc030574c %s) at
../../kern/kern_shutdown.c:582
#3 0xc02b2faf in trap_fatal (frame=0xc030cd64, eva=48)
at ../../i386/i386/trap.c:956
#4 0xc02b2c5d in trap_pfault (frame=0xc030cd64, usermode=0, eva=48)
at ../../i386/i386/trap.c:849
#5 0xc02b2803 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1070166208, tf_esi = 0, tf_ebp = -1070543444,
tf_isp = -1070543472, tf_ebx = -1070432644, tf_edx = 6832192,
tf_ecx = 8, tf_eax = 0, tf_trapno = 12, tf_err = 0,
tf_eip = -1071357192, tf_cs = 8, tf_eflags = 66050, tf_esp = 0,
tf_ss = 0}) at ../../i386/i386/trap.c:448
#6 0xc02462f8 in acquire_lock (lk=0xc0327e7c)
at ../../ufs/ffs/ffs_softdep.c:271
#7 0xc024a896 in softdep_fsync_mountdev (vp=0xe36db540)
at ../../ufs/ffs/ffs_softdep.c:3986
#8 0xc024ec5a in ffs_fsync (ap=0xc030ce20) at
../../ufs/ffs/ffs_vnops.c:134
#9 0xc024d8e7 in ffs_sync (mp=0xc198ec00, waitfor=2, cred=0xc1474500,
p=0xc0368f40) at vnode_if.h:558
#10 0xc019ffd3 in sync (p=0xc0368f40, uap=0x0) at
../../kern/vfs_syscalls.c:547
#11 0xc016f9ae in boot (howto=256) at ../../kern/kern_shutdown.c:234
#12 0xc016fff5 in panic (fmt=0xc030574c %s) at
../../kern/kern_shutdown.c:582
#13 0xc02b2faf in trap_fatal (frame=0xc030cf38, eva=50529055)
at ../../i386/i386/trap.c:956
#14 0xc02b2c5d in trap_pfault (frame=0xc030cf38, usermode=0, eva=50529055)
at ../../i386/i386/trap.c:849
#15 0xc02b2803 in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16,
tf_edi = -1047960544, tf_esi = 0, tf_ebp = -1070542904,
tf_isp = -1070543004, tf_ebx = 50529027, tf_edx = 0,
tf_ecx = -1048122492, tf_eax = 6424576, tf_trapno = 12, tf_err = 0,
tf_eip = -1071935415, tf_cs = 8, tf_eflags = 66054,
tf_esp = -1047960544, tf_ss = 50529027}) at
../../i386/i386/trap.c:448
#16 0xc01b9049 in rtalloc1 (dst=0xc1896420, report=0, ignflags=65792)
at ../../net/route.c:135
#17 0xc01c53e5 in in_addroute (v_arg=0xc1896420, n_arg=0x0,
head=0xc186ea80,
treenodes=0xc1e95c00) at ../../netinet/in_rmx.c:121
#18 0xc01b98e8 in rtrequest1 (req=11, info=0xc030d054, ret_nrt=0xc030d0b8)
at ../../net/route.c:692
#19 0xc01b9518 in rtrequest (req=11, dst=0xc030d130, gateway=0x0,
netmask=0x0,
flags=0, ret_nrt=0xc030d0b8) at ../../net/route.c:489
#20 0xc01b9097 in rtalloc1 (dst=0xc030d130, report=1, ignflags=256)
at ../../net/route.c:149
#21 0xc01b9004 in rtalloc_ign (ro=0xc030d12c, ignore=256)
at ../../net/route.c:111
#22 0xc1a22019 in ?? ()
#23 0xc1a22b73 in ?? ()
#24 0xc01c73b7 in ip_input (m=0xc1476600) at ../../netinet/ip_input.c:419
#25 0xc01c793b in ipintr () at ../../netinet/ip_input.c:843
#26 0xc02a7d95 in swi_net_next ()
(kgdb) up 16
#16 0xc01b9049 in rtalloc1 (dst=0xc1896420, report=0, ignflags=65792)
at ../../net/route.c:135
135 if (rnh (rn = rnh-rnh_matchaddr((caddr_t)dst, rnh))
(kgdb) list
130 int s = splnet(), err = 0, msgtype = RTM_MISS;
131
132 /*
133 * Look up the address in the table for that Address
Family
134 */
135 if (rnh (rn = rnh-rnh_matchaddr((caddr_t)dst, rnh))
136 ((rn-rn_flags RNF_ROOT) == 0)) {
137 /*
138 * If we find it and it's not the root node, then
139 * get a refernce on the rtentry associated.
(kgdb) print rnh
$1 = (struct radix_node_head *) 0x620800
(kgdb) print dst
$2 = (struct sockaddr *) 0xc1896420
(kgdb) print rn
$3 = (struct radix_node *) 0x0
(kgdb) print *rnh
cannot read proc at 0
(kgdb) print *dst
$4 = {sa_len = 0 '\000', sa_family = 97 'a',
sa_data = \211Á\020\002\000\000£\001\177\236\000\000\000}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: Network stalls with 4.5
Mike Tancsa [EMAIL PROTECTED] writes: Do you have a separate simple non production box you can put on the LAN with totally different hardware that you can try the same tests with running FreeBSD? No, unfortunately the servers are across the country from my location, and they're all in production. But they do have varying hardware -- some Intel network cards, some 3COM; more or less RAM; different processor speeds; etc. All worked fine at various 4.3 and 4.4 versions, and all developed these symptoms when we upgraded to 4.5-RC, and then 4.5-STABLE. Thanks, Aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Problems with large disk. ( 1 TB)
Trying to disklabel a 1 TB disk (with sysinstall or disklabel) produces a lot of errors. In sysinstall, there's a kazillion overflows and negative offsets, and stuff. With disklabel, it tells me that the partition size needs to be truncated, then writes the label. then if I run disklabel again, it takes the truncated size, says it's too big, and truncates it again. Interestingly enough, using DOS FDISK to put a 32MB dos partition at the beginning of the drive makes it all work fine. I am not convinced that I am not missing some space, but I haven't counted up everything yet. In any case, is this supposed to work? I'll snag a ton of data if somebody wants to look at it, but I don't want to invest the time if it's not meant to. This is a 8 disk Maxtor 160GB disks in raid 5, on a 3ware 7850 with the 7.4 release firmware. -Stable supped as of 3/19. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Problems with large disk. ( 1 TB)
I don't have a solution for you, but I am pretty sure I know the problem: calc 2^31*512 = 1TB. disklabel references everything using a unit of 512 byte sectors. That number of sectors I'm sure is stored as an unsigned int making 2^31-1 the max number of sectors. Aka, just under a TB is fine, one TB or over is bad. So the 32mb dos partition probably made it just under a TB. Maybe someone else knows a solution for this problem. - Original Message - From: Jaye Mathisen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 19, 2002 16:15 Subject: Problems with large disk. ( 1 TB) Trying to disklabel a 1 TB disk (with sysinstall or disklabel) produces a lot of errors. In sysinstall, there's a kazillion overflows and negative offsets, and stuff. With disklabel, it tells me that the partition size needs to be truncated, then writes the label. then if I run disklabel again, it takes the truncated size, says it's too big, and truncates it again. Interestingly enough, using DOS FDISK to put a 32MB dos partition at the beginning of the drive makes it all work fine. I am not convinced that I am not missing some space, but I haven't counted up everything yet. In any case, is this supposed to work? I'll snag a ton of data if somebody wants to look at it, but I don't want to invest the time if it's not meant to. This is a 8 disk Maxtor 160GB disks in raid 5, on a 3ware 7850 with the 7.4 release firmware. -Stable supped as of 3/19. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Network stalls with 4.5
From: Aaron Baugher [EMAIL PROTECTED] Date: 19 Mar 2002 14:32:11 -0600 Sender: [EMAIL PROTECTED] David Wolfskill [EMAIL PROTECTED] writes: You might try doing something as crude as while (1) netstat -ni sleep 10 end and use that to see of you're getting errors or collisions durng the stalls. Thanks. They've all been up for 20-30 days, and show zero errors or collisions. Also, we're not having this problem with the Linux or OpenBSD boxes on the same LAN, so it doesn't seem to be a cabling or hub problem. Aaron, This may be simple confusion on terminology, but hub normally is the term used for a multi-port Ethernet device that acts as a simple repeater with all connections in a common collision domain and all running half-duplex. If this is the case, zero collisions is VERY hard to believe. Collisions will always happen in a half-duplex LAN on a system that does any significant amount of writing to the network. Simple matter of statistics. Is the connecting box a hub (repeater) or a switch (bridge)? If it's a bridge, you should probably be running full-duplex and would ALWAYS have zero collisions as collision detection is disabled in that case. If it's a hub or if the interface is running half-duplex, it's possible that the NIC is defective and that could be the source of the problems. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Having trouble submitting with send_pr
I'm having a hard time with send_pr. I've tried several times to submit
a maintainer update for a port, but all the mails send_pr sends seem to
disappear in the digital nirvana. I receive no confirmation email, no
bounces, no nothing. So I just submitted it with the web interface
again.
I'm using Postfix and I can normally send email just fine (my mutt uses
Postfix's sendmail).
So I thought the problem is the wrong sendmail is used, so I created a
config file for GNATS and set the MAIL_AGENT variable appropriately.
Still no luck.
Any suggestions? I'd really like to get this fixed.
Gerhard
--
mail: gerhard at bigfoot dot de registered Linux user #64239
web:http://www.cs.fhm.edu/~ifw00065/OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9 3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: cdrecord for ATAPI burners available..
On Tue, 2002-03-19 at 06:26, Sxren Schmidt wrote: For those that have problems with burncd or simply cannot live without, I've put up the source for an ATAPI enabled cdrecord on: ftp://freebsd.dk/pub/ATA/cdrtools-1.10-ATA.tgz On -stable it needs the ATA driver update I did a yesterday. It does *not* need CAM or the atapicam patches, it uses the ATA driver directly.. Enjoy! -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message Søren, In the past you've objected to ATAPI-CAM on two grounds, fear that it won't be done right, and fear that it will add more work to yourself. I think that there are enough highly intelligent people interested in the project that the first issue can be put to rest. While I highly respect what you have done with this port, I think that you are eroding your defense of the second issue. I fail to see how porting (and presumably maintaining) a multitude of CD utilities will be less work for you than allowing someone to put a CAM hook into your acd driver, and then sitting back as they maintain that work. If you object to ATAPI-CAM, just come out and and admit it. This isn't a battle of egos of wills, and nobody is trying to discredit your work. You are a valuable member of the FreeBSD community, and everybody appreciates the work that you have put it. ATAPI-CAM is not meant to replace you, since we still need your expertise in every other part of the ATA/ATAPI/IDE framework. It is meant to help users who want a simple way to do cool stuff with their ATAPI devices. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
ATA: HPT370 only uses UDMA66 after update to 4.5-STABLE
Hi, after updating from a 4.4-STABLE (october last year) to 4.5-STABLE (2002-03-18) my HPT370 uses only UDMA66 by default. Nothing else has changed. The cable is specified for that speed and there is only one UDMA100 capable disk on each channel. UDMA100 worked w/o any problems with 4.4-STABLE. with 4.4-STABLE: atapci1: HighPoint HPT370 ATA100 controller port 0xb000-0xb0ff,0xb400-0xb403,0xb800-0xb807,0xd000-0xd003,0xd400-0xd407 irq 11 at device 12.0 on pci0 ad4: 76319MB MAXTOR 4K080H4 [155061/16/63] at ata2-master UDMA100 ad6: 76319MB MAXTOR 4K080H4 [155061/16/63] at ata3-master UDMA100 with 4.5-STABLE: atapci1: HighPoint HPT370 ATA100 controller port 0xb000-0xb0ff,0xb400-0xb403,0xb800-0xb807,0xd000-0xd003,0xd400-0xd407 irq 11 at device 12.0 on pci0 ad4: 76319MB MAXTOR 4K080H4 [155061/16/63] at ata2-master UDMA66 ad6: 76319MB MAXTOR 4K080H4 [155061/16/63] at ata3-master UDMA66 Has anybody seen this before? Bye, Ronald -- * The whole problem with the world is that fools and fanatics are always * so certain of themselves, but wiser people so full of doubts. * --Bertrand Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
