Re: fsck and lost+found space
* Charles Sprickman <[EMAIL PROTECTED]> [2004-08-10 23:52 -0400]: > I was hoping for some option in fsck to allow an alternate lost+found > directory on another device, but no such luck. Is there anything else > that I'm overlooking? I'm willing to try anything since I'm doing all > this on a junk box with a ton of space that I can panic without it > bothering anyone. I'm not sure whether this has been suggested before. Can you stop fsck just before it begins to throw away files? Then you could perhaps rename lost+found (perhaps with fsdb) and rerun fsck. Just an idea, Nicolas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fsck and lost+found space
Hi, I've worked through most of the problems I had with trying to recover some data from a dd image of a wrecked filesystem. Thanks very much to everyone that helped me out with the basics and with the vnconfig stuff to mount it. Right now I'm working on another copy of this same image, and I could use a bit of help with a problem I'm having while running fsck. At some point during the check, fsck starts complaining that there's not enough space in "lost+found" and that the file it just rescued will be trashed instead of being stashed in lost+found. >From what I've seen digging through Google this isn't an issue of not enough space on the device itself, but some limitation on how many files/directories that fsck can create in lost+found. Some folks here have suggested creating and then deleting a large number of files in that directory and then re-running fsck. I have tried that, but since I'm mounting a dirty filesystem r/w to do that all of my attempts have ended in the box panicing. Is there any other option? I know that when I hit the stage where fsck starts running out of space I'm losing about 5GB of stuff. The reason there are such a large number of files is that this is the remnants of a mailserver that used Maildirs... I was hoping for some option in fsck to allow an alternate lost+found directory on another device, but no such luck. Is there anything else that I'm overlooking? I'm willing to try anything since I'm doing all this on a junk box with a ton of space that I can panic without it bothering anyone. Thanks again, Charles ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using the VIA 8237 ATA133 IDE ports
Heikki Turunen wrote: >> Ok, I am now about to upgrade. I can still not tell, from the >> hardware notes, whether 4.10R will actually support the VIA 8237 ATA >> 133 as well (it only talks about VIA 8237 SATA 150). I hope so. > > I'm using 4.10-STABLE and VIA 8237 works just fine. > > 8< > localhost/heikki:$ dmesg | grep atapci1 > atapci1: port 0x9000-0x900f irq 14 at > device 15.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci1 > ata1: at 0x170 irq 15 on atapci1 > >8 I overcame my reluctance, upgraded to 4.10-RELEASE-p2, and now everything is working again! :) atapci1: port 0xd000-0xd0ff,0xd400-0xd40f,0xd800-0xd803,0xe000-0xe007,0xe400-0xe403,0xe800 -0xe807 irq 10 at device 15.0 on pci0 ata4: at 0xe800 on atapci1 ata5: at 0xe000 on atapci1 atapci2: port 0xfc00-0xfc0f at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci2 ata1: at 0x170 irq 15 on atapci2 ad0: 39205MB [79656/16/63] at ata0-master UDMA133 ad4: 78167MB [158816/16/63] at ata2-master UDMA133 Long live 4.10 FreeBSD VIA 8237 support! Now I will never have to start using 5.x series. :) Yay! - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Realtime memory testing - Was: Re: how to logically disable memory
Porting is probably not an option, since the memory managers are very different. But the same idea could be applied. Indeed, in my college times, I had a class about memory testing procedures, and had an idea to patch the FreeBSD kernel to do realtime memory tests and lock bad memory. This way, the system would be a lot more stable, even with bad hardware (common in poor countries like Brasil). The solution is probably near the VM core. At that time I was thinking in changing the page mapper, but now I know this would just make the system more i386 specific, and the solution could be architecture generic. No, unfortunatly I never let this idea grow into a solution. Probably because I never got the guts to fully understand the FreeBSD VM engine. ;-) Joan Picanyol wrote: * Danny Braniss <[EMAIL PROTECTED]> [20040809 11:42]: is there an 'easy' way to mark some memory as unusable? thanks, Linux has BadRAM: http://rick.vanrein.org/linux/badram/index.html, I think someone was thinking of porting it to FreeBSD... (or maybe it was you ;) qvb ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ready or not?
On Thu, 29 Jul 2004, Pawel Malachowski wrote: > On Wed, Jul 28, 2004 at 03:02:38PM +0200, Max Laier wrote: > > Hello, > > > as PF+ALTQ gateway in production environment. For ALTQ there is the problem > > of "will your driver be supported?". > > Could You please explain a bit, why ALTQ model is placed so close > to network adapter driver (that they have to be modified) instead > of placing it in upper layers (and leaving NIC drivers untouched)? Short answer: ALTQ is short for "alternate queueing", it works by changing the default (FIFO) queueing discipline of the NIC. For the details and design criteria, look here: ftp://ftp.csl.sony.co.jp/pub/kjc/papers/dissertation.ps.gz http://www.csl.sony.co.jp/person/kjc/kjc/papers/usenix98/ Fer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: piespy on freebsd 4.10
On Tue, Aug 10, 2004 at 07:25:56PM +0200, christian astrup bakke // chasm wrote: > has anyone here successfully installed piespy (link further down) in a > 4.10(-release) enviroment? it needs java, and a paragraph on the piespy page > says: > > "If you run PieSpy in a non-graphical environment (e.g. a Unix console that > does not have access to an X server) you will need to pass the following > command line parameter to java: -Djava.awt.headless=true. Note that PieSpy > may not function properly on FreeBSD. This is because Java on FreeBSD > handles floating point calculations incorrectly." > > i indeed plan to use it from the console on my server. neither piespy og > java has been installed at this point, because i'd like some feedback on it > first. > > so, what do you guys and girls think? is this "floating point calculations" > thing still a problem? > > link til piespy: http://www.jibble.org/piespy/ Firstly, this is better asked on freebsd-java, not freebsd-hackers. In response to your question, both the 1.3 and 1.4 JDK implementations have passed all the extensive floating point tests in the JCK compliance suite. The statement they made may have been true in the early days of porting the JDK, but is currently without any factual basis. -- Greg Lewis Email : [EMAIL PROTECTED] Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
piespy on freebsd 4.10
hi! has anyone here successfully installed piespy (link further down) in a 4.10(-release) enviroment? it needs java, and a paragraph on the piespy page says: "If you run PieSpy in a non-graphical environment (e.g. a Unix console that does not have access to an X server) you will need to pass the following command line parameter to java: -Djava.awt.headless=true. Note that PieSpy may not function properly on FreeBSD. This is because Java on FreeBSD handles floating point calculations incorrectly." i indeed plan to use it from the console on my server. neither piespy og java has been installed at this point, because i'd like some feedback on it first. so, what do you guys and girls think? is this "floating point calculations" thing still a problem? link til piespy: http://www.jibble.org/piespy/ thanks in advance! -- with regards, christian astrup bakke // chasm. http://chasm.nu/ - chasm at chasm dot nu pgp key id: 0xF0FB7BB7 pgp fp: 9EB1 AA42 1142 2A7C CD24 65CA 584E 537C F0FB 7BB7 (scanned with norton antivirus 2004) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[Fwd: Re: Which architecture]
jean-marc tallet said: > Hi, > > > I have a typical pc where I run windows and wish to > install FreeBSD. Which platform should I choose? > My processor is x86 family 6 model 4. > > > Sorry also I wanted to know which architecture to pick > up on the mirror site, between pc98 and i386! > You'll need FreeBSD 4.10 i386. 5.2.1 is a developpement release and PC98 is totally another architecture. -- Nicolas Bérard Nault ([EMAIL PROTECTED]) http://staff.xeatech.net/nicobn PGP public key: 0x64159509 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reboots after "OR AL,1 MOV CR0, EAX" on some computers.
> good free environment for initialization and further running. Shortly: ON > SOME COMPUTERS (MAYBE CPUS) I GET REBOOTING JUST ON 'JMP' INSTRUCTION > AFTER PE BIT IS ENABLED. I've got no reboots on all i386, i486, i586 > computers that I tryed to boot from. I have a Pentium III Celeron > (Coppermine) 900MHz - no reboots. Also tested on some Pentium II 400MHz - > no reboots. But on other side Pentium IV (don't remember speed) gave me a > reboot. And other computer I was not able to see processor model (maybe > PentiumIV !?) gave me a reboot too. Using endless loop stop points I > figured out that reboot is before any instruction pointed by 'protected' > label and that reboot happens after setting the PE bit. I've tested the code on a Dual-CPU P-166 - the system always goes into cold reboot. I first thought that SMP systems need some special procedure to switch to protected mode (the fact that all Pentium IV CPUs have second logical processor helps the idea), but then I tested it on Athlon XP system - reboots also. I'll play with it later. Maybe somebody at freebsd-hackers know the answer? Timestamp: 0x4118F317 [SorAlx] http://cydem.org.ua/ ridin' VN1500-B2 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
Marc Fonvieille wrote: On Tue, Aug 10, 2004 at 04:08:48PM +0200, Søren Schmidt wrote: I used in past your cdrecord version when it was available on your site. Is there any new version freely available? :) They are still at my site actually, butI havn't cared to update them much (dont fix what aint broken)... [...] It seems ftp.freebsd.dk does not accept passive mode :(( Sorry, glitch, fixed... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FW: Anyone tried new Dell PowerEdge 2850 Server Box?
Has anyone tried either Stable or Current on the new Dell 1850 or 2850 boxes (looks like identical motherboard)? Or any other platform using the Intel E7520 chipset? Comments? Dave David Grant CanWeb Internet Services ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel panic in 5.2.1-p9
I have been getting these kernel panics more frequently now and it has
become a problem. I have used gdb to provide basic information, but I am
not very experienced in this so let me know what to do to give you any more
information. I have had 2 crashes dump a core, so I will include both
(sorry for the length)
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x53
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc05c6857
stack pointer = 0x10:0xe00c2be8
frame pointer = 0x10:0xe00c2be8
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 = 45 (syncer)
trap number = 12
panic: page fault
syncing disks, buffers remaining... panic: bremfree: removing a buffer not
on a queue
Uptime: 14d17h59m7s
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x24
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04fa06c
stack pointer = 0x10:0xe1adabec
frame pointer = 0x10:0xe1adabfc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= resume, IOPL = 0
current process = 3 (g_up)
trap number = 12
panic: page fault
Uptime: 14d17h59m7s
Dumping 1022 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320
336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624
640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928
944 960 976 992 1008
---
Reading symbols from
/usr/obj/usr/src/sys/HERCULES/modules/usr/src/sys/modules/acpi/acpi.ko.debug
...done.
Loaded symbols for
/usr/obj/usr/src/sys/HERCULES/modules/usr/src/sys/modules/acpi/acpi.ko.debug
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc04da545 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc04da849 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0515af7 in bremfreel (bp=0xd2d00800) at
/usr/src/sys/kern/vfs_bio.c:647
#4 0xc0515a24 in bremfree (bp=0xd2d00800) at
/usr/src/sys/kern/vfs_bio.c:629
#5 0xc051953c in getblk (vp=0xc68c330c, blkno=2, size=16384, slpflag=0,
slptimeo=0, flags=0)
at /usr/src/sys/kern/vfs_bio.c:2468
#6 0xc0515b79 in breadn (vp=0xc68c330c, blkno=2, size=16384, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0)
at /usr/src/sys/kern/vfs_bio.c:700
#7 0xc0515b44 in bread (vp=0xc68c330c, blkno=2, size=16384, cred=0x0,
bpp=0xe00c2848)
at /usr/src/sys/kern/vfs_bio.c:682
#8 0xc05b642b in ffs_balloc_ufs2 (vp=0xc68c330c, startoffset=0, size=3872,
cred=0xc25b7d80, flags=65536,
bpp=0xe00c2994) at /usr/src/sys/ufs/ffs/ffs_balloc.c:601
#9 0xc05ca3ca in ffs_write (ap=0xe00c29bc) at
/usr/src/sys/ufs/ffs/ffs_vnops.c:698
#10 0xc05d2a98 in dqsync (vp=0xc6e7ab2c, dq=0xc6f26f40) at vnode_if.h:432
#11 0xc05d2477 in qsync (mp=0xc655e400) at
/usr/src/sys/ufs/ufs/ufs_quota.c:775
#12 0xc05c8e90 in ffs_sync (mp=0xc655e400, waitfor=2, cred=0xc25aae80,
td=0xc06a17c0)
at /usr/src/sys/ufs/ffs/ffs_vfsops.c:1204
#13 0xc052a137 in sync (td=0xc06a17c0, uap=0x0) at
/usr/src/sys/kern/vfs_syscalls.c:141
#14 0xc04da0c8 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:281
#15 0xc04da849 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#16 0xc061ac42 in trap_fatal (frame=0xe00c2ba8, eva=83) at
/usr/src/sys/i386/i386/trap.c:821
#17 0xc061a983 in trap_pfault (frame=0xe00c2ba8, usermode=0, eva=83) at
/usr/src/sys/i386/i386/trap.c:735
#18 0xc061a5a1 in trap (frame=
{tf_fs = 24, tf_es = -536084464, tf_ds = -1067319280, tf_edi = 3531,
tf_esi = 0, tf_ebp = -536073240, tf_isp = -536073260, tf_ebx = -738407384,
tf_edx = 0, tf_ecx = 0, tf_eax = -738410444, tf_trapno = 12, tf_err = 2,
tf_eip = -1067685801, tf_cs = 8, tf_eflags = 66178, tf_esp = -536073116,
tf_ss = -1067762932})
at /usr/src/sys/i386/i386/trap.c:420
#19 0xc060df38 in calltrap () at {standard input}:94
#20 0xc05b3b0c in ffs_blkfree (fs=0xc676c800, devvp=0xc67d0c30,
bno=23149179, size=2048, inum=3531)
at /usr/src/sys/ufs/ffs/ffs_alloc.c:1760
---Type to continue, or q to quit---
#21 0xc05c0057 in handle_workitem_freefrag (freefrag=0xcaabcf40) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:1587
#22 0xc05bf007 in process_worklist_item (matchmnt=0x0, flags=0) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:767
#23 0xc05bed6c in softdep_process_worklist (matchmnt=0x0) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:622
#24 0xc0526bf1 in sched_sync () at /usr/src/sys/kern/vfs_subr.c:1766
#25 0xc04c8581 in fork_exit (callout=0xc0526864 , arg=0x0,
frame=0xe00c2d48)
at /usr/src/sys/kern/kern_fork.c:793
Fatal trap 12: page fault while in kernel mo
Re: ATAPI DVDwriters (not) to buy?
On Tue, Aug 10, 2004 at 04:08:48PM +0200, Søren Schmidt wrote: > > > >I used in past your cdrecord version when it was available on your site. > >Is there any new version freely available? :) > > They are still at my site actually, butI havn't cared to update them > much (dont fix what aint broken)... > [...] It seems ftp.freebsd.dk does not accept passive mode :(( Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
Marc Fonvieille wrote: On Tue, Aug 10, 2004 at 03:44:03PM +0200, Søren Schmidt wrote: You meant a growisofs version that does not require ATAPICAM? Yes, one that uses the ATA userland interface instead, just as I have versions of cdrecord/cdrdao. I used in past your cdrecord version when it was available on your site. Is there any new version freely available? :) They are still at my site actually, butI havn't cared to update them much (dont fix what aint broken)... Maybe it's difficult to maintain, I don't know, but what about having an ATA cdrecord or cdrdao port in our Ports Collection? By all means, feel free to grap those off my site and "portify" them.. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
On Tue, Aug 10, 2004 at 03:44:03PM +0200, Søren Schmidt wrote: > > > >You meant a growisofs version that does not require ATAPICAM? > > Yes, one that uses the ATA userland interface instead, just as I have > versions of cdrecord/cdrdao. > I used in past your cdrecord version when it was available on your site. Is there any new version freely available? :) Maybe it's difficult to maintain, I don't know, but what about having an ATA cdrecord or cdrdao port in our Ports Collection? Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
Marc Fonvieille wrote: On Tue, Aug 10, 2004 at 03:11:50PM +0200, Søren Schmidt wrote: I used my own creation that at some point could replace burncd, but for now it is just a skunkworks project (and no I wont hand out copies :) ) I would think that growisofs will work (I do have an ATA version of that somewhere IIRC). You meant a growisofs version that does not require ATAPICAM? Yes, one that uses the ATA userland interface instead, just as I have versions of cdrecord/cdrdao. (Currently growisofs+ATAPICAM work like a charm) I wouldn't know :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Using the VIA 8237 ATA133 IDE ports
Dear Sirs: Using FreeBSD 4.9R-p3, I cannot use the VIA 8237 ATA133 IDE ports: > /var/log/dmesg.today:atapci1: port > 0xfc00-0xfc0f at device 15.1 on pci0 > /var/log/dmesg.today:ata0: at 0x1f0 irq 14 on atapci1 > /var/log/dmesg.today:ata1: at 0x170 irq 15 on atapci1 I saw 8.10, however, *does* support the VIA 8237. Is there a way I can just upgrade the ata driver, without going all the way to 8.10? I really cannot continue with using WDMA2 on 16 MB/s. I am not sure whether it is at all possible to upgrade the ata(4) driver in this fashion. If it is a matter of recompiling the kernel, I can do that. I am sorry if this sounds like a stupid question. But I have searched the FreeBSD site and Google; but I cannot find anything which deals with upgrading the ata(4) drivers. I appreciate the help, - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
On Tue, Aug 10, 2004 at 03:11:50PM +0200, Søren Schmidt wrote: > > I used my own creation that at some point could replace burncd, but for > now it is just a skunkworks project (and no I wont hand out copies :) ) > > I would think that growisofs will work (I do have an ATA version of that > somewhere IIRC). > You meant a growisofs version that does not require ATAPICAM? (Currently growisofs+ATAPICAM work like a charm) > Burncd support DVD+R to some extent, depends on burner doing what I > think it should. But as you might infer from the above I'm thinking of > changing that :) > great! Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
Marc Fonvieille wrote: On Mon, Aug 09, 2004 at 10:29:35PM +0200, Søren Schmidt wrote: Wilko Bulte wrote: How standard are DVD writers these days? In the sense of: can I expect an ATAPI DVDwriter to 'just work' with FreeBSD or are there brands/models to avoid or to prefer? Any experiences with a NEC ND-2510 ? Good/bad? Bought one of those a couble of weeks ago, it has burnt CDR, CDRW, DVD+/-R and DVD+/-RW media for me with no problems at all. Havn't tried duallayer media yet as I havn't been able to locate any that didn't cost an arm and a leg :) Did you use growisofs or a new burncd allowing DVD+/-R burning? Have you any plan on supporting DVD+/-R write with burncd? I used my own creation that at some point could replace burncd, but for now it is just a skunkworks project (and no I wont hand out copies :) ) I would think that growisofs will work (I do have an ATA version of that somewhere IIRC). Burncd support DVD+R to some extent, depends on burner doing what I think it should. But as you might infer from the above I'm thinking of changing that :) -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI DVDwriters (not) to buy?
On Mon, Aug 09, 2004 at 10:29:35PM +0200, Søren Schmidt wrote: > Wilko Bulte wrote: > >How standard are DVD writers these days? In the sense > >of: can I expect an ATAPI DVDwriter to 'just work' > >with FreeBSD or are there brands/models to avoid or > >to prefer? > > > >Any experiences with a NEC ND-2510 ? Good/bad? > > Bought one of those a couble of weeks ago, it has burnt CDR, CDRW, > DVD+/-R and DVD+/-RW media for me with no problems at all. Havn't tried > duallayer media yet as I havn't been able to locate any that didn't cost > an arm and a leg :) [...] Did you use growisofs or a new burncd allowing DVD+/-R burning? Have you any plan on supporting DVD+/-R write with burncd? Marc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to logically disable memory
> > Danny Braniss wrote: > > > hi, > > > is there an 'easy' way to mark some memory as unusable? > > > thanks, > > > danny > > > > You'll hopefully get a better answer than mine, but in case you don't > > & need to start hacking code ... > > > > Way back on 2.2.8 I disabled all above 16M 'cos one certain manufacturers > > mboard failed to cache & board went slower with more ram ! > > > > Can't remember much now, & doubtless patch doesnt apply now (& that > > 486 board not in service regularly) but it might give a clue where > > to look, looking at > > > > http://berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/sys/i386/i386/machdep > .c.maxmem.diff.ignore > > > > back then it seemed to be MAXMEM in sys/i386/i386/machdep.c > > Hi, > The short version: I need to disable 'some' physical memory, it's bad, > and so far can't find it to change it :-). > > The long version: this is an IBM Thinkpad X40, quiet new, that > lost it's warranty because somehow 'some liquid' was spilled on the keyboard. > It seems to have some 512M of memory on the motherboard, which after an > almost total dissasembly could not find. Windows crashes too often, but > FreeBSD is doing fine. So if i can just disable parts of it (memtest has > found the bad memory) then this is a neat notebook. > > danny Is the low boundary of what memtest shows, too low to sacrifice all above by patching out all above ? It would get you up & stable, with low performance. If after that you don't find an answer on hackers, probably best contact author of the swapper, who probably reads current@, or whose name may be found in CVS. If desperate, You might want to offer some incentive, eg bottle of Whisky or whatever, to whoever will write you some custom hacks to the swapper to patch out one range permanently ? Good luck. - Julian Stacey. Unix C & Net Services Consultant, Munich. http://berklix.com Mail Ascii plain text. Html dumped as Spam. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Driver for Thinkpad Hotkeys.
Takanori Watanabe wrote: Hi, I updated ThinkPad Hotkey driver so that it can * Read Brightness * Read Volume * Read Mute status * Read Keylight status * AccessIBM, Zoom Screen(Fn+Sp) toggle. ToDo lists * Set Brightness * Set Volume * Bluetooth attach/detach. * Userland worker. These features will come Real Soon Now. * Wireless LAN indicator Will be take more time. I wrote for ThinkPad X31, but it may work on some other ThinkPad X,R,T,S series. Enjoy! http://www.init-main.com/acpi_tpkey/ Thanks for working on this. After 5.3-RELEASE, I think it would be good to import it. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network interface RUNNING and UP flags
Ah yes, now I see. There is no mutex on struct ifnet then? And I suppose
those splimp/splx calls should remain. I'll look at whats available and
relay my findings to you guys.
On Mon, 2004-08-09 at 17:14, Maksim Yevmenkin wrote:
> Hello,
>
> > Here, I pushed that section of code up before the prior
> > mtx_unlock(&tp->tap_mtx) above it, then removed the splimp/splx
> > calls. Is this what you were referring to (attached)? Also, I noticed
> > splx and splimp are called in a number of other places in this
> > driver, even under -CURRENT. You want those out too? The patch is a
> > patch on the original -CURRENT version of the driver and not a patch
> > to the previous patch I received.
>
> ok, the "tap_mtx" lock is used to protect fields which belongs to the
> "struct tap_softc". the IFF_xxx flags are set in the "if_flags" field,
> which belongs to the "struct ifnet". note that other parts of the system
> will access the same "struct ifnet", and, thus separate lock is required
> to protect all fields inside the "struct ifnet". currently it is done
> (or rather not done) with splimp(9)/splx(9) calls. i guess this will be
> fixed some time in the future.
>
> my original patch was not 100% correct. i have attached better (imo)
> patch. please try it out, and, if there are no objections, i will commit it.
>
> thanks,
> max
>
>
> __
> --- if_tap.c.orig Fri Aug 6 15:02:06 2004
> +++ if_tap.c Mon Aug 9 13:57:48 2004
> @@ -340,7 +340,8 @@
> struct thread *td;
> {
> struct tap_softc*tp = NULL;
> - int error;
> + struct ifnet*ifp = NULL;
> + int error, s;
>
> if ((error = suser(td)) != 0)
> return (error);
> @@ -368,10 +369,15 @@
> bcopy(tp->arpcom.ac_enaddr, tp->ether_addr, sizeof(tp->ether_addr));
> tp->tap_pid = td->td_proc->p_pid;
> tp->tap_flags |= TAP_OPEN;
> + ifp = &tp->tap_if;
> mtx_unlock(&tp->tap_mtx);
>
> - TAPDEBUG("%s is open. minor = %#x\n",
> - tp->tap_if.if_xname, minor(dev));
> + s = splimp();
> + ifp->if_flags |= IFF_RUNNING;
> + ifp->if_flags &= ~IFF_OACTIVE;
> + splx(s);
> +
> + TAPDEBUG("%s is open. minor = %#x\n", ifp->if_xname, minor(dev));
>
> return (0);
> } /* tapopen */
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network interface RUNNING and UP flags
Here, I pushed that section of code up before the prior
mtx_unlock(&tp->tap_mtx) above it, then removed the splimp/splx calls.
Is this what you were referring to (attached)? Also, I noticed splx and
splimp are called in a number of other places in this driver, even under
-CURRENT. You want those out too? The patch is a patch on the original
-CURRENT version of the driver and not a patch to the previous patch I
received.
--
coleman kane
On Sat, 2004-08-07 at 05:23, Yar Tikhiy wrote:
> On Sat, Aug 07, 2004 at 10:06:17AM +0300, Alex Lyashkov wrote:
> >
> > not better move this under tp->tap_mtx mutex without using splX
> > functions?
>
> ...especially taking into account that splX do nothing
> in CURRENT anyway. Mutex locking framework adopted by
> the interface driver should be used of course.
--- if_tap.c.orig Thu Jun 24 13:16:35 2004
+++ if_tap.c Mon Aug 9 16:42:40 2004
@@ -368,6 +368,12 @@
bcopy(tp->arpcom.ac_enaddr, tp->ether_addr, sizeof(tp->ether_addr));
tp->tap_pid = td->td_proc->p_pid;
tp->tap_flags |= TAP_OPEN;
+
+/* Set the interface to RUNNING state while the device is
+ opened
+ */
+ tp->tap_if.if_flags |= IFF_RUNNING;
+ tp->tap_if.if_flags &= ~IFF_OACTIVE;
mtx_unlock(&tp->tap_mtx);
TAPDEBUG("%s is open. minor = %#x\n",
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network interface RUNNING and UP flags
Seems to work in both -RELEASE and -CURRENT, though I needed to manually apply the patch as line numbers were off in -RELEASE. I can see how the locking could become a problem in -CURRENT. On Sat, 2004-08-07 at 05:23, Yar Tikhiy wrote: > On Sat, Aug 07, 2004 at 10:06:17AM +0300, Alex Lyashkov wrote: > > > > not better move this under tp->tap_mtx mutex without using splX > > functions? > > ...especially taking into account that splX do nothing > in CURRENT anyway. Mutex locking framework adopted by > the interface driver should be used of course. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Kernel Development
Yeah, this page: http://people.freebsd.org/~phk/TODO/ was one that I looked at and wasn't sure what the status was on the projects that were listed. One in particular was the PCI device driver library item. Does anyone know the status on this? I would like to pick this up if it is still open. Thanks. ed -Original Message- From: Daniel O'Connor [mailto:[EMAIL PROTECTED] Sent: Saturday, August 07, 2004 9:25 AM To: [EMAIL PROTECTED] Cc: Smith III, Edward Mr. CAA/ISC Subject: Re: Kernel Development -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 6 Aug 2004 23:57, Smith III, Edward Mr. CAA/ISC wrote: > Hey- > I am an experienced developer and have been using FreeBSD for several years > now. I am looking to get involved in FreeBSD system development and was > wondering if there were any projects that need developers. I have been > programming for years but am somewhat new to the BSD kernel. I found some > project pages on the websites but almost all of them are out of date. The > hardware that I have on hand currently is all x86 with no exotic > peripherals although I am hoping to get an alpha and/or a sparc by the end > of the year. Any help on this would be appreciated. v/r Not sure which pae you went to, but perhaps this one may help you -> http://people.freebsd.org/~phk/TODO/ Hmm although it looks 12 months old :( Certainly something _I'd_ appreciate would be to robustify the USB code :) - -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBFNhO5ZPcIHs/zowRAs0xAJ0UhRXoFlZIff3aePFyRzBUsPdxuQCfQgt5 q2LJMFVilmHHFlthbTC3HHI= =H00c -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to logically disable memory
* Danny Braniss <[EMAIL PROTECTED]> [20040809 11:42]: > is there an 'easy' way to mark some memory as unusable? thanks, Linux has BadRAM: http://rick.vanrein.org/linux/badram/index.html, I think someone was thinking of porting it to FreeBSD... (or maybe it was you ;) qvb -- pica ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
