Re: Is there any modern alternative to pstack?
On Saturday, March 31, 2012 3:41:41 pm Yuri wrote: I look at seemingly abandoned sysutils/pstack, last modified upstream 2002-11-27. It doesn't really work on 9.0 i386, prints some errors. It's functions, though, is quite desirable if one wants to understand why some multithreaded program hangs or is not responsive. Since there were no updates, I wonder, is this because there is some alternative in FreeBSD that I don't know about, or it is primarily due to the lack of interest/resources? I don't take gdb as alternative since it is not single line, and also it has some threading issues of its own. Hmm, I don't know if the port has it, but I did some work on pstack a while ago to make it work with libthread_db so it at least handles i386 ok. It needs to be modified to use something like libunwind though or some other unwinder. And possibly it should use libelf instead of its own ELF-parsing code. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Approaching the limit on PV entries
On Thursday, March 22, 2012 1:48:29 pm Mark Saad wrote: On Thu, Mar 22, 2012 at 8:03 AM, John Baldwin j...@freebsd.org wrote: On Wednesday, March 21, 2012 4:20:17 pm Mark Saad wrote: On Wed, Mar 21, 2012 at 12:39 PM, Sergey Kandaurov pluk...@gmail.com wrote: On 21 March 2012 19:19, John Baldwin j...@freebsd.org wrote: On Tuesday, March 20, 2012 11:37:57 am Sergey Kandaurov wrote: On 22 November 2011 19:29, Mark Saad nones...@longcount.org wrote: Hello All [found this mail in my drafts, not sure if my answer is still useful] I want to get to the bottom of a warning in dmesg. On 7.2-RELEASE and 7.3-RELEASE I have seen the following warning in dmesg. Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. So looking around I see a few posts here and there about how to tune the sysctls to address the warning however I am not 100% sure what each value does. It appears changing vm.pmap.shpgperproc affects the value of vm.pmap.pv_entry_max . Can someone explain the relationship of the two sysctls. Also This is how they are calculated. pv_entry_max = shpgperproc * maxproc + cnt.v_page_count; and, respectively, shpgperproc = (pv_entry_max - cnt.v_page_count) / maxproc; So, changing one sysctl will change another and vice versa. what pitfalls of changing them are. Not known to me (on amd64 platform). I have had vm.pmap.shpgperproc=15000 on 8.1 amd64 with 4G RAM to make some badly written commercial software to work until it was decommissioned to the scrap. FYI, Alan just removed this warning and the associated sysctls from HEAD yesterday because they were made obsolete several years ago. I think they are obsolete even on 7. Certainly on 8. Yep, and since switching to direct map (somewhere around 7.x on amd64?) made PV entry limit factually obsolete, this is really cool. -- wbr, pluknet Interesting so this warning is relevant in 7.x ? No, looks like it was obsolete starting with 7.0. -- John Baldwin Any chance it could be mfc'ed to 7-STABLE ? I just merged it to stable/7. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is there any modern alternative to pstack?
On 04/02/2012 05:31, John Baldwin wrote: Hmm, I don't know if the port has it, but I did some work on pstack a while ago to make it work with libthread_db so it at least handles i386 ok. It needs to be modified to use something like libunwind though or some other unwinder. And possibly it should use libelf instead of its own ELF-parsing code. I see pstack -1.2_1 failing even on i386: pstack: cannot read context for thread 0x1879f pstack: failed to read more threads 1947: /usr/local/share/chromium/chrome - thread 100255 - 0x1879f () - thread -1 (running) - 0x389f1df9 __sys_recvmsg (3, bfbfcd44, 0, bfbfcd68, 0, c) + 5 0x97850b4 _init (3, bfbfcdc8, 800, bfbfdc20, bfbfdc4c, bfbfdc40) + 15c7c1c 0xa8089d0 _init (bfbfe074, 3, 0, bfbfe0c4, 20, bfbfdca0) + 264b538 0xa8094d7 _init (bfbfe44c, 0, bfbfe108, 37a85517, 37aa7680, 38fbf400) + 264c03f 0x8e7ec02 _init (bfbfe44c, bfbfe4a0, 3c, 0, 0, 0) + cc176a 0x8e7f102 _init (bfbfe468, bfbfe44c, bfbfe4a0, 37a9f4b4, 37aa5d40, 1) + cc1c6a 0x8e7f471 _init (2, bfbfe540, bfbfe4a0, 88f9c28, bd4dce8, bd4de88) + cc1fd9 0x81c64ab _init (2, bfbfe540, bfbfe4e8, af61795, bfbfe500, bfbfe540) + 9013 0x81c6452 _init (0, 0, bfbfe518, 81c63a7, 2, bfbfe540) + 8fba 0x81c63a7 _init (3791afd0, 2, bfbfe540, 0, 0, 0) + 8f0f 0x81c6318 _init (bfbfe6d0, bfbfe6f1, 0, bfbfe6ff, bfbfe762, bfbfe7b8) + 8e80 Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Upgrading FreeBSD
Basically it consists of (re)compilation and installation of world + kernel However, 2 parts are always ommited: Stage 1 - mbr|boot0 Stage 2 - boot I won't also mention GPT part ... Stage 3 - loader (is covered by world install) Should it be expanded to world + kernel + bootcodes The old way, one could pull it's old bootcodes, from 6.0 to 10.0 world + kernel And bootcodes are changing. I've got bitten by bug in stage 2 boot, during 8.2 - 9.0. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Is there any modern alternative to pstack?
On Monday, April 02, 2012 12:39:26 pm Yuri wrote: On 04/02/2012 05:31, John Baldwin wrote: Hmm, I don't know if the port has it, but I did some work on pstack a while ago to make it work with libthread_db so it at least handles i386 ok. It needs to be modified to use something like libunwind though or some other unwinder. And possibly it should use libelf instead of its own ELF-parsing code. I see pstack -1.2_1 failing even on i386: pstack: cannot read context for thread 0x1879f pstack: failed to read more threads Yes, threads don't work for modern binaries (newer than 4.x) without my changes to make it use libthread_db. You can find the patch I used for this at http://www.freebsd.org/~jhb/patches/pstack_threads.patch -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
CAM disk I/O starvation
Hello list, I am convinced that there is a bug in the CAM code that leads to I/O starvation. I have already discussed this privately with some. I am now bringing this up to the general audience to get more feedback. My setup is that I have 1 RAID controller with 2 arrays connected to it, da0 and da1. The controller supports 252 tags. After boot up, camcontrol tags on da0 and da1 shows that both devices have 252 openings each. A process P0 writing on da0 is dormant most of the time, but would wake up with burst of I/Os, 5000-6000 ops as reported by gstat. A process P1 writing on da1 has a fixed data rate to da1 as reported by gstat. The issue: When P0 generates that burst of 5000-6000 ops, the write rate of P1 on da1 goes to 0 MB/sec for up to 8-9sec, vfs.hirunningspace starts climbing and we get into waithirunning() or getblk() sleep channel. BTW, raising hirunningspace has no effect on the 0 MB/s behavior. The first problem that I see here, is that if the sim's devq has 252 alloc_queue and send_queue, the struct cam_ed representing da0 and da1 should each have 126 openings and not 252. The second problem is that clearly, there is no I/O fairness in CAM as seen in gstat output and da0 exclusively takes a hold of the sim/controller until it has processed all it's I/Os (8-9 seconds). The code that does this is at cam/cam_xpt.c:3030 3030 (devq-alloc_openings 0) and cam/cam_xpt.c:3091 3091 (devq-send_openings 0) After you've split the openings to 126 each, the tests above will always be true I have a patch and it fixes those problems. I can share it to the list if requested to. da0 and da1 now both automatically get 126 openings and based on that, extra logic implements fairness in cam/cam_xpt.c. No more 0 MB/s on da1. This is on 8.1-RELEASE FreeBSD. Any comments welcome. Thanks, Jerry ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 03/30/2012 07:41, Joe Greco wrote: On 3/29/2012 7:01 AM, Joe Greco wrote: On 3/28/2012 1:59 PM, Mark Felder wrote: FreeBSD 8-STABLE, 8.3, and 9.0 are untested As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. Doug So you're saying that he should have been using 8.3-RELEASE, then. That isn't what I said at all, sorry if I wasn't clear. The OP mentioned 9.0-RELEASE, and in the context of his message (which I snipped) he mentioned 8-stable. That's what I was referring to. And since both the poster and I made it clear that this doesn't seem to be a case of it fails reliably on a machine of your choosing, just installing random other versions and hoping that it's going to cause a fail ... well, let's just say that doesn't make a whole lot of sense. Or at least it's a recipe for a hell of a lot of busywork, busywork not guaranteed to return any sort of useful result. And since you can't reliably reproduce the problem, how do you expect us to? I understand that these sorts of bugs are difficult/annoying, etc. Been there, done that. In the meantime, it's unrealistic to tell people to use supported releases, to wait fifteen months between releases, and then to criticize people complaining about problems with a supported release for using old code. Just to be clear, I didn't criticize anyone. And I share your frustration with the length of the 8.3 release cycle. I really wish I had a better answer, but as much as you and I may wish that things were different, Try a newer version is the best answer we have atm. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 03/30/2012 07:41, Joe Greco wrote: On 3/29/2012 7:01 AM, Joe Greco wrote: On 3/28/2012 1:59 PM, Mark Felder wrote: FreeBSD 8-STABLE, 8.3, and 9.0 are untested As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. Doug So you're saying that he should have been using 8.3-RELEASE, then. That isn't what I said at all, sorry if I wasn't clear. The OP mentioned 9.0-RELEASE, and in the context of his message (which I snipped) he mentioned 8-stable. That's what I was referring to. And since both the poster and I made it clear that this doesn't seem to be a case of it fails reliably on a machine of your choosing, just installing random other versions and hoping that it's going to cause a fail ... well, let's just say that doesn't make a whole lot of sense. Or at least it's a recipe for a hell of a lot of busywork, busywork not guaranteed to return any sort of useful result. And since you can't reliably reproduce the problem, how do you expect us to? I understand that these sorts of bugs are difficult/annoying, etc. Been there, done that. Nobody expected you to. We're trying to figure out any commonalities that might exist; these may serve to help shed light on where the problem lies. The interesting thing is that I took it and looked at it and came to a conclusion that might have been wrong, though I think the trail of reasoning I used was itself reasonable, given my exceedingly small (one example of problem) sample size. Mark's able to actually *reproduce* the problem on separate installs and with circumstances that are at least somewhat different than what my theory involved, though it is not quite possible to rule out some sort of corruption. Since I have to *assume* that many sites run some sort of FreeBSD on their VMware gear, given that VMware actually lists it as a supported version and VMware generally does things for profit, I am still kind of of the opinion that this is some sort of corruption bug, one that I triggered inadvertently, but one that Mark's environment reproduces rather more frequently. That just seems so unlikely, but more unlikely things have come to pass, so I'm holding onto it as my working theory ;-) I still plan to try to recover my broken VM from backups at some point if time permits. But in short, to answer your question: I don't *care* if you can reproduce the problem. As a user, you can't win. If you don't report a problem, you get criticized. If you report a problem but can't figure out how to reproduce it, you get criticized. If you can reproduce it but you don't submit a workaround, you get criticized. If you submit a workaround but you don't submit a patch, you get criticized. If you submit a patch but it's not in the preferred format, you get criticized. Hm. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: __NR_mmap2 in FreeBSD
On Saturday, March 31, 2012 5:40:50 pm Maninya M wrote:
Thanks.
I've tried this. Still getting some allocation problems.
if (temp_regs.r_eax != addr)
warn(Wanted space at address 0x%.8x, mmap2 system call returned
0x%.8x. This could be a problem.,addr,temp_regs.r_eax);
What can I do? Please help.
Hmm, can you capture a ktrace of the target process during this so you can see
if the kernel sees the mmap request properly?
void map_memory(unsigned long addr, unsigned long size, int flags)
{
int status;
struct reg regs,temp_regs;
unsigned long int_instr = 0x80cd; /* INT 0x80 */
printf(%x\n,addr);
//addr=addr0x;
if (ptrace(PT_GETREGS,exec_pid,(caddr_t)regs,0) 0)
die_perror(ptrace(PTRACE_GETREGS,%d,(caddr_t)regs,0),exec_pid);
/* mmap2 system call seems to take arguments as follows:
* eax = __NR_mmap2
* ebx = (unsigned long) page aligned address
* ecx = (unsigned long) page aligned file size
* edx = protection
* esi = flags
* Other arguments (fd and pgoff) are not required for anonymous mapping
*/
temp_regs = regs;
//printf(temp=%u,
\teip=%u\tregs=%u\teip=%u\n,temp_regs,temp_regs.r_eip,regs,regs.r_eip);
// temp_regs.r_eax = __NR_mmap2;
temp_regs.r_eax=71;
/*temp_regs.r_ebx = addr;
temp_regs.r_ecx = size;
temp_regs.r_edx = flags;
temp_regs.r_esi = MAP_PRIVATE | MAP_ANONYMOUS;*/
//push size
//temp_regs.r_eip = temp_regs.r_esp - 4;
//printf(temp=%u,
\teip=%u\tregs=%u\teip=%u\n,temp_regs,temp_regs.r_eip,regs,regs.r_eip);
if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-4),addr) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed
ADDER,exec_pid,temp_regs.r_esp,addr);
if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-8),size) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed
size,exec_pid,temp_regs.r_esp);
if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-12),flags) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed
protections,exec_pid,temp_regs.r_esp);
if (ptrace(PT_WRITE_D,exec_pid,(void
*)(temp_regs.r_esp-16),MAP_PRIVATE|MAP_ANON|MAP_FIXED) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed
flags,exec_pid,temp_regs.r_esp);
if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-20),-1) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed
ADDER,exec_pid,temp_regs.r_esp,addr);
if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-24),0) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed
offset1,exec_pid,temp_regs.r_esp,addr);
if (ptrace(PT_WRITE_D,exec_pid,(void *)(temp_regs.r_esp-28),0) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,0x%.8x) failed
offset1,exec_pid,temp_regs.r_esp,addr);
/*
if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x80cd) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while allocating
memory,exec_pid,temp_regs.r_eip);
*/
if (ptrace(PT_WRITE_I,exec_pid,(void *)(temp_regs.r_eip),0x80cd) 0)
die_perror(ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while allocating
memory,exec_pid,temp_regs.r_eip);
//temp_regs.r_eip = temp_regs.r_esp - 32;
temp_regs.r_esp = temp_regs.r_esp - 28;
if (ptrace(PT_SETREGS,exec_pid,(caddr_t)temp_regs,0) 0) {
die_perror(ptrace(PT_SETREGS,%d,...) failed while allocating
memory,exec_pid);
}
if (ptrace(PT_STEP,exec_pid,NULL,0) 0)
die_perror(ptrace(PT_STEP,...) failed while executing mmap2);
wait(status);
if (WIFEXITED(status))
die(Restarted process abrubtly (exited with value %d). Aborting
Restart.,WEXITSTATUS(status));
else if (WIFSIGNALED(status))
die(Restarted process abrubtly exited because of uncaught signal (%d).
Aborting Restart.,WTERMSIG(status));
if (ptrace(PT_GETREGS,exec_pid,(caddr_t)temp_regs,0) 0) {
die_perror(ptrace(PT_GETREGS,...) failed after executing mmap2 system
call);
}
//fprintf(stdout,hello iam here \n);
if (temp_regs.r_eax != addr)
warn(Wanted space at address 0x%.8x, mmap2 system call returned
0x%.8x. This could be a problem.,addr,temp_regs.r_eax);
else if (cr_options.verbose)
fprintf(stdout,Successfully allocated [0x%.8lx -
0x%.8lx]\n,addr,addr+size);
/* Restore original registers */
if (ptrace(PT_SETREGS,exec_pid,(caddr_t)temp_regs,0) 0) {
die_perror(ptrace(PT_SETREGS,...) when restoring registering after
allocating memory (mmap2));
}
}
On 29 March 2012 19:14, John Baldwin j...@freebsd.org wrote:
On Thursday, March 29, 2012 9:15:43 am Maninya M wrote:
Thanks a lot for replying!
Ok I've tried this to push arguments onto stack.
Is it right?
I get an error at this line:
die_perror(ptrace(PT_WRITE,%d,0x%.8x,INT 0x80) failed while
dasfallocating memory,exec_pid,temp_regs.r_eip);
Please tell me what to do.
void map_memory(unsigned long addr, unsigned long size, int flags)
{
int status;
struct reg
GSoC: EFI on intel
I'm assessing possible summer of code projects, and the EFI work caught my attention. I've been running FreeBSD on a macbook for a little under a year now, and booting on EFI is definitely an interest to me. Does anyone know if this is still a viable project proposal? I certainly have the skills to undertake it, I just want to make sure that it stands a chance of actually being selected. signature.asc Description: OpenPGP digital signature
Re: Approaching the limit on PV entries
On Mon, Apr 2, 2012 at 11:23 AM, John Baldwin j...@freebsd.org wrote: On Thursday, March 22, 2012 1:48:29 pm Mark Saad wrote: On Thu, Mar 22, 2012 at 8:03 AM, John Baldwin j...@freebsd.org wrote: On Wednesday, March 21, 2012 4:20:17 pm Mark Saad wrote: On Wed, Mar 21, 2012 at 12:39 PM, Sergey Kandaurov pluk...@gmail.com wrote: On 21 March 2012 19:19, John Baldwin j...@freebsd.org wrote: On Tuesday, March 20, 2012 11:37:57 am Sergey Kandaurov wrote: On 22 November 2011 19:29, Mark Saad nones...@longcount.org wrote: Hello All [found this mail in my drafts, not sure if my answer is still useful] I want to get to the bottom of a warning in dmesg. On 7.2-RELEASE and 7.3-RELEASE I have seen the following warning in dmesg. Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl. So looking around I see a few posts here and there about how to tune the sysctls to address the warning however I am not 100% sure what each value does. It appears changing vm.pmap.shpgperproc affects the value of vm.pmap.pv_entry_max . Can someone explain the relationship of the two sysctls. Also This is how they are calculated. pv_entry_max = shpgperproc * maxproc + cnt.v_page_count; and, respectively, shpgperproc = (pv_entry_max - cnt.v_page_count) / maxproc; So, changing one sysctl will change another and vice versa. what pitfalls of changing them are. Not known to me (on amd64 platform). I have had vm.pmap.shpgperproc=15000 on 8.1 amd64 with 4G RAM to make some badly written commercial software to work until it was decommissioned to the scrap. FYI, Alan just removed this warning and the associated sysctls from HEAD yesterday because they were made obsolete several years ago. I think they are obsolete even on 7. Certainly on 8. Yep, and since switching to direct map (somewhere around 7.x on amd64?) made PV entry limit factually obsolete, this is really cool. -- wbr, pluknet Interesting so this warning is relevant in 7.x ? No, looks like it was obsolete starting with 7.0. -- John Baldwin Any chance it could be mfc'ed to 7-STABLE ? I just merged it to stable/7. -- John Baldwin Thanks again john . -- mark saad | nones...@longcount.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 4/2/2012 11:43 AM, Joe Greco wrote: As a user, you can't win. If you don't report a problem, you get criticized. If you report a problem but can't figure out how to reproduce it, you get criticized. If you can reproduce it but you don't submit a workaround, you get criticized. If you submit a workaround but you don't submit a patch, you get criticized. If you submit a patch but it's not in the preferred format, you get criticized. I'm still not sure what you're taking as criticism. Nothing I've said was intended that way, nor should it be read that way. If you feel that you've been criticized by others in the manner you describe, you should probably take it up with them on an individual basis. My experience of FreeBSD as a community is that we tend to be both less critical of users, and less tolerant of it. Especially when compared to other communities that I've interacted with. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Please help me diagnose this crazy VMWare/FreeBSD 8.x crash
On 4/2/2012 11:43 AM, Joe Greco wrote: As a user, you can't win. If you don't report a problem, you get criticized. If you report a problem but can't figure out how to reproduce it, you get criticized. If you can reproduce it but you don't submit a workaround, you get criticized. If you submit a workaround but you don't submit a patch, you get criticized. If you submit a patch but it's not in the preferred format, you get criticized. I'm still not sure what you're taking as criticism. Nothing I've said was intended that way, nor should it be read that way. If you feel that you've been criticized by others in the manner you describe, you should probably take it up with them on an individual basis. It certainly seemed to me that As much as I'm sensitive to your production requirements, realistically it's not likely that you'll get a helpful result without testing a newer version. 8.2 came out over a year ago, many many things have changed since then. was an unwarranted criticism for reasons that I've already explained. Or perhaps this: And since you can't reliably reproduce the problem, how do you expect us to? I understand that these sorts of bugs are difficult/annoying, etc. Been there, done that. Which would appear to be suggesting that either (or possibly both): 1) The reporter has a duty to be able to reliably reproduce the problem prior to reporting, and/or 2) That there was some unreasonable expectation on the reporter's part that you were expected to reproduce it. I consider 1) to be ridiculous, as long as the reporter is reasonably willing to work to resolve the issue, that should certainly be good enough, and he's certainly been interactive enough to _my_ comments, and 2) seems to be nowhere in sight in the reporter's comments, but is nonetheless present in your response. Please respect Reply-to. Thanks. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Fwd: [gsoc2012] Port NetBSD's UDF implementation
cc hackers@ -- Forwarded message -- From: Yongcong Du ycdu.vmc...@gmail.com Date: Tue, Apr 3, 2012 at 1:23 AM Subject: [gsoc2012] Port NetBSD's UDF implementation To: a...@freebsd.org, netch...@freebsd.org Hi Andriy and Alexander, Firstly, let me introduce myself;) I'm a graduate student from Shanghai, timezone: GMT+8. I began to use FreeBSD and programing under it from 2009. 5 years experience in *nix posix C programing and 2 years experience in linux kernel programing. I have some experience in linux udf filesystem during one intern job -- add read_12 support which is similar as http://msdn.microsoft.com/en-us/library/windows/hardware/gg441227%28v=vs.85%29.aspx, but in an ugly hack way ;) and some hacks to improve the read performance. I want to take Port NetBSD's UDF implementation (GSoC) as my gsoc2012 project. Have anyone taken it?seems no according david_chi on freebsd-soc? I did some homework about this project: 1. the udf was implemeted in FreeBSD firstly then ported to NetBSD, the supported revisions is old. Then Reinoud Zandijk implemented most of UDF features and write support win latest udf revision in mind. 2. The work includes kernel (sys/fs/udf) source code and userland mount_udf. And can be completed by either sync the FreeBSD's implementation with NetBSD's or port NetBSD's from scratch. I like the second method. Any suggestions? 3. The difficulty of this project is how to resolve the lock, vm and vfs subsystem difference between NetBSD and FreeBSD. Would you please give some suggestions about it? Thanks in advance, Yongcong ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
