On Sat, 3 Apr 2010, Tijl Coosemans wrote:
Wikipedia's article on FAT has this to say about the maximum size of
clusters:
"The limit on partition size was dictated by the 8-bit signed count of
sectors per cluster, which had a maximum power-of-two value of 64. With
That seems unlikely. The MS-
on 03/04/2010 18:27 Andriy Gapon said the following:
> on 03/04/2010 18:07 Tijl Coosemans said the following:
>> I'm not sure the second paragraph is worth supporting, but the first
>> seems to say that 32k limit you have in your patch only applies to
>> disks with 512 byte sectors. For disks with
on 03/04/2010 18:07 Tijl Coosemans said the following:
>
> I'm not sure the second paragraph is worth supporting, but the first
> seems to say that 32k limit you have in your patch only applies to
> disks with 512 byte sectors. For disks with larger sectors it would
> be proportionally larger.
La
On Friday 02 April 2010 21:31:33 Andriy Gapon wrote:
> on 02/04/2010 22:26 Andriy Gapon said the following:
>> OK, I did it again.
>> I tested the below patch using the scenario described above.
>> Could you please review and/or test this patch?
>> If you like it and it works, I can commit it.
>> T
On 4/2/10, Andriy Gapon wrote:
> on 02/04/2010 22:26 Andriy Gapon said the following:
>>
>> OK, I did it again.
>> I tested the below patch using the scenario described above.
>> Could you please review and/or test this patch?
>> If you like it and it works, I can commit it.
>> Thanks!
>>
>> --- a
on 02/04/2010 22:26 Andriy Gapon said the following:
>
> OK, I did it again.
> I tested the below patch using the scenario described above.
> Could you please review and/or test this patch?
> If you like it and it works, I can commit it.
> Thanks!
>
> --- a/sbin/newfs_msdos/newfs_msdos.c
> +++ b/
on 02/04/2010 14:09 Andriy Gapon said the following:
> on 02/04/2010 13:57 Fabian Keil said the following:
>> Andriy Gapon wrote:
>>> Anyways, here is a patch that I would use.
>>> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too,
>>>
>>> --- a/sys/fs/msdosfs/msdosfs_vfsops.c
>
on 02/04/2010 13:57 Fabian Keil said the following:
> Andriy Gapon wrote:
>> Anyways, here is a patch that I would use.
>> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too,
>>
>> --- a/sys/fs/msdosfs/msdosfs_vfsops.c
>> +++ b/sys/fs/msdosfs/msdosfs_vfsops.c
>> @@ -580,6 +580,7
Andriy Gapon wrote:
> on 30/03/2010 18:41 Andriy Gapon said the following:
> > on 30/03/2010 18:36 Fabian Keil said the following:
> >> Andriy Gapon wrote:
> >>
> >>> on 29/03/2010 23:29 Fabian Keil said the following:
> Andriy Gapon wrote:
> > Thus, clearly, it is a fault of a tool th
on 30/03/2010 18:41 Andriy Gapon said the following:
> on 30/03/2010 18:36 Fabian Keil said the following:
>> Andriy Gapon wrote:
>>
>>> on 29/03/2010 23:29 Fabian Keil said the following:
Andriy Gapon wrote:
> Thus, clearly, it is a fault of a tool that formatted the media for FAT.
on 30/03/2010 18:36 Fabian Keil said the following:
> Andriy Gapon wrote:
>
>> on 29/03/2010 23:29 Fabian Keil said the following:
>>> Andriy Gapon wrote:
Thus, clearly, it is a fault of a tool that formatted the media for FAT.
It should have picked correct values, or rejected incorrec
Andriy Gapon wrote:
> on 29/03/2010 23:29 Fabian Keil said the following:
> > Andriy Gapon wrote:
> >> Thus, clearly, it is a fault of a tool that formatted the media for FAT.
> >> It should have picked correct values, or rejected incorrect values if
> >> those were provided as overrides via com
On Tue, Mar 30, 2010 at 10:40:07AM +1100, Bruce Evans wrote:
> On Mon, 29 Mar 2010, Andriy Gapon wrote:
>
> >...
> >I am not a FAT expert and I know to take Wikipedia with a grain of salt.
> >But please take a look at this:
> >http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector
> >
> >I
>
> BTW, why can't gdb find any variables? They are just stack variables whose
> address is easy to find.
>
> ...
>>>
>>> #14 0x8042f24e in bread (vp=Variable "vp" is not available.
>>> ) at /usr/src/sys/kern/vfs_bio.c:748
>>>
>>
> ... and isn't vp a variable? Maybe the bad default -O2 i
On Mon, 29 Mar 2010, Andriy Gapon wrote:
...
I am not a FAT expert and I know to take Wikipedia with a grain of salt.
But please take a look at this:
http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector
In our formula:
SecPerClust *= pmp->pm_BlkPerSec;
we have the following pa
on 29/03/2010 23:29 Fabian Keil said the following:
> Andriy Gapon wrote:
>> Thus, clearly, it is a fault of a tool that formatted the media for FAT.
>> It should have picked correct values, or rejected incorrect values if
>> those were provided as overrides via command line options.
>
> The kern
Andriy Gapon wrote:
> on 28/03/2010 18:25 Fabian Keil said the following:
> > Andriy Gapon wrote:
> >> Looking at the code in mountmsdosfs(), it seems that SecPerClust can
> >> have zero value at the place of the crash only if pm_BlkPerSec is
> >> zero. See this line and the check above it:
> >>
If you want to make sure that I see your reply please include me into recipient
list. FreeBSD mailing lists sometimes have high volume and it's easy to miss a
followup even if you are interested in reading it.
on 28/03/2010 18:25 Fabian Keil said the following:
> Andriy Gapon wrote:
>> Looking
Andriy Gapon wrote:
> on 19/03/2010 20:26 Paul B Mahol said the following:
> > On Fri, Mar 19, 2010 at 7:11 PM, Fabian Keil
> > wrote:
> >> Paul B Mahol wrote:
> >>
> >>> FreeBSD 9.0 CURRENT panics when mounting file system created via
> >>> newfs_msdos on DVD-RAM disc.
> >>> Something to do ab
on 19/03/2010 20:26 Paul B Mahol said the following:
> On Fri, Mar 19, 2010 at 7:11 PM, Fabian Keil
> wrote:
>> Paul B Mahol wrote:
>>
>>> FreeBSD 9.0 CURRENT panics when mounting file system created via
>>> newfs_msdos on DVD-RAM disc.
>>> Something to do about divide by zero.
>> I recently had
On Fri, Mar 19, 2010 at 7:11 PM, Fabian Keil
wrote:
> Paul B Mahol wrote:
>
>> FreeBSD 9.0 CURRENT panics when mounting file system created via
>> newfs_msdos on DVD-RAM disc.
>> Something to do about divide by zero.
>
> I recently had a similar problem with a 16GB iPod. I still haven't
> managed
Paul B Mahol wrote:
> FreeBSD 9.0 CURRENT panics when mounting file system created via
> newfs_msdos on DVD-RAM disc.
> Something to do about divide by zero.
I recently had a similar problem with a 16GB iPod. I still haven't
managed to actually mount it, but the patch below at least works
around
Hi,
FreeBSD 9.0 CURRENT panics when mounting file system created via
newfs_msdos on DVD-RAM disc.
Something to do about divide by zero.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe,
23 matches
Mail list logo
